ONR: Mapa do Registro de Imóveis

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

The description explains the behavior of both modes (token provided vs. no args) and the distinction between permanent and session-based login. No contradiction with annotations; it adds context about configuration requirements and session limits beyond what annotations provide.

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 the purpose. Every sentence adds value: purpose, best practice, session alternative, and no-args behavior. Slightly verbose but not wasteful.

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 the main flows and security considerations. It could mention response format but is otherwise sufficient for an agent to invoke correctly.

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 fully compensates by explaining the 'token' parameter: it's the JWT pasted by the user, and that omitting it triggers link retrieval. This adds complete semantic meaning to the only 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's purpose: to authenticate IDE agents by logging in and obtaining an access token. It specifies the action (log in, copy token) and resource (access token), though it does not explicitly differentiate 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?

Provides explicit usage instructions: add token to config for permanent access or pass it as a parameter for session-based login. Also clarifies that calling with no args returns a link, giving clear context on when to use each mode, but does not mention when not to use this 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful output-cycle context: authenticated:true with empty pending[], and connect_url/toolkit URLs when credentials are missing. It does not fully describe partially configured states, but it is transparent for a simple status tool.

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 with no filler. It front-loads the core purpose and then immediately provides conditional behavior, making it efficient and easy to scan.

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 parameters and a simple read-only status method, the description is complete. It explains the primary return values and the two important output states, and there is no output schema to compensate for.

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 input schema has zero properties, so there are no parameters to explain. The description reasonably does not add parameter-level details because none are required.

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 returns connection status and URLs, with concrete state-dependent output. It distinguishes itself from sibling tools like authenticate by framing this as a read-only status check rather than an authentication action.

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 context for when to use the tool by describing the two key scenarios: all providers connected versus credentials missing. It does not explicitly contrast with sibling alternatives, but the intended usage is strongly implied.

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 annotations (readOnlyHint=false, openWorldHint=true), the description details that invoke works without installation, requires owner/admin for writes, and returns connect/checkout links on missing credentials or funds. This adds significant behavioral context not encoded in 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 dense and front-loaded, covering the core flow before edge cases, with no filler sentences. However, it's a single long paragraph that would benefit from bullet points or line breaks to improve scannability, given its 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 tool with 23 parameters and no output schema, the description covers all major aspects: core flows, edge cases (auth, payment), permission requirements, and the prompt library sub-feature. It even differentiates between installed_in_toolkit and installed_in_workspace flags, demonstrating completeness.

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 and 23 params, the description compensates by explaining the action values (search, describe, invoke, etc.) and their effects on behavior. It mentions tool_id and arguments implicitly through the invoke flow but does not systematically document each parameter (e.g., limit, query, prompt_* fields), which would have elevated it further.

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 explicitly states the marketplace is 'the in-platform catalog of every MCP/tool, AND the way to run them,' immediately followed by the search→describe→invoke flow. This clearly differentiates the tool from siblings like authenticate or show_version by detailing the tool's lifecycle within the first two sentences.

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?

Gives direct guidance: 'Use install only to make an MCP PERMANENT in the active toolkit; prefer invoke for a single/occasional use.' It also explains when to use subscribe/cancel, report_bug, and request_mcp, explicitly contrasting with alternatives.

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, idempotent, non-destructive. The description adds that it is hosted on the platform, requires no platform credentials, is pay-per-query with prepaid credits, and is not confidential data, plus LGPD responsibilities for the client.

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 four concise sentences, each adding distinct information (purpose, hosting/payment, data nature, legal responsibility). No redundancy and it front-loads the main purpose.

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?

While the description covers the operational and legal context, it omits essential parameter semantics and expected return values. For a query tool with no output schema and no parameter descriptions, this is a significant gap that hinders 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?

The input schema lists 'camada', 'car', and 'hash_endereco' with no descriptions, and the tool description does not explain what these parameters mean or how they should be used. With 0% schema description coverage, the description fails to compensate, leaving the agent unable to construct a valid query.

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 identifies the tool as a query (consulta) on the 'Mapa do Registro de Imóveis' using an official source. It stands out from sibling platform tools (authenticate, connect, etc.) as the only data query tool.

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 about when to use: when needing official Brazilian property registry map data. It explains the payment model and data availability, but does not explicitly state when not to use or name alternatives.

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, destructiveHint=false, and idempotentHint=true, so the description adds little behavioral insight beyond 'reporting' and the reproduction instruction. It does not contradict annotations but also does not elaborate on side effects, return details, or what happens with the data.

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 sentence that front-loads the purpose and includes a critical usage hint about the conversation array. No redundant words or 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?

The tool has 3 parameters and no output schema. The description covers the essential purpose and mentions the most important parameter (conversation), but does not state what the tool returns or any additional context like authentication or expected response. For a simple reporting tool, it is adequate but not 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?

With 0% schema description coverage, the description must compensate. It explains 'conversation array' as containing recent messages for reproduction, and implies 'message' is the content of the report, but 'context' is not explained. This gives partial value but falls short of fully clarifying all three 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 verb 'Report' and the resources 'bug, missing feature, or send feedback,' making the tool's purpose unmistakable. It is distinct from sibling tools like 'connect' or 'show_version' since none are related to reporting issues.

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 reporting a bug, missing feature, or feedback') but does not explicitly contrast with alternative tools or state when not to use it. It includes a specific instruction to include the conversation array, which is a parameter-level guidance rather than usage context.

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, covering safety. The description adds that it shows both MCP platform and adapter versions, which is useful context beyond the annotations. No further behavioral disclosure is needed for a no-parameter read-only tool.

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 sentence that directly conveys the tool's purpose with no unnecessary words, earning a top score for conciseness.

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 trivial nature, no parameters, and no output schema, the description sufficiently covers everything an agent needs to know to select and invoke it. It clearly states what versions will be shown.

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 and the schema has no properties, so the description does not need to explain parameter semantics. Baseline for zero-parameter tools is 4, and the description adds no misleading 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 clearly states the tool shows current MCP platform and adapter versions, using the specific verb 'Show' and naming the resource (version info). It is distinct from sibling tools, which handle authentication, connectivity, marketplace, and other 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?

The description implies the tool is used when version information is needed, but it does not explicitly state when to use it or provide alternatives. Since there are no similar sibling tools, the context is clear but not explicitly framed.

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 safety profile is well covered. The description adds value by specifying what information is returned (installed MCPs, connection status, accounts, catalog tool counts), which goes beyond the annotations. However, it does not disclose details like potential latency or whether the state is cached, but given the annotations, a 3 is appropriate.

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, concise sentence that front-loads the purpose and lists the key information returned. Every word earns its place, with no redundancy or 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?

Given the tool's simplicity (no parameters, no output schema), the description is complete enough. It covers the main aspects of the toolkit state. It could potentially mention whether the output is a summary or detailed, but the description is sufficient for an agent to understand what to expect.

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, and the schema is empty. The description does not need to explain parameters, and the baseline for zero-parameter tools is 4. The description effectively communicates what the tool does without needing parameter details.

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: it returns the current toolkit state, listing installed MCPs, connection status, connected accounts, and catalog tool counts. This is specific and distinguishes it from sibling tools like authenticate or connect, which handle setup actions.

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 a read-only informational tool for checking the toolkit's current state, which is clear from the context. However, it does not explicitly state when to use it versus alternatives (e.g., when to use show_version or marketplace), though the purpose is distinct enough that usage is reasonably inferred.

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