BTGPactual MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false, and the description explains that calling with no args returns a login link, while calling with a token performs authentication. This adds contextual behavior beyond annotations, such as the two possible outcomes. 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 efficient, front-loading the purpose and then detailing two usage scenarios. Every sentence is informative, though slightly verbose with 'MCP.AI for IDE agents (Cursor, etc.):' which could be trimmed.

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

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

Given no output schema and a simple tool, the description covers the main behaviors but lacks details on error handling, token validation outcomes, or what the returned link looks like. It is adequate but not fully comprehensive.

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

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

The schema has 0% description coverage, but the description compensates by clarifying that the 'token' parameter is for pasting a JWT for session login, and that omitting it returns a link. It adds meaning beyond the schema's type/format.

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

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

The description clearly identifies the tool as an authentication mechanism for MCP.AI IDE agents, specifying the action (log in, copy token, paste or configure) and the resource (access token). It distinguishes from siblings like 'connect' and 'marketplace' by focusing on 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 on when to use each method: permanent via config header or session-only by pasting the token. It also explains the alternative of adding to config as the 'best' approach, though it doesn't explicitly list 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 indicate safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds valuable context about response contents (authenticated, pending, URLs), which goes beyond annotations and helps the agent understand what to expect.

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 that are front-loaded with the core purpose and then expand with conditional behavior. No superfluous language.

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

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

Given zero parameters, presence of annotations, and no output schema, the description fully informs the agent about the tool's behavior and expected return values without needing further elaboration.

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 schema coverage is 100% by default. The description does not need to add parameter details, and the baseline score of 4 is appropriate.

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

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

The description clearly states the tool returns connection status and URLs, distinguishing it from sibling tools like authenticate or openfinance_list_connections by focusing on a consolidated status view with authenticated flag and pending array.

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: to check if all providers are connected or to get URLs when credentials are missing. It does not explicitly state when not to use, but the context of sibling tools implies it's for top-level status checking.

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 details behaviors beyond annotations: invoke works even when MCP is not installed, returns connect or checkout links for auth/paid scenarios, and that writes require workspace owner/admin. It does not contradict the annotations (readOnlyHint=false, destructiveHint=false).

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 dense paragraph that covers many details but lacks structure (e.g., bullet points or sections). While it is front-loaded with purpose, the length and density could be improved for easier scanning.

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 (13 parameters, no output schema, multiple actions), the description is remarkably complete. It covers the full search-describe-invoke flow, install vs invoke trade-offs, billing, auth, and mentions all relevant sibling tools. No critical gaps remain.

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 compensates by explaining the action enum and its values, the flow involving query, mcp_id, tool_id, and arguments. However, not all 13 parameters are individually described (e.g., limit, immediate, tier_slug, etc.), leaving some ambiguity.

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

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

The description clearly states that the marketplace is the official in-platform catalog and the way to run MCPs/tools. It provides a specific verb+resource with an explicit core flow (search → describe → invoke) and distinguishes itself from sibling tools like report_bug and request_mcp by stating 'use THIS tool FIRST, before any external/generic registry'.

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

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

The description gives explicit guidance on when to use each action (e.g., 'use install only to make an MCP PERMANENT... prefer invoke for a single/occasional use'), contrasts invoke vs install, and mentions when not to use (e.g., admin required for writes). It also names alternative sibling tools like report_bug and request_mcp for specific needs.

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 aligns with the destructiveHint annotation, explicitly stating data deletion. It also adds value by disclosing the return of a re-connection URL, which is not indicated by annotations. No contradictions.

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

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

The description is concise with two sentences, no redundant information, and provides essential information upfront.

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 one undocumented parameter, the description is incomplete. It does not specify what the parameter 'item' should be, undermining usability despite covering the basic behavior.

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 sole parameter 'item' is not described in the description. Despite 0% schema coverage, the description fails to explain what 'item' represents (e.g., bank identifier). This is a critical omission that prevents correct usage.

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

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

The description clearly states the action (revokes consent and deletes connection data) and the resource (specific bank). It distinguishes from sibling tools by specifying a unique operation: disconnecting a bank and returning a re-connection URL.

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

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

The description implies the tool is used when a bank connection needs to be revoked. It provides context on the consequence (data no longer available) and a follow-up action (re-connection URL). However, it does not explicitly exclude cases or mention 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?

