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 discloses behavioral traits beyond the annotations: it explains the flow of returning a login link when called with no args and accepting a JWT token for session authentication. It also differentiates between permanent (config header) and temporary (session) modes, adding valuable context about how authentication state is managed.
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 somewhat lengthy but every sentence carries necessary information. It leads with the purpose, then explains both authentication methods. It could be tightened slightly for brevity, but it remains structured and focused.
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 authentication tool with only one optional parameter and no output schema, the description is complete. It explains all invocation modes and expected outcomes, ensuring an agent knows exactly how to use 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 schema only defines an optional 'token' string with no description. The description fully compensates by explaining that 'token' is a JWT to be passed after the user pastes it, and that omitting it triggers a link response. This gives the parameter clear meaning and usage context that the schema lacks.
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: authenticating IDE agents to MCP.AI. It specifies the action (log in, authenticate) and the target resource (MCP.AI for IDE agents), and distinguishes itself from siblings by focusing on browser-based token authentication.
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 instructions for all scenarios: adding the token to config for permanent access, passing the token for session-only access, or calling with no args to get the link. It mentions the intended context (Cursor and similar IDE agents), but does not explicitly contrast with sibling tools like 'connect', so there is a slight gap in alternative selection guidance.
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.
Most tools have clearly distinct purposes: authentication, connection status, marketplace exploration, bug reporting, version info, and toolkit state. However, 'connect' and 'toolkit_info' both report on connection status, which could cause some confusion for an agent deciding which to call.
Naming is highly inconsistent: single-word verbs (authenticate, connect, marketplace), verb_noun patterns (report_bug, show_version), noun-based names (toolkit_info), and a Portuguese verb_noun_noun phrase (veiculo_frotas_consultar). There is no uniform convention or predictable verb/noun ordering.
Although there are 7 tools, 6 of them are generic platform management utilities unrelated to the server's stated purpose ('Veículos do Proprietário'). The single domain-specific tool is buried among unrelated infrastructure tools, making the count feel bloated and unfocused for the apparent vehicle-query scope.
For a server named 'Veículos do Proprietário', only one vehicle-related operation exists (consult by CPF/CNPJ). There is no way to list, update, delete, or otherwise manage vehicle records. The tool offers a single lookup with no CRUD lifecycle coverage, leaving the domain surface severely incomplete.