Recall

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

The description reveals important behaviors beyond annotations: config-based login gives a non-expiring connection, token-based login is session-only, and no-args calls return a login link. This complements the annotations without contradicting them, though it does not detail error conditions or what happens after authentication.

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 all sentences contribute useful guidance. The structure is a bit dense and some phrasing is awkward, but it front-loads the core instruction and then presents two options clearly.

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 one optional parameter, no output schema, and an uncomplicated auth flow, the description covers both entry points (token vs no-args) and explains the long-term session setup. It does not describe what the tool returns on success/failure, but this is not essential for this simple 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?

With 0% schema description coverage, the description carries the full weight. It clarifies that the token parameter is a JWT and describes usage from the user's perspective. It could add stricter format or expiry details, but is enough for correct invocation.

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 this as the authentication tool for MCP.AI: it tells the agent to have the user log in, copy the access token, and pass it either through configuration or the token parameter. It distinguishes itself from sibling tools like 'connect' by specifying its exact role and the browser/token 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?

Explicit guidance is given for the two modes: permanent login via config header, and session-only login by pasting the token. It also explains calling with no args to get the link, covering the practical decision points. It does not compare itself to sibling tools, but this is not essential for a self-contained authentication flow.

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 indicate readOnlyHint: true, idempotentHint: true, and destructiveHint: false, so the safety profile is clear. The description adds value by explaining the response structure in detail: when authenticated:true and pending[] empty, and when it returns connect_url and per-install URLs. It does not contradict 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 two sentences, front-loaded with the purpose, and every phrase adds value (explains status conditions and return URL details). No waste.

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 simple nature (no params, no output schema), the description is complete for understanding the return status and URL behavior. It covers the main states and what to expect. Minor gap: it doesn't describe the exact return format or any error cases, but the context signals indicate a simple 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?

There are zero parameters, so the schema provides no semantic info. The description fully explains what the tool returns, which compensates for the lack of parameters. A baseline of 4 is appropriate since no parameter info is needed or provided.

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 fetches connection status and URLs, specifying the distinction between authenticated and pending states. It distinguishes itself from siblings like 'authenticate' which would initiate authentication, though it doesn't explicitly name the alternative.

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 for checking connection status, but does not explicitly state when to use this tool versus 'authenticate' or other siblings. It lacks guidance on when not to use it or under what conditions the status might be stale.

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 are sparse (readOnlyHint false, openWorldHint true, idempotentHint false, destructiveHint false) and provide no detail. The description compensates thoroughly: it explains that invoke works even when MCP is not installed, details credential/paid flow (returns connect or checkout/top-up links), states permission requirements for writes, and distinguishes one-off vs permanent installs. It adds context beyond the annotations without contradiction (no annotation_contradiction flagged).

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 front-loaded with the primary flow and key distinctions. Each sentence adds value—core flow, invoke vs install, permission notes, prompt library—yet it is a single dense paragraph that could be better organized (e.g., bullets for actions). It is not tautological but slightly verbose relative to the number of concepts covered; still, given the tool's complexity, it is appropriately sized.

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 23 parameters, no output schema, and 0 required params, the description must provide sufficient context. It covers the main use cases (search, describe, invoke, install, prompts), permission requirements, and credential/paid handling. However, it does not explain every action (e.g., resume, subscribe/cancel details) nor all parameter-specific behaviors (immediate, tier_slug). It is largely complete for primary flows but leaves niche actions vague.

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 bears full responsibility for explaining parameters. It gives meaning to core parameters (action, mcp_id, tool_id, arguments) through the described flow, and explains prompt-related actions (search_prompts, get_prompt, publish_prompt) at a high level. However, many parameters (e.g., immediate, tier_slug, conversation, report_context, request_details) are not explicitly defined, so the description only partially compensates for the schema gap.

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 tool's role: 'The official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It clearly distinguishes itself from siblings (recall_*, authenticate) by defining a specific domain (MCP catalog and execution) and outlines core actions (search, describe, invoke) with a clear main flow. The verb+resource is specific, and it differentiates from other tools by being the central MCP/action hub.

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 explicit when-to-use guidance: the core flow 'action=search discovers MCPs by intent → describe returns one MCP's full profile → invoke RUNS that tool.' It also contrasts invoke vs install: 'prefer invoke for a single/occasional use' vs 'install only to make an MCP PERMANENT.' It mentions when to use search_prompts for the prompt library, and identifies permission requirements for writes. Clear alternatives and exclusions are present.

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 readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context: chunks are returned, focus_query influences which chunks are selected, max_chunks constrains volume, and card_ids enables bulk execution. No contradiction with annotations exists.

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: the first sentence establishes purpose, the second covers control parameters, and the third covers bulk support. Every sentence adds value with 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 read-only retrieval tool with strong annotations, the description is largely sufficient: it states what is returned, how to focus results, how to limit volume, and how to batch. It does not describe the exact chunk return format or the account parameter, but given the tool's moderate complexity, this is 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 schema description coverage at 0%, the description compensates well for key parameters: focus_query selects which chunks return, max_chunks has range 1-50 and default 20, and card_ids enables batched execution. However, the account parameter is left undocumented, and card_id is only implicit from the tool's purpose.

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 the tool returns the content of a specific card as chunks, which distinguishes it from siblings like recall_list_cards and recall_search. However, it lacks an explicit verb such as 'retrieves' or 'returns', so it is clear but not maximally precise.

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?

