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 provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false, and the description adds useful context beyond these: the config-header path yields a permanent, non-expiring connection, while the pasted-token path is session-only. It also discloses that no-args returns the login link. There is no contradiction with the annotations.
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 a single dense paragraph but contains no filler; it front-loads the purpose and packs in audience, browser flow, permanent vs session options, and call shapes. It could be more scannable with bullets or separate sentences, but it remains concise and information-dense.
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?
With one optional parameter, no output schema, and no auth-related siblings, the description covers the core flows and expected outcomes: getting a login link or performing a session login. It does not specify the exact return value for the token-present case or failure handling, but the essential decision guidance for an agent is fully present.
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 exposes only an optional, undocumented string parameter `token` (0% description coverage). The description compensates fully by explaining that the token should be a JWT/access token, how to pass it in the call, and that omitting it triggers the link-generation flow. This transforms an opaque schema field into an actionable parameter.
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 with MCP.AI by either returning a login link when called with no arguments or accepting a pasted JWT/access token. It identifies the resource (MCP.AI server) and the action (log in / authenticate), and the sibling list contains no other auth-related tool, so there is no ambiguity.
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 gives explicit usage paths: call with no args to get the login link, or call with { token: "<jwt>" } after the user pastes it. It also distinguishes the recommended permanent config-header approach from the session-only token-paste approach. It does not mention alternative tools explicitly, but no sibling tool serves an auth purpose, so the guidance is adequate.
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 domain tools (capivara_dossie, capivara_resolver, capivara_registrar_consentimento) are clearly distinct, but the platform tools (connect, marketplace, toolkit_info, authenticate, report_bug, show_version) overlap in lifecycle management responsibilities. Notably, marketplace's invoke capability can also 'consulta um CPF', creating ambiguity with capivara_dossie for the same user intent.
Naming is split between Portuguese domain tools with the capivara_ prefix and generic English platform tools (connect, marketplace, report_bug, show_version, toolkit_info). Within the domain tools, capivara_dossie uses a noun while capivara_resolver and capivara_registrar_consentimento use verbs, breaking any consistent verb_noun pattern.
At 9 tools, the count is within the ideal range. However, the server bundles platform administration tools (connect, marketplace, toolkit_info, report_bug, show_version, authenticate) with domain-specific investigation tools, which inflates the apparent surface area — though several platform tools could be consolidated.
The domain lifecycle is well covered: identity discovery (capivara_resolver), consent registration (capivara_registrar_consentimento), and the main dossier query (capivara_dossie) form a coherent workflow. Minor gaps exist such as no explicit tool to update or revoke consent, and no history of past investigations, but these are edge cases on the core flow.