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?
Annotations indicate idempotentHint: true and destructiveHint: false, which aligns with the description. The description adds context about the two auth methods and the permanent nature of the config-based token. It doesn't contradict annotations. However, it could disclose what happens on repeated calls or failure states.
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 concise and front-loaded with the tool's purpose. It packs a lot of information into three sentences without being verbose. Slightly dense with instructions but organized with a colon and comma-separated options.
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?
Given the tool's simplicity (0 required params, only 1 optional, no nested objects, no output schema), the description covers the main use cases well. It explains the two authentication paths and the no-arg behavior. Could mention what the return value is but that's minor.
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?
Schema description coverage is 0%, and the description compensates by explaining the 'token' field is a JWT and how to use it. It also explains no-arg behavior. Slight deduction because it doesn't specify token format beyond '<jwt>' or error handling, but given only one optional param, it's well-handled.
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 states the tool's purpose: authenticate to MCP.AI for IDE agents by logging in via browser and copying an access token. It specifies the resource (MCP.AI) and the action (authenticate/login).
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 provides clear context on when to use this tool (to log in) and gives two methods (permanent via config header or session-only via token argument). However, it doesn't explicitly mention alternatives, but sibling tools don't seem to overlap, and the guidance is quite detailed for authentication flow.
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.
The tools have distinct purposes: authenticate handles login, connect checks status, marketplace explores MCPs, etc. The domain-specific tool cfo_cadastro_consultar is clearly separate, though connect and authenticate have some overlap in authentication context. Overall, no two tools are easily confused.
Tool names follow no consistent pattern: verb-style (authenticate, connect, show_version) mixes with noun-style (marketplace, toolkit_info) and a Portuguese phrase (cfo_cadastro_consultar). There is no uniform verb-noun convention across the set.
7 tools is a reasonable count, but the vast majority are generic MCP platform utilities (connect, marketplace, report_bug, show_version, toolkit_info) that are unrelated to the server's stated purpose of dental council registration. Only one tool (cfo_cadastro_consultar) is domain-specific, making the set feel padded with infrastructure rather than domain coverage.
For a server meant to handle Conselho Federal de Odontologia cadastro (registration), there is only a single lookup tool. Missing any create, update, delete, or list capabilities. The domain surface is severely incomplete for the stated purpose.