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?

Discloses key behaviors: invoke runs one-off without installing, may return connect or checkout links, and write actions require owner/admin. Annotations confirm non-readOnly, non-idempotent, non-destructive, and description adds significant 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 lengthy but densely informative with no wasted words. It front-loads the core purpose and flow. Could benefit from more structured formatting (e.g., bullet points) but remains clear and 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 the tool's complexity (15 parameters, multiple actions, no output schema), the description thoroughly covers the workflow, behavioral nuances, permission requirements, and edge cases (credential/payment handling). It is sufficiently complete for an AI 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?

With 0% schema description coverage for 15 parameters, the description compensates by explaining the role of key parameters through action descriptions (e.g., query for search, mcp_id for describe). However, not all parameters like limit, immediate, or tier_slug are explicitly explained.

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 defines the marketplace as 'THE official mcp.ai marketplace' and explains it serves as both a catalog and execution platform. It distinguishes the core flow (search, describe, invoke) from sibling tools like list_tools and authenticate.

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 this tool 'FIRST, before any external/generic registry.' Provides detailed guidance on when to use invoke vs install, prerequisites for write actions, and what to do when credentials or payment are needed.

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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: potential degradation to last-synced balance, structured warnings for CREDIT accounts, and the response shape. 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 is concise with no fluff. It front-loads the main purpose, then covers edge cases and response shape efficiently. 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 one-parameter tool without an output schema, the description covers the key behaviors: real-time, degradation, warnings, and response format. It could mention authentication requirements, but annotations imply read-only access. Overall, it's sufficient 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?

The input schema has 0% description coverage, so the description must compensate. It specifies the array type and size constraint (1–50), which is helpful. However, it could further clarify that each string is an account ID, though this is implied by the tool name.

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

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

The description clearly states the tool's purpose: returning a real-time balance payload per account ID, with the endpoint explicitly mentioned. It uses a specific verb and resource, and the name itself distinguishes it from sibling tools focused on accounts, transactions, and other data.

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 use the tool, including constraints like array size (1–50) and edge cases (CREDIT accounts, institution unavailability). However, it does not explicitly exclude alternatives or compare with siblings, leaving some ambiguity for the agent.

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. Description adds batch shape {results, errors} and provider_incident context, enhancing transparency.

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 informative and front-loaded with purpose; each sentence adds value, though 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?

Despite no output schema, the description covers return shape and critical caveats (provider incident). Missing details on error handling, but sufficient for typical 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?

Schema has 0% coverage, but description explicitly explains account_ids parameter (array of 1-50) and batch shape, compensating for 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?

Description clearly states the tool returns full account objects with extended creditData by ID, distinguishing it from siblings like openfinance_list_accounts (list-only) and openfinance_get_account_balance (balance-only).

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?

Specifies passing account_ids as array 1-50 and warns about provider_incident making values unreliable, but does not explicitly guide when to use this vs. 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?

Adds significant value beyond annotations: batch shape {results, errors}, Pluggy lacks paid/status field, payments[] reflects previous bill's payment, and creditCardMetadata.billId is inconsistent. No contradiction with readOnlyHint.

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 each sentence adds value. Starts with purpose, then caveats. Could be slightly more concise, but complexity justifies 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?

