Banco do Nordeste do Brasil MCP

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

Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that calling with no args returns a link and that passing a token sets it for the session. This discloses behavioral modes but doesn't detail error handling.

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 purpose and then details the two usage methods. It is moderately concise; every sentence adds value but could be slightly more streamlined.

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

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

For a simple tool with one optional parameter and no output schema, the description covers main usage scenarios well. It lacks error handling details but otherwise provides sufficient context for invocation.

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

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

The input schema has 0% description coverage with one undocumented string parameter. The description fully compensates by explaining the token is a JWT and that omitting it returns a login link, adding 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 authenticates for MCP.AI in IDE agents, specifying the action (log in via browser token) and the resource (MCP.AI). It distinguishes from siblings like 'connect' by focusing on token-based authentication.

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

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

The description provides clear context on when to use the tool: for initial login, with two methods (permanent config or session-only token). It does not explicitly state when not to use, but the 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 readOnlyHint and idempotentHint. The description adds valuable behavioral context by detailing return conditions (authenticated:true vs connect_url), which helps the agent understand the tool's 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 two sentences, front-loaded with the core purpose, and every sentence adds useful information. No wasted words.

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

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

While the description covers two common scenarios, it omits edge cases like partial connection status (some providers connected, some not). Without an output schema, this gap may leave the agent uncertain about all possible return states.

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%. The description does not need to add parameter information, earning a baseline of 4 as per guidelines.

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, with specific scenarios for all-connected and missing-credentials cases. It distinguishes from siblings like authenticate which handles 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 implies use for checking connection status but does not provide explicit guidance on when to use this tool vs alternatives like authenticate or openfinance_list_connections. No when-not-to-use or comparative 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?

The description fully discloses behavioral traits beyond annotations: it explains write operations (install, invoke), one-off vs permanent installation, auth requirements (workspace owner/admin), and return of connect/checkout links. No contradiction with 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 verbose, packing extensive detail into a single block. While front-loaded with purpose, the dense text could be better organized into concise sections. It contains all necessary info but sacrifices clarity for completeness.

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 (13 params, no output schema, multiple actions), the description covers the core flow and major behaviors. It handles edge cases (login, payment) and distinguishes between actions. However, some parameter details and exact return structures are partially addressed, leaving minor 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?

With 0% schema description coverage, the description must explain parameters. It covers key ones (action, mcp_id, tool_id, arguments) and the flow, but 13 parameters include undocumented ones like 'conversation', 'request_name', etc. The description provides usage context but not full parameter semantics, earning a baseline-adjusted 3.

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

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

The description clearly states it is the official mcp.ai marketplace, acting as both catalog and execution gateway. It specifies core actions (search, describe, invoke) and distinguishes from external registries, making the tool's purpose unmistakable.

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: use this tool first before any external registry, explains when to use invoke vs install, and details handling of credentials and payments. It also differentiates from sibling tools (e.g., openfinance_*), offering clear decision paths.

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

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

Annotations already indicate destructiveHint=true, but the description adds valuable context: revocation of consent, deletion of data, unavailability of data, and a return of a reconnection URL. 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?

Two concise sentences front-load the action and outcome, with no unnecessary words. Every sentence adds 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 destructive tool with one parameter and no output schema, the description adequately covers the outcome and return value. However, it lacks guidance on the parameter meaning and does not mention irreversibility or user confirmation needs.

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

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

The input schema has one parameter 'item' with no description and 0% coverage. The tool description does not clarify what 'item' represents (likely a bank identifier), leaving the agent to guess.

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

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

The description uses specific verbs ('revokes', 'deletes') and clearly identifies the resource ('Open Finance consent for a specific bank'). It distinguishes from sibling tools by focusing on removal, which is unique among list/sync tools.

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

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

