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 explains the behavior beyond annotations: calling with no args yields a link, calling with token authenticates. It clarifies the token format (JWT) and the distinction between permanent and session-only login, adding significant context to the high-level annotations.
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 slightly verbose but every sentence adds value, covering context, best practice, and alternative. The structure is logical, progressing from setup to invocation, though it could be tightened.
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?
Given the simple tool with one optional parameter and no output schema, the description covers necessary context: the interactive nature, two login modes, and how to invoke each. It is complete enough for an agent to execute 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?
With schema description coverage at 0%, the description fully compensates by explaining the 'token' parameter is a JWT and how to use it in both modes. It leaves no ambiguity about the parameter's meaning.
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 for the MCP server via a browser login and token. It provides the exact invocation pattern, distinguishing it from likely siblings by focusing on authentication flow.
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 explicit usage scenarios: best practice of adding the token to config for permanent access, and session-only login by pasting the token. It does not explicitly mention alternatives or when-not-to-use, but the two usage modes provide clear context.
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 function: authentication, CARF lookup, connection status, marketplace operations, bug reporting, version, and toolkit info. There is slight overlap between connect and toolkit_info regarding status, but descriptions clarify their different outputs.
Naming is inconsistent: verbs like authenticate, connect, and report_bug; nouns like marketplace and toolkit_info; and a mixed carf_consultar with Portuguese. No consistent pattern across tools.
Seven tools is a reasonable number for a server that handles both CARF queries and platform administration. The scope is broad but each tool serves a distinct purpose, and the count is not excessive.
The CARF consultation tool covers the core function of checking processes by CPF/CNPJ. The platform tools cover authentication, connection status, marketplace discovery and invocation, version, bug reporting, and toolkit state, which appears sufficient for managing MCP integration. No critical gaps are evident.