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?
With annotations only supplying idempotentHint=true and readOnlyHint=false, the description adds meaningful behavioral context: the permanent vs. session-only distinction, how to call with/without args, and the non-expiring nature of the header-based connection. Doesn't mention error or failure behavior, which would round it out.
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?
A dense three-sentence description where every clause earns its place: audience, recommended approach, fallback approach, and invocation semantics. It's a bit run-on and mixes setup guidance with call signatures, but it's front-loaded and contains zero fluff.
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 optional-param tool with no output schema, the description covers both invocation modes and their persistence trade-offs thoroughly. An agent could drive the full flow without consulting external docs. It doesn't cover response shapes or error cases, but nothing here is incomplete enough to drop below a 4.
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?
Schema coverage is 0% and the token param has no description, so the description carries the full weight — and it does so well by explaining the token is a JWT pasted by the user and that calling with no args yields the login link. Slightly more detail on the JWT's origin or validation could push this to 5.
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 conveys the verb+resource ('log in in the browser, copy the access token') and names the target audience (MCP.AI for IDE agents like Cursor). It's unambiguous about what the tool does, though it doesn't explicitly differentiate itself from a sibling like `connect` — a 5 would require that explicit sibling distinction.
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 explicit guidance on when to use what: the 'Best' permanent approach (server config header) vs. session-only login via the token argument. This effectively scopes the tool's two usage modes, though it doesn't cover when NOT to use the tool or name alternatives.
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 platform tools are largely distinct: authenticate, connect, marketplace, report_bug, show_version, and toolkit_info each have clear roles. The single SEFAZ tool is unambiguous. Minor overlap exists between marketplace (catalog/install) and toolkit_info (current state) that could cause slight confusion.
Naming is inconsistent: some tools are single words (authenticate, connect), others are snake_case multi-word (report_bug, show_version, toolkit_info), and the domain tool uses a completely different prefix (sefaz_pi_visualizar_cert_consultar). There is no consistent verb_noun pattern.
Seven tools is a reasonable count for an MCP platform server that includes a single domain-specific query. It's not excessive, and each tool serves a distinct purpose within the platform management scope.
Platform utilities are relatively complete for managing MCPs, but the primary domain of SEFAZ PI certificate viewing is covered by only one consult tool. This may suffice for a simple query, but there are no additional operations such as listing or history, leaving minor gaps.