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?
Adds behavioral details beyond annotations: describes the need for a browser login step, distinguishes between permanent and session-only auth, and explicitly states behavior with and without the token parameter. No contradiction with the idempotentHint=true annotation since the auth process can be safely re-invoked.
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 wordy, but every sentence contributes to the reader's overall understanding of the auth flow. The two-path explanation is front-loaded and logically ordered from permanent to session-based, making it both concise and structured.
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 single-parameter tool with no required params and no output schema, the description is highly complete: it covers the browser login, token handling, permanent vs session options, and no-args behavior. Minor gaps include missing error handling or response shape, but overall satisfies all needed context.
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?
With 0% schema coverage, the description fully compensates by explaining the optional 'token' parameter as a JWT to paste for session-only login and clarifies that calling with no arguments returns a link. It does not describe the output format, but the single token is well contextualized.
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 performs an authentication/log-in flow for IDE agents, using a browser token or pasted JWT. It distinguishes itself from the general 'connect' sibling through its focus on obtaining and using an access token, though it does not explicitly contrast with alternatives.
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?
Provides specific usage guidance: permanent bearer header via config for a non-expiring connection, or session-only login by passing a JWT token, or no args to receive a link. It gives clear scenarios, including 'after the user pastes' and 'with no args to get the link', but does not explicitly state when not to use this 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.
The `marketplace` tool is a single name hiding 10+ operations (search, describe, invoke, install, subscribe, cancel, prompts), forcing intent-matching through argument parsing rather than distinct tools—the exact disambiguation failure mode. Meanwhile `connect`, `authenticate`, and `toolkit_info` blur the boundary between 'auth,' 'status,' and 'toolkit state,' so an agent could plausibly hit the wrong one for a connection check. Only `sefaz_pe_nfce_consultar` and `show_version` have crisp, unambiguous responsibilities.
Most tools follow a snake_case, verb-leading pattern (authenticate, connect, report_bug, show_version), which is good. But `marketplace` and `toolkit_info` are noun-y fragments that give no hint of their action, and `sefaz_pe_nfce_consultar` mixes PT-BR acronyms with the underscore pattern, breaking the otherwise English verb-first convention. The inconsistency is noticeable but not chaotic—there's no camelCase or random naming.
Seven tools sits right in the middle of the ideal 3–15 range and is well-scoped for a platform utility server. The only knock is that this is deceptive: the marketplace tool should fragment into 8+ tools, which would push the true surface to ~15. As presented, though, the count itself is reasonable and navigable.
The platform side is decently covered—auth, connection status, version, toolkit info, and bug reporting form a coherent operational loop. But the actual domain the server is named for (SEFAZ PE: NFC-e) is a single `sefaz_pe_nfce_consultar` tool with no related operations (e.g., no detail-by-chave view, no DANFE/PDF, no correlate/validate flows), and the marketplace embeds prompt management that feels bolted on. It works for a one-shot look-up but nothing more.