Cadastro Ambiental Rural: Imóvel

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

The description discloses key behaviors: calling with no args returns a link, passing a token performs login, and adding to config yields a permanent connection. It does not contradict the idempotentHint annotation, and it mentions the side effect of permanent configuration.

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 well-structured, dividing into permanent vs. session scenarios. It provides necessary details without redundancy, 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 simplicity of the tool (one optional param, no output schema), the description adequately covers what the tool does and how to use it. It implies return values (link or success) but does not explicitly state error handling or output format, which is acceptable for this context.

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 only parameter 'token' is explained in the description: it is the JWT to be passed for session login. The description covers the parameter's usage and purpose, fully compensating for the lack of schema description.

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 authentication via token, distinguishing it from sibling tools like 'connect' or 'marketplace'. It explains the login process and the two modes (permanent via config, session via token).

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 usage instructions: either add the token to the server config for permanent access, or pass the token as a parameter for session login, or call with no args to receive a login link. It implies when to use it (when authentication is needed) but doesn't explicitly state a prerequisite like 'use before other tools'.

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 read-only, but the description adds critical behavioral details: payment requirement, absence of platform credentials, data non-confidentiality, and LGPD data control responsibilities. These go beyond the annotations and are valuable for agent decision-making.

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 somewhat verbose with redundant statements (e.g., 'consulta em fonte oficial' repeated) and includes legal jargon. It is front-loaded with the main purpose but could be tightened without losing important compliance information.

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?

With a single parameter and no output schema, the description covers purpose, cost, and data classification, but lacks explicit parameter semantics and any indication of response format. It is minimally sufficient for basic use but not comprehensive.

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%, yet the description does not explicitly explain the 'car' parameter beyond implying it refers to a property. No format, example, or validation guidance is provided, leaving the agent to guess the meaning of the parameter.

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 queries the Rural Environmental Registry (CAR) for property information from official Brazilian sources. It explicitly mentions 'consulta em fonte oficial' and differentiates from sibling platform tools which are admin-oriented.

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 context that this is a paid query using prepaid credit and requires no platform credentials, but does not explicitly state when not to use it or name alternatives. Since siblings are unrelated (authenticate, connect, etc.), this is acceptable.

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, idempotentHint, and non-destructive behavior; the description adds conditional output semantics ('authenticated:true and empty pending[]' vs 'connect_url for the toolkit and per-install URLs'). This is useful context beyond the annotations and does not contradict them.

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, front-loaded with the core purpose and followed by concrete conditions. No filler or redundant restatement of the title.

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?

