Banco BRB MCP

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

Annotations already specify idempotentHint=true and destructiveHint=false. The description adds behavioral context beyond annotations: it explains that calling without token returns a login link, while calling with token logs in. This explains what the tool does in each case, though it could mention potential errors or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with clear structure: introduction, best practice, usage instruction. It is well front-loaded but includes some technical details (e.g., 'Authorization: Bearer') that could be trimmed for brevity. Still 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?

The description covers purpose, usage modes, and parameter meaning. However, it lacks details about the return value (e.g., success confirmation or error messages) and does not explain what happens after authentication (e.g., session state). Given no output schema, this is a notable 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?

Schema coverage is 0% with no parameter descriptions, so the description fully compensates. It explains the 'token' parameter as a JWT for session-only login, and clarifies that omitting the argument returns a login link. This adds 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 the tool's purpose: authentication for MCP servers in IDE agents. It specifies the resource (authentication token) and verb (login, obtain link), and distinguishes the tool from siblings like openfinance or marketplace which are unrelated to authentication.

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 two usage modes: permanent via config or session-only by passing a token. It explains when to use each (best practice vs. session-only) and how to invoke the tool (with or without arguments). However, it does not explicitly state alternatives or when not to use the 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 and idempotentHint=true. The description adds context about response structure (authenticated:true, pending[], connect_url) but does not reveal additional behavioral traits beyond 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 concise sentences front-load the purpose and explain key states with 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?

For a zero-parameter, read-only tool with strong annotations, the description is complete, covering both response scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so baseline 4 is appropriate. The description correctly omits parameter details as none exist.

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 connection status and URLs, differentiating between connected and missing credentials states. It uses specific verbs and resources.

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 behavior but does not explicitly state when to use this tool versus siblings like 'authenticate'. No when-not or alternatives are mentioned.

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 only indicate readOnlyHint=false, but the description extensively covers behaviors: invoke runs tools without installation, returns connect/checkout links for auth/payment, and lists actions requiring admin. 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 lengthy due to the tool's complexity but front-loads core purpose and flow. It could be better organized with sections, but every sentence adds value. Not overly verbose given the scope.

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?

No output schema exists, so the description should clarify return values. It mentions search/describe flags and error links but does not detail success responses for actions like list_tools or invoke. More completeness on return structures is needed.

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 partially compensates by explaining action (enum with flow), mcp_id, tool_id, and arguments. However, many parameters (e.g., limit, query, report_context) lack any explanation, leaving the agent to guess their roles.

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 is 'THE official mcp.ai marketplace' for discovering and running MCPs/tools, distinguishing it from sibling tools like openfinance functions. It outlines the core flow (search → describe → invoke) and contrasts with external registries.

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 instructions are provided: use this tool first before external registries, prefer invoke over install for one-off use, and handle credential/payment links. It also notes that write actions require workspace owner/admin, offering clear when-to-use and when-not-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 declare destructiveHint=true. Description adds that data will no longer be available and returns a reconnection URL, providing useful behavioral context beyond 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, front-loaded with action, no redundant information. Efficiently conveys purpose and key behaviors.

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 destructive tool with one parameter and no output schema, the description covers the core behavior, consequence, and reconnection option. Missing parameter details are a gap but overall adequate 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 has one parameter 'item' with 0% description coverage. Description indicates it identifies the bank but does not specify the format, source, or how to obtain it (e.g., from list_connections). Minimal value added.

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

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

Description clearly states the action (revokes consent), the resource (specific bank), and the consequence (deletes data). It is specific and distinguishes from sibling tools which are mostly read or list 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 guidance on when to use this tool versus alternatives. Does not mention prerequisites or context (e.g., needing to have a connection first). Implicitly for disconnecting, but no explicit 'use when' or 'instead of'.

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?

Discloses polling behavior up to 60s, return fields (status, executionStatus, etc.), error indicators (needs_action, timed_out), and the effect of omitting items. Annotations only provide basic hints; description adds full operational detail.

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 paragraph is well-structured with front-loaded core action. Slightly long (~100 words) but every sentence adds value; could be marginally 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?

