Monte Bravo MCP

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

Annotations (idempotentHint=true) are consistent. Description adds context about permanent vs session login and that calling without args returns a link. No contradictions.

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?

Three sentences, front-loaded with purpose. Slightly dense but no wasted words. Could benefit from clearer structure (e.g., bullet points) but remains effective.

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?

Lacks output schema and description of return value (e.g., success/error). For a simple auth tool, it's adequate but incomplete regarding behavior after calling.

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 0% schema coverage, the description compensates fully by explaining the token parameter is a JWT and how to pass it (with or without args).

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 (authentication) and distinguishes it from siblings like 'connect' and 'marketplace' by specifying two authentication methods: permanent via config or session-only via token argument.

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 guidance on how to obtain the access token (log in, copy), best practice (add to config), and alternative (paste token) with calling conventions. Lacks explicit when-not-to-use, but context is sufficient.

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 adds behavioral context beyond annotations (readOnlyHint, idempotentHint) by detailing the two scenarios and the returned fields. No contradiction. Could mention if any side effects, but none expected.

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 concise sentences with clear structure. No wasted words, front-loaded with purpose and necessary detail.

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 parameter-free status tool, the description covers main scenarios. Could elaborate on other possible states or the exact format of URLs, but adequate given no 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?

No parameters in input schema, schema coverage 100%, baseline for 0 params is 4. Description adds no parameter info as none exists, which is acceptable.

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, distinguishing between all providers connected (authenticated:true) and missing credentials (connect_url). It uniquely identifies what this tool does among siblings.

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 explains return values in different states but does not explicitly guide when to use this vs alternatives like 'authenticate' or 'list_connections'. Implied usage as a status check, but no exclusions or explicit when-not-to-use.

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?

Description adds extensive context beyond annotations: explains invoke works without installation, provides auth/checkout links, and mentions workspace owner/admin requirements. 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?

Description is verbose (over 300 words) but front-loaded with core purpose. Could be more concise; includes some redundancy.

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 complexity (13 params, no output schema), the description does not fully address all parameters or explain return values. Missing details on outputs of actions like describe and invoke.

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 compensates by explaining key parameters (action, query, mcp_id, tool_id, arguments) through context, but leaves many parameters undocumented (limit, message, immediate, tier_slug, conversation, request_name, report_context, request_details). Partial but insufficient coverage.

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 it is the official marketplace and describes core actions (search, describe, invoke, install). It distinguishes itself from sibling tools by being the first tool for capability seeking.

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?

Explicitly says to use this tool first before external registries, when to use invoke vs install, and mentions action-specific flows. Provides clear when-to-use 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 destructiveHint=true, and the description reinforces the irreversible deletion of data and unavailability. It additionally reveals the return of an add_connection_url, providing useful beyond-annotation context. However, it doesn't detail other side effects like required permissions or rate limits.

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 action, and contains no filler. Every sentence adds critical information: revocation, deletion, data unavailability, and the returned reconnection URL.

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 one parameter and no output schema, the description adequately covers the effect and return value. However, the undefined 'item' parameter and lack of guidance on obtaining it leave a significant gap, preventing full autonomous use.

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 one required parameter 'item' with no description, and the tool description does not explain what 'item' refers to. With 0% schema description coverage, the description fails to add any meaning to the parameter, severely hindering correct usage.

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 tool revokes consent and deletes connection data for a specific bank, distinguishing it from sibling tools like 'connect' or 'force_sync'. The verb 'disconnect' and resource 'bank' are specific and unambiguous.

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 should be used when wanting to remove a bank connection, but lacks explicit guidance on when not to use it or alternatives. No mention of prerequisites or comparison to other tools like 'openfinance_list_connections' for obtaining the required item parameter.

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?