With no output schema, the description appropriately explains the main return branches and URL outputs. It could elaborate on partial connection states or pending[] contents, but for a zero-parameter read-only status tool, the coverage is largely sufficient.

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 tool has zero parameters, so the input schema leaves nothing to explain. The description therefore does not need to add parameter details; baseline 4 applies for a no-parameter tool.

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 says 'Returns connection status and URLs' and details two output conditions (authenticated:true with empty pending[], or connect_url plus per-install URLs). This is a specific verb+resource statement, but it does not explicitly differentiate from the sibling 'authenticate' tool, so it stops short of a 5.

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 output conditions imply a diagnostic use: check connectivity before/instead of authenticating, and retrieve connect URLs when credentials are missing. No explicit alternatives or when-not-to-use guidance is given, but the use context is clear enough for a simple status tool.

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 discloses critical behaviors beyond annotations, including that invoke works without installation, the return of connect/payment links for credential or funding gaps, the need for owner/admin on writes, and the difference between one-off and permanent installation. No contradictions with annotations (readOnlyHint=false, destructiveHint=false) are present.

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 (~300 words) but highly information-dense and well-structured with semicolons to separate ideas. It front-loads the core purpose and flow, then covers exceptions, permissions, and the prompt library. While it could be tightened, every sentence adds necessary context for a multi-action tool with 23 parameters.

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, 14 actions, no output schema, and complex auth/payment requirements, the description is remarkably complete. It explains the end-to-end flow, handle for missing credentials and funds, permission requirements, and the prompt library sub-system. It gives sufficient information for an agent to select and invoke the correct action and parameters in most scenarios.

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 coverage is 0%, so the description carries the full burden, but it only explains some parameters (action, mcp_id, tool_id, arguments) implicitly through the flow. It does not systematically describe many parameters like tier_slug, prompt_vars, prompt_targets, or cancel_comment, though context helps infer their roles. The description adds meaning for the core workflow but leaves many parameters underspecified.

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 that marketplace is the official mcp.ai catalog and execution engine, listing a concrete set of actions (search, describe, install, invoke, etc.) and the capability requests it handles (e.g., 'find an MCP that does X'). It is specific about its role and distinguishes it from the sibling tools, which are unrelated (authenticate, connect, etc.).

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 outlines the core flow (search → describe → invoke), provides strong guidance on when to use invoke vs install ('prefer invoke for a single/occasional use'), and names alternatives like list_tools for immediate capability. It also covers when each action is appropriate (e.g., install for permanent toolkit addition, request_mcp for new MCPs).

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=false, idempotentHint=true, and destructiveHint=false, indicating this is a non-destructive write operation. The description adds minimal behavioral context beyond describing the reporting action itself. It doesn't mention side effects, response expectations, or authentication needs. With annotations present, the bar is lowered, but the description could have added more context (e.g., that reports are submitted asynchronously). Score 3 reflects adequate but not rich disclosure.

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 the primary purpose and the key usage instruction. Every sentence serves a purpose, with no fluff or repetition. It is well-structured and concise.

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 tool with 3 parameters (1 required), no output schema, and no nested objects, the description is mostly complete. It covers the main action and the critical conversation parameter. It doesn't elaborate on the return value or the context parameter, but these are relatively minor gaps given the tool's simplicity and the presence of annotations. A dedicated effort to explain that context is optional additional information would push it to 5, but as is, it's adequate.

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 must compensate for parameter meanings. It explicitly explains the 'conversation' parameter ('Include the conversation array with recent messages for reproduction'), which adds value. However, it does not explain the optional 'context' parameter or expand on 'message' beyond the schema. This partial compensation yields a baseline score of 3.

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: 'Report a bug, missing feature, or send feedback.' It specifies the verb (report) and the resource (bug/feature/feedback), which distinguishes it from sibling tools like authenticate, marketplace, or show_version. The added instruction about the conversation array reinforces its purpose.

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 when to use the tool (when there is a bug or feedback) and provides specific guidance to include the conversation array. However, it does not explicitly mention alternatives or when not to use it, but the sibling tools are clearly distinct in scope, so exclusion is less critical. Slight deduction for lack of explicit when-not 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety info. The description adds the specific detail of what versions are shown (platform and adapter), which is useful but minimal. 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?

Single sentence, no unnecessary words, fully front-loaded with purpose. Every word earns its place.

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 tool's simplicity (no params, no output schema, trivial read operation), the description is complete and sufficient for an agent to understand when and how to use it. No missing critical information.

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?

Tool has 0 parameters and schema coverage is 100% effectively. Baseline for no parameters is 4 per rubric, and the description doesn't need to add param details since there are none.

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?

Description clearly states the action (show) and the resource (current MCP platform and adapter versions). It is specific and distinguishable from sibling tools like authenticate or connect, which serve different purposes.

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 usage: call this tool to check version information. No exclusions or alternatives are needed because no sibling tool provides version info, and context is clear. Slightly above baseline as it is an obvious use case.

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 the tool read-only, idempotent, and non-destructive, and the description's 'Returns ... state' is consistent with that profile. It adds output categories but no additional behavioral context such as authentication needs, freshness/caching behavior, or edge-case side effects.

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 front-loaded sentence that leads with the action and resource, then uses a concise colon-separated list to enumerate the return contents. There is no fluff, redundancy, or repetition of annotation 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?

For a zero-parameter informational tool with strong annotations and a clearly enumerated return payload, the description is complete enough. It gives the agent all relevant information needed to select and invoke the tool without 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?

The tool has zero parameters, so parameter documentation is not needed; the schema covers this fully. Per the baseline for no-parameter tools, this is handled appropriately, and the description adds no misleading parameter information.

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 a concrete resource ('current toolkit state'), then enumerates exactly what that includes: installed MCPs, connection status, connected accounts, and catalog-tool counts. This clearly differentiates it from siblings like show_version and report_bug.

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 usage context is implied: call this to inspect toolkit state, MCP connections, and connected accounts. However, there is no explicit when-to-use statement, no prerequisites, and no named alternatives or exclusions relative to sibling tools.

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