Covers usage, behavior, parameters, return values, error states, and contrasts with sibling tools. No output schema exists, so description fills the gap thoroughly.

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 both parameters: items as array of selectors with omission meaning all, and wait as fire-and-forget mode. No additional meaning needed.

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 forces a re-sync and waits for completion. It distinguishes from siblings like openfinance_get_item_status by noting when to use that tool instead.

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 when-to-use: 'when a balance or transaction list looks stale'. Explains what it avoids: 'WITHOUT disconnecting/reconnecting'. Mentions alternatives for timed_out state and the wait parameter for fire-and-forget.

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 and idempotentHint. The description adds that CREDIT accounts may return BALANCE_FETCH_ERROR as warnings instead of throwing, and describes the response shape with errors, providing useful behavioral context beyond 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 plus a response shape note, all front-loaded with the main purpose. Every sentence adds value 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?

The tool has one parameter and no output schema; the description covers the response shape and error handling. It does not mention prerequisites like authentication, but sibling tools cover that. Overall, it is complete for a simple balance retrieval.

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?

Input schema has 0% description coverage, but the description adds critical semantics: account_ids must be an array of 1–50 items. This compensates for the lack of schema descriptions and clarifies the parameter's meaning.

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 payload per account id, specifies the REST endpoint, and distinguishes it from sibling tools like openfinance_list_accounts and openfinance_get_accounts_detail by focusing on 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?

Provides explicit instructions on how to pass account_ids as an array (1–50) and notes that CREDIT accounts may return warnings. Does not explicitly state when not to use, but the context of sibling tools makes it clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds the batch shape ({ results, errors }) and array size limit, which are useful behavioral details 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 sentences front-load the main purpose and then give input/output format. No wasted 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?

For a simple one-parameter tool with annotations, the description covers input constraints, output shape, and returned data (full account objects with extended creditData). It is complete given the tool's complexity and available structured fields.

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 description carries full burden. It specifies that account_ids must be an array (1–50), adding constraint and usage context the schema lacks. This compensates well for lack of 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 clearly states the tool returns full account objects including extended creditData per ID, and specifies the HTTP endpoint pattern. It distinguishes from listing tools by focusing on detailed per-ID retrieval.

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 usage guidance for the account_ids parameter (array, 1-50) but does not explicitly compare with sibling tools like openfinance_list_accounts or openfinance_get_account_balance. No when-not-to-use or alternative recommendations are given.

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 context beyond annotations: notes batch shape, Pluggy missing paid status, and explains the meaning of payments[] in Brazilian Open Finance. Annotations already indicate read-only and idempotent, so description enriches understanding of edge cases.

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 detailed and well-structured, front-loading the core purpose. It could be slightly more concise, but every sentence adds value. Minor redundancy in explaining payments[] 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?

For a single-parameter tool with no output schema, the description covers return fields, batch shape, and common pitfalls. It addresses domain-specific nuances (paid status, payment cycle) comprehensively, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining that bill_ids is an array of IDs discovered via the list tool. It gives contextual usage and the expected batch shape, making the parameter's purpose clear.

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 bill-level detail for credit card bills by ID, listing specific fields. It explicitly distinguishes from sibling tool openfinance_list_transactions by noting what it does NOT return (individual transactions) and directing to the appropriate tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear when-to-use: after discovering bill IDs via openfinance_list_credit_card_bills. Includes explicit alternatives (use openfinance_list_transactions for itemized transactions) and warns about misinterpretation of payments[] in Brazilian Open Finance.

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, and non-destructive behavior. The description adds context about return values (status, executionStatus, connector metadata) and the shape for all-banks calls ({ count, items }), which is beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, with the key action and parameter options front-loaded. Every sentence adds value 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?

