Carrefour MCP

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

The description adds significant behavioral context beyond annotations: calling without args returns a login link, calling with a 'token' arg accepts a JWT for session login, and mentions a permanent method via config. 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 two sentences, efficiently conveying options. The first sentence is slightly long but still clear. Could be slightly more concise, but overall well-structured.

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

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

For an authentication tool with no output schema, the description fully covers the two behaviors (with/without token) and mentions a permanent alternative. No missing information for its purpose.

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 optional parameter 'token' is fully explained: it is a JWT that the user pastes. Since schema coverage is 0%, the description compensates entirely, adding meaning and usage 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?

The description clearly states the tool is for authentication, specifying it provides a login link or accepts a token. It distinguishes itself from sibling tools like 'connect' or 'openfinance_*' which are unrelated.

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

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

The description explains when to use the tool: for IDE agents to log in, with two options (permanent config vs. session-only token). It does not explicitly state when not to use it, but the context is clear.

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

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

The description adds behavioral context beyond annotations (e.g., 'readOnlyHint: true' is confirmed, and it explains what the response contains in different scenarios). 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 sentences, no unnecessary words, front-loaded with purpose. 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 zero parameters and no output schema, the description fully explains the tool's behavior and expected output. No gaps.

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

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

No parameters exist, so description cannot add value for them. Baseline 4 applies as the description provides full behavior explanation.

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, differentiating between fully connected and missing credentials states. However, it could be more specific about the resource (e.g., 'Check connection status of the toolkit and provider integrations').

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 when to use (to check connection status) but does not explicitly mention alternatives or when not to use. Given sibling tools like 'authenticate' and 'openfinance_*', it's clear this is a status check, but no guidance on selecting it over other tools.

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

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

Discloses important behavior beyond annotations: invoke runs one-off without installing, may return connect/checkout links; writes (install, uninstall, etc.) require admin. No contradiction with annotations (readOnlyHint=false is consistent with write capabilities).

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 dense but well-structured, starting with purpose then detailing flow and special cases. Every sentence adds value, though it could be broken into clearer sections for 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 tool's complexity (10+ actions, no output schema), the description covers all major use cases: search, describe, invoke, install, billing, etc. It includes necessary context about auth, payments, and administrative scope.

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 for 13 parameters. The description explains the action enum and gives context for parameters like query, mcp_id, tool_id, arguments, but does not detail each parameter's format or required values. Adequate for understanding flow, but could be more explicit.

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 is "the in-platform catalog of every MCP/tool" and explains its role as a gateway to discover and run MCPs. It distinguishes itself from sibling tools (e.g., OpenFinance tools) by instructing to use this tool first before external registries.

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

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

Provides explicit guidance: "use THIS tool FIRST" contrasts with siblings. Details core flow (search→describe→invoke) and when to prefer invoke vs install. Notes permission requirements for write actions (workspace owner/admin).

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, and the description is consistent. It adds that the tool returns an add_connection_url, but does not disclose other behavioral traits like irreversibility beyond 'data will no longer be available'.

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 long, front-loaded with the key action, and every word serves a purpose (action, effect, return value). 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?

For a simple destructive tool with one parameter and no output schema, the description covers the main action and result. However, it lacks parameter details and could better clarify permanence of data loss.

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% for the single 'item' parameter, and the description does not explain what 'item' represents (e.g., bank identifier or connection ID). The description only vaguely mentions 'a specific bank'.

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 verb+resource: 'Revokes the Open Finance consent for a specific bank and deletes the connection data.' It clearly states the tool's purpose and distinguishes it from siblings like list or 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 usage for disconnecting a bank, but does not provide explicit guidance on when to use this tool vs. alternatives (e.g., list_connections first), nor does it mention when not to use it.

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

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

Annotations already indicate non-read-only and non-destructive behavior. The description adds rich behavioral context: polling up to ~60s, final status meanings (status, executionStatus, lastUpdatedAt, synced, needs_action, timed_out), and the effect of the 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 a single focused paragraph that front-loads the core action. Every sentence adds value—covering input, behavior, output, and edge cases—without repetition or fluff.

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

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