Usage context is implied: it is for accessing a specific card's content, and guidance is given for focus_query and max_chunks. There is no explicit mention of when to prefer this over recall_search or recall_list_cards, nor any exclusion/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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the install-scoped context and the return fields (id and nickname), which goes beyond the annotations. No contradiction observed.

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 is front-loaded with the primary action and scope. It earns its place but could have added a brief note about the 'account' parameter without becoming verbose.

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 the purpose and mentions return fields (id and nickname), which is sufficient for a simple listing tool. However, the unexplained 'account' parameter leaves a gap in completeness, especially since there is no output schema or parameter documentation.

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 single optional parameter 'account' has zero schema description and the tool description does not mention it at all. With 0% schema coverage, the description should compensate, but it fails to explain what the parameter does, leaving the agent without guidance on how to use it.

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 'Lists Recall accounts linked to this install — id and nickname.' This clearly identifies the verb (lists) and resource (Recall accounts) with a scope (linked to this install), and distinguishes from sibling tools that list cards or search.

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 mentions that it lists accounts for the current install, but does not explicitly state when to use this tool versus alternatives like recall_list_cards or recall_search. It implies its use for retrieving account IDs, but lacks explicit guidance on when not to use it or prerequisites.

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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds the 'leitura' label and the no-filter default behavior, but it does not disclose potential pagination, ordering, rate limits, or authentication nuances. This is adequate but not rich beyond 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?

The description is three concise sentences with the core purpose first, followed by filter details and default behavior. Every sentence contributes information without repetition 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?

