MPF: Amazônia Protege

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds behavioral context by distinguishing between permanent (header config) and session-only (token) logins, which is not in the annotations. However, it doesn't discuss potential side effects or error handling, but annotations already indicate non-destructive, non-read-only behavior.

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 two sentences, front-loaded with purpose, and packs all necessary usage and parameter information without wasted words. It is well-structured and easy to parse.

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 simple authentication tool with one optional parameter and no output schema, the description covers all essential usage aspects: how to call, what to provide, and the two modes. It doesn't mention response format, but that is not critical for this tool.

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?

Despite zero schema coverage, the description fully explains the 'token' parameter as a JWT the user pastes, and clarifies that it's optional (calling with no args is allowed). It also explains the alternative of configuring the token in the server config, adding rich meaning beyond the bare schema.

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 authenticate the user by either providing a browser link or accepting a token. It explicitly names the resource (MCP.AI) and the verb (authenticate), and distinguishes from siblings by detailing 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?

The description explicitly explains when to call with no args (to get a link) versus with a token (session-only login), and recommends adding the token as a header for a permanent connection. It provides clear usage context for both scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds behavioral context by describing the conditional response for connected vs. missing-credential states. It does not contradict the 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?

Two sentences with no filler. Each sentence provides distinct information: the general purpose and the conditional outcomes.

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?

The tool is simple (no params), and the description covers the two main states and key fields (authenticated, pending, connect_url). However, it doesn't address a partially-connected state or define 'per-install URLs' fully, leaving a minor gap.

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 zero parameters, there is nothing for the description to explain; the baseline of 4 applies. The description correctly focuses on return behavior instead.

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 uses a specific verb ('returns') and identifies the resource ('connection status and URLs'), clearly distinguishing it from siblings like 'authenticate' which likely initiates a connection. The state-based explanation further clarifies what the tool reports.

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 does not explicitly state when to use this tool over 'authenticate' or other siblings. It implies a status-checking role but lacks explicit 'use this when...' guidance or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the sparse annotations, the description discloses that writes require workspace owner/admin, that invoke runs uninstalled MCPs without adding them to the toolkit, and that credential/payment failures generate user-facing links before retry. These are precisely the behavioral traits an agent needs to anticipate. No contradiction with annotations was found.

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 long but dense and useful: catalog definition, core flow, install-vs-invoke rule, permission note, and prompt library are all covered without obvious fluff. It is front-loaded with the core purpose and uses scannable flow language. The density is appropriate for a 14-action dispatcher.

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 tool with 23 parameters and no output schema, the description covers the main workflows, credential and payment edge cases, permission requirements, and the prompt library. It does not fully document every action, such as resume, or every parameter, such as immediate, but the critical paths are sufficiently complete for correct invocation.

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 coverage, the description must compensate for parameter meaning. It does explain the action-level flow and the role of tool_id, arguments, and prompt actions, but most of the 23 parameters—such as limit, immediate, tier_slug, cancel_comment, prompt_targets, and conversation—are never individually described. This leaves a real gap for an agent trying to construct correct calls.

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 states it is the mcp.ai marketplace: the in-platform catalog of MCP/tools and the mechanism to run them, and lays out the core search → describe → invoke flow. This clearly identifies the resource and scope while distinguishing it from sibling tools like connect, authenticate, and show_version.

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 explicitly tells the agent to prefer invoke for one-off use and install only for permanent inclusion, and explains what to do when invoke returns connect or checkout links. It also separates the prompt-library workflow from the MCP marketplace workflow, giving strong when-to-use and alternative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly, idempotent, and non-destructive behavior, and the description adds significant context beyond them: payment model, lack of platform credentials, official/non-confidential data nature, and LGPD controller responsibility. This gives the agent a strong understanding of operational and legal expectations. No contradiction with 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 compact and front-loaded, with each sentence earning its place: purpose, access/payment model, and legal/data handling context. There is no redundant repetition of the tool name or schema fields.

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?

