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 two modes of operation (permanent config vs. session-only) and the side effect of generating a login link when called without arguments. It does not explicitly detail rate limits or other behavioral aspects, but it does not contradict the annotations (idempotentHint: true aligns with the description of calling with no args to get a link). Minor deduction for not describing error handling or edge cases.
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 a compact paragraph that front-loads the purpose. It includes an example call format and covers both auth modes without being overly verbose. However, it could benefit from some light structuring (e.g., bullet points) to separate the permanent and session-only flows.
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 provides the necessary context for both usage modes. It lacks details on the exact URL or the token validation process, but given the tool's simplicity and the presence of sibling tools that don't overlap, it is reasonably complete.
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 provides only a 'token' string with no description or format. However, the description explicitly explains the parameter's meaning: the token is a JWT that can be passed for session-only login. This adds significant meaning beyond the raw schema, but it could be more precise about the expected format or validation rules.
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: to handle user authentication for MCP.AI, allowing login via a browser, and supporting both permanent and session-only tokens. It distinguishes itself from the sibling tools (credit checks, marketplace) by focusing on the 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?
It explains when to use this tool: when a user needs to log in, and provides a clear distinction between permanent (config header) and session-only (pass token) auth. It also implicitly contrasts with other tools, as none of the siblings handle authentication.
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.
Several credit tools overlap heavily, such as credito_dossie vs credito_relatorio_pf_completo, credito_relatorio_pf_mais vs credito_relatorio_pf_completo, and credito_score vs credito_risco_pj. The marketplace tool also blurs the server's identity by providing generic platform capabilities that overlap with connect and toolkit_info.
Most tool names use consistent snake_case, and the credit tools follow a clear 'credito_' prefix pattern. However, generic platform tools like marketplace, report_bug, show_version, and toolkit_info break the semantic verb_noun pattern, creating a minor inconsistency.
At 17 tools, the server is on the heavier side. The credit-specific subset (13 tools) is reasonably scoped, but the inclusion of non-domain tools (marketplace, report_bug, show_version, toolkit_info) inflates the count and makes it feel bloated for a credit-focused server.
The credit data domain is well covered, including negative records, positive reports, protests, SCR, score, risk, and credit limits. The only noticeable gaps are the absence of writing operations (e.g., update/delete) and the disconnect between the platform tools and the credit domain, but the core read-only workflows are thorough.