Ágora MCP

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

Annotations indicate idempotentHint=true and destructiveHint=false, and the description aligns with these, explaining that no-arg calls return a link (non-destructive) and token-based calls perform authentication. It adds context about session vs permanent setup, which helps the agent understand 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?

The description is concise with no wasted words. It is front-loaded with the tool's target audience and core action, and each sentence adds value by clarifying usage, options, or best practices.

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

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

Given the simple schema and no output schema, the description covers the two main use cases (with and without token) and provides best-practice guidance. It could be improved by noting potential error states, but overall it is sufficiently complete for the tool's complexity.

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

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

The input schema has 0% description coverage, but the description compensates by explaining the 'token' parameter (a JWT access token) and the effect of omitting it. This adds essential meaning that the schema alone does not provide.

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: authenticating an IDE agent by either providing an access token or obtaining a login link. It distinguishes from sibling tools by focusing specifically 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 and how to use the tool, including two modes (with token for session login, without token to get link) and a best practice for permanent setup. It does not explicitly exclude scenarios, but the guidance 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=true and destructiveHint=false, so safety is clear. The description adds valuable context about return values (authenticated, pending, connect_url) and behavior per connection state, 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, each providing critical information: the function and the conditional outputs. No redundancy or filler, front-loaded with the core purpose.

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

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

The description explains the return structure without an output schema. It covers the main cases (all connected, missing credentials) but could mention potential error responses or status fields. Still, it is sufficiently complete for a simple, parameterless 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?

No parameters exist (schema coverage 100%), so the description naturally adds no parameter details. Baseline for 0 parameters is 4, and the description appropriately focuses on behavior and output.

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 explains that the tool returns connection status and URLs, with specific behavior for different states (all connected vs. missing credentials). It distinguishes itself effectively from siblings like 'authenticate' and 'marketplace' by focusing on status checking rather than actions.

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

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

The description implies usage for checking connection status, but does not explicitly state when to use this tool over alternatives like 'openfinance_list_connections'. However, the context of checking overall connectivity 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?

The description discloses key behavioral traits beyond annotations, such as that 'invoke' runs a tool one-off without adding it to the toolkit, behavior for credentials (returns connect link) and payment (checkout/top-up), and that writes require owner/admin. This adds significant context that annotations (readOnlyHint=false, openWorldHint=true) do not fully capture.

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 efficient, front-loading the core purpose and flow. Every sentence adds value, though it could be more structured (e.g., with bullet points). It avoids unnecessary fluff but is not as concise as possible.

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 params, no output schema), the description covers the essential flow, distinguishes between one-off and permanent use, and explains auth and payment. However, it does not describe return values or provide details on all parameters, leaving some gaps for a 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 meaning of key parameters like 'action' (search, describe, install, etc.) and 'tool_id' in context, but many parameters (e.g., 'limit', 'query', 'message', 'immediate', 'tier_slug', etc.) are not explained. The description adds some value beyond the schema but is incomplete for all 13 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 identifies 'marketplace' as the official MCP marketplace and catalog, with a specific verb-resource ('use THIS tool FIRST') that distinguishes it from external registries and sibling tools like 'report_bug' or 'toolkit_info'. It outlines the core flow of search, describe, and invoke, which sets clear expectations.

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 (when a user wants a capability), when not to use external registries, and when to prefer 'invoke' over 'install'. It also notes admin requirements for writes and the behavior for credentials and payment, offering clear context 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?

The description aligns with the destructiveHint annotation, accurately noting that data will be deleted and no longer available. It adds value by mentioning the returned 'add_connection_url' for reconnection.

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

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

The description is three sentences, front-loaded with the primary action, followed by consequence and return value. No extraneous information.

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

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

For a simple deletion tool with annotations and one parameter, the description covers the main action and outcome but omits clarification of the critical parameter and does not mention error conditions or prerequisites.

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

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

The single required parameter 'item' has no description in the schema (0% coverage), and the tool description does not explain what 'item' refers to (e.g., bank ID or connection ID). This leaves the agent uncertain.

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 'Revokes the Open Finance consent for a specific bank and deletes the connection data.' This distinguishes the tool from sibling tools that list connections, force sync, or manage accounts.

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

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