The description implies this tool is for disconnecting a bank, but it does not explicitly state when to use it versus other tools (e.g., openfinance_force_sync) or provide conditions for 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 only indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds rich behavioral details: polling up to ~60s, return format with results/errors, fields like synced, needs_action, timed_out, and the effect of wait parameter. 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 front-loaded with the core action, then usage context, then parameter details, then return format. Every sentence provides essential information; no wasted words. Despite length, it is efficiently 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 thoroughly explains return fields (results, errors, status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out). Covers all edge cases (timeout, user action needed, fire-and-forget). Complete for a complex 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 fully explains both parameters: items as an array of selectors (item_id, connector_id, or connector_name) with option to omit for all, and wait as boolean for synchronous vs fire-and-forget. This adds complete meaning beyond the bare schema.

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

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

The description clearly states the tool's purpose: force a re-sync of one or more connections and wait for it to finish. It distinguishes from other tools like openfinance_get_item_status by specifying that this triggers a sync and waits, while the sibling is for re-checking after timeout.

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 states when to use (stale balance/transactions) and what it does (fresh data without disconnecting). Provides alternatives: use openfinance_get_item_status after timeout, and different behavior when items is omitted (sync all) or wait is false (fire-and-forget).

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

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

Adds significant behavioral context beyond annotations: explains error handling for credit accounts (structured warning instead of throwing), response shape, and array constraints. Annotations already cover readOnly, idempotent, 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?

Three sentences covering purpose, usage detail, and response/error info. No wasted words; 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?

Includes response shape and error cases, but omits mention that the tool is read-only and idempotent (already in annotations). Could clarify that account_ids must belong to authenticated user. Otherwise sufficient for simple retrieval.

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

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

With 0% schema coverage, the description provides essential semantics: 'Pass account_ids as an array (1–50)' and implies they are required. Could be improved by specifying the source of account IDs (likely from list_accounts).

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

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

The description clearly states the tool's purpose: 'Returns real-time balance payload per account id' with the specific API endpoint. It distinguishes this from sibling tools that list accounts or get other 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?

Descriptions mentions array usage and size limit (1–50) and credit account error behavior, but does not explicitly guide on when to use this tool over alternatives like openfinance_list_accounts or openfinance_get_accounts_detail.

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 discloses batch behavior: returns {results, errors} shape and accepts up to 50 IDs. It also mentions extended creditData in the response. This adds useful context about what the tool does and its batch nature.

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, no redundant information. It front-loads the core purpose and includes essential details (batch shape, parameter constraint). Every word contributes to 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?

For a simple tool with one parameter, no output schema, and comprehensive annotations, the description is complete. It covers the operation, input constraints, and response shape, leaving no critical gaps for an agent to invoke it correctly.

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

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

The schema only defines account_ids as an array of strings with no description. The description adds meaning by specifying the array size constraint (1–50) and implies it should contain account IDs. This partially compensates for the 0% schema description coverage, though it could clarify the source of these IDs.

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

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

The description clearly states the tool returns full account objects with extended creditData for specific IDs. It mentions the endpoint pattern, making the purpose explicit. However, it does not directly differentiate from the sibling tool openfinance_list_accounts, which lists accounts, though the detail vs list distinction is implied.

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 specifies the input format (array, 1–50 elements) but does not provide explicit guidance on when to use this tool versus alternatives like openfinance_list_accounts. It implies usage for account detail retrieval by ID but lacks when-not-to-use or alternative references.

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=true annotation, the description discloses critical behavioral details: Pluggy does not return a paid/status field, explains that payments[] reflects payments from previous bill's billing cycle, and notes the batch shape { results, errors }. This provides significant transparency about data semantics and limitations.

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 with a lead sentence stating purpose, then what it does not do, sibling tool guidance, parameter instruction, and behavioral notes. However, it is somewhat lengthy (several sentences) which impacts conciseness, though each 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 the lack of output schema, the description covers key return fields (financeCharges, payments with id, paymentDate, etc.) and essential context. It could list more return fields but provides enough for effective use and includes important caveats (payments meaning, no paid status). Covering these effectively compensates for the missing 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?

With 0% schema coverage, the description fully explains the only parameter: 'Pass `bill_ids` as an array' and recommends using openfinance_list_credit_card_bills to discover ids. It also adds context about the batch response shape, meaning the agent understands how to invoke the tool correctly.

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 'Returns bill-level detail for one or more credit card bills by id' with specific resources (credit card bills) and action (get detail). It also explicitly distinguishes from sibling tools by stating 'Does NOT return individual transactions' and directs to openfinance_list_transactions for itemized transactions.

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

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

