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 align with the description's non-destructive nature. The description adds behavioral context beyond annotations: it explains the two authentication modes (permanent vs session-only), the browser login flow, and the token format (JWT). It doesn't contradict annotations. Slight deduction for not explicitly stating that calling with no args returns a link, but this is implied.
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 main purpose. It uses a colon to separate the main purpose from usage details. It's a bit dense with multiple clauses, but every sentence earns its place. Slight deduction for the run-on structure and the parenthetical 'or paste it here' which could be clearer.
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 (1 optional param, no output schema), the description is fairly complete. It covers the two usage modes, the token format, and the permanent vs session distinction. It could mention what the response looks like (e.g., success/failure), but with no output schema, this is a minor gap. The description is adequate for an agent to use this tool correctly.
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%, so the description must compensate. It does explain the 'token' parameter: it's a JWT that the user pastes for session-only login. It also explains the no-args case (returns link). This adds meaning beyond the bare schema, though it could be more explicit about the token's format and purpose.
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 with MCP.AI for IDE agents by logging in via browser and obtaining an access token. It distinguishes itself from siblings by being the only authentication tool among the listed siblings (connect, marketplace, etc.).
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 guidance: it explains two methods (permanent config-based token vs session-only token), when to use each (permanent vs session-only), and how to call the tool (with token argument or no args to get link). It also mentions the best practice of adding to config for permanent connection.
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', 'connect', and 'marketplace' all deal with authentication and connection status. 'INCRA_coordenadas_consultar' is the only domain-specific tool, while the rest are platform utilities, creating confusion about which tool to use for a given task. The marketplace tool also covers actions like 'report_bug' and 'show_version', making their boundaries unclear.
Tool names mix styles: English verbs (authenticate, connect, report_bug, show_version) with camelCase (toolkit_info), and a Portuguese snake_case domain tool (incra_coordenadas_consultar). There's no consistent verb_noun pattern, and the marketplace tool name does not convey its broad scope.
With 7 tools, the count is within a reasonable range, but the set is dominated by platform management tools (connect, marketplace, report_bug, show_version, toolk it_info) rather than the core domain of availability of coordinates. The server's stated purpose is narrowly about INCRA coordinates, yet only one tool addresses that, making the count feel inflated by unrelated functionality.
For the domain of providing coordinates, there is only a single query tool and no apparent update, delete, or batch operations. The platform management tools are housekeeping functions that do not fill gaps in the core domain. The server's purpose seems to be a gateway to a broader marketplace rather than a focused INCRA service, leaving the core domain surface severely incomplete.