No guidance is provided on when to use this tool versus alternatives, such as checking connection status first or using other disconnect methods. There are no prerequisites or usage notes.

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 the polling behavior, timeout (~60s), return values including 'needs_action' and 'timed_out', and the effect of omitting 'items'. Annotations do not contradict (readOnlyHint=false, destructiveHint=false are consistent with a mutating sync operation that does not destroy data).

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 verbose but every sentence serves a purpose: core action, use case, parameter details, return format, error handling. It is front-loaded with the key action. Slightly long but justified by the tool's complexity; could be trimmed slightly.

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 fully covers return values ('results, errors'), status fields ('status', 'executionStatus', 'lastUpdatedAt', 'synced'), and edge cases ('needs_action', 'timed_out'). It also references a sibling tool for follow-up. No missing gaps for the tool's 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?

With 0% schema coverage, the description fully explains both parameters: 'wait' as a boolean for fire-and-forget, and 'items' as an array of selectors (item_id, connector_id, connector_name) with the special case of omitting to sync all. This adds critical meaning beyond the schema's bare types.

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

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

The description clearly states the verb 'forces the bank to re-sync' and the resource 'one or more connections', with a specific use case ('when a balance or transaction list looks stale'). It distinguishes from siblings by noting it pulls fresh data without disconnecting/reconnecting, which is unique among the listed 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 explicitly states when to use ('when a balance or transaction list looks stale') and provides alternative instructions for timeout ('re-check with openfinance_get_item_status'). It also explains the two modes (wait vs. fire-and-forget) with 'set wait: false'.

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 goes beyond annotations by disclosing that CREDIT accounts may return a BALANCE_FETCH_ERROR with a structured warning, and provides the exact response shape including error format. Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description adds valuable context 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?

The description is concise with three sentences: purpose and endpoint, parameter usage, and special behavior/response. No redundant information, and key details are 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 the simple one-parameter tool with no output schema, the description covers the essential details: what it returns, error handling, and parameter constraints. It lacks information about authentication requirements or caching behavior, but the annotations and context make it reasonably complete.

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

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

The schema has 0% description coverage for the 'account_ids' parameter. The description compensates by stating the parameter is an array of strings, limiting it to 1–50 items, and implying each item is an account ID. It does not explain the format of the account IDs or how to obtain them, but the constraint and usage hint are helpful.

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 a real-time balance payload per account id, and specifies the REST endpoint. It distinguishes itself from sibling tools like openfinance_list_accounts (listing) and openfinance_get_accounts_detail (details) by focusing on balance.

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 this tool (to get balances) and includes a specific note about CREDIT accounts returning a warning instead of throwing. However, it does not explicitly state when not to use it or mention alternatives, such as using list tools to first obtain account IDs.

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 batch behavior and error format, which is useful but not extensive 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 purpose, then input and output details. Every sentence adds value with no redundancy.

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

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

Covers input constraints, batch behavior, and result shape. Lacks explicit mention of permissions or error scenarios, but adequate 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 coverage is 0%, but description adds constraints: array of strings, size 1-50. This provides meaning beyond the bare schema, though doesn't enumerate all possible 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?

States 'Returns full account objects including extended creditData' with a specific verb and resource. Distinguishes from siblings like openfinance_list_accounts by mentioning batch retrieval and extended 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?

Implies usage by specifying input format (array 1-50) and batch shape, but does not explicitly state when to use this over siblings like openfinance_list_accounts or 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 context beyond annotations: notes that Pluggy does not return a paid/status field, explains the meaning of payments array in Brazilian Open Finance, and recommends an alternative to check payment status, enriching the agent's understanding of limitations and behavior.

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

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

The description is front-loaded with the core function, followed by clear sections on what is not returned, usage prerequisites, and important caveats. Every sentence adds distinct value without redundancy.

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

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