Description provides explicit when-to-use and when-not-to-use: 'to get itemized credit card transactions (purchases, subscriptions, etc.), use openfinance_list_transactions'. Also advises to use openfinance_list_credit_card_bills first to discover ids, and warns against assuming payment status from payments array. This includes concrete alternatives and 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the return includes executionStatus and connector metadata, and explains the return shape for the 'all banks' mode (returns { count, items }). 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 consists of two sentences with no redundant information. The first sentence states the purpose and expected return values; the second explains the parameter usage. Information 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 one optional parameter and no output schema, the description is complete. It covers both usage modes and the return shape. Minor missing info like error handling or rate limits, but acceptable given the tool's simplicity and read-only nature.

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 fully explains the parameter's role: omitting it returns all banks, passing it returns a single bank. It could specify valid values for 'item' (e.g., connection ID), but the semantics are clear.

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

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

The description clearly states the tool returns the current status of a bank connection, including specific status values like UPDATED, UPDATING, LOGIN_ERROR, executionStatus, and connector metadata. It also distinguishes behavior based on the 'item' parameter, making it distinct from sibling tools like openfinance_list_connections.

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

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

The description provides explicit guidance on when to omit or pass the 'item' parameter: omit for all banks, pass for a single bank. While it does not explicitly state when not to use this tool versus alternatives, the distinction is clear enough for selection.

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

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

Beyond annotations (readOnlyHint, idempotentHint) which ensure safety, the description adds critical behavioral details: CREDIT balance meaning is connector-dependent and should not be treated as current bill, and explains the open billing cycle fields.

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

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

The description is relatively long but every sentence adds necessary value given the tool's complexity. It is front-loaded with core information and could be slightly more structured, but remains 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?

Without an output schema, the description comprehensively explains return fields, aggregation behavior, and special cases like credit balance. It also references the relevant sibling tool for deeper credit card data, making the description self-contained.

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 parameter coverage, the description fully compensates by explaining the effect of 'item' (omitting vs providing) and the meaning of the 'type' enum values (BANK/CREDIT), as well as clarifying output fields like 'bank' and 'name'.

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

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

The description explicitly states the tool returns accounts for bank connections with specific types and fields, and distinguishes from sibling tools like openfinance_list_credit_card_bills by mentioning alternative usage for standardized bill amounts.

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

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

Provides clear when-to-use guidance: omit 'item' for all banks, pass 'item' for a single bank. Also explains when not to use the 'balance' field for credit cards and directs to another tool for standardized amounts.

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 caching behavior and that the response is a single aggregated entity with no batch ids, which provides useful behavioral context beyond annotations.

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

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

Description is three sentences, each adding value: purpose, field details, and response nature. No fluff, front-loaded with the core 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?

Given no parameters, rich annotations, and clear field description, the description is fully complete for this simple listing tool. No output schema needed as fields are explained.

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

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

There are zero parameters, so the description carries the full burden. It adds meaning beyond the empty schema by detailing each response field (id, description, descriptionTranslated, parentId, parentDescription) and their usage.

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

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

Description clearly states it returns Pluggy's transaction category taxonomy (GET /categories), cached for the session. It distinguishes from siblings by specifying that the `id` field is used by `openfinance_update_transaction_category`, making its purpose and relationship explicit.

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 notes it is cached and a single aggregated response, implying it should be called once per session. While it doesn't explicitly state when not to use it, the context of no sibling category tools makes this adequate.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying returned fields and the purpose of add_connection_url. 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?

Single sentence with no waste. Front-loaded with purpose and includes key details in a compact form.

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 covers purpose and return fields sufficiently. However, it lacks details on ordering, pagination, or response size limits, which could be useful.

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 zero parameters, so description cannot add parameter meaning. Baseline for 0 params is 4. Description does not need to discuss 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 'Returns the saved bank connections for this install' with specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling list tools like openfinance_list_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?