Despite no output schema, description details return fields and batch shape. Covers what the tool does and does not do, plus critical behavioral nuances for Brazilian Open Finance and Pluggy. Complete for a complex domain.

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 compensates by explaining bill_ids should come from openfinance_list_credit_card_bills and must be passed as an array. Could add format hints but sufficient.

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 explicitly states it returns 'bill-level detail for one or more credit card bills by id' with specific fields (financeCharges, payments). Clearly distinguishes from siblings like openfinance_list_credit_card_bills (for discovery) and openfinance_list_transactions (for itemized 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 guidance: use openfinance_list_credit_card_bills first, do not use for itemized transactions (point to openfinance_list_transactions), and warns about payments[] interpretation. Also cautions against reconstructing bill totals from transactions.

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?

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds detail on batch result shape, array size limits, and specific return fields, going 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?

Compact, front-loaded with purpose, then details, usage guidance, parameter specification, and return shape. 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?

No output schema, but description lists many return fields, covers batch results/errors, parameter constraints, and references sibling tool. Complete for a detail 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?

Schema has 0% coverage, but description adds that loan_ids is an array of 1-50 strings, and mentions batch shape, compensating 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?

Clearly states it returns full loan contract detail by ID, lists specific fields, and distinguishes from sibling openfinance_list_loans.

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 after openfinance_list_loans to deep-dive on a specific contract', providing clear when-to-use 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 confirm read-only, idempotent, and non-destructive behavior. The description adds critical context: explains field semantics (e.g., 'name' vs 'bank'), the unreliable nature of some data during provider incidents, and the caveat about credit balance meaning varying by connector.

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 verbose; however, every sentence adds value and the core purpose is front-loaded. It could be slightly trimmed without losing clarity.

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

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

Given the tool's complexity (multiple account types, field meanings, provider incidents, alternative tools), the description is complete. It covers necessary details for correct invocation and interpretation, even without an output schema.

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

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

Schema has 0% description coverage, so the description must fully explain parameters. It does: explains that omitting 'item' aggregates all banks, passing it targets one, and clarifies the 'type' enum with examples ('BANK (checking/savings)' and 'CREDIT (credit card)').

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 accounts for bank connections, specifying account types (BANK, CREDIT) and included data fields. It distinguishes itself from sibling tools like openfinance_list_credit_card_bills by noting when to use that alternative 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?

Provides explicit guidance on when to omit or pass the 'item' parameter to list all banks or target a single bank. Also warns about the connector-dependent meaning of CREDIT balance and redirects to openfinance_list_credit_card_bills for standardized billing data.

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?

Beyond readOnlyHint and idempotentHint annotations, the description discloses extensive behavioral traits: payment_status derivation, cross-bill payment rules, open bill availability and confidence levels, connector asymmetry, bill grouping reliability, and conditions for warnings. 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 is long but well-structured with clear sections and bolded key terms. It front-loads the core return values. While verbose, the density of critical information for the complex domain justifies the length. Could be slightly more concise 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?

No output schema, so description must fully explain return values. It covers all fields: payments array with subfields, payment_status derivation, open_bill object details, future_bills, warnings, and connector asymmetry. It also explains what not to do (e.g., summing by billId), providing complete context for correct usage.

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 compensate. It extensively explains include_open_bill and account_ids (bulk support), adding significant meaning. However, it does not explicitly describe page and page_size parameters, though they are standard pagination. The description adds high value for the most important parameters.

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

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

The description clearly states it returns CLOSED credit card bills for a CREDIT-type account, listing returned fields. It distinguishes from siblings like openfinance_get_credit_card_bill (singular) and openfinance_list_transactions (itemized), making the purpose specific and differentiated.

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

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

The description provides explicit when-to-use instructions: opt-in include_open_bill for open bill and total debt, warning not to use account balance, and directs to openfinance_list_transactions for itemized purchases. It also clarifies cross-bill payment logic and connector asymmetry, giving clear guidance on alternatives and limitations.

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 many behavioral traits beyond annotations: auto-pagination, truncation at 5000, error handling (returns error object instead of throwing), detail levels and their implications, credit card PENDING/POSTED behavior variation, billId sparsity, provider incidents, and response structure. 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 well-structured: front-loaded with core purpose, then organized into logical sections (credit card specifics, filtering, pagination, detail options, response, error handling, bulk). Every sentence adds value, though slightly verbose; a bit more conciseness could improve readability without losing essential 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?

Covers all aspects needed for a complex tool with no output schema: account types, filtering, pagination, detail levels, error handling, response structure (account echo, warning/error, truncated flag), cross-tool references, and provider incidents. The agent gets complete guidance to invoke and interpret results 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% parameter descriptions, but the description compensates fully by explaining all 8 parameters: from/to as ISO YYYY-MM-DD, search_queries as case-insensitive substring search with OR semantics and 5000 limit, page for auto vs manual pagination, page_size max 500, detail levels with detailed explanations of what each returns, account_id and account_ids for bulk. Adds significant value.

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 accounts (BANK or CREDIT) and distinguishes itself from sibling openfinance_list_credit_card_bills by noting it is the ONLY way to get itemized credit card transactions. It specifies the verb (list) and resource (transactions), with clear scope and differentiation.

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 credit card itemized transactions) and when-not-to-use (e.g., do not sum by billId for bill totals, use openfinance_list_credit_card_bills instead). Also gives alternatives like openfinance_get_item_status for connection health and openfinance_list_accounts for statement dates.

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 beyond annotations: scan cap at 5000/account with truncated flag, provider_incident block indicating possible incomplete data. No contradiction with readOnlyHint, idempotentHint, or destructiveHint.

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?

Slightly long but densely packed with value. Front-loaded with main purpose. Every sentence adds new information; 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?

Given 7 parameters, no output schema, and annotations, the description is exceptionally complete: explains return structure, edge cases (truncated, provider incidents), and parameter combinations. 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 explains all key parameters: item (connector_id/name/item_id or omit), from/to (ISO dates), granularity (monthly/raw), detail (compact/rich/raw), type (BANK/CREDIT), and top_n (implied). Compensates fully 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?

Clearly states it performs consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally. Distinguishes from sibling tools by explicitly saying no need to call openfinance_list_accounts first.

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 scenarios (e.g., annual/monthly analysis, cash flow) and when to omit item for all banks. Mentions granularities and their use cases. Lacks explicit comparison to siblings like openfinance_list_transactions, but the exclusion of account_id requirement is helpful.

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.