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 description goes beyond annotations by explaining the auth flow: it provides a link for browser login, accepts a token, and distinguishes persistent vs session-only behavior. While it doesn't explicitly mention idempotency, the idempotentHint annotation is consistent. It could have clarified side effects (e.g., storing token) a bit more, but overall it's transparent.
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 run-on paragraph with multiple instructions and examples, which could be better structured with bullet points or separate sentences. While all necessary information is present, it lacks brevity and clarity in presentation.
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 a straightforward auth purpose, the description covers all necessary aspects: how to obtain credentials, how to pass them, and the two modes of operation. No further detail is needed.
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 input schema only defines 'token' as a string with no description, but the tool description fully explains its meaning: the JWT to paste for session login, with the alternative of omitting it to receive a link. This adds essential semantic value beyond the 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 authenticates the user for MCP.AI IDE agents, describing the browser login flow and token retrieval. It distinguishes from siblings like 'connect' and 'marketplace' by focusing on the auth-specific action.
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?
It explicitly tells when to use it (for logging in) and gives two concrete usage patterns: permanent via config header and session-only via token paste. It also mentions the alternative of calling with no args to get the link, effectively guiding when to call without parameters.
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 are generally distinct: authenticate, connect, marketplace_list, report_bug, show_version, toolkit_info, and the CVM-specific query tool each have a clear purpose. There is a slight overlap between marketplace and toolkit_info, but descriptions differentiate them adequately, and the CVM tool is unique.
Names follow inconsistent patterns: verbs in camelCase (authenticate, connect, report_bug, show_version), nouns (marketplace, toolkit_info), and one Portuguese snake_case tool (cvm_processo_administrativo_consultar). This mix of conventions and languages prevents predictability.
While 7 tools is a moderate number, the vast majority are generic platform utilities (authentication, marketplace, reporting, etc.) unrelated to the server's stated domain of CVM sanctioning processes. The server carries unnecessary generic tools and only one domain-specific operation, misaligning count with purpose.
The domain coverage is severely incomplete. Only a single query tool for CVM processes is provided; there are no actions to list, create, update, or delete processes, nor any other relevant workflows. The generic tools do not contribute to the domain, leaving most expected operations missing.