Description details polling behavior (up to ~60s), return fields (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and the effect of wait=false. Annotations are minimal (readOnlyHint false), so description fully compensates.

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?

Description is thorough but slightly long; however, it front-loads the main purpose and usage, and every sentence adds value. Could be tightened but remains well-structured.

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 no output schema, description fully explains return values and edge cases (needs_action, timed_out). Covers behavior for both wait settings and provides all necessary context for an agent to use the tool 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 has 0% description coverage, but description explains each parameter: `items` as an array of selectors (item_id, connector_id, or connector_name) and that omitting it syncs all; `wait` false for fire-and-forget. Adds significant meaning beyond types.

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 'Forces the bank to re-sync one or more connections NOW and WAITS for it to finish', providing a specific verb and resource. It distinguishes from sibling tools like openfinance_get_item_status by indicating it is for triggering syncs, not just checking status.

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?

Explicitly says 'Use this when a balance or transaction list looks stale' and notes it pulls fresh data WITHOUT disconnecting/reconnecting. It also provides an alternative: if timed_out, re-check with openfinance_get_item_status.

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 adds value beyond annotations by detailing error handling for CREDIT accounts returning BALANCE_FETCH_ERROR with a warning instead of throwing. It also outlines the response shape with results and errors arrays. This complements the readOnlyHint and idempotentHint 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 sentences, front-loaded with the core purpose and endpoint, followed by parameter instruction and then error/response details. Every sentence adds necessary information without redundancy.

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, parameter, error behavior, and response shape. It is missing prerequisites or authentication notes, but given the simple tool and existing annotations, it is largely complete. The lack of an output schema is compensated by the description.

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 the input schema having no parameter description (0% coverage), the description explicitly explains the account_ids parameter format as an array and the constraint of 1-50 items. This fully compensates for the lack of schema documentation.

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 real-time balance per account ID and specifies the HTTP endpoint. It distinguishes itself from sibling tools like openfinance_list_accounts which list accounts but not balances.

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. It provides parameter constraints (1-50 account IDs) but no guidance on when not to use it or what other tools might be more appropriate for related tasks.

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 and idempotentHint=true, indicating safe read operations. The description adds valuable behavioral context by specifying the batch output shape (`{ results, errors }`) and that it returns extended creditData, which goes beyond what annotations provide. No contradictions.

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 concise sentences: first states purpose and endpoint, second gives usage and output shape. No unnecessary words. The description is front-loaded with the most critical 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 no output schema, the description provides the output shape (`{ results, errors }`) and mentions key content (creditData). It does not list all fields of the account object, but for a one-parameter tool with minimal complexity, this is sufficient for correct usage. Covers batch behavior and error handling implicitly.

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 0% description coverage for the only parameter. The description compensates by specifying that `account_ids` is an array of 1-50 strings, adding constraints and purpose. This is sufficient for typical use, though it could clarify that these IDs come from list_accounts.

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 it returns full account objects with extended creditData per ID, distinguishing it from sibling tools like openfinance_list_accounts (which lists all accounts) and openfinance_get_account_balance (which only returns balance). The HTTP endpoint and batch processing are also specified, leaving no ambiguity about the tool's function.

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 a constraint on usage: pass an array of 1-50 account_ids. However, it does not explicitly state when to use this tool versus alternatives (e.g., when you need full details vs. list or balance). The agent must infer usage context from sibling tool names and descriptions.

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 (readOnly, idempotent, non-destructive), description discloses key behaviors: does not return transactions, batch shape {results, errors}, Pluggy field limitation, and nuanced interpretation of payments[] in Brazilian Open Finance. 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?

Description is longer than ideal but well-structured: core functionality first, then caveats and usage notes. Every sentence adds value, though slight trimming could improve 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?

Despite no output schema, description details response fields (financeCharges, payments array with subfields) and batch shape. Covers subtle financial domain knowledge (payment cycle interpretation) making it complete for the tool's complexity.

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?

Only parameter bill_ids is thoroughly described: must be an array of strings, instructions to discover ids via sibling tool, and the purpose of the parameter. Despite 0% schema coverage, the description fully documents the parameter semantics.

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 it returns bill-level detail for credit card bills by id, specifying fields like financeCharges and payments[]. It contrasts with openfinance_list_transactions for transactions, making the purpose specific and unambiguous.

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?

Explicitly tells when to use this tool (for bill details) and when to use alternatives (openfinance_list_transactions for individual transactions, openfinance_list_credit_card_bills to discover ids and check payment status). Provides clear guidance on interpretation of payments field.

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 and idempotentHint=true, indicating no side effects. The description adds behavioral details: returns executionStatus and connector metadata, and for the all-banks mode returns { count, items }. No contradictions 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?

Two sentences: first states the core functionality with return values, second explains parameter usage. No extraneous words, front-loaded with purpose. Highly efficient.

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 read-only tool with one optional parameter and no output schema, the description is mostly complete. It details the all-banks response structure but omits the exact single-bank response format (assumed direct object). Minor gap, but overall 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?

Schema coverage is 0%, so the description must compensate. It explains the 'item' parameter's purpose: omit for all banks, pass for a single bank. This adds critical semantics beyond the schema. Could briefly mention the expected format of 'item' (e.g., ID string), but adequate.

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 the current status of a bank connection, listing possible statuses like UPDATED, UPDATING, LOGIN_ERROR. It distinguishes two usage modes (all vs. single bank), which differentiates it from siblings like openfinance_list_connections.

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?

Explicitly guides when to omit the 'item' parameter for all banks vs. pass it for a single bank. Does not explicitly state when not to use the tool or compare to alternatives, but the two modes provide clear 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 indicate read-only, non-destructive, idempotent. The description adds value by disclosing that the balance field is connector-dependent and should not be treated as 'this month's bill', and explains billing cycle fields. 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 long but front-loaded with the main purpose. Every sentence adds necessary detail about usage and caveats. There is no fluff, though some minor condensation could improve succinctness.

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 no output schema and only 2 optional parameters. The description covers the return structure (fields like balance, number, type, bank, connector_id), parameter usage, and important behavioral nuances. It references sibling tools for further details, making it sufficiently complete for the complexity.

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 burden. It explains the two modes for the `item` parameter (omit vs pass). However, the `type` parameter is not explicitly explained as a filter, though its effect is implied by the return types mentioned. The description adds significant value but slightly lacks full parameter coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns accounts for a bank connection with specific fields (balance, number, type, etc.). It identifies the resource (accounts) and distinguishes from siblings like openfinance_list_credit_card_bills by noting which tool to use for standardized bill amounts.

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 omit `item` (to list across all linked banks) and when to pass `item` (to target a single bank). It also cautions about balance meaning and directs to another tool for standardized bill amounts, providing clear guidance on 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable behavioral details: caching, single aggregated response, no batch ids, and field explanations for `id`, `description`, `descriptionTranslated`, `parentId`, `parentDescription`. No contradictions.

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 sentences, concise, front-loaded with the main action, and each sentence adds value. No redundant 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 no parameters, no output schema, and read-only behavior, the description fully covers what the tool does, what the response contains, and how it relates to other tools. It is complete and leaves no ambiguity.

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 parameters, so the baseline is 4. The description adds no parameter semantics because there are none, but it correctly acknowledges the tool takes no input.

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 as 'Pluggy's transaction category taxonomy'. It distinguishes from sibling tools by mentioning the `id` field is used by `openfinance_update_transaction_category`, and no sibling lists categories.

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 clearly states the tool's purpose and links to the update tool, implying when to use it. However, it lacks explicit when-not-to-use or alternative tools 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 and destructiveHint=false. Description adds that it returns saved connections and includes an add_connection_url, but does not disclose additional behavioral traits beyond what annotations already cover.

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 with front-loaded action ('Returns the saved bank connections'). No redundant information, highly efficient.

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 no parameters, rich annotations, and no output schema, the description is complete. It clearly lists the return fields (connector_id, item_id, bank name, add_connection_url).

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 no parameters (0 params, 100% schema coverage). Description does not need to explain parameters. Baseline 4 applies as schema coverage is complete and description adds no parameter detail.

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 saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url), distinguishing it from sibling list tools like list_accounts or list_transactions.

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?

