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 include idempotentHint=true and destructiveHint=false, but the description adds value by explaining that token-based login is non-expiring and session-only vs permanent. It also mentions the browser flow and token copy, which is behavioral context beyond annotations. No contradiction noted; the annotation hints align with the description.
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, consisting of two sentences, and is front-loaded with the main purpose. It packs essential information about permanent vs session login, configuration, and token usage without redundancy. Slight improvement could be separating the config method from the call method for clarity, but it's generally efficient.
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 simple schema (one optional token param) and no output schema, the description covers the main context: what authentication does, how to set it up permanently or for a session, and the token argument. It might mention what happens on success or failure, but that's not critical. The complexity is low, so this is reasonably complete.
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 has 0% description coverage, so the description must add parameter meaning. It explains that 'token' is a JWT that can be passed for session login, and that calling with no args gets the link. However, it doesn't detail token format or required syntax beyond mentioning JWT. Baseline is low due to no schema description, but the description partially compensates; still, it's not fully explicit.
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 purpose: authenticate for MCP.AI IDE agents by either using a browser login or providing a token. It specifies the action (log in), the resource (MCP.AI server), and differentiates from siblings by focusing on authentication, while siblings like 'connect' or 'marketplace' likely serve different purposes.
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 explicit usage guidelines: recommends adding the token to config for permanent access, or pasting it for session-only login. It explains both token and no-argument invocation with token input. This clearly indicates when to use and what to expect, with no exclusions or alternatives needed beyond the mentioned config method.
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.
Several tools overlap in purpose: authenticate and connect both deal with authentication/connection status, while marketplace and toolkit_info are generic platform tools unrelated to the document domain. The single domain-specific tool (ecrvsp_docs_imprimir_baixa_consultar) is distinct, but the mix of generic and domain tools creates ambiguity about which tool to use for a given task.
Naming is highly inconsistent: most tools use English verb-noun patterns (authenticate, connect, report_bug, show_version, toolkit_info), but one is a long Portuguese compound (ecrvsp_docs_imprimir_baixa_consultar) and another is a noun (marketplace). This lack of a uniform convention makes it difficult to predict tool names.
With 7 tools, the count is within a typical range, but the majority are generic platform utilities (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) rather than domain-specific features. The server's stated purpose appears to be vehicle document printing, yet only one tool directly addresses that, making the set feel unbalanced and not well-scoped to the domain.
For a document printing service, having only a single combined tool (imprimir, baixa, consultar) is likely insufficient. The surface lacks separate operations for listing documents, updating statuses, or managing multiple document types, leaving significant gaps in the core functionality that an agent would need to handle real tasks.