Description implies usage for listing bank connections of the current install but does not explicitly state when to use this tool versus alternatives like openfinance_list_accounts or openfinance_list_transactions. No exclusions or when-not guidance is provided.

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, non-destructive. The description adds significant behavioral detail: payment cycle logic, payment_status derivation rules, connector asymmetry for open bill, and that it returns a warning instead of failing if product not enabled. 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 verbose but well-structured with logical sections. Every sentence adds value given the complexity of payment semantics. Could be trimmed, but front-loads core purpose effectively.

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 explains the return structure: fields, arrays, derived status, open_bill object, future_bills, and connector asymmetry. Also provides cross-reference to related tool for transactions. No gaps for an agent to understand what the tool returns.

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 must compensate. It explains account_id, account_ids, and include_open_bill in detail, but does not describe page and page_size parameters. This leaves a gap for pagination semantics, though they may be inferred. Baseline 3 due to low coverage, 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 CLOSED credit card bills for CREDIT-type accounts with specific fields. It distinguishes from sibling openfinance_get_credit_card_bill and openfinance_list_transactions by noting that the latter is for itemized transactions. The verb 'list' and resource are explicit.

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, including when to opt-in for open_bill (only if needed due to extra scan), when to use derived payment_status instead of raw payments[], and when to use a different tool for transactions. Also warns about connector asymmetry and misinterpretation of payments.

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, idempotentHint, destructiveHint. Description adds that it returns a specific error-handled response (total, results, warning) and lists data fields. 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?

Single sentence with inline list, front-loads purpose. Not overlong, but could be more structured. Acceptable.

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 what tool returns and response structure, but lacks parameter semantics and usage context. Without output schema, partial coverage of return values.

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% and description does not explain any parameter (item, page, type, page_size). The term 'connection' is used but not linked to 'item'. No added meaning.

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

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

The description clearly states it returns investment portfolio for a connection, listing specific asset types (FIIs, stocks, ETFs, etc.) and response fields. It distinguishes from siblings like openfinance_list_investment_transactions.

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

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

No explicit when-to-use or when-not-to-use guidance. It mentions error handling but does not clarify prerequisites (e.g., connection ID needed) or alternatives among siblings.

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 and idempotent behaviors. The description adds value by detailing the output structure (fields like quantity, value, expenses) and bulk support. It does not mention pagination behavior, but overall adds useful behavioral context without contradicting annotations.

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

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

The description is concise with two paragraphs, front-loading the key purpose and output fields. It avoids redundancy but could benefit from structured formatting (e.g., list of fields). No wasted words.

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

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

Given the tool's complexity (multiple transaction types, many fields, bulk, pagination), the description covers main purpose, relationship to list_investments, and bulk support. However, it misses pagination details (page, page_size) and any default ordering or limits. Adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains investment_id (required) and investment_ids (for bulk). However, it does not mention page and page_size parameters, leaving their purpose unclear. Thus 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 the tool returns movement history for a specific investment position, lists transaction types (BUY/SELL/TAX/INTEREST/AMORTIZATION/TRANSFER) and response fields. It is distinct from siblings like openfinance_list_investments and openfinance_list_transactions.

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

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

The description explicitly tells to use after openfinance_list_investments to get investment_id, which provides sequential use guidance. It also mentions bulk support. However, it does not explicitly state when not to use or compare with alternatives like 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?

Discloses behavioral details beyond annotations: sequential querying with rate-limit spacing when multiple connections are specified, and the return format (`{ results, errors }` per connection). Annotations already indicate read-only and idempotent, which the description supports.

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: first states purpose and endpoint, second details parameter usage and behavior. Every sentence adds value, no fluff.

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

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

Despite no output schema, the description specifies the return structure and behavior for single vs. multiple connections, making it fully complete for effective agent usage.

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

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

With schema coverage at 0%, the description fully explains that `items` is an array of connection selectors (item_id uuid, connector_id, or connector_name), adding essential meaning absent 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 lists loan contracts per bank connection, naming the endpoint and differentiating from sibling tools (e.g., list_accounts, list_transactions) by focusing specifically 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?