Rich behavioral details beyond annotations: explains it uses PATCH, polls up to ~60s, returns fields like status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out. Describes the behavior when wait is true vs false. Annotations only provide hints; description adds substantial 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?

Description is a single paragraph but front-loaded with the core action. All sentences add value. Slightly long but acceptable; could be more structured with bullet points, but still concise enough.

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 description fully explains the return object ({ results, errors }) and key fields. Covers both parameters, behavior variations, and error indicators (needs_action, timed_out). Complete for a tool of this complexity.

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

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

Input schema has 0% description coverage, so description fully compensates. For 'items', explains it accepts item_id, connector_id, or connector_name, and that omitting syncs all. For 'wait', explains fire-and-forget behavior. Adds complete 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's purpose: to force re-sync of bank connections and wait for completion. It distinguishes this from disconnecting/reconnecting and from checking status (via sibling tools like openfinance_get_item_status). The verb 'forces' and resource 'connections' are specific.

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

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

Provides explicit when-to-use guidance: 'Use this when a balance or transaction list looks stale'. Also explains when to omit items vs specify selectors, and when to set wait: false for fire-and-forget. Lacks explicit when-not-to-use, but context is clear enough.

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

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

Annotations indicate a safe read operation. The description adds detail about CREDIT accounts returning a structured error instead of throwing, and the response shape includes errors. This provides behavioral insight 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?

Three concise sentences: purpose, parameter guideline, behavioral note, and response shape. Front-loaded with purpose, no redundant information.

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

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

Despite no output schema, the description fully describes the response shape (results and errors). Covers parameter constraints and error behavior. Complete for a simple tool.

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

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

Schema has 0% description coverage, but the description compensates by specifying that account_ids should be an array of strings with size 1-50. This adds practical semantics. Could be more detailed (e.g., required format).

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

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

The description explicitly states 'Returns real-time balance payload per account id', specifying the verb 'returns' and the resource 'balance'. It distinguishes from sibling tools like openfinance_get_accounts_detail and openfinance_list_accounts by focusing on balance 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 clear context for use (real-time balance) and parameter constraints (array of 1-50 ids). However, it does not explicitly compare with alternative tools or state 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 already declare readOnlyHint and idempotentHint. The description adds batch operation behavior, array length limits, return structure { results, errors }, and inclusion of extended creditData, providing useful 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: first states purpose and endpoint, second specifies input format and output shape. No wasteful words, efficient and well-structured.

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

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

Despite no output schema, the description covers input constraints, return format (batch with results/errors), and included data (extended creditData). Sufficient for an agent to invoke correctly 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?

With 0% schema description coverage, the description fully compensates by explaining that account_ids is an array of 1-50 strings for batch querying, adding essential meaning missing from 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 full account objects including extended creditData per specific IDs, and mentions the HTTP endpoint and batch shape. It differentiates from sibling list_accounts by targeting individual accounts with 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?

The description provides input constraints (array 1-50) and output shape, guiding usage. However, it does not explicitly state when to use this tool versus alternatives like openfinance_list_accounts, nor does it mention prerequisites or 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds crucial behavioral context: the semantics of payments[] (may be from previous bill), absence of paid/status field, and batch result shape {results, errors}, all of which go 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?

Description is relatively long but well-structured: main purpose first, then exclusions, usage notes, and caveats. Every sentence adds value, though tightening could improve conciseness.

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

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

With no output schema, description covers return shape and key fields. It addresses the nuanced behavior of payments[] in Brazilian Open Finance and provides pointers for related operations. Completeness is high given tool complexity.

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

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

Schema has 0% description coverage, so description must compensate. It explains that bill_ids is an array, that it should be populated using the list tool, and how to use it. This is sufficient for a simple array parameter, though it does not elaborate on format constraints.

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

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

Description clearly states it returns bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments[] etc.), and explicitly distinguishes from sibling tools by stating what it does NOT return (individual transactions) and directing to openfinance_list_transactions for that purpose.

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 (discover ids via openfinance_list_credit_card_bills first), when-not-to-use (to get itemized transactions), and important context about payments[] not indicating payment status. Also recommends openfinance_list_credit_card_bills for checking paid 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds detail about return shape for bulk ({ count, items }) and mentions executionStatus and connector metadata, enriching behavioral understanding without 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 with no wasted words. Front-loads the purpose (returns status) and then provides usage guidance. Every sentence is necessary 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?

