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, meaning the tool is safe to call multiple times. The description adds context by explaining the browser-based flow and the token handling, including that providing no args yields a link. However, it does not explicitly mention that the token is a JWT or discuss expiration, but the annotation already handles idempotency. Overall, the description adds value beyond annotations by clarifying the authentication flow.
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 well-structured, with a front-loaded statement about the tool's purpose and then actionable instructions. It covers two use cases in a single sentence, and the recommendations are clear. No wasted words.
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 (one optional parameter, no output schema), the description is highly complete. It explains both invocation modes, the permanent setup via header, and references the browser flow. It leaves no gaps for an agent to misunderstand how to use the tool.
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 only defines 'token' as a string with no description. The tool description compensates by explaining the token's purpose: it is a JWT access token that the user pastes, and that calling with { token: ... } enables session-only login. It also mentions that the token can be used as a header for permanent connections. This adds significant semantic meaning beyond the schema's minimal definition.
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, either by providing a token after browser login or triggering a login link. It specifies the verb 'authenticate' and the resource (MCP.AI) it interacts with, making it distinct from sibling tools like 'connect', 'marketplace', or 'report_bug'.
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 explicitly explains when to use this tool: when an IDE agent needs to authenticate. It also distinguishes two usage scenarios: passing a token for session-only login, or calling with no args to get a login link. It further recommends a permanent solution by adding an Authorization header to the server config. This is clear guidance on how to use the tool.
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.
Each tool serves a clearly distinct function: authentication, connection status, marketplace browsing/execution, bug reporting, version display, toolkit inspection, and the single domain-specific process query. There is no overlap or ambiguity in their purposes, even if some are related.
The tool names are highly inconsistent: most are simple single-word verbs (authenticate, connect, marketplace) or verb_noun pairs (report_bug, show_version, toolkit_info), but the only domain-relevant tool uses a long prefixed snake_case name (tribunal_trt12_processo_consultar). This mix of generic platform naming and a domain-specific convention breaks any predictable pattern.
The server has 7 tools, which is a reasonable count for a platform utility server, but the named purpose (TRT12 process consultation) is served by only one tool. The other six are generic MCP platform management tools that could apply to any server, making the set feel mismatched: too many utility tools for a domain-specific query server, yet too few domain tools to justify the name.
The stated domain is judicial process consultation, but without any supporting CRUD or lifecycle operations. There is only a single query tool, no ability to list processes, filter by different criteria, retrieve details, or perform any management. The other tools cover the platform's generic functionality but not the domain, so the surface is severely incomplete for the server's claimed purpose.