Given no output schema, the description adequately describes the return shape (batch {results, errors}) and key fields (financeCharges, payments with sub-fields). It also notes limitations and cross-tool dependencies, making the tool's behavior fully comprehensible.

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?

Although the schema has 0% description coverage, the description compensates by explaining the 'bill_ids' parameter should be passed as an array and sourced from the list_bills tool. This adds usable context, though it does not detail constraints like format or uniqueness.

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 bill-level detail for credit card bills by ID, specifying included fields (financeCharges, payments) and explicitly distinguishing it from listing itemized transactions, thereby providing a precise verb+resource definition.

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 to discover IDs, when to prefer openfinance_list_transactions for itemized data, and a critical warning about interpreting the payments array. This enables correct tool selection and usage.

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 value beyond annotations by explaining the different return structure when item is omitted vs passed (returns { count, items } vs single object). No contradictions 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?

Two sentences, no filler. Purpose is front-loaded, additional details are concise. 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?

Given low complexity (1 optional param, no output schema), the description fully covers behavior in both modes, return format hints, and key fields. Agent can correctly invoke this tool without additional info.

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 with only one string parameter. Description fully explains its meaning: pass item for single bank, omit for all banks. Compensates completely for schema deficiency.

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 current status of a bank connection with specific fields (status, executionStatus, connector metadata) and distinguishes two modes: all banks without item, single bank with item. This is specific and differentiates 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?

Provides clear guidance on when to use (get status) and how to use (omit or pass item parameter). No explicit exclusion of alternatives, but the context is sufficient for an agent to decide.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds critical behavioral context: the `name` field is the legal entity not the brand, the `balance` for CREDIT is connector-dependent and should not be interpreted as the current bill, and the meaning of creditData fields. 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 appropriately sized for the complexity, front-loaded with the core purpose, and each sentence adds necessary detail. No redundant information; warnings and usage notes are integrated effectively without wasting 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, the description fully covers return values (balance, number, type, subtype, bankData, creditData, bank, connector_id). It also explains the `name` field and provides guidance on interpreting credit card balances. Additional context on aggregated vs. single-item responses and cross-referencing to other tools makes this complete.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It does: `item` is explained as 'target a single bank' with contextual usage, and `type` is explained as filtering to BANK or CREDIT. It also explains the return fields and their meanings, adding value beyond the schema.

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

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

The description clearly states the tool lists accounts (BANK and CREDIT) with detailed fields. It distinguishes between listing all accounts (omit item) and targeting a single bank (pass item), which differentiates it from siblings like openfinance_get_account_balance and 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?

Explicit guidance on when to omit or include the `item` parameter, with a concrete example: 'use this when the user asks for my accounts/cards without naming a bank.' It also directs users to an alternative tool (openfinance_list_credit_card_bills) for standardized bill amounts, providing clear when-to-use and when-not-to-use instructions.

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. The description adds behavioral details: cached for the adapter session and single aggregated response, which are useful 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?

The description is three sentences, front-loaded with the main purpose, and every sentence adds essential information with no redundancy or unnecessary details.

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 or output schema, the description provides necessary context: caching behavior, response structure, and linkage to update tool. Could mention refresh policy, but sufficient for most use cases.

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 adds full value by detailing the response fields (id, description, descriptionTranslated, parentId, parentDescription) and their relationships, going beyond the baseline.

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 transaction category taxonomy, specifies the API endpoint, and distinguishes from siblings by noting caching and single aggregated response. The title from annotations further reinforces.

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 that the `id` field is used by openfinance_update_transaction_category, providing clear usage context. It does not explicitly state when not to use, but the tool's read-only nature implies safe use when categories 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 readOnlyHint, idempotentHint, and destructiveHint. The description adds that it returns specific fields and an add_connection_url, but does not disclose other behavioral traits like response limits or performance characteristics.

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, clearly front-loaded with the core purpose, and contains no extraneous 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?

The description covers what is returned and mentions the add_connection_url. Given no output schema, this is sufficient for a simple list operation, though could note potential pagination or ordering.

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 does not need to explain them. Baseline 4 is appropriate as the description adds no additional parameter info, but none is 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 returns saved bank connections with specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling tools like list_accounts or list_transactions by focusing on the connection entity.

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 like authenticate or connect. The description does not mention exclusions or context for usage.

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

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