Despite no output schema, the description outlines the return contents (status, executionStatus, connector metadata) and the shape for all banks ({ count, items }). For a simple read-only tool, this is sufficient for an agent to understand what to expect.

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

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

Input schema has 0% description coverage, but the description fully explains the semantics of the `item` parameter: omitting returns all banks (with count and items), passing it returns a single bank's status. This adds meaning beyond the basic schema definition.

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 the status of a bank connection with example statuses (UPDATED, UPDATING, LOGIN_ERROR, etc.), executionStatus, and connector metadata. Differentiates between all banks (omit item) and single bank (pass item), distinguishing it 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?

Provides explicit instructions on when to omit vs. pass the `item` parameter for bulk vs. single status. Does not explicitly mention alternatives or when not to use, but the context is clear given the sibling tools (e.g., openfinance_force_sync for syncing).

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds crucial behavioral details: how the tool behaves with and without the `item` parameter (aggregation vs. single bank), the distinction between `name` and `bank` fields, and the connector-dependent meaning of credit balance. It also clarifies the meaning of `creditData` fields for billing cycle. No annotation 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?

The description is well-structured, front-loading the core purpose and then diving into parameter behavior and caveats. Every sentence adds value. However, it is somewhat long, and some details (e.g., the full list of fields) could be more compact. Still, it is efficient for the 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?

Given the tool has only 2 parameters, no required, no output schema, and high complexity, the description provides extensive context about return fields (balance, bankData, creditData), aggregation behavior, and field meanings. It could be slightly more explicit about the response structure (e.g., that `results` is an array of accounts), but it adequately covers the key aspects.

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. It explains that `item` is optional and controls the scope of results (all banks vs. one bank). It explains that `type` is an enum with values 'BANK' or 'CREDIT' and what each returns. This adds complete semantics missing from 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 starts with a clear verb and resource: 'Returns accounts for a bank connection'. It lists specific account types (BANK and CREDIT) and fields returned (balance, number, type, etc.). It distinguishes from sibling tools like openfinance_list_credit_card_bills by noting that credit balance should not be misinterpreted and directing to the appropriate tool for standardized billing 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 explicit when-to-use guidance: 'OMIT `item` to list accounts across ALL linked banks at once' and 'Pass `item` to target a single bank'. It tells when not to use the balance field (do not treat as bill amount) and recommends an alternative tool for credit card bills. This covers both inclusion and exclusion criteria.

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

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

The description adds behavioral context beyond annotations: the result is cached for the session, and it is a single aggregated response with no batch ids. Annotations already mark it as read-only, idempotent, and non-destructive. No contradictions.

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

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

The description is three sentences long, front-loaded with the main purpose, and every sentence adds value. No redundancy or 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 simple list tool with no parameters, the description is comprehensive. It explains caching, output fields, and the connection to the update transaction category tool. Lacks explicit mention of when to retrieve categories (e.g., before updating transactions) but still adequate.

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 description coverage, the baseline is 3. The description compensates by detailing the output structure, including the purpose of each field and the Portuguese translation note.

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 Pluggy's transaction category taxonomy, cached for the session, with explicit field details (id, description, descriptionTranslated, parentId, parentDescription). It distinguishes from sibling tools by being the only category listing 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?

The description indicates that the id is used by openfinance_update_transaction_category, providing a clear usage context. However, it does not explicitly state when not to use this tool or mention alternative 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 convey read-only and idempotent behavior. The description adds context about returned fields and the add_connection_url, which is beyond annotations but not contradictory.

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

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

Single sentence, no fluff. All information is relevant and front-loaded.

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

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

Given no parameters and no output schema, the description sufficiently explains what the tool returns. Could mention if there is pagination or errors, but for a simple list, it's complete enough.

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 (0 params, 100% schema coverage). Description adds value by listing the fields returned, helping the agent understand output without an output schema.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes itself from siblings like openfinance_list_accounts by focusing on 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?

