Autodesk MCP servers differ in how they authenticate you and what access they require. Some require no authentication at all. Some ask you to sign in with your Autodesk account. Others are reached only through an Autodesk product that handles authentication for you.

This topic explains these models so you know what to expect before you connect. Because each server defines its own authentication, the exact flow, the client support required, and where access is managed are documented with that server. This topic describes the concepts; the server-specific documentation describes the procedure.

Why authentication varies

An MCP server authenticates you only to the extent its capabilities require:

• A server that exposes public information, or that runs locally on your own machine, may need no authentication.
• A server that accesses your Autodesk data must confirm who you are and what you are entitled to.

As a result, the authentication model reflects what the server does and where it runs. Whatever the model, the server remains responsible for validating each request, enforcing its execution boundaries, and acting only within the access you have. For more information, see About Autodesk MCP Servers.

Authentication models you may encounter

Autodesk MCP servers currently use one of three models. Check the server's documentation to confirm which one applies.

Model	Typically used by	What you do
No authentication	Local servers, and public remote servers	Nothing — you connect without signing in
Autodesk account sign-in	Cloud servers that access your Autodesk data	Sign in with your Autodesk account through your client
Host-managed	Servers reached through an Autodesk product	Sign in to the product; it handles authentication for you

No authentication

Some servers do not require you to sign in. This is typical of:

• Local servers that run on your own device. They communicate locally through inter-process communication (STDIO) or a loopback address, with no traffic routed over the network. Because the server runs on your machine and acts against your live application session, access is bounded by what is open on your machine rather than by a sign-in. Local servers are unauthenticated by design.
• Public remote servers that expose non-sensitive information over a public endpoint. These are typically read-only. However, a public server is not required to be read-only, because a provider could expose write operations without sign-in. Check the server's documented tools.

Even without authentication, the server still validates requests and enforces its defined boundaries.

Autodesk account sign-in

Cloud-hosted servers that access your Autodesk data require you to sign in with your Autodesk account. When you connect, your client prompts you to sign in through a built-in authentication flow. This flow follows the Model Context Protocol authorization specification and uses Client ID Metadata Documents (CIMD), the recommended method for client integrations. The server then acts within the access associated with your account.

Two things follow from this model:

• Your client must support the sign-in flow. Not every MCP client does. Currently Claude Desktop, Claude Code, ChatGPT, and VS Code support the CIMD sign-in flow. Cursor does not support it yet (planned, with no date announced), so use Cursor only with public servers that need no sign-in. Support for Dynamic Client Registration (DCR), which would broaden client compatibility, is planned.
• Access is bounded by your entitlements. What you can retrieve or do through the server is limited to the hubs, projects, databases, or operations your Autodesk account can already access. Some cloud servers are also region-specific, so you must use the endpoint for your region.

Host-managed authentication

Some servers are not connected directly at all. Instead, you use them through a supported Autodesk product experience, and that host application handles authentication on your behalf. You sign in to the Autodesk product as usual. The host obtains and exchanges the tokens the server requires, and you never configure MCP URLs or credentials yourself. Access depends on your account entitlements and, in some cases, on the server being available for your product, region, or license.

Authorization and access control

Authentication confirms who you are; authorization determines what you are allowed to do. A server may authenticate you successfully and still reject a request when the request:

• Exceeds your entitlements
• Is disabled by policy
• Is not available in the server's current mode

If a well-formed request is rejected, this is usually an authorization or policy decision rather than an authentication failure. See the authorization and policy guidance in Handling Unexpected Results.

Finding a server's authentication requirements

Because authentication is server-specific, always confirm the requirements before you connect. For each server, its documentation describes:

• Which model it uses, and whether authentication is required
• For account sign-in, which clients support the flow, and which endpoint or region to use
• For host-managed servers, which product experiences the server is available in
• How access maps to your account entitlements

Use this topic to understand the model, then follow the server's connection documentation for the exact steps.