The description covers purpose, access, payment, and legal context well, and the annotations provide safety metadata. However, with no output schema and no parameter documentation, the description still leaves ambiguity about what exactly is returned and how the CPF/CNPJ parameters should be supplied, so it is not fully 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?

Schema description coverage is 0%, so the description must compensate, but it never mentions CPF or CNPJ, whether they are alternatives, required, or how they should be formatted. The bare property names give some hint, but the description adds no semantic value for invoking the tool correctly.

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 opens with 'MPF: Amazônia Protege, consulta em fonte oficial', giving a specific verb and resource and clearly identifying this as an official-source consultation tool. It further distinguishes itself from the platform-related sibling tools (authenticate, connect, marketplace, etc.) by stating it provides information from official Brazilian sources, not platform services.

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 provides clear usage context: no platform credentials are needed, it is hosted by the platform, and each query is paid for with prepaid credit. It does not explicitly name alternatives or exclusion cases, but the sibling tools are unrelated enough that the use case is reasonably clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that this is a reporting/feedback action and that the conversation array is needed for reproduction, but it does not explain authentication requirements, side effects, or outcome after submission.

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 two short sentences, front-loaded with the purpose and followed by the most important input instruction. There is no filler or redundant wording.

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 three parameters, no output schema, and no parameter descriptions in the schema, the tool description is too sparse. It does not clarify the context parameter, explicitly map the required message parameter, or mention prerequisites such as authentication or expected behavior after reporting.

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 description coverage is 0%, so the description must compensate. It adds meaning for the conversation parameter by describing it as recent messages for reproduction, but it leaves the required message parameter and the context parameter semantically unexplained beyond what the schema already shows.

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 uses a specific verb ('Report') and names explicit resource types: a bug, a missing feature, or feedback. It also tells the agent to include the conversation array, clearly distinguishing this tool from the unrelated sibling tools such as authenticate, connect, and show_version.

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 clear usage context by stating the tool is for reporting a bug, missing feature, or feedback. It does not name alternatives or specify when not to use it, so it falls just short of fully explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is consistent with the annotations (readOnly, idempotent, non-destructive) but adds little beyond them. It says 'current' implying live data, but does not elaborate on side effects (though none are implied).

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 single, clear sentence with no unnecessary words or fluff. It is appropriately sized for the tool's simplicity.

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?

The description explains what the tool returns (versions of MCP platform and adapter), which is sufficient for a simple read-only operation. It does not specify the format, but that is acceptable given the lack of an output schema.

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?

There are no parameters, so the schema fully covers this aspect. The description adds no extra parameter-related information, which is fine given the absence of parameters.

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 function: showing current MCP platform and adapter versions. It is specific and distinguishes itself from sibling tools like authenticate and 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?

The description does not explicitly state when to use this tool versus alternatives, but as a simple version-check tool, its purpose is self-evident. Lacks explicit guidance on when to invoke it (e.g., for debugging or compatibility checks).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe read. The description adds useful context about what state is returned but does not add behavioral details like freshness/latency or whether it triggers any background checks.

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?

One sentence, front-loaded with the action ('Returns the current toolkit state'), and every phrase adds information: installed MCPs, connection status, accounts, catalog tool counts. No filler.

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 zero-parameter, read-only status tool, the description is nearly complete. It doesn't state whether the list of installed MCPs is sorted or formatted, but given no output schema, it provides a solid summary of what the agent will receive. The sibling set includes related toolkit tools, so this fills a clear niche.

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 has zero parameters, and schema description coverage is 100% (trivially). The description compensates by specifying the shape of the returned state, which is the entire informational content of the tool. With no parameters, baseline is 4.

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 this tool returns toolkit state, enumerating exactly what it includes: installed MCPs, connection status, connected accounts, and catalog tool counts. This is a specific verb+resource combination that distinguishes it from sibling tools like authenticate or 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?

The description implies this is the tool to call when checking overall toolkit status, and the read-only annotations support safe invocation. However, it does not explicitly state when to prefer this over sibling tools or mention any alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.