Implicitly clear when to use: when needing to list saved bank connections. Not explicitly compared to alternatives, but the purpose is straightforward.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds extensive behavioral context: payment cycle logic (pre-payment stays on the bill being paid, payment between close and due lands on next bill), derived payment_status with caveats (PAST_DUE_UNCONFIRMED), connector asymmetry for open bill, and warning behavior instead of failure when product not enabled. 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 very verbose (300+ words). While the complexity warrants detailed explanation, some sections (e.g., payment logic, derived payment_status) could be condensed. The front-loading of key return fields is good, but the length may overwhelm agents looking for quick understanding.

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 (5 parameters, no output schema), the description is exceptionally complete. It covers return fields, payment status derivation, open bill behavior, connector asymmetry, bulk support, warnings, and links to related tools. No important aspect is left unexplained.

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 thoroughly explains the critical parameters: account_id (implied), account_ids for batch execution, and include_open_bill with its behavior and implications. However, page and page_size are not described; their roles in pagination are only implied by 'bulk support' and 'results'. This minor gap prevents a perfect score.

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 like dueDate, totalAmount, minimumPaymentAmount, payments, etc. It distinguishes from sibling tools such as openfinance_get_credit_card_bill (for a single bill) and openfinance_list_transactions (for itemized purchases), establishing a unique purpose.

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 on when to use this tool (for bill-level summaries, not transactions), when to opt-in for include_open_bill, and what not to assume (e.g., payment_status interpretation). It also warns about connector asymmetry and directs users to openfinance_list_transactions for itemized data, covering both usage and alternatives.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds valuable context about fallback responses on errors and lists returned fields, 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?

Two sentences, no wasted words. The first sentence states purpose and scope, the second adds details on return fields and error handling. Fully front-loaded 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 4 parameters (all optional), no output schema, and no parameter documentation, the description is moderately complete. It explains return structure and error handling but ignores pagination and connection identification (e.g., 'item' parameter).

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

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

Schema description coverage is 0%, and the description does not explain any parameters. It lists asset types that map to the 'type' enum, but fails to clarify 'item', 'page', or 'page_size', leaving the agent to infer from schema alone.

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 investment portfolio for a connection, listing specific asset types and fields. It distinguishes from siblings like openfinance_list_accounts or openfinance_list_transactions by specifying 'investment portfolio'. However, it does not explicitly contrast with siblings.

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

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

The description implies usage for investment holdings but does not specify when to use this tool versus alternatives like openfinance_list_transactions. It mentions error handling (returns warning instead of throwing) which provides some guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds concrete behavioral details like data returned and bulk support, which are beyond annotations. No contradictions.

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

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

Three sentences, each serving a distinct purpose: main functionality, prerequisite, and bulk support. No redundancy, front-loaded with key 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 output schema, the description adequately describes return fields and transaction types. Provides prerequisite and bulk support. Slightly incomplete on pagination (page/page_size) but acceptable.

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. Description explains investment_id and investment_ids (bulk support) but does not describe page and page_size. Core parameters are covered, but not all, so partial compensation.

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 an investment position, enumerating transaction types (BUY, SELL, TAX, etc.) and listing return fields. It also instructs to use after openfinance_list_investments, differentiating it from that sibling.

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

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

Explicitly says to use after openfinance_list_investments to get investment_id and mentions bulk support for batched execution. Lacks explicit exclusion of when not to use, but context is sufficient.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds behavioral details like sequential querying with rate-limit spacing and the return structure, exceeding annotation coverage.

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

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

The description is two sentences, front-loads the purpose, and contains no superfluous information, making it highly efficient.

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

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

Given the single parameter, no output schema, and annotations covering safety, the description sufficiently explains input, behavior, and output shape, leaving no critical 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?

Despite 0% schema description coverage, the description fully explains the 'items' parameter's purpose, allowed types (uuid, connector_id, connector_name), and the effect of omitting it, compensating for the 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 it lists loan contracts per bank connection, specifies the endpoint, and distinguishes from sibling tools by focusing on loans versus accounts or 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?

It provides explicit guidance on when to include or omit the 'items' parameter, but does not mention when not to use the tool or alternative tools for similar tasks.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses numerous behavioral traits: auto-pagination with 5000 ceiling and truncated flag, variation in CREDIT PENDING/POSTED coverage by bank, upstream error handling (returns error object), detail level impacts, and search query semantics. This is comprehensive and far exceeds 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 long but well-structured and information-dense, with clear sections for core purpose, credit card specifics, pagination, detail levels, and troubleshooting. While every sentence adds value, slight trimming could improve conciseness without losing necessary detail.

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

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