Provides clear instructions on how to use the optional `items` parameter to specify connections, or omit for all banks. Implicitly distinguishes usage but does not explicitly state when not to use this tool vs. alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds extensive behavioral context: CREDIT PENDING vs POSTED varies by bank, search_queries aggregates up to 5000, on errors returns {total:0, results:[], warning, error} instead of throwing, and detail levels affect data richness. 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 long but well-structured with front-loaded main purpose. Every sentence adds value, though some details could be slightly condensed. Given the complexity, the length is justified.

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 lacking an output schema, the description covers output behavior (truncated flag, zero results, error responses) and cross-references to related tools (e.g., openfinance_list_credit_card_bills, openfinance_get_item_status). It is sufficiently complete for agent 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 fully compensates by explaining all parameters: from/to date format (ISO YYYY-MM-DD), pagination (max 500/page), detail enum (compact/rich/raw with specific use-cases), search_queries (case-insensitive substring match, OR semantics), and bulk support via account_ids.

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

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

The description clearly states 'Returns transactions for a bank account (BANK or CREDIT type)' and explicitly distinguishes from siblings like openfinance_list_credit_card_bills, making the tool's purpose unambiguous.

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

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

The description provides detailed when-to-use and when-not-to-use guidance, including alternatives: 'For CREDIT... this is the ONLY way to get itemized transactions' and 'To get a standardized open-bill total... use openfinance_list_credit_card_bills'. It also covers error handling and connection health checks.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description reveals important behaviors: the tool caps at 5000 transactions per account with a truncated flag, returns compact summary by default, and describes output structure including monthly evolution, top expenses, and per-account breakdown. 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 a single dense paragraph that could be more structured with bullet points or clearer section breaks, but every sentence adds value and the core purpose is 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 tool's complexity (7 parameters, no output schema), the description is comprehensive: it explains the output format, behavior (truncation), parameter semantics, and use cases. No apparent 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?

Although schema description coverage is 0%, the description thoroughly explains all 7 parameters: from/to as ISO dates, item as connector identifier, type filtering, detail options (compact/rich/raw), granularity (monthly/raw), and top_n. Defaults (e.g., granularity monthly) are also noted.

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 does consolidated cash-flow analysis for a bank connection in one call, explicitly distinguishing itself from siblings by noting it resolves accounts internally without needing separate calls to list accounts or carry account IDs.

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

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

Provides explicit use cases ('análise anual/mensal', 'fluxo de caixa') and explains when to use different granularity and detail options. Also clarifies how to target one bank vs all, and contrasts with other tools by saying you do not need to call openfinance_list_accounts first.

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 return structure (global indicator, degraded components, open incidents, `your_banks_affected`) and explains its operational behavior (checking a public status page, not your own connection). Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value without contradiction. A 5 would require mention of rate limits or data freshness, but it's still strong.

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

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

The description is relatively verbose but every sentence adds distinct value: purpose, distinction from sibling, usage scenario, and return details. It could be slightly tighter (e.g., 'LIVE' vs 'live'), but it is well-structured and front-loaded with the key 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 fully covers what the tool returns (global indicator, components, incidents, `your_banks_affected`) and explains how to interpret the results. Given that there is no output schema, this level of detail is essential and complete for the agent to use the tool correctly.

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

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

There are zero input parameters, and schema description coverage is 100%. The description does not add parameter-level semantics (none exist), but it compensates by detailing the output fields and their meaning, which helps the agent understand what the tool returns without needing to call it first.

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 ('Checks the LIVE operational status') and clearly identifies the resource ('Open Finance provider (its public status page)'). It explicitly distinguishes this tool from the sibling `openfinance_get_item_status`, which checks connection health, not provider health.

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 ('whenever data looks incomplete or stale even though a connection shows UPDATED') and what problem it solves (distinguishing upstream outage from connection issues). It also names the alternative tool (`openfinance_get_item_status`) for connection-specific status.

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

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

The description adds valuable behavioral context beyond annotations: it honors user's plan (PF hides PJ banks), requires keywords (else hint), and includes a pre-selected connect_url. Annotations already mark it as readOnly, idempotent, non-destructive, and the description aligns with those.

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 efficient paragraph of four sentences, each with distinct purpose: function, return details, plan behavior, and usage note. No superfluous 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?