Despite having no output schema, the description explains the return structure ({ results, errors } with detailed fields) and covers error states (needs_action, timed_out) and fallback tool. It is complete for this nontrivial 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 the description fully explains both parameters: 'items' as an array of selectors (item_id, connector_id, or connector_name) and that omitting it syncs all; 'wait' as false for fire-and-forget. This compensates completely for missing schema descriptions.

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

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

The description uses a specific verb ('forces... to re-sync'), identifies the resource ('one or more connections'), and clearly distinguishes from siblings by mentioning when to use openfinance_get_item_status. It also explains the HTTP method and polling behavior.

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 this tool: when balance/transaction list looks stale and a connection reads UPDATED but is hours old. It also provides alternatives: use openfinance_get_item_status if timed out, and mentions when to set wait=false for fire-and-forget.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds context: real-time nature, structured response format with results and errors, and non-throwing warnings for credit accounts. No mention of rate limits or authentication, but these are likely covered elsewhere.

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 details. Every sentence adds value: endpoint, parameter constraints, edge case, response shape. No filler.

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 a single parameter and no output schema, the description explains the response structure and handles errors. Covers key usage details for a straightforward tool. No gaps detected.

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

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

Schema has 0% description coverage, so the description carries the burden. It explains that account_ids is an array of 1-50 IDs, adding meaning beyond the raw schema. Does not describe each parameter in detail but compensates with clear usage context.

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 real-time balance per account id, specifying the HTTP method and endpoint. It distinguishes from siblings like openfinance_get_accounts_detail and openfinance_list_accounts 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?

Provides explicit guidance on passing account_ids as an array (1-50) and explains error handling for credit accounts. Lacks explicit when-not or alternative tool recommendations but is sufficient for correct 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 readOnlyHint and idempotentHint, indicating a safe, idempotent read. The description adds that it is a batch operation returning a { results, errors } structure, which is behavioral information beyond what annotations provide. No contradictions.

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

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

Two concise sentences, no unnecessary words. The first sentence captures the main purpose and endpoint, the second clarifies the parameter format and return shape. Well-structured 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 read tool with one parameter and no output schema, the description is complete: it covers the purpose, parameter constraints, and return structure. No additional information is needed for an AI agent to select and invoke the tool correctly.

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

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

The schema has 0% description coverage for 'account_ids'. The description compensates by specifying it is an array (1-50 items), adding meaning beyond the schema's type and required fields. However, it does not clarify that the strings represent account identifiers, leaving some ambiguity.

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

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

The description clearly states it returns 'full account objects including extended creditData' and specifies the HTTP endpoint. It distinguishes from siblings like openfinance_list_accounts by emphasizing 'full' and 'extended creditData', and mentions the batch shape, 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 explains how to use the parameter (array of 1-50 account IDs) and the return shape, but does not explicitly guide when to use this tool over alternatives like openfinance_list_accounts or openfinance_get_account_balance. Usage context is implied but not directly stated.

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), describes batch shape {results, errors}, clarifies that payments[] reflects payments registered during this bill's cycle and not necessarily this bill's payment, and notes Pluggy does not return a paid/status field.

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?

Lengthy but every sentence adds value. Front-loaded with purpose, then details and caveats. Could be slightly more concise but overall effective.

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

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

For a tool with 1 parameter and no output schema, description thoroughly explains returned fields, batch shape, payment semantics, and cross-reference to sibling tools for discovering IDs and checking paid status.

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 explains bill_ids is an array and advises to first discover IDs via openfinance_list_credit_card_bills. Also mentions batch shape. Compensates well for lack of schema description.

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

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

Clearly states it returns bill-level detail for credit card bills by ID, listing specific fields (financeCharges, payments with subfields) and distinguishes from sibling tool 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?

Explicitly provides when to use (get bill detail), when not to use (use openfinance_list_transactions for transactions), prerequisite (use openfinance_list_credit_card_bills first to discover IDs), and important caveats about payments and paid status.

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

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

