Securing Your DocStar MCP Server: Sign-In, Consent and API Keys

Connecting an AI assistant to your API is powerful, so it should be deliberate. Who is connecting? What are they allowed to do? Whose permissions does each call run with?

Every DocStar MCP server answers those questions with a small set of controls, all in the collection's MCP tab. This guide walks through them, from the most open setup to the most locked down.

By default, a collection's MCP server lets anyone search the published docs and browse the API reference. That fits public documentation: the same pages are already on the open web, so the assistant is just reading them faster.

Calling the API is different. For endpoints that need authentication, the first call asks the user to sign in, and their own token is attached from then on.

If your API uses OAuth, add your OAuth details to the MCP settings. When an assistant needs to call your API, DocStar sends the user through your normal sign-in. After that:

• Each request runs as that user, with their permissions and nothing more.
• The assistant never sees or stores a password or token.
• If the user is not allowed to do something in your product, the assistant is not allowed either.

There is no shared service account to leak, and your own audit logs show the real person behind each call.

Some docs should not be readable by just anyone, even if you only want assistants to search them. For those, turn on Require sign-in when connecting.

With the switch on, an assistant cannot connect to the server, not even to search, until the user has signed in. It is the right setting for:

• Internal documentation and runbooks.
• Partner-only API references.
• Any collection where the reference itself is sensitive.

It is a single toggle, and you can change your mind later. Existing connections follow the new setting.

When someone connects an assistant to your server, they land on a consent page first. It tells them what they are about to authorize, so a connection is always an informed choice and never a surprise.

Assistants decide how careful to be based on what a tool can do. DocStar helps by splitting the API tools:

• A read-only tool that can only send GET requests, and says so in its metadata.
• A call tool for POST, PUT, PATCH and DELETE.

Because the read tool is clearly marked, assistants that ask for approval before changing things can let harmless lookups through, and still stop to confirm a delete. Tool hints are always sent explicitly, so clients never have to guess.

If your API uses keys rather than OAuth, the server includes a key tool. A user provides their key once and it is applied to later calls, instead of being pasted into every prompt where it could end up in a transcript.

The DocStar CLI takes the same approach for the terminal: keys are stored once, and key emit can write one straight into a project's env file.

Permissions limit what an assistant can do. Instructions shape what it should do. Use these to add a layer of care:

• Extra instructions. Add guidance like "always confirm before deleting a record" or "never run write calls against production".
• Your own skill. Rewrite the generated skill with your safe-usage recipes, or reset it to the default.
• Clearer tool descriptions. Edit the built-in tool descriptions so assistants pick the right tool, and understand the risk of the dangerous ones.

1. Decide if the docs are public. If not, turn on Require sign-in when connecting.
2. Add your OAuth details so each call runs with the caller's own permissions.
3. Review the extra instructions and add any "confirm first" rules.
4. Optionally, put the server on your own domain, such as mcp.yourcompany.com.
5. Connect it yourself and try a read, then a write, to see the prompts your users will see.

Good MCP security is mostly about identity: know who is connecting, and let your product's own permissions decide what they can do. DocStar gives you the switches. Open your collection's MCP tab and set them up in a few minutes.