Annotations already declare readOnly and idempotent, but the description adds deep behavioral context: payment cycle semantics, derived payment_status, connector asymmetry, open_bill availability flags, and that it returns a warning instead of failing. This goes well beyond the annotations.

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

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

The description is verbose and dense, containing many details and long paragraphs. While every sentence adds value, it could be more concise and better structured for quick scanning. The front-loading of purpose is good, but overall length harms readability.

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

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

Given the complexity of Open Finance semantics, derived fields, and connector asymmetry, the description is remarkably complete. It covers edge cases, bulk support, limitations, and provides cross-references to other tools. There is no output schema, so the description carries full burden and succeeds.

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 explains include_open_bill and account_ids in detail, but page, page_size, and account_id lack explicit descriptions. The meaning can be inferred, but not fully explained. Thus adequate but not excellent.

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 with specific fields. It distinguishes from sibling tools like openfinance_list_transactions by stating it's bill-level summaries, not individual transactions. Also contrasts with openfinance_get_credit_card_bill by being a list operation.

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: mentions that for itemized purchases, use openfinance_list_transactions. Discusses opt-in for open_bill and when not to use (connector asymmetry). Also advises against calling a bill 'vencida' categorically, giving clear 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 declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: it returns a warning structure on upstream errors instead of throwing, and lists many fields in the output. This goes 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 fairly concise given the complexity of the tool, listing many asset types and fields in a single sentence. It front-loads the core purpose. Minor improvement could be made by separating parameter details.

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 lists many return fields but lacks an output schema. It details common fields but could be more systematic. The error handling behavior is well described. Overall adequate but incomplete.

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 and 4 parameters (item, page, type, page_size), the description provides no explanation of their meaning or usage. The agent gets no guidance on how to filter or paginate, severely limiting effective invocation.

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

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

The description clearly states it returns the investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and key fields. It distinguishes from siblings like openfinance_list_investment_transactions by focusing on the portfolio, not 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 explains that it handles errors gracefully by returning a structured response instead of throwing on 403, guiding usage when the product is not enabled. However, it does not explicitly contrast with similar tools like openfinance_list_accounts or openfinance_list_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 readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context by listing the specific movement types and detailed fields returned (expenses itemization), which goes beyond the annotations.

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

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

Two efficient sentences covering purpose, usage, and key details. Front-loaded with main function, 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?

For a list endpoint without output schema, it adequately describes return types and fields. Lacks detail on pagination defaults, but parameters are present in 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. Description clarifies 'investment_id' as required and 'investment_ids' for bulk, but does not mention page or page_size parameters. Partially compensates for schema gaps.

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

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

The description explicitly states 'Returns the movement history for a specific investment position' with clear transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER), distinguishing it from sibling tools that handle regular transactions or account listings.

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 usage guidance: 'Use after openfinance_list_investments to get the investment_id' and mentions bulk support. While it doesn't explicitly say when not to use, the distinct purpose makes alternatives clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds behavioral details: sequential querying per connection, rate-limit spacing, and return format with results and errors per connection.

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 three sentences, front-loaded with purpose, then parameter details, then omission behavior. No unnecessary words, 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?

No output schema, but description specifies return shape '{ results, errors }' per connection. Parameter behavior is fully explained. Adequate for a list tool with one optional 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 for 'items' has no description (0% coverage). Description compensates by explaining that items is an array of connection selectors (item_id uuid, connector_id, or connector_name) and that omitting it fetches all connections.

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 lists loan contracts per bank connection, using specific verb 'list' and resource 'loan contracts per bank connection'. It distinguishes from sibling tools like openfinance_list_accounts by focusing on 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?

Description explains when to use 'items' parameter (for specific connections) and when to omit it (list all linked banks). Also mentions sequential querying with rate-limit spacing, providing clear context for usage.

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

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