Annotations already indicate readOnly and idempotent. The description adds value by specifying the output includes executionStatus and connector metadata, and describes the all-banks return format ('{ count, items }'). No contradictions.

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

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

Two efficient sentences that are front-loaded with the core purpose. No redundant words; every phrase adds value.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers input behavior and output shape sufficiently. No missing information.

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 one parameter 'item' has no schema description (0% coverage), but the description fully explains its optionality and the behavioral difference when provided vs omitted. Compensates completely for the schema gap.

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

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

Clearly states it returns status of a bank connection with example values (UPDATED, UPDATING, LOGIN_ERROR). Distinguishes between retrieving all connections (omitting 'item') vs a single connection (passing 'item'), which differentiates it from siblings.

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

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

Provides explicit guidance: omit 'item' for all banks (with return structure) or pass 'item' for a single bank. However, no explicit when-not-to-use or alternatives like openfinance_list_connections are mentioned, but the context is clear.

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

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

Beyond annotations (readOnlyHint, idempotentHint), the description details response aggregation behavior, tagging per account when omitting item, and root-level fields when passing item. Warns about CREDIT balance interpretation.

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 detailed and well-structured, but slightly verbose at ~250 words. It front-loads key information but could be tightened without losing clarity.

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

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

Given no output schema, description fully covers response structure, parameter effects, CREDIT balance nuance, and references another tool for standardized billing. Complete for a tool with this complexity.

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

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

Schema coverage is 0%, but description fully explains both parameters: 'item' (optional, targets single bank) and 'type' (enum BANK/CREDIT), and how they affect response structure. Adds crucial 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?

Clearly states it returns accounts for a bank connection, listing types BANK and CREDIT with specific fields. Distinguishes from sibling tool openfinance_list_credit_card_bills by directing to it for standardized credit card 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?

Explicitly explains when to omit 'item' (list all accounts across banks) vs. pass 'item' (target a single bank), and warns about the connector-dependent meaning of CREDIT balance, providing 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?

Annotations declare readOnly, idempotent, non-destructive. Description adds caching behavior and field semantics, providing value beyond annotations 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?

Efficiently structured with purpose, field details, and a note on aggregation. Every sentence adds value.

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

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

Fully describes the response structure, caching, and relationship to update transaction. 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, schema coverage 100%, so baseline is 4. Description does not need to add param info.

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 the transaction category taxonomy, explains each field, and distinguishes from siblings through the caching note and reference to openfinance_update_transaction_category.

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?

Mentions caching for the session and that it's a single aggregated response with no batch ids, implying it's for one-time retrieval. Could explicitly contrast with other list tools, 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 declare readOnlyHint and idempotentHint, which the description aligns with. The description adds value by detailing the return fields and mentioning the add_connection_url for linking more banks. No contradictions, and no additional behavioral concerns need disclosure for this simple read-only operation.

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

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

The description is a single sentence that is front-loaded with the purpose (returns saved connections) and then enumerates the returned fields. It is concise with 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?

Given the tool's simplicity (no parameters, no output schema), the description adequately covers what it does and what it returns. It might benefit from mentioning that it returns all connections or that it is a list operation, but it is sufficient for the context.

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

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

With zero parameters, the baseline is 4 per instructions. The schema coverage is 100% trivially, and the description does not need to add parameter info. The description appropriately communicates that no parameters are 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 it returns saved bank connections for the install and lists specific fields (connector_id, item_id, bank name, add_connection_url). This distinguishes it clearly from sibling tools like openfinance_list_accounts or 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 implies usage for viewing existing bank connections but does not explicitly state when to use this tool versus alternatives like connect for creating a connection or openfinance_disconnect_bank for removing one. No exclusions or alternative references are 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 indicate read-only and idempotent. The description adds extensive behavioral context: payment cycle semantics, derived payment_status, connector asymmetry for open bills, and warning vs failure behavior. 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?

