MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as idempotent and non-destructive; the description adds context about the two authentication modes (permanent via config header vs session-only via token) and the link-generation behavior. It does not disclose server-side effects like session invalidation or error responses, but with annotation coverage, the added context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences that front-load the purpose, then present the two authentication options. 'Best:' and 'Or' structure the instructions clearly. It could be tightened (e.g., 'MCP.AI for IDE agents' is a bit tag-like), but every sentence contributes necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and safe annotations, the description covers the essential usage paths: getting a link via no args and submitting a token for session login. It explains the permanent config alternative and the browser login flow. Minor gaps include return-value details and error handling, but these do not compromise the core understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines an optional 'token' string with no description (0% coverage). The tool description compensates by explaining that the token is a JWT pasted by the user for session-only login and that calling with no arguments returns a link. This clarifies the parameter's role and optionality, though it doesn't specify validation or format details beyond 'jwt'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies authenticate as a tool for IDE agents to log in to MCP.AI, with specific instructions for obtaining and submitting an access token. It distinguishes from sibling tools like connect or kb_search by focusing solely on authentication. The phrase 'MCP.AI for IDE agents' plus the two usage paths make the tool's function specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts a permanent config-based header approach ('Best: add it to this server's config as a header...') with a session-only token submission ('Or paste it here for a session-only login'), giving clear context on when to use each. It also specifies call patterns with or without the token argument, though it doesn't formally name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools are distinct: kb_* tools handle knowledge base operations, while authenticate/connect/marketplace/toolkit_info serve system-level purposes. However, 'connect' and 'toolkit_info' overlap slightly in reporting connection status, and 'marketplace' is a broad multi-purpose tool that might be confused with 'report_bug' for feedback.
The kb_* tools follow a consistent snake_case verb_noun pattern (kb_add_text, kb_get_document, kb_ingest_url, etc.), but system tools break the pattern: 'authenticate', 'connect', 'marketplace', 'report_bug', 'show_version', 'toolkit_info' use varying conventions (bare verbs, nouns, compound names). The mixed style reduces overall consistency.
With 13 tools, the server covers both the knowledge base domain (9 kb_* tools) and platform management (4 system tools). This is a well-scoped count that doesn't feel bloated, and each tool addresses a distinct operational need.
The kb_* tools cover the core lifecycle: add text, ingest URLs, get/list documents, search, remove. Missing obvious operations like 'update document' or 'create a new empty document' are minor gaps easily worked around. The marketplace tool adds extensibility that mitigates domain gaps, but within the stated purpose the coverage is strong.