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?
Beyond the annotations, it adds useful context: the config-header path is permanent/non-expiring while this tool call is session-only, and the tool returns encourages a login link when called without args. It does not fully describe side effects or failure behaviors, but given the idempotent and non-destructive annotations, the description covers the important traits.
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 dense but relevant; every sentence provides a needed piece of information. It is slightly stream-of-consciousness and mixes user-facing config advice with tool call instructions, but it remains understandable and well within acceptable length.
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-parameter tool with no output schema, the description covers the key operational details: when to revisit the token, when to call with no args, and how to interpret the session-only vs permanent setup. It lacks a formal description of the result/response object, but that is less critical here because the expected outcome is a link or session.
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 is nearly empty, so the description must compensate. It clearly explains that the optional 'token' is a JWT supplied by the user and demonstrates the exact call shape `{ token: '<jwt>' }` as well as the no-args alternative. This is enough for an agent to invoke the tool correctly despite the 0% schema coverage.
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 explains that this tool handles authentication for MCP.AI IDE agents, including both the no-arg flow to retrieve a login link and the token flow for session-only login. It is specific about the login action, though it never explicitly says 'authenticate' and could more cleanly distinguish itself from sibling tools like 'connect'.
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 gives clear guidance on two invocation modes: pass { token: '<jwt>' } after the user pastes a token, or call with no arguments to get the link. It also contrasts the session-only approach with the more permanent config-based header approach, which helps the agent know when tool-based authentication is appropriate.
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 server mixes platform-management tools (authenticate, connect, marketplace, report_bug, show_version, toolkit_info) with a single domain-specific tool (mpt_ms_cnf_consultar). The platform tools are distinct, but the presence of the domain tool alongside them creates confusion about the server's purpose. 'authenticate' and 'connect' overlap in credential management, and 'marketplace' has broad, multi-role behavior that may be ambiguous with 'toolkit_info'.
Naming is inconsistent: mostly snake_case verbs (authenticate, connect, marketplaces, report_bug, show_version, toolkit_info), but the domain tool uses a multi-part snake_case with an acronym 'mpt_ms_cnf_consultar' that doesn't follow the simple verb_noun pattern. Also the server is named 'MPT MS' but the tool 'marketplace' is not mpt-specific, adding to inconsistency.
7 tools is within a reasonable range, but the server appears to be a general MCP platform toolkit rather than a focused Certidão service. Only one tool (mpt_ms_cnf_consultar) serves the stated domain, while the others are platform utilities, making the count appropriate for a platform server but mismatched with the server name.
For the stated domain 'Certidão Negativa de Feitos', the surface is severely incomplete—only one consultation tool with no supporting operations (e.g., status check, history, PDF retrieval). The other tools are generic platform functions not specific to the domain, but they do provide infrastructure for authentication and billing, so the server isn't useless.