Well-structured and front-loaded but very verbose. Multiple paragraphs with detailed examples could be more concise for quick scanning. Every sentence is informative but there is room for trimming.

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 fully explains return structure: fields, payments, payment_status, open_bill details. Also covers edge cases, connector asymmetry, and cross-tool references. Comprehensive.

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

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

Schema has 0% description coverage, but the description explains include_open_bill in detail and mentions account_ids for bulk. Pagination params (page, page_size) are not explicitly described but are standard. Overall adds significant meaning beyond 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 states it returns closed credit card bills for CREDIT-type accounts, listing specific fields. It clearly distinguishes from sibling tools like openfinance_list_transactions and openfinance_get_credit_card_bill.

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: to get closed bills. Provides guidance on interpreting payment_status and when to use include_open_bill. Directs to openfinance_list_transactions for itemized purchases.

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

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

Annotations already indicate readOnly and idempotent behavior. The description adds valuable transparency by detailing the alternative return format {total, results, warning} on errors, and enumerates specific fields returned, which is beyond what annotations provide.

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

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

The description is a single paragraph but efficiently packs core purpose, asset types, return fields, and error handling. It is front-loaded with the main action and avoids unnecessary detail.

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

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

The description covers key return fields and error behavior, but lacks parameter documentation and pagination details. Given the tool's complexity (multiple investment types, pagination), it is adequate but not fully comprehensive.

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

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

Schema description coverage is 0%, and the description fails to explain parameter meanings. For example, 'item' likely refers to a connection but is not defined, and 'type' enum values are not described. The description does not compensate for the lack of schema-level documentation.

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

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

The description clearly states the tool returns investment portfolio for a connection, listing specific asset types like FIIs, stocks, ETFs, etc. It distinguishes from sibling tools like openfinance_list_investment_transactions which focus on 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 implies usage for getting portfolio snapshot but does not explicitly state when to use vs alternatives or when not to use. No 'when-not-to-use' or alternative tool names are mentioned.

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

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

Annotations already declare readOnlyHint and idempotentHint. Description adds behavioral details: bulk execution via investment_ids and the prerequisite workflow. No contradictions.

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

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

Two concise paragraphs with no redundancy. Front-loaded with purpose and output fields, followed by bulk support note.

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 output fields, prerequisite, and bulk support. Lacks explanation of pagination parameters (page, page_size) given no output schema, leaving agents potentially unclear about pagination behavior.

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

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

Schema coverage is 0%, so description must compensate. It explains investment_id (implied) and investment_ids (bulk), but fails to mention page and page_size parameters. Half of parameters are undocumented.

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

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

Clearly states it returns movement history for a specific investment position, listing transaction types and key fields. Distinguishes from sibling tools like openfinance_list_transactions by its focus on investments.

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

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

Explicitly instructs to use after openfinance_list_investments to obtain investment_id. Mentions bulk support. Does not exclude alternatives but provides 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds behavioral details: sequential execution per connection, rate-limit spacing, and return format of '{ results, errors }' per connection. 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 with no wasted words. It front-loads the purpose, then explains usage options, then return format. Perfectly concise while covering all essential points.

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

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

For a simple list tool with one optional parameter and no output schema, the description adequately covers parameter usage, behavior, and return structure. It could mention pagination, but not necessary for this endpoint. Overall complete for its 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?

With 0% schema description coverage, the description fully compensates by explaining that 'items' is an array of connection selectors (item_id uuid, connector_id, or connector_name) and that each entry corresponds to one connection. This adds critical meaning beyond the schema's basic array-of-strings type.

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 ('Lists'), resource ('loan contracts'), and scoping ('per bank connection'). It differentiates from sibling list tools like openfinance_list_accounts by specifying the resource and the optional behavior to list across all banks.

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

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

Provides explicit guidance on when to pass 'items' vs omit it, and explains sequential querying with rate-limit spacing. However, does not explicitly state when not to use this tool or mention alternatives, though sibling context implies other list tools for different resources.

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: credit card pending/posted nuances, error return format with warning/error fields, truncated flag, and bulk execution. No annotation contradiction.

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

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