The description adds significant behavioral context beyond annotations. It explains connector-specific behavior for credit cards (PENDING vs POSTED, future-dated installments), details pagination aggregation with search_queries, error handling that returns structured warnings instead of throwing, and bulk support via account_ids. All consistent with readOnlyHint and 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 long but well-structured, starting with the main purpose, then diving into credit card specifics, filtering/pagination details, error handling, and bulk support. Every sentence adds value, though it could be slightly more concise. The information is front-loaded and logically ordered.

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 (7 parameters, no output schema), the description covers most aspects but lacks a detailed response schema. It mentions response fields like creditCardMetadata.billId and status:'PENDING' and the error response format, but does not fully describe the transaction object structure. This is a minor gap for a comprehensive understanding.

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

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

With 0% schema description coverage, the description compensates well by explaining functional roles of parameters (from/to date filters, pagination, search_queries with case-insensitive OR match and 5000 aggregation limit). It mentions account_ids for bulk execution. However, it does not explicitly map each schema property to its description, and the format for date parameters is only implied.

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

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

The description clearly states the tool returns transactions for bank accounts (BANK or CREDIT). It distinguishes from siblings like openfinance_list_credit_card_bills by noting it is the only way to get itemized credit card transactions, and it explains how credit card transactions relate to 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. It contrasts with openfinance_list_credit_card_bills for bill-level data, advises checking connection health via openfinance_get_item_status if total is 0, and suggests force sync or reconnection steps. It also explains the behavior for different credit card connectors and pagination limits.

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

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

Annotations indicate readOnlyHint and idempotentHint. Description adds behavioral details: scan caps at 5000/account with truncation flag, default behavior of 'monthly' granularity returns compact summary, and internal fan-out of transactions. 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?

Description is comprehensive but slightly long. Well-structured with main purpose first, then details. Every sentence adds value, but could be tightened slightly.

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 6 parameters and no output schema, description covers return value (compact summary fields, truncation), filters, and use cases. Provides enough context for agent to use 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 coverage is 0% so description fully compensates. Explains all parameters: item accepts multiple formats, from/to are ISO dates, granularity effects, type filter, and top_n implied for top lists. Adds meaning beyond the schema.

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

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

The description clearly states it performs consolidated cash-flow analysis for a bank connection, resolving accounts internally. It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_accounts, and lists specific use cases like 'fluxo de caixa'.

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 you don't need to call openfinance_list_accounts first, explains how to target one bank or all, and when to use granularity 'raw'. Missing explicit 'when not to use' but provides clear context.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context beyond annotations: it details what the tool returns (global indicator, degraded components, open incidents, and `your_banks_affected`) and explains its use in troubleshooting. No contradiction with annotations.

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

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

The description is a single, well-structured sentence that front-loads the purpose, then provides usage guidance, and finally lists return values. Every sentence earns its place; there is no redundancy or unnecessary detail. Despite being moderately long, it is efficient and clear.

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 and no output schema, the description is complete. It covers purpose, usage guidance, and return values (global indicator, degraded components, open incidents, affected banks). It provides sufficient context for an agent to decide when and why to use it.

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 (0 params). Baseline for 0 parameters is 4 per rubric. The description does not need to add parameter information. It implicitly suggests no input is needed, but does not explicitly state 'requires no input'.

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

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

The description clearly states it checks the LIVE operational status of the Open Finance provider, distinctly separating it from the sibling tool `openfinance_get_item_status` which checks the connection's own status. The verb 'Checks' and resource 'operational status' are specific and unambiguous.

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

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

The description explicitly tells when to use this tool: whenever data looks incomplete or stale despite a connection showing UPDATED. It explains what the tool reveals (upstream outages, known incidents) and how it helps differentiate provider-side problems from connection issues. It also mentions the return values (global indicator, degraded components, open incidents, affected banks) which aids in decision-making.

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, description adds that the tool honors user's plan (hides PJ banks for PF users), returns pre-selected connect_url, and never dumps the full catalog without keywords.

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 tightly structured sentences: purpose, return details, when to call, and mandatory parameter. No redundant or missing information.

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

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