No guidance is provided on when to use this tool vs alternatives (e.g., list_accounts). It simply describes functionality without context of selection criteria.

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, idempotentHint), the description details payment attribution logic, derived payment_status, connector asymmetry, and limitations. It provides extensive behavioral context that an AI agent needs to use the tool correctly.

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 thorough but verbose, with redundant explanations. While front-loaded, it could be more concise without losing critical details. The length is somewhat justified by domain complexity.

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 output fields, derived logic, edge cases (connector asymmetry), cross-references to siblings, and error handling. It is highly complete given the complexity and lack of 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?

Despite 0% schema description coverage, the description explains each parameter's purpose: account_id required, account_ids for bulk, include_open_bill opt-in with trade-off, and implies pagination with page and page_size.

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 that the tool returns closed credit card bills for a CREDIT-type account, listing specific fields and distinguishing from sibling tools like openfinance_get_credit_card_bill (singular bill) and openfinance_list_transactions (itemized purchases).

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 guidance on when to use this tool (for closed bills, opt-in for open bill) and when to use alternatives (e.g., openfinance_list_transactions for itemized purchases). It also warns against common misinterpretations about payment attribution.

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 as false. The description adds value by detailing that errors are returned as a structured warning rather than thrown, and lists the fields included. No contradictions 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 consists of two well-structured sentences. The first sentence states the core purpose and lists included asset types. The second covers error behavior and data fields. No unnecessary words or repetition. Front-loaded with the most important 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?

