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 already declare idempotentHint=true and destructiveHint=false, but the description adds key behavior: it can be called without args to obtain a link or with a token to perform a session login. It also mentions the permanent configuration option. This explains the tool's effects beyond the annotations, which is helpful, though it doesn't explicitly state side effects like resetting an existing token.
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 bit lengthy but well-structured and front-loaded with the core purpose. It condenses multiple options into a single paragraph without excessive fluff. Every sentence provides useful info, though it could be tightened slightly.
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?
Considering the tool's complexity (authentication flow with two modes), the description covers the call variants, the permanent configuration option, and the target audience. It does not need to cover output since there is no output schema. It gives enough context for an agent to use the tool correctly, though it could mention what the response looks like (e.g., success message).
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 has no description for the 'token' parameter and a coverage of 0%. The description compensates fully: it explains the token is optional, describes its format (JWT), and clarifies the behavior when omitted (returns a link) vs. when provided (session login). This adds significant meaning beyond the bare schema.
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: to authenticate MCP.AI for IDE agents. It specifies the actions (log in, copy token) and distinguishes from unrelated sibling tools like connect or marketplace. The description is specific about the resource (server for IDE agents) and being detailed.
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 instructions: call with no args to get a login link, or with a token for session login. It also suggests an alternative permanent configuration via header, which is a clear usage alternative. It lacks explicit when-not-to-use, but the context and instructions are sufficient.
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 have distinct purposes (auth, status, marketplace, version, etc.). However, connect and toolkit_info both report connection status and overlap significantly, and marketplace is an overloaded catch-all that could confuse an agent about which action to invoke.
Naming is inconsistent: camelCase (authenticate, connect), snake_case (report_bug, show_version, toolkit_info), and a lengthy domain-specific name (sefaz_ro_ipva_consultar). No coherent pattern across the set, making it harder to predict tool names.
7 tools is a reasonable number, but the server's stated purpose (SEFAZ RO: IPVA) is mostly ignored—only one tool is domain-specific while the rest are generic platform utilities. The count feels bloated for the declared scope and mismatched with the server name.
For an IPVA consultation server, the surface is severely incomplete—only a single query tool with no supporting operations like payment history, receipts, or update. The generic platform tools do not cover the domain's lifecycle, leaving obvious gaps for any real workflow.