Given the tool's complexity (8 parameters, no output schema), the description is remarkably complete. It covers return behavior (auto-paginated results, error format, truncated flag), edge cases (total=0 for credit accounts indicating sync failure), and cross-references other tools for related data. No gaps remain.

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 every parameter: from/to as ISO date filters, page and page_size for pagination, detail enum values and effects, account_id and account_ids for bulk, and search_queries for substring matching. It also clarifies default behaviors (e.g., omit page for auto-pagination).

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

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

The description clearly states that the tool returns transactions for bank accounts (BANK or CREDIT type) and explicitly distinguishes its role for credit card accounts as the only way to get itemized transactions, differentiating it from sibling tools like openfinance_list_credit_card_bills.

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 on when to use this tool versus alternatives, such as using openfinance_list_credit_card_bills for standardized open-bill total, openfinance_list_accounts for closing/due dates, and openfinance_get_item_status for connection health. It also details when to use different detail levels and pagination modes.

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

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

The description discloses behavioral traits beyond annotations: scan caps at 5000/account with a truncated flag, internal account resolution, and the behavior of different granularity and detail options. It also explains the output structure clearly. No contradiction with readOnlyHint or idempotentHint.

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

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

The description is front-loaded with the main purpose and is well-structured, but it is relatively long with some repetition. It earns its length by providing detailed behavioral and parameter information, but could be more concise.

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

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

Given the complexity of the tool (7 parameters, no output schema), the description is very complete. It explains the compact summary fields, raw transaction output, truncation, and per-account breakdown. It covers the key aspects needed for correct tool selection and invocation.

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

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

With 0% schema coverage, the description compensates well by explaining most parameters: item (connector_id/name/item_id, omit for all), from/to (ISO dates), granularity (monthly/raw), detail (compact/rich/raw), type (BANK/CREDIT). However, the top_n parameter is only implied in the output description, not 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 starts with a clear verb and resource: 'Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call.' It explicitly states that it resolves accounts internally, distinguishing it from sibling tools like openfinance_list_accounts and openfinance_list_transactions. The purpose is specific and well-defined.

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 use cases: 'análise anual/mensal', 'fluxo de caixa', etc. It explains when to use different granularity and detail levels, and notes that you can omit the item parameter to analyze all banks. However, it does not explicitly list sibling tools for comparison or state 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 already mark as readOnly, idempotent, non-destructive. Description adds detail that it checks a public status page and returns global indicator, degraded components, open incidents, and flags affecting connected banks. No contradictions; fully transparent about behavior 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?

Three sentences: first explains purpose and distinguishes from sibling; second gives usage guidance; third lists return value. No filler, each sentence earns its place. Front-loaded with key action.

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 tool with no output schema, the description covers purpose, usage scenario, return structure, and differentiation from sibling tools. There is no missing information needed for correct invocation.

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

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

Input schema has 0 parameters (schema coverage 100%), baseline is 4. Description adds no parameter info because none are needed. It does not waste space explaining absent 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?

Description clearly states it checks the LIVE operational status of the Open Finance provider's public status page, and explicitly distinguishes itself from 'openfinance_get_item_status' by specifying it is the provider's health, not the connection's. Verb is 'Checks', resource 'provider status', scope 'provider vs connection'.

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 when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED...' and explains it helps differentiate provider-side problems from connection issues. Provides clear context and alternative (openfinance_get_item_status).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds useful behavioral details: returns connect_url, honors user's plan, caveat warnings, and never dumps the whole catalog. However, there is a minor discrepancy where description says keywords is REQUIRED but schema does not mark it required.

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 multi-sentence description with each sentence adding value. Front-loaded with purpose, structured logically, 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?

Describes return fields in detail (connector id, access, audience, existing connections, accounts, connect_url, caveat). Missing output schema but description compensates well. Lacks mention of error handling or result limits but adequate for search tool.

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

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