For a read-only list tool with four optional parameters and no output schema, the description provides a thorough overview of the returned data, error handling, and supported asset types. The only gap is the lack of parameter documentation, but given the optional nature and the list's simplicity, the description is largely 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%, and the description provides no explanation of the four parameters (item, page, type, page_size). The mention of investment types in the description hints at the type parameter's enum, but this is indirect and insufficient. The description fails to compensate for the missing schema descriptions.

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 specific verbs and nouns: 'Returns the investment portfolio' followed by a list of asset types. It clearly identifies the resource (investments for a connection) and distinguishes it from sibling tools like openfinance_list_accounts which deal with accounts, not investments.

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 investment portfolio retrieval by naming specific asset classes and noting that it returns a warning when INVESTMENTS is not enabled. While no explicit 'use instead of X' language exists, the context of sibling tool names and the clear scope make the use case evident.

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 declare readOnlyHint and idempotentHint true, destructiveHint false. Description adds behavioral context about data fields (quantity, value, expenses) and bulk execution, which is consistent with 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?

Three concise sentences, front-loading the core functionality and data details. No unnecessary words, every sentence adds value.

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?

Provides essential context for the tool's purpose and key output fields, but lacks details on pagination parameters and complete output format. Given 0% schema coverage and no output schema, the description could be more 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?

The description mentions investment_id and investment_ids for bulk, but does not describe page and page_size parameters (pagination). With 0% schema description coverage, the description should compensate by documenting all parameters, but it falls short.

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?

Clearly states it returns movement history for investment positions, listing specific transaction types (BUY, SELL, etc.) and key data fields. Distinguishes from sibling tools by specifying use after openfinance_list_investments.

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?

Explicitly instructs to use after openfinance_list_investments to obtain investment_id, and mentions bulk support with investment_ids. No explicit exclusions or alternatives, but provides clear context for correct invocation.

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, destructiveHint, idempotentHint), the description adds valuable behavioral details: sequential querying with rate-limit spacing, per-connection return structure with `results` and `errors`. No contradictions.

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 primary purpose. Every sentence adds value, no fluff.

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 list tool with one parameter and no output schema, the description covers usage, behavior, and return structure. It could mention typical fields in loan contracts, but overall it's complete enough for effective use.

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 fully explains the `items` parameter: it's an array of connection selectors (item_id uuid, connector_id, or connector_name) and its optionality. It lacks specific valid formats but provides sufficient guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists loan contracts per bank connection, specifies the HTTP method (GET /loans), and distinguishes from sibling tools by mentioning per-connection listing. The verb 'Lists' and resource 'loan contracts' are specific.

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 on when to pass `items` (specific connections) vs when to omit it (all banks). However, it does not mention alternatives or compare to sibling list tools, slightly reducing guidance for selection.

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?

