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 adds context beyond annotations by explaining two authentication modes: a permanent non-expiring connection via config header, and a session-only login via token. It also notes the tool returns a link when called with no args. This enriches the behavioral understanding without contradicting the idempotent and non-destructive hints.
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 three sentences and front-loaded with the purpose. It is reasonably concise, but the phrasing 'log in in the browser' is slightly awkward and the config-header explanation could be more streamlined. Overall it is structured and each sentence earns its place.
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 one-parameter schema and no output schema, the description covers the primary use cases: permanent config vs. session token, and the no-args behavior. It lacks details on error responses or token validation, but these are not critical for an authentication tool. The description is complete enough for an agent to invoke it 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?
The input schema only defines 'token' as an optional string with no description. The description fully compensates by explaining exactly how to use it: 'call with { token: "<jwt>" } after the user pastes' and what happens when omitted ('with no args to get the link'). This provides complete parameter semantics.
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 states the tool authenticates the user, with a clear process: 'log in in the browser, copy the access token.' It defines the resource (authentication) and the verb (authenticate). However, it does not explicitly distinguish this from the sibling tool 'connect', so it misses the top score for sibling differentiation.
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 clear usage guidance: call with no args to get a link, or pass a JWT token for session-only login. It also explains when to prefer the permanent config header approach over the session method. It does not mention alternatives like 'connect', so it falls short of a 5.
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 marketplace tool is a catch-all that subsumes many operations (search, invoke, install, report bug, prompts), creating overlap with the standalone report_bug tool and making it unclear when to use which. authenticate and connect both deal with authentication/connection status, causing potential selection confusion.
Tool names exhibit no consistent pattern: some are bare verbs (authenticate, connect), some verb-noun (report_bug, show_version), some nouns (marketplace, toolkit_info), and one is a Portuguese phrase (tcu_inidoneo_consultar). The mix of languages and conventions makes the set feel chaotic.
Seven tools is within a reasonable range and each has a distinct surface area, though the marketplace tool is extremely overloaded with functionality. The count itself is appropriate for a platform server, but the heavy concentration of capabilities in one tool reduces the effective granularity.
The core domain operation (tcu_inidoneo_consultar) is present, and the platform tools cover authentication, connection status, bug reporting, and version info. However, the server's stated purpose is TCU-related, yet most tools are generic platform utilities, leaving the domain surface thin. Missing operations like listing prior consultations or managing query history are not covered.