For a read-only list tool with no required parameters and no output schema, the description covers the main behavior, filter semantics, and default result. The main omission is the unexplained 'account' parameter and any mention of pagination, but overall the tool is well enough described for an agent to invoke it 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 description coverage is 0%, so the description must compensate. It does so by explaining tags as UUIDs, date_from/date_to as an ISO 8601 date range, and source_url_contains as a filter. However, the 'account' parameter is not mentioned at all, leaving a gap in an otherwise helpful explanation.

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 'Lista os cards da sua base Recall (leitura)', clearly naming the action (list), the resource (Recall cards), and the access mode (read). It also distinguishes this list-oriented tool from siblings like recall_get_card and recall_search by describing the full list behavior with optional filters.

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 explaining optional filters and the default behavior when no filters are provided ('Sem filtros, retorna seus cards'). It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for basic selection among siblings.

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 destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context: mode affects speed and result count, and bulk support accepts card_ids for batched execution. No contradictions or misleading statements 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 three concise sentences, front-loaded with the core purpose. Every clause earns its place: query semantics, mode behavior, optional filters, and bulk support. There is no filler or repetition.

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 9-parameter search tool with no output schema, the description covers the core usage, mode semantics, filters, and bulk behavior. The main omissions are the account parameter and date format details, and it does not describe result contents, but the annotations plus straightforward search semantics keep it reasonably 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-level parameter descriptions, the description carries the explanatory burden. It defines q as a natural-language query, explains mode's two values and default, lists optional filters, and introduces card_ids bulk behavior. It omits account and exact date_from/date_to format, so it is not perfect, but it adds substantial 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 opens with 'Busca semântica na sua base Recall' — a specific verb and resource — and clearly distinguishes this tool from siblings like recall_get_card and recall_list_cards by framing it as natural-language search. It also names the query parameter and optional filters, making the purpose unmistakable.

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: mode has focused (fast, fewer results, default) vs exhaustive (broader coverage) options, and optional filters are listed. It does not explicitly name sibling alternatives or say when not to use the tool, but the search-vs-fetch/list distinction 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?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds useful behavioral context beyond annotations by emphasizing the need for the conversation array for reproduction, implying the tool consumes this data for debugging. It does not contradict 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 two sentences, front-loaded with purpose, and directly followed by key usage guidance. Every word earns its place; there is zero waste.

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 lack of output schema and 0% parameter schema coverage, the description is incomplete. It omits semantics for two of three parameters (message, context) and does not clarify the format or expected content of the conversation string. It is sufficient only for basic orientation.

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 only explains the 'conversation' parameter (the array for reproduction) but leaves 'message' and 'context' undefined. The names are suggestive but not described explicitly, leaving ambiguity for required and optional 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 purpose with specific verbs and resources: 'Report a bug, missing feature, or send feedback.' It distinguishes from sibling tools (authentication, data retrieval, marketplace) by focusing on feedback reporting.

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 states when to use the tool (when encountering a bug, missing feature, or for feedback) and provides a key instruction ('Include the conversation array with recent messages for reproduction'). No exclusions or alternatives are mentioned, but the usage conditions are 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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which already cover the safety profile. The description adds the specific scope (MCP platform and adapter versions) beyond generic annotations. No contradiction with annotations. It could add more about the format or detail of the version output, but for a simple read-only query, the existing annotations and description are sufficient.

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 wasted words. It's perfectly sized for a simple no-parameter version tool. The structure is ideal - purpose is front-loaded and immediately understandable.

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 (0 params, no output schema, read-only annotations), the description is nearly complete. It clearly states what it shows. It could mention return format or any side effects, but with readOnlyHint and no parameters, there's little room for additional behavioral requirements. It's complete for its scope.

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 schema provides no parameter constraints. The description correctly notes the purpose but doesn't need to explain parameters. Baseline for 0 params is 4, and the description doesn't harm that. It could mention that no arguments are required, but the empty schema already communicates this.

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: 'Show the current MCP platform and adapter versions.' It uses a specific verb ('Show') and resource ('MCP platform and adapter versions'), which distinguishes it from siblings like authenticate or marketplace. It loses a point because it doesn't explicitly differentiate from potentially similar version-related tools like toolkit_info, but the scope is clear enough.

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 (when you need version info) but doesn't provide explicit when/when-not guidance or mention alternatives. It's a simple, obvious tool, so the lack of explicit guidance is acceptable, but there's no discussion of when to use this versus toolkit_info or other information 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds context about what information is returned (installed MCPs, connection status, accounts, catalog tool counts), which is useful but not extensive. 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 a single, concise sentence that efficiently lists the key information returned. No wasted words, and it's front-loaded with 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?

Given the tool has no parameters, no output schema, and strong annotations, the description is complete enough. It clearly states what the tool returns, which is the main information an agent needs. The lack of output schema is compensated by the description's explicit enumeration of return contents.

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 description doesn't need to explain parameter semantics. The baseline for 0 params is 4, and the description appropriately focuses on the return value rather than 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 purpose: returning the current toolkit state, including installed MCPs, connection status, connected accounts, and catalog tool counts. This is specific and distinguishes it from sibling tools like 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 implies usage for checking toolkit state but does not explicitly state when to use it versus alternatives. It doesn't mention exclusions or alternatives, but given the tool's self-explanatory nature and zero parameters, the context is clear enough.

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