For a simple status-checking tool with one optional parameter and no output schema, the description covers all necessary behavioral aspects. It explains both invocation modes and expected responses.

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% (no description for 'item'), but the description fully compensates by explaining that omitting 'item' returns status for all linked banks, while passing it returns status for a single bank. This adds essential meaning.

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 the current status of a bank connection with enumerated possible values. It explicitly distinguishes between using the tool without 'item' (all banks) and with 'item' (single bank), which sets it apart from sibling tools 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?

The description provides clear guidance on when to omit versus pass the 'item' parameter. However, it could be improved by explicitly stating when not to use this tool (e.g., for listing connections instead of getting 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?

Beyond annotations (readOnly, idempotent), it discloses critical behavioral traits: the meaning of 'bank' vs 'name', the connector-dependent nature of CREDIT balance, and the aggregation behavior when omitting item. This adds significant value.

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 detailed and front-loaded with key return info. While lengthy, each part serves a purpose (e.g., warnings about balance). Could be slightly more concise, but the complexity justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two optional parameters, multiple account types, and important caveats, the description covers everything needed: return fields, parameter usage, data interpretation, and references to sibling tools. No output schema, but return values are sufficiently described.

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 description must explain parameters. It clearly explains 'item' and its effect. For 'type', it mentions BANK and CREDIT but doesn't explicitly state that omitting returns both. Overall, adds substantial 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 it returns accounts for bank connections, listing both BANK and CREDIT types with specific fields. It distinguishes between listing all accounts (omit item) and targeting a single bank (with item), and even points to a sibling tool for billing details.

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: omit 'item' to list all accounts across banks (for requests like 'my accounts/cards') and use 'item' for a single bank. Also directs to openfinance_list_credit_card_bills for standardized billing amounts, clearly indicating 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?

Discloses caching behavior, single aggregated response (no batch ids), and the return structure. Annotations already provide readOnlyHint, idempotentHint, destructiveHint; the description adds valuable behavioral context beyond these.

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?

Concise, front-loaded with main purpose. Each sentence adds value: purpose, caching, field details, usage hint. No superfluous content.

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 and no output schema, the description adequately explains the return format and behavior. Lacks mention of error cases or what happens when cache is empty, but is sufficient for most agents.

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 exist, so the description has no need to explain them. Baseline of 4 is appropriate as schema coverage is 100% and no param info 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?

Clearly states the tool returns Pluggy's transaction category taxonomy, cached for the session. Specifies fields like id, description, descriptionTranslated, parentId, parentDescription. Distinguishes from the sibling openfinance_update_transaction_category by noting the id field's usage.

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?

Implies usage for retrieving category information, and notes that descriptionTranslated is preferred for pt-BR users. However, does not explicitly state when to use or not use this tool compared to other siblings, though the purpose is clear.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the description adds value by specifying return fields (connector_id, item_id, bank name, add_connection_url). No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys essential 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?

Given no input parameters and annotations covering safety, the description fully explains what is returned, enabling correct use. No output schema needed.

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 defined, and schema coverage is 100%. Baseline score of 4 applies as description needs no additional 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?

Clearly states the tool returns saved bank connections and lists specific fields. Title from annotations aligns. Distinguishes from sibling tools like connect or disconnect.

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 is implied by the description: use to list connections. No explicit when-to-use or when-not-to-use, nor alternatives mentioned. Slightly above minimum due to clarity.

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 and idempotentHint; description adds significant behavioral context: no paid field, payment cycle semantics, derived payment_status legend, connector asymmetry for open bill, and warning behavior when product not enabled. Goes well beyond 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?

Long but well-structured with bold, italics, and sections. Front-loaded with core purpose. Some repetition and detail could be trimmed, but overall organization helps readability.

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?

Very comprehensive despite no output schema. Describes return fields (payments[], payment_status, open_bill, future_bills) and edge cases (PAST_DUE_UNCONFIRMED, connector asymmetry). Provides complete guidance for complex credit card bill semantics.

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 description must compensate. It covers account_id, account_ids, and include_open_bill with context, but page and page_size parameters are not described at all. Some parameter meaning is inferable but not explicit, leaving gaps.

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 CLOSED credit card bills for a CREDIT-type account, listing specific fields. It distinguishes from sibling tools like openfinance_get_credit_card_bill and openfinance_list_transactions, making the purpose precise 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?

Extensive guidance: when to use (closed bills), when not (use openfinance_list_transactions for individual transactions), and important caveats about payment_status interpretation. Explicitly warns against assuming payment from payments[] and provides opt-in guidance for open_bill.

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 read-only and idempotent behavior. The description enhances transparency by detailing the exact fields returned (balance, rates, dates, etc.) and specifying graceful error handling (returns object with warning instead of throwing on 403/errors). This adds significant behavioral context beyond 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, well-structured paragraph that efficiently conveys purpose, covered asset types, key data fields, and error handling. Every sentence adds value; no redundancy or 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?

The description covers return values and error handling comprehensively for a read-only list tool. However, it lacks explanation of input parameters and pagination behavior, which are important for usage. With no output schema, slightly more detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description does not explain any of the four parameters (item, page, type, page_size). The enum values for 'type' are listed in schema but not elaborated in text. Users receive no guidance on how to use these parameters from the description.

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

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

The description uses the specific verb 'Returns' and clearly defines the resource as 'investment portfolio' for a connection, listing all covered asset classes (FIIs, stocks, ETFs, etc.). Although it does not explicitly compare to sibling tools, the detailed enumeration makes the purpose unambiguous and distinct from related tools like openfinance_list_investment_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?

The description does not provide explicit guidance on when to use this tool versus alternatives like openfinance_list_investment_transactions. It implies the use case through listing portfolio items, but no direct comparison or when-not-to-use advice is given.

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, and the description adds no contradiction. It provides additional behavioral details about the returned fields (quantity, value, netAmount, expenses) and transaction types, enhancing transparency beyond 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 paragraphs: first lists the output details, second gives usage order and bulk support. It is concise, front-loaded with the main purpose, and contains no unnecessary 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 the absence of an output schema and 4 parameters, the description covers the core functionality, output fields, prerequisite usage, and bulk capability. However, it omits details on pagination behavior (page, page_size) and potential limitations, leaving minor gaps for a fully complete 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?

Schema description coverage is 0%, so the description must compensate. It explains the purpose of investment_id and investment_ids (bulk), but does not describe page or page_size (pagination parameters). The description adds partial value but 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 movement history for a specific investment position, listing transaction types like BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER. It distinguishes itself from sibling tools like openfinance_list_transactions by focusing on investments and requiring the investment_id from 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?

The description explicitly instructs to use after openfinance_list_investments to obtain the investment_id, and mentions bulk support via investment_ids. While it doesn't explicitly state when not to use, the context of sibling tools makes the scope 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?

Adds key behavioral details beyond annotations: HTTP method, per-connection querying, rate-limit spacing, and return structure ({results, errors}). Annotations already indicate read-only and idempotent.

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?

Four sentences, front-loaded with the main purpose, no redundant information, 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?

Fully covers the tool's behavior, parameter, and return format without an output schema. Simple tool with one optional parameter, well-explained.

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 schema only defines `items` as an array of strings; the description enriches it with concrete connection selector formats (item_id, connector_id, connector_name) and usage 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?

The description clearly states it lists loan contracts per bank connection via GET /loans, differentiating from sibling tools like openfinance_list_accounts and openfinance_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?

Explicitly explains when to pass `items` (specific connections) and when to omit (all banks), plus notes sequential fetching with rate-limit spacing. Lacks explicit reference to alternative tools for other data types.

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?

Discloses auto-pagination, 5000-ceiling truncation, error handling returning warning/error instead of throwing, and CREDIT PENDING/POSTED variation by bank. Annotations already indicate read-only/idempotent; description adds valuable context.

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?

Long but well-structured, front-loaded with purpose and key behaviors. Could be slightly trimmed but justified by tool 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?

Highly complete: covers purpose, sibling relationships, parameter nuances, pagination, error modes, detail levels, and troubleshooting. The lack of output schema is compensated by description of return shapes.

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 explains all parameters: from/to ISO format, pagination behavior, detail enum meanings, search_queries semantics, and bulk support via account_ids.

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 transactions for BANK or CREDIT accounts, and distinguishes from siblings like openfinance_list_credit_card_bills by specifying it's the only way to get itemized credit card 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?

Provides explicit when-to-use (e.g., for itemized credit card transactions) and when-not-to (use bills for totals), along with detail level recommendations and troubleshooting advice.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses key behaviors: internal account resolution, transaction fan-out, a scan cap of 5000/account with truncation flag, and the exact return structure for each granularity/detail combination. This fully informs the agent of costs and constraints.

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 comprehensive but somewhat dense; it packs many details into a single paragraph. Front-loading the main purpose is good, but a slightly more structured layout (e.g., bullet points for parameters or behaviors) could improve readability for an AI agent. Nevertheless, every sentence adds value 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?

Given the tool has 7 parameters, no output schema, and moderate complexity, the description covers all critical aspects: invocation, parameter semantics, behavioral constraints (truncation), and return structure for different modes. An agent can fully understand how and when to use this tool without additional 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?

Despite 0% schema description coverage, the description explains the purpose and allowed values for most parameters: 'item' (connector_id/name or omitted), 'from'/'to' (ISO dates), 'granularity' (monthly/raw), 'detail' (compact/rich/raw), and 'type' (BANK/CREDIT). The 'top_n' parameter is implicitly explained via 'largest N each'. One minor gap: the exact mapping of 'top_n' to output sections is not explicit, but overall the description effectively compensates for the schema's lack of 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 clearly states the tool provides consolidated cash-flow analysis for a whole bank connection in one call, distinguishing it from other list tools by explaining it resolves accounts internally and fans out transactions. This specificity leaves no ambiguity about the tool's core 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?

The description explicitly lists use cases ('análise anual/mensal', 'fluxo de caixa', etc.) and explains when to use different granularities (monthly vs raw) and detail levels. However, it does not explicitly state when NOT to use this tool versus alternatives like openfinance_list_transactions, though the context strongly implies it.

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. The description adds value by detailing what the tool returns (global indicator, degraded components, open incidents, your_banks_affected) and that it reads a public status page, enhancing transparency beyond 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 concise with four sentences that front-load the main purpose and usage guidance. Every sentence is meaningful, though slightly verbose in the middle. Still, it's efficient and structured well.

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 and zero parameters, the description fully covers the tool's behavior, return values, and use cases. It explains the response structure and how to interpret results, making it complete for an agent.

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 baseline is 4. The description correctly omits parameter details since none exist, and schema coverage is 100% (empty schema). No additional parameter semantics needed.

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, distinguishing it from the sibling tool openfinance_get_item_status. It uses a specific verb ('checks') and resource ('provider status'), making the purpose 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 explicitly tells when to use this tool: when data looks incomplete or stale despite a connection showing UPDATED, to diagnose upstream outages. It contrasts with openfinance_get_item_status, providing clear 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 indicate read-only, idempotent, non-destructive. Description adds that it honors user's plan, returns a hint without keywords, and surfaces caveats for non-Open-Finance connectors. No contradiction; all behavioral aspects are well disclosed.

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 relatively long but dense with valuable information. It front-loads the core purpose and proceeds logically. Slightly verbose but justified given the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description covers return values comprehensively (connector id, access, audience, accounts, connect_url, caveat). Also includes plan integration, prerequisite behavior, and response to missing keywords. No gaps.

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 clarifies keywords[] is REQUIRED (despite schema not marking required) and explains the effect of include_accounts. Adds crucial semantics beyond schema, though lacks explicit format details like expected string casing.

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 searches bank connectors by keywords and returns connector id, access type, audience, linked connections, and connect_url. It distinguishes from siblings by emphasizing its role as a prerequisite for connecting, and explicitly mentions 'Call this 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?

Provides explicit when-to-use guidance: 'Call this BEFORE connecting'. Also explains when not to use (without keywords returns a hint, never dumps catalog), and highlights plan restrictions and caveats for credential connectors, helping the agent choose the right path.

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 reveals key behavioral details beyond annotations: it overrides Pluggy's automatic categorization, creates a Category Rule for future similar transactions (case-insensitive exact match), and describes batch behavior including per-item error handling without failing the whole batch.

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 concise yet comprehensive, front-loading the core purpose and method, then providing necessary context on IDs, side effects, and response structure 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?

Given the complexity of batch updates, side effects, and lack of output schema, the description covers all essential aspects: how to use, what happens (rule creation), error handling, and response structure.

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 fully compensates by explaining that 'items' is an array of objects with transaction_id and category_id, specifying their sources (from sibling tools), and detailing the batch response format including updated counts, results, and errors.

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 transaction categories, specifies the HTTP method (PATCH), and distinguishes it from sibling tools like openfinance_list_transactions and openfinance_list_categories by explaining how to obtain the required IDs.

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 when to use the tool (to fix miscategorized transactions and improve future categorization), provides sources for input IDs, and implies that it is the correct tool for recategorization. However, it does not explicitly exclude alternative tools or mention when not to use it.

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, suggesting safe, repeatable behavior. The description adds that the conversation array is for reproduction, implying the tool logs the report. However, it does not explain what happens after submission (e.g., ticket creation, response).

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 concise—two sentences with no unnecessary words. It front-loads the purpose and follows with actionable guidance. A slightly more structured format (e.g., listing parameters) could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 3 parameters and no output schema. The description covers the reproduction aspect but omits details on the 'context' parameter and what the user can expect as a result (e.g., confirmation message). Adequate for a simple reporting tool but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must add meaning. It partially does by mentioning 'conversation array' should include recent messages. However, it does not explain the 'context' parameter or the format of 'message', so only partial compensation 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 clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It identifies the specific verb (report) and resource (bug/feature/feedback), and distinguishes effectively from sibling tools that are focused on financial data access and authentication.

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 guidance: 'Include the conversation array with recent messages for reproduction.' This tells users what to include when using the tool. However, it does not mention when not to use it or provide alternatives for other types of queries.

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 true/false appropriately. The description adds useful context by specifying exactly what versions are shown ('MCP platform and adapter versions'), going beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, succinct sentence with no extraneous words. It is appropriately front-loaded and every word 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?

Given no parameters, no output schema, and a simple task, the description is complete. It tells the agent exactly what the tool does without missing any necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the description cannot add parameter information. With 0 parameters, the baseline is 4, and the description suffices without needing to explain anything about inputs.

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

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

The description clearly states the verb 'Show' and the resource 'current MCP platform and adapter versions,' making its purpose specific and distinct from all sibling tools, none of which deal with version display.

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?

While no explicit when-to-use or when-not-to-use guidance is given, the function is so simple (retrieve version info) that its usage is self-evident. A minor deduction for lack of explicit context compared to more complex 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, idempotentHint, and destructiveHint, so the description adds value by detailing the returned data without contradicting 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, front-loaded sentence containing all necessary information without redundancy, earning its place 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?

Given the zero-parameter, no-output-schema design, the description provides adequate completeness by specifying the return content. It is slightly vague on potential error states but sufficient for a simple informational 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 no parameters and 100% schema coverage, the description does not need to add parameter information. It appropriately focuses on the output, earning the baseline score of 4.

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

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

The description uses a specific verb ('Returns') and clearly identifies the resource ('current toolkit state') with enumerated items ('installed MCPs, their connection status, and how many catalog tools each exposes'), making it distinct from sibling 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 implies usage for inspecting toolkit state but does not explicitly state when to use this tool versus alternatives or any exclusions. It is clear but lacks explicit guidance.

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