While lengthy, every sentence earns its place. The description is well-structured: starts with overall purpose, then details credit card behavior, then query parameters, error handling, and bulk support. Front-loaded with most important info.

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

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

Given 7 parameters, no output schema, and complex credit card behavior, the description covers all necessary aspects: return format (total, results, warning, error), truncated flag, date range narrowing, and cross-reference to other tools for credit card bills and connection health. Fully equips an agent to use the tool correctly.

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

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

Schema coverage is 0%, but the description explains all 7 parameters in detail: date filters (ISO YYYY-MM-DD), pagination (max 500/page), keyword search (case-insensitive, OR semantics, up to 5000 aggregated), and bulk via account_ids. Adds significant meaning beyond 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 it returns transactions for bank accounts (BANK or CREDIT type) and distinguishes itself from sibling tool openfinance_list_credit_card_bills by specifying that for credit cards this is the only way to get itemized transactions.

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

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

Provides extensive guidance: when to use this vs openfinance_list_credit_card_bills, how pending/posted behavior varies per connector, date/pagination/search usage, error handling, and tips for zero totals on credit accounts. Also mentions bulk support and suggests checking connection health.

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, so the tool is a safe read operation. The description adds valuable behavioral context: internal resolution of accounts, transaction fan-out, truncation at 5000/account with a flag, and the compact summary output by default. 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: it starts with the core purpose, then usage details, parameter explanations, and output description. Every sentence adds value, though it could be slightly more concise. It is appropriately front-loaded with the key benefit.

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

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

Given the complexity of the tool (6 parameters, no output schema), the description is comprehensive. It covers the purpose, all parameters, output format (including compact vs raw, monthly evolution, top expenses/revenues, per-account breakdown), edge cases (truncation), and usage contexts. It leaves no major gaps.

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

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

Schema description coverage is 0%, so the description must explain all parameters. It explains `item`, `from`, `to`, `granularity`, and `type` clearly. The `top_n` parameter is not explicitly defined but is implied via the output description ('largest N each'). Overall, it adds significant 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 it provides consolidated cash-flow analysis for a whole bank connection in one call, resolving accounts internally. It distinguishes from sibling tools like openfinance_list_transactions and openfinance_list_accounts by noting that no prior calls are needed. The verb 'list_transactions_by_item' is specific and the description clarifies the scope.

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 says when to use (cash-flow analysis, annual/monthly analysis) and when to use granularity='raw' (only when itemized rows needed). It advises against calling openfinance_list_accounts first. However, it does not explicitly state when not to use or provide alternative tool names, but the guidance is clear enough.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing what the tool returns: global indicator, degraded components, open incidents, and which incidents affect the user's banks.

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 necessary information. No redundancy or wasted words.

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

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

Given no parameters, rich annotations, and no output schema, the description fully explains the tool's purpose, output details, and when to use it, including context about user's banks affected.

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 does not need to add parameter meaning. The schema coverage is 100%, and the description adequately explains the tool's input-less nature, earning a baseline score of 4.

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

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

The description clearly states the tool checks the LIVE operational status of the Open Finance provider, uses a specific verb 'Checks', and distinguishes it from the sibling tool openfinance_get_item_status which checks the user's own connection.

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

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

The description explicitly states when to use this tool: when data looks incomplete or stale despite a connection showing UPDATED, and it contrasts with openfinance_get_item_status. While it doesn't list exclusions, the context is clear and helpful.

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

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

Annotations indicate readOnly and idempotent. Description adds behavioral details: returns connector id, access type, audience, linked connections/accounts, connect_url, and plan-based hiding of PJ banks for PF users. 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?

Description is detailed but each sentence adds value. Could be slightly more concise, but front-loaded with main action and organized logically. Minimal 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?

No output schema, so description covers return fields (connector id, access, audience, connections/accounts, connect_url) and edge cases (missing keywords, plan restrictions). Complete for a search tool.

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

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

