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 permanent vs session-only distinction and the browser login flow, adding context beyond the annotations. It does not contradict the idempotentHint or destructiveHint annotations, and clarifies the non-expiring nature of the config-based approach.
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 bit long but every sentence contributes necessary context for the two usage modes. It is structured logically, starting with the login flow, then the two options, and the no-args behavior.
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 absence of an output schema, the description sufficiently covers the tool's purpose and usage. It does not describe return values on success/failure, but for an authentication flow, the steps are clear enough.
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 description coverage, the description compensates by explaining the token parameter (as a JWT) and the empty call for retrieving the link. This adds meaning beyond the schema's simple type definition.
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 it is an authentication tool that guides the user through logging in via browser and obtaining an access token. It distinguishes itself from siblings by focusing on login/token acquisition rather than connection or marketplace functions.
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 provides explicit guidance on two usage modes: permanent configuration via Authorization header and session-only login via token parameter. It also explains the no-args behavior for getting the link. However, it does not mention when not to use this tool or directly compare to alternatives like 'connect'.
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 tools have overlapping purposes (authenticate and connect both relate to authentication) and the descriptions are verbose and repetitive, making it hard to distinguish their roles. The domain-specific tool mpt_pb_cnf_consultar is buried among generic platform management tools, creating confusion about the server's core function.
Tool names follow no consistent pattern: some are verbs (authenticate, connect), others are nouns (marketplace), some are snake_case (mpt_pb_cnf_consultar), and others are compound nouns (toolkit_info, report_bug). This mixed naming makes it difficult to predict tool behaviors.
With 7 tools, the count is within a reasonable range, but the set includes a mix of generic platform utilities (report_bug, show_version, toolkit_info) that seem unrelated to the server's stated purpose of providing a certidão negativa, giving it a bloated and unfocused feel.
The server offers only a single domain-specific operation (mpt_pb_cnf_consultar) with no additional related features, leaving a minimal surface for its stated purpose. The presence of unrelated platform tools does not address the gap in domain coverage, making the tool set incomplete for a robust certidão service.