With 0% schema description coverage, the description fully explains both parameters: keywords (required, search by name, examples) and include_accounts (boolean, returns accounts when true). Lacks default values but sufficient for agent understanding.

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 searches bank connectors by name, returns specific fields including a connect_url, and distinguishes itself from sibling tools like connect or list tools by explicitly instructing to call it 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', requires keywords[] or returns a hint, and advises preferring Open Finance connectors for automation based on caveat information.

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 provides essential behavioral context beyond annotations: it explains that recategorizing automatically creates a Category Rule for future similar transactions (case-insensitive exact match), and describes batch error handling (per-item errors do not fail the whole batch). This is significant and not covered by 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 well-structured, starting with the main action and then providing details. It is moderately long but every sentence adds value. Minor reduction for slightly verbose explanation of the side effect, but overall 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?

Given no output schema, the description provides a complete output shape and explains batch behavior and side effects. It could mention prerequisites like authentication, but the sibling 'authenticate' tool exists. Adequate for a write tool.

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

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

With 0% schema description coverage, the description fully compensates by explaining the purpose of each field: transaction_id comes from openfinance_list_transactions, category_id from openfinance_list_categories. It also describes the response structure with updated, results, and errors arrays, which is not present in the input 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 action ('Corrects the category of one or more transactions') and specifies the HTTP method and endpoint (PATCH /transactions/:id). It also distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_categories by focusing on updating categories.

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

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

The description explicitly tells when to use this tool ('fix miscategorized transactions') and where to obtain the required IDs (from openfinance_list_transactions and openfinance_list_categories). However, it does not explicitly state when not to use it or mention alternative tools, but the context 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 indicate idempotentHint=true, destructiveHint=false. The description does not contradict them and adds the importance of including conversation for reproduction. However, it does not disclose what happens upon submission (e.g., ticket creation, email), rate limits, or authentication requirements.

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) and front-loaded with the purpose. No unnecessary words, but could be slightly more formal.

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

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

Lacks output schema, and the description does not explain return values or success/failure behavior. For a simple feedback tool with 3 parameters, it is minimally complete but missing parameter semantics limits its usefulness.

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%. The description only mentions 'conversation array' but fails to explain the other parameters ('context', 'message'), their purpose, or expected formats. This is a significant gap for a 3-parameter tool.

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's purpose: 'Report a bug, missing feature, or send feedback.' It specifies the verb and resource, distinguishing it from sibling tools that focus on authentication or finance 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?

The description provides guidance: 'Include the conversation array with recent messages for reproduction.' This helps the agent understand the required input context. However, it does not explicitly mention when not to use the tool or provide alternatives for similar actions.

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, which clearly communicate safety and idempotency. The description adds the specific output context ('MCP platform and adapter versions') but does not disclose additional behavioral traits 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 sentence that directly states the tool's function with no extraneous words. It is front-loaded 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?

For a simple tool with no parameters and a well-defined output (versions), the description is complete. It adequately informs the agent about what the tool returns, and the lack of an output schema is acceptable given the 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?

The tool has no parameters and schema coverage is 100%. The description does not need to add parameter information beyond the schema, as there are none. Baseline 4 is appropriate.

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 'show' and clearly identifies the resource as 'the current MCP platform and adapter versions', making the tool's purpose unambiguous. It distinguishes itself from siblings like 'toolkit_info' by focusing specifically on version information.

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 no guidance on when to use this tool versus alternatives, such as 'toolkit_info' or other informational tools. An explicit recommendation or exclusion would improve 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 already declare readOnlyHint, idempotentHint, and destructiveHint as safe. The description adds value by specifying the exact content returned, which is beyond annotations. No contradictions present.

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

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

The description is a single, clear sentence that front-loads the core purpose without any fluff. Every part of the sentence adds value, earning a perfect score.

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

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

Given no output schema, the description adequately explains the return value (installed MCPs, connection status, catalog tools count). However, it could be more detailed about format or return type, but for a zero-parameter tool it is reasonably complete.

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

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

With zero parameters, schema coverage is trivially 100%. The description adds the meaning of the return value, which is necessary because there is no output schema. It provides context beyond the schema, justifying a baseline 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 a clear resource 'toolkit state', listing exact data points (installed MCPs, connection status, catalog tools count). It distinctly separates this tool from siblings like 'authenticate' or 'connect'.

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

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

The description states what the tool returns but does not explicitly guide when to use it versus alternatives. There is no mention of exclusions or when-not to use it. Given sibling tools include many financial operations, guidance would be beneficial.

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