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 readOnlyHint=false, and the description adds meaningful context: token use creates a session-only login, no-arg calls generate a link, and config-header auth yields a permanent non-expiring connection. This goes beyond the annotations without contradicting them.
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 reasonably compact and front-loads the main purpose. Some wording is slightly awkward ('log in in the browser'), but every sentence contributes meaningful setup or invocation details.
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 simple one-parameter auth tool with no output schema, the description covers the important pathways: browser login, config header persistence, session token, and no-args link retrieval. It could add a bit more about response/error behavior, but it is sufficiently complete for this 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?
Even though schema coverage is 0%, the description fully explains the single `token` parameter: it is optional, should be a JWT pasted by the user, and omitting it triggers the link-generation flow. This fully compensates for 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 identifies the tool as an auth/login flow for MCP.AI IDE agents, with the specific actions of logging in and copying an access token. It does not explicitly contrast itself with the sibling `connect` tool, so it lacks explicit sibling differentiation, but the purpose is unambiguous.
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 gives concrete usage guidance: permanent auth via config header, session-only auth via passed token, and no arguments to retrieve a login link. It does not explicitly state when to avoid using this tool or how it compares to `connect`, but it clearly explains how to use it.
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 has a clear, distinct purpose: authentication, connection status, the Enel query, marketplace discovery, bug reporting, version display, and toolkit info. No two tools overlap in functionality.
The naming is inconsistent: six tools use simple English names (authenticate, connect, marketplace, etc.) while the only domain tool uses a long, snake_case Portuguese name (contas_enel_rj_instalacoes_consultar). The mixture of language and casing conventions makes the set feel disjointed.
Seven tools is an acceptable number, but the server's stated purpose ('Lista de Instalações') is served by only one tool. The remaining six are generic platform utilities that seem unrelated to the domain, making the count feel inflated for the core function.
The domain coverage is narrow: only a single query operation exists for the installations list, with no apparent retrieval of individual records, filtering, pagination, or other lifecycle operations. While a list query may suffice for the primary use case, the lack of any additional domain-specific tools leaves notable gaps if more advanced interactions are needed.