Schema coverage is 0% but description fully explains both parameters: keywords (required, example given) and include_accounts (controls inclusion of accounts). Provides meaning beyond the schema itself.

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 keywords and returns specific fields. Verb 'searches' and resource 'bank connectors' are explicit. Differentiated from siblings like 'connect' by advising to call this before connecting.

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

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

Explicitly instructs to call this before connecting and that keywords[] is required. Explains behavior without keywords (returns hint) and how user's plan is honored. Lacks explicit when-not-to-use but 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?

The description goes beyond annotations (which only show readOnlyHint=false and destructiveHint=false) by disclosing that the tool overrides automatic categorization, creates a category rule affecting future transactions, and provides batch behavior with per-item error handling. 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 dense but efficient, front-loaded with the action and followed by essential details. It could be slightly streamlined, but every sentence adds significant value without fluff.

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

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

Given the absence of an output schema and the tool's complexity (batch update with side effects), the description is exceptionally complete. It covers input sources, output shape (updated, results, errors), and the teaching mechanism, leaving no ambiguity for an AI agent.

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

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

Schema coverage is 0% (no description for properties), but the tool description fully compensates by explaining the items array, the required fields (transaction_id, category_id), and their origins from other tools. This adds critical meaning beyond the raw schema.

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

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

The description explicitly states the tool corrects transaction categories via PATCH, specifies input format, and explains the side effect of creating a category rule. It distinguishes from sibling tools like list_transactions or list_categories by describing the update action and its impact.

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 (fix miscategorized transactions) and where to obtain required IDs from sibling tools. While it doesn't explicitly state when not to use it, the purpose is well-defined and the usage scenario 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 state idempotentHint=true, meaning repeated calls should be safe. The description adds that the conversation array is needed for reproduction, which is useful but does not further elaborate on behavioral traits like network effects or 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 a single, well-structured sentence that immediately states the purpose and then provides a crucial usage instruction. No unnecessary words.

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

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

Given the tool's simplicity (3 parameters, no output schema, annotations provided), the description covers the essential information: purpose and required input (conversation). It could be enhanced by noting the expected format of the conversation array but is otherwise 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?

With 0% schema description coverage, the description must compensate. It explains the conversation parameter partially ('Include the conversation array') but does not specify that it should be a JSON string or clarify the 'context' parameter. This leaves gaps in parameter understanding.

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

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

The description clearly identifies the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses a specific verb and resource, and is distinctly different from sibling tools which focus on financial operations and system utilities.

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 usage: 'Include the conversation array with recent messages for reproduction.' While it doesn't explicitly state when not to use this tool, the purpose is clear enough that an agent can infer when to invoke it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying that it shows both platform and adapter versions, which is behavioral context 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 a single, efficient sentence with no redundant words. It is front-loaded and earns its place.

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

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

Given the tool has no parameters and no output schema, the description is fully complete. It tells exactly what the tool does without omissions.

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 and schema coverage is 100% (empty). With no parameters, baseline is 4. The description does not need to add parameter information.

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 shows 'MCP platform and adapter versions', using a specific verb and resource. It distinguishes itself from sibling tools like openfinance functions or authentication 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?

While no explicit when-to-use or when-not-to-use guidance is given, the tool is simple and self-explanatory. The description implies it should be used to retrieve version information, which is clear given the 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 read-only, idempotent, non-destructive. The description adds the specific data returned (MCPs, status, catalog counts), providing useful context 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?

Single, clear sentence with no wasted words; effectively communicates the tool's output.

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

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

Given the tool has no parameters and no output schema, the description sufficiently covers what the tool returns and is complete for its purpose.

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 baseline is 4. The description correctly states what the tool returns without needing parameter 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?

The description clearly states the tool returns the current toolkit state including installed MCPs, their connection status, and catalog tool counts. It distinguishes from sibling tools that focus on specific operations.

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

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

No explicit when-to-use or when-not-to-use advice is given. The context implies it's for status overview, but no alternatives or exclusions are mentioned.

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