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 provide idempotentHint: true, but the description adds behavioral context by detailing side effects: it can return a login link when called with no args or accept a JWT for session-only login. It clarifies that the token can be stored permanently in config or last only for the session, which 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 three sentences long, front-loaded with the core purpose, and provides essential details without unnecessary fluff. A missing newline or bullet list is a minor structural improvement, but it's efficient for the information conveyed.
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 an authentication tool with one optional parameter and no output schema, the description adequately covers usage but omits return value semantics (e.g., success/failure responses) and error scenarios (e.g., invalid token). Given the lack of an output schema, a brief note on expected outcomes would elevate completeness.
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 shows an optional 'token' string with no description (0% coverage). The description fully compensates by explaining that 'token' is a JWT from the user and that omitting it triggers a link generation. This comprehensive explanation makes up for the schema gap.
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 authenticates to MCP.AI for IDE agents by logging in and handling access tokens. It provides specific usage details, distinguishing it from siblings like 'connect' by focusing on token-based authentication. However, it doesn't explicitly contrast with sibling tools, so it misses a top score.
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 clear context on when to use the tool (for browser-based login to obtain a token) and explains two usage patterns: permanent via config header or session-only via token. It implicitly differentiates by describing the alternative of configuring a header, but doesn't explicitly mention 'use this instead of X'. This is clear enough for a 4.
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 distinct purpose: authentication, connection status, JUCESP consultation, marketplace operations, bug reporting, version display, and toolkit info. Descriptions are detailed and clearly differentiate the tools, leaving no ambiguity about when to use each.
Tool names are inconsistent in style and language: some are single verbs (authenticate, connect), some are noun_verb (toolkit_info), one is a long snake_case Portuguese phrase (jucesp_certidao_simplificada_consultar), and others mix English conventions. The pattern is unpredictable, making it harder to guess tool names.
With 7 tools, the count is within a reasonable range, but the majority are generic platform-level utilities unrelated to the server's stated JUCESP purpose. The one domain-specific tool feels like an afterthought, and the set could be trimmed or better scoped.
For the core JUCESP certificate consultation, the single tool covers the entire operation (query by CNPJ, NIRE, or name). The included platform tools handle surrounding needs like authentication, billing, and marketplace discovery, so no major dead ends exist. Minor gaps like explicit certificate history or multiple formats are absent, but not critical.