Without an output schema, the description fully details the return structure (id, access, audience, connections, accounts conditionally, connect_url) and key behaviors (plan filtering, keyword requirement). It also gives clear usage context, making it self-sufficient.

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

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

Schema descriptions coverage is 0%, so the description must compensate. It explains that keywords[] is required (with example and consequence of omission) and that include_accounts=true returns accounts. This fully covers both parameters with meaningful guidance.

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

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

The description explicitly states it searches bank connectors by name using keywords, and lists the returned fields, including a connect URL. This clearly distinguishes it from sibling tools like openfinance_list_connections, which list all connections without search.

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

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

The description instructs to call this BEFORE connecting to provide a one-click link, and warns that keywords[] is required (without it returns a hint, not the full catalog). It does not explicitly compare to sibling tools but gives clear usage context.

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

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

Discloses that it overrides automatic categorization and teaches Pluggy by creating a category rule, and details batch behavior (per-item errors do not fail the whole batch). Annotations provide no such detail.

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

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

Single paragraph packs all essential information but is slightly lengthy; however, every sentence adds value and the main action is 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?

Covers all necessary context for a batch mutation tool: parameters, side effects, error handling, and response shape, despite no output schema.

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

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

Despite 0% schema coverage, the description thoroughly explains that items is an array of { transaction_id, category_id } and where to obtain those IDs, adding meaning beyond the schema structure.

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 corrects the category of transactions with the specific API endpoint PATCH /transactions/:id, and distinguishes from siblings by referencing where to get transaction and category IDs.

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

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

Explicitly explains when to use (fix miscategorized transactions), notes the side effect of creating a category rule for future similar transactions, and provides context on batch error handling.

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 non-destructive and idempotent behavior. The description adds the requirement to include the conversation array but does not disclose other behavioral aspects like authentication needs or server response. It provides marginal additional value.

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

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

Two sentences that are front-loaded and concise. The first sentence effectively states the purpose. Could be slightly more structured but is efficient overall.

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 bug-report tool with 3 parameters and no output schema, the description is adequate but lacks details like expected outcome or any confirmation. It is minimally complete but could be more informative.

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 mentions 'conversation array' for reproduction, adding meaning beyond raw schema, but doesn't explain 'context' or 'message' beyond their names. It partially compensates but is insufficient for the low coverage.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' This is specific and distinguishes it from siblings, which are all about OpenFinance or 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 advises to 'Include the conversation array with recent messages for reproduction,' providing clear guidance on what to include. While no explicit when-not-to-use is given, the sibling tools are unrelated, so usage 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 already declare readOnlyHint, idempotentHint, destructiveHint, so the description adds the specific output (platform and adapter). No contradictions. It could mention caching or stability but not required for this simple tool.

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, perfectly concise, no wasted words.

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

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

As a parameterless version tool, the description completely covers what the tool does. No output schema needed.

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

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

No parameters exist, so description adds no parameter info beyond schema. Baseline score of 4 is appropriate given zero parameters.

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

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

The description clearly states it shows MCP platform and adapter versions, which is specific and unambiguous. No sibling tool does this, so it's well-differentiated.

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

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

The description implies it's for checking versions, and given the sibling tools are mostly finance and auth operations, the usage context is clear. However, it lacks explicit guidance on 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 destructiveHint, so the description's role is to add behavioral context. It specifies exactly what is returned (installed MCPs, connection status, catalog tool counts), which goes 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?

A single, focused sentence that front-loads the purpose and lists specific return contents. No wasted words.

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

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

With zero parameters and no output schema, the description and annotations together provide a complete specification of the tool's behavior. No additional information is needed.

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

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

No parameters exist; schema coverage is 100% (empty). Baselines at 4 since no parameter information is needed. Description adds no parameter semantics but that is not required.

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 retrieves toolkit state including installed MCPs, connection status, and catalog tool counts. This is specific and distinguishes it from sibling tools that focus on financial operations or 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?

No explicit usage guidelines are provided, but the tool's purpose is self-explanatory given it is the only informational tool among siblings. Implicitly it should be used when toolkit state is needed.

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