Skip to main content
The server accepts two credentials. The difference is not a setup preference - it changes which workspaces the connection can read and whether the access is attributable to a person. Prefer OAuth. It carries an identity, it can be revoked without rotating a shared secret, and there is no key to leak into a config file that might get committed.
Neither credential narrows what is readable inside a workspace. NeetoPlaydash’s tools read the whole workspace’s projects, runs, and test results, so an OAuth connection sees the same data in a granted workspace that an API key would. The difference is which workspaces are reachable at all, and whether the access is attributable.

​
OAuth, scoped to the workspaces you approve

The server implements OAuth 2.1 with PKCE and dynamic client registration, so a client that speaks it needs no configuration beyond the URL. Discovery metadata is published at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource, so most clients find all of this on their own.

​
Signing in

1

Add the server

Point your client at https://connect.neetoplaydash.com/mcp/messages with no credential. See Connect for your client’s exact steps.
2

Approve in the browser

The client opens NeetoPlaydash in your browser. Sign in if you are not already.
3

Choose your workspaces

If your account belongs to more than one NeetoPlaydash workspace, you pick which ones this connection may read. Only the ones you approve become reachable.
4

Return to the client

The client stores the token and refreshes it as needed. offline_access is what makes that refresh possible, so you are not signed out mid-session.

​
Working across workspaces

Every tool accepts an optional workspace argument naming a subdomain, and the ListWorkspaces tool reports which workspaces the connection may read. Omit workspace and the tool runs against the primary one. An API key has only one workspace, so workspace is redundant on that kind of connection.

​
API key, scoped to one workspace

Use an API key when your client cannot do OAuth, or when you want a connection that belongs to the workspace rather than to a person - a shared bot, for instance. Generate one from your workspace’s API keys screen; see the help centre article. It is the same key the REST API uses. Send it as a bearer token:
The header differs from the one the REST API expects. The same key authenticates both, but the REST API reads it from X-Api-Key while the MCP server reads it from Authorization, because that is the only header MCP clients send.
An API key grants full read access to its workspace and carries no identity, so nothing in an audit trail says who used it. Treat it like a password. Take particular care with clients that read an in-repository config file, such as VS Code’s .vscode/mcp.json - do not commit a key.

​
How this compares to the other surfaces