Adds significant behavioral context beyond annotations: error handling (returns warning/error instead of throwing), aggregation behavior with search_queries (up to 5000 transactions), PENDING vs POSTED variability, and truncation handling. 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 front-loaded with purpose and contains valuable details, but is somewhat verbose. Every sentence is justified, but could be tightened slightly without loss. Still well-organized.

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?

Covers purpose, usage, error handling, edge cases, and sibling tools. However, without an output schema, the description does not describe the return structure (e.g., fields in results), which would be helpful for an agent. Very complete otherwise.

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 fully compensates by explaining all parameters: date filters (ISO YYYY-MM-DD), pagination (max 500/page), keyword search (case-insensitive, OR semantics), bulk support via account_ids. Adds meaning beyond the 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 returns transactions for bank accounts of type BANK or CREDIT, and distinguishes itself from the sibling tool openfinance_list_credit_card_bills by explaining when to use each.

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 provided: for CREDIT accounts, this is the only way to get itemized transactions; use the sibling tool for standardized totals; advises narrowing date range if truncated; suggests checking health status if total is zero.

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 adds significant behavioral context beyond annotations: it explains internal resolution of accounts, the 5000 transaction cap per account with a truncation flag, the compact summary format vs raw rows, and default granularity. No contradiction with annotations (readOnlyHint, destructiveHint, idempotentHint).

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 well-structured, starting with the main purpose and then detailing parameters. It is somewhat lengthy but every sentence adds value. Some phrases could be tightened, but overall it is effective and front-loaded.

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 no output schema, the description thoroughly explains the return format: compact summary with fields like 'total entradas', 'por_mes', 'top_despesas', and per-account breakdown. It also covers the truncation flag and filtering options, making it complete for agent understanding.

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 fully compensates by explaining each parameter: 'item' accepts connector_id, connector_name, or item_id; 'from'/'to' are ISO dates; 'granularity' defaults to 'monthly' and describes return data; 'type' filters BANK/CREDIT; 'top_n' is implied. This provides meaning beyond the raw 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 that this tool performs consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally and fanning out transactions. It distinguishes itself from sibling tools like openfinance_list_accounts by eliminating the need for prior calls, and it explains the output granularity options.

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 specific use cases (e.g., 'fluxo de caixa', 'maiores gastos') and explains when to use different granularity settings. It mentions that you do NOT need to call openfinance_list_accounts first, but it does not explicitly list alternative tools or conditions 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: it checks a public status page, returns global indicator, degraded components, open incidents, and flags incidents affecting connected banks via 'your_banks_affected'. 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 relatively long but every sentence adds unique value. It front-loads the main purpose and then adds usage guidance and return details. It is structured logically and efficiently.

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?

Despite having no output schema, the description comprehensively explains what the tool returns: 'global indicator (none/minor/major/critical), degraded components, open incidents, and — when you have banks connected — flags the incidents that affect YOUR connected banks in `your_banks_affected`'. It covers all necessary context for selection and 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 tool has no parameters, so baseline score is 4. The description does not need to add parameter semantics beyond the schema, which already has 100% coverage. No information about parameters is missing.

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 'Checks the LIVE operational status of the Open Finance provider (its public status page)', distinguishing it from the sibling 'openfinance_get_item_status' which checks connection health. The verb 'checks' and the resource 'provider status' are specific and unambiguous.

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?

Explicitly provides when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED (accounts/transactions/balances missing, a bank not returning everything)'. Also contrasts with 'openfinance_get_item_status' by stating it reveals 'provider-side problem' vs 'connection that just needs reconnecting'. Excellent usage 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 read-only, idempotent, non-destructive behavior. The description adds valuable context: it honors the user's plan (PF hides PJ banks), returns a ready connect_url, and never dumps the entire catalog without keywords. 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 somewhat lengthy but efficiently packs essential information. It is front-loaded with the purpose and provides examples. Every sentence adds value, though minor redundancy could be trimmed.

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 2 parameters, no output schema, and is a search/filter function, the description comprehensively covers what it returns (connector id, access, audience, linked connections, accounts, connect_url) and how it behaves (plan filtering, keyword requirement). The user's plan behavior and the connect_url are critical details provided.

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 explains keywords as an array of bank names (e.g., ['nubank','btg']) and states it is required despite not being marked as required in schema. It explains include_accounts returns accounts when true. Both parameters are adequately described.

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 searches available bank connectors by name (keywords) and returns specific fields including connector id, access type, audience, linked connections, and a connect_url. It distinguishes itself from siblings like openfinance_list_connections by explicitly stating it should be called before connecting.

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 instructs to call this BEFORE connecting to provide a one-click link, which is a clear usage directive. It also notes that keywords are required and that without them it returns a hint, not the full catalog. It does not explicitly exclude alternatives like listing existing connections, but the context makes the distinction 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?