For a search tool with 2 parameters and no output schema, description covers all necessary context: what it does, parameters, edge case, and integration guidance.

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, description fully explains 'keywords' with examples and behavior when omitted, and 'include_accounts' with its effect on returned account details.

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 searches bank connectors by name, specifies returned fields, and distinguishes from sibling list tools by focusing on search and providing a ready connect_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?

Explicitly instructs to call this tool before connecting, explains that keywords are required and that omitting them returns a hint rather than dumping the catalog.

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 the important side effect of creating Category Rules for future transactions, and explains batch error handling (per-item errors don't fail the batch). This adds value beyond annotations, which only indicate non-readonly and non-destructive.

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 front-loads the purpose and adds all necessary details. Slightly verbose but every sentence is substantive.

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 fully explains the return format (updated, results, errors) and side effects, making it complete for a mutation 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 compensates by explaining that transaction_id comes from openfinance_list_transactions and category_id from openfinance_list_categories, and describes the batch shape and error handling.

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

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

The description clearly states the tool corrects the category of one or more transactions, specifying the HTTP method and endpoint. It differentiates from sibling tools like openfinance_list_transactions and openfinance_list_categories by its update action.

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

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

Provides clear context for when to use (fix miscategorized transactions) and where to get input IDs. Does not explicitly state when not to use, but the purpose is well-defined.

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 include idempotentHint=true and destructiveHint=false, so the description adds value by specifying the need to include conversation data. 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 a single sentence, efficiently stating the purpose and a key instruction. However, it could be slightly more structured to list parameters.

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 output schema, the description covers the main intent but lacks details on required and optional parameters, making it incomplete.

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%, but description only mentions the conversation parameter, ignoring the required 'message' and optional 'context'. This leaves the agent uncertain about what to provide for those parameters.

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

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

The description clearly states the tool's purpose: report a bug, missing feature, or send feedback. This is specific and distinct from sibling tools which are primarily financial 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 advises to include the conversation array for reproduction, which provides clear guidance. No alternatives are mentioned, but siblings are unrelated so no confusion.

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 that the tool returns version information, which is consistent and provides the specific resource shown. Since annotations cover safety, no further behavioral details are necessary, and the description does not contradict them.

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, front-loaded sentence that conveys the entire purpose without unnecessary words. It is concise and effective, earning its place with no waste.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is largely complete. However, it does not mention the return format (e.g., string or object), which could help an agent understand the output. This minor gap prevents a perfect score.

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, and schema description coverage is effectively 100%. According to guidelines, zero parameters warrant a baseline score of 4. The description does not need to add parameter information, and it does not; this 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 a specific verb ('Show') and explicitly names the resource ('current MCP platform and adapter versions'), clearly distinguishing the tool from sibling tools focused on authentication, connection management, and financial data retrieval. There is no ambiguity about the tool's sole 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 implies the tool is for checking version information, which is self-evident. While it does not explicitly state when to use or not use this tool, the context of sibling tools (none are version-related) makes the usage intuitive. A mention of using it before reporting issues would strengthen guidance, but it is not lacking.

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's job is to add behavioral context. It adds value by specifying the exact returned fields (installed MCPs, connection status, catalog tool counts). This is useful beyond annotations, but could mention if the tool is fast or has any 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 a single, front-loaded sentence that efficiently communicates the tool's purpose without redundancy. 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?

For a tool with no parameters, no output schema, and simple behavior, the description provides a clear idea of what the tool returns. It could be more complete by mentioning if the result is a list or object, but it is sufficient for most use cases.

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, and schema coverage is 100% (since no parameters exist). The description does not need to add parameter info. The baseline for 0 parameters is 4, which is appropriate here.

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 toolkit state, specifically listing what it provides: installed MCPs, connection status, and catalog tool counts. It uses a specific verb ('Returns') and a well-defined resource, distinguishing it from sibling tools that perform authentication, data retrieval, or configuration tasks.

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

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

The description implies usage for checking toolkit status but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. Given its simplicity and lack of parameters, the usage is evident, but explicit guidance would improve clarity.

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