Auth and token scope
Meshive MCP uses bearer-token authentication. Tokens are created by a signed-in human operator and then used by an MCP-capable agent.
Endpoint auth
Section titled “Endpoint auth”Send the token on every MCP request:
Authorization: Bearer <agent-token>The MCP route requires auth for GET, POST, and DELETE. During the handshake, Meshive resolves the bearer token to an active connection and stamps lastSeenAt.
Each tool call re-validates the token before touching data, so authorization is enforced at the service layer as well as at the MCP route.
Token storage
Section titled “Token storage”Raw tokens are shown once when the connection is created. Meshive stores:
- A SHA-256 hash used for lookup.
- A short token prefix for display.
- The connection status.
- The workspace id.
- Optional project ids.
If the raw token is lost, create a new token. The original cannot be recovered.
Revocation
Section titled “Revocation”Revoking a connection changes its status. Revoked tokens no longer authenticate and tool calls return an invalid or revoked token error.
Project scope
Section titled “Project scope”A token always belongs to one workspace. Its project scope is either:
- Empty, meaning all projects in the workspace.
- A list of project ids, meaning only those projects.
Scope is checked for project, task, step, and issue operations. If a token is out of scope, Meshive returns a not-authorized error for that object.
Use list_projects first to see the projects the token can reach.
Agent attribution
Section titled “Agent attribution”Mutating workflow calls record the connection name as the actor. Use clear token names such as Codex production, Claude local, or CI planner so activity entries are readable in the Operator Desk.