The description discloses important behavioral traits beyond annotations: it overrides automatic categorization and creates a Category Rule for future similar transactions. It also explains batch handling with per-item errors not failing the whole batch. Annotations indicate readOnlyHint=false, consistent with description.

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 packed with information but is somewhat verbose with long sentences. However, every sentence adds value, and the structure is logical. It could be slightly more 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?

Given no output schema, the description provides a complete picture: purpose, usage, side effects, batch response format (updated, results, errors), and parameter sourcing. It covers all necessary aspects for correct tool 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?

Schema description coverage is 0%, so the description must add meaning. It explains the 'items' array structure, that transaction_id comes from openfinance_list_transactions, and category_id from openfinance_list_categories. This significantly supplements the 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 corrects the category of one or more transactions (PATCH /transactions/:id). It specifies the action (corrects), resource (transaction categories), and provides context on where input IDs come from (openfinance_list_transactions and openfinance_list_categories), differentiating it from sibling list tools.

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 to use this tool to 'fix miscategorized transactions and improve categorization accuracy going forward.' It explains the side effect of creating a Category Rule. While it doesn't explicitly mention when not to use it or alternative tools, the context is clear and useful.

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 idempotentHint=true and destructiveHint=false, and the description confirms it's a non-destructive reporting action. No contradictions, but the description adds little beyond what annotations already convey.

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, straight to the point, no unnecessary words. High information density.

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 reporting tool with no output schema, the description covers the essential purpose and key input. However, it lacks details on outcomes or response format, but this is acceptable given the tool's simplicity.

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%, and the description only mentions the conversation parameter briefly. The other parameters (context, message) are not explained beyond their names, which is insufficient for an agent to understand nuances.

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 reports bugs, missing features, or feedback, which is specific and distinct from sibling tools that are mostly related to OpenFinance operations.

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 advises including the conversation array for reproduction, providing clear usage context. However, it does not explicitly state when not to use it or mention alternatives, but given the niche purpose, this is minor.

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 and idempotentHint=true, meaning the tool is safe and idempotent. The description adds minimal behavioral context beyond confirming it shows versions, so it meets the baseline but does not exceed.

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 of 11 words, front-loaded and efficient. Every word earns its place with no redundancy.

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 a straightforward purpose, the description is fully complete. An agent can understand exactly 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?

There are zero parameters, and schema coverage is 100%. Per rubric, 0 parameters gives a baseline of 4. The description does not need to add 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 clearly states the tool shows 'the current MCP platform and adapter versions,' using a specific verb and resource. It is unambiguous and distinguishes itself from sibling tools like authenticate or openfinance tools.

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 provide explicit guidance on when to use this tool versus alternatives. While the simple purpose makes it obvious, it lacks when-not or alternative recommendations, which is a minor gap.

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, so the description need not repeat safety traits. It adds value by describing the output content, which is consistent with 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?

A single, clear sentence that front-loads the purpose and specific output details. No wasted words.

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 zero parameters, no output schema, and thorough annotations, the description sufficiently explains what the tool returns. It is complete for a simple state retrieval 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?

The tool has no parameters, so schema coverage is 100% by default. The description does not need to add parameter details; it correctly provides no param info.

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 returns toolkit state with specific details: installed MCPs, connection status, and catalog tool counts. It clearly distinguishes from sibling tools, which perform other functions like authentication or OpenFinance operations.

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?

No explicit when-to-use or alternatives are provided, but given it's a parameterless read-only info tool, the usage context is clear. It implies use for inspecting toolkit state, and siblings are generally not alternatives.

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