Necton MCP

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

The description explains the behavior beyond annotations: idempotent, session vs permanent, and how to get the token. No contradiction with annotations. It adds value by explaining the browser login flow.

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 slightly verbose but well-structured, front-loading the purpose and then detailing usage. All sentences add value, though it could be tightened slightly.

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

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

For a simple authentication tool with one parameter and no output schema, the description is complete. It explains the two modes and the source of the token. Missing explicit return value description, but the 'get the link' implies the output.

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 explains the 'token' parameter well: it's a JWT from browser login. It also explains the no-arg case for getting the link. Compensates adequately for lacking schema descriptions.

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

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

The description clearly states the tool's purpose: authenticating for IDE agents. It specifies the verb 'authenticate' and the resource 'user authentication'. It differentiates from siblings by being the only authentication tool.

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

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

Provides explicit guidance on when to use, including two clear scenarios: permanent via config or session-only via token. Tells the agent exactly how to invoke it with or without arguments.

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

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

Annotations already declare readOnly and idempotent behavior. Description adds context on returned fields (authenticated, pending, connect_url) and conditions, providing value beyond annotations.

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

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

Two sentences, no fluff, front-loaded with main 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?

Covers main behavior and response shape hint. Could mention error states, but sufficient for a simple status tool. No output schema, but description compensates.

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 is 100%. Description does not need to add parameter info. Baseline 4 is appropriate.

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

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

The description clearly states it returns connection status and URLs, with specifics on authentication states. However, it does not distinguish from siblings like 'authenticate' which may also relate to 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?

Implies use for checking connection status, but lacks explicit when-to-use vs alternatives. Given siblings like 'authenticate' and 'marketplace', more guidance would help.

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 not covered by annotations: the range of actions (search, describe, invoke, install, etc.), the one-off invoke behavior without installation, auth/payment handling, and permission requirements. No contradiction with annotations.

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

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

The description is dense but efficient, covering all necessary concepts in a single paragraph. It could be slightly more structured, but every sentence adds value without repetition.

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

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

Given no output schema and complex multi-action behavior, the description is exceptionally complete: it explains each action, the invoke vs install distinction, auth/payment handling, permission requirements, and integration with other tools. No gaps identified.

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 adds significant meaning by explaining the action enum and how parameters like mcp_id, tool_id, arguments relate to each action. However, not all 13 parameters are individually described, relying on the overall flow.

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's role as 'the official mcp.ai marketplace' for discovering and running MCPs/tools. It distinguishes itself from siblings by instructing to use this tool first before external registries, and contrasts with sibling tools like authenticate and openfinance_*.

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 guidelines: use first for any capability search, prefer invoke for one-off use vs install for permanent addition. Specifies permission requirements for writes (owner/admin) and explains conditions for auth/payment flows.

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 the destructiveHint annotation by specifying that bank data will no longer be available and that a reconnection URL is returned. 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?

Three sentences, no filler, front-loaded with the primary action. 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?

Covers purpose, effect, and return for a simple destructive action with one parameter. Could elaborate on the reconnection URL, but overall adequate.

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

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

The 'item' parameter (required) is not described. The description mentions 'specific bank' but does not clarify whether it expects an ID, connection token, or bank name. With 0% schema description coverage, more detail is needed.

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

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

The description clearly states the action ('revokes Open Finance consent', 'deletes connection data') and the resource ('specific bank'), distinguishing it from siblings like openfinance_list_connections or openfinance_force_sync.

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 implicitly indicates usage (when you need to disconnect a bank), but lacks explicit guidance on when not to use it or alternatives. It is adequate but not explicit.

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 the tool forces a sync, waits up to 60s, and returns specific fields (status, executionStatus, etc.). Describes outcomes like needs_action and timed_out. Adds value beyond annotations which only indicate non-read-only, non-destructive, non-idempotent.

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

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

The description is thorough but slightly lengthy. However, it is well-structured with front-loaded purpose, clear parameter details, and return value explanation. Every sentence adds value, earning a slight deduction for verbosity.

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 the complex polling behavior, return structure (results, errors), and relevant fields including edge cases (needs_action, timed_out). No output schema exists, but the description provides sufficient detail for correct invocation and result interpretation.

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

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

Despite 0% schema description coverage, the description fully explains both parameters: 'items' as 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 compensates entirely for missing schema docs.

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 specifies the verb 'force sync', the resource 'connections', and the behavior (re-sync NOW and WAIT). It distinguishes this tool from siblings like openfinance_get_item_status by mentioning polling and alternatives.

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 ('when a balance or transaction list looks stale') and when not to use (not disconnecting/reconnecting). Provides alternative for timed_out case (openfinance_get_item_status) and differentiates wait modes (fire-and-forget vs synchronous).

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral details beyond this: the response shape, error structure, and that credit accounts return warnings. No contradiction with annotations.

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

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

The description is three sentences, each providing essential information: purpose and endpoint, parameter usage and error case, and response shape. No unnecessary words or redundancy. Well-structured and front-loaded.

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

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

Given the parameter count (1), no output schema, and the tool's specific role among 23 siblings, the description covers the key aspects: real-time balance, array size constraint, error handling for credit accounts, and response format. It does not mention auth or rate limits, but those are likely handled at a higher level.

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 lists only 'account_ids' as a required array of strings with 0% description coverage. The description adds critical meaning: the array must contain 1–50 account IDs, and explains how to pass it. This compensates for the schema's lack of description.

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

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

The description clearly states the function: 'Returns real-time balance payload per account id (GET /accounts/:id/balance).' It specifies the verb (returns), resource (balance), and API endpoint. It distinguishes from sibling tools like openfinance_get_accounts_detail or openfinance_list_accounts by focusing specifically on balance retrieval.

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

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

The description gives explicit usage guidance: 'Pass `account_ids` as an array (1–50).' It also explains how credit account errors are handled with warnings instead of exceptions. It does not explicitly mention when not to use this tool or alternatives, but the context makes the purpose clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral details: batch shape { results, errors } and array size constraint (1-50), which go beyond annotations.

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

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

Two sentences, no wasted words. Front-loaded with the core return value and 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?

For a read tool with no output schema, the description explains return shape (batch), key included data (creditData), and input constraints. Lacks explanation of other fields in account object, but overall adequate.

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

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

Schema coverage is 0%, but the description compensates by explaining the single parameter account_ids is an array of IDs with a 1-50 size limit and that it retrieves per ID. This adds significant 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 full account objects with extended creditData, specifying the HTTP endpoint. It implies a more detailed response than the sibling list_accounts, though it does not explicitly differentiate.

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

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

It instructs to pass account_ids as an array (1-50) and hints at use for full details including creditData, but provides no when-not or comparison to alternative tools like openfinance_list_accounts.

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, idempotentHint, and destructiveHint. The description adds significant behavioral context: the tool does not return individual transactions, returns batch shape { results, errors }, notes that Pluggy does not return a paid/status field, and explains the nuanced meaning of payments[] reflecting the previous bill's payment. No contradiction with annotations.

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

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

The description is fairly long but each sentence adds necessary value. It is well-structured: main purpose, exclusions, parameter usage, and important notes. Slightly verbose but not excessive.

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

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

Given no output schema, the description explains output shape and important details about payments and paid status. However, it does not enumerate all fields in the bill-level detail beyond financeCharges and payments, which could be more complete.

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

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

The schema has 1 parameter (bill_ids) with 0% description coverage. The description compensates by explaining it must be an array and that ids come from first using openfinance_list_credit_card_bills. It also mentions the batch shape. This is sufficient but could include an example or note on required length.

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 bill-level detail for credit card bills by id, listing specific fields (financeCharges, payments array). It explicitly distinguishes itself from sibling tools by stating what it does not return and directing 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?

The description provides explicit usage guidance: use openfinance_list_credit_card_bills first to discover ids, pass bill_ids as an array, and for individual transactions use openfinance_list_transactions with specific date range and account_id. It also warns about the meaning of payments[] and that Pluggy does not return paid status.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing status values, output shapes, and the effect of omitting vs. passing `item`. 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 sentences, front-loaded with purpose, then usage variants. No wasted words, efficient and clear.

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

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

Given the tool has one optional parameter and no output schema, the description adequately covers both invocation modes and expected outputs, including status values and shapes. Missing details like 'connector metadata' are minor.

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

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

Schema coverage is 0% with no parameter descriptions. The description fully explains the `item` parameter: omit for all banks, pass a string for a single bank. This adds complete meaning beyond the schema.

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

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

The description clearly states it returns the current status of a bank connection, lists possible status values (UPDATED, UPDATING, LOGIN_ERROR, etc.), and distinguishes between getting all banks or a single bank. This differentiates it from sibling tools like openfinance_list_connections.

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

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

The description provides explicit guidance on when to omit vs. pass the `item` parameter, covering both use cases. It does not explicitly state when not to use it, but the context is clear given the sibling tools.

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

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

Annotations indicate read-only, non-destructive, idempotent. The description adds that response structure varies based on 'item' presence, 'name' is legal entity not brand, 'balance' meaning is connector-dependent, and key fields like 'bank' and 'connector_id' are explained.

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 detailed and front-loaded but slightly verbose with multiple caveats. However, every sentence adds value, and it is well-structured with clear separations of usage, caveats, and references.

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

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

Given no output schema and moderate complexity (multiple account types, connector-dependent behavior, two response structures), the description covers all necessary aspects: return fields, parameter effects, data interpretation warnings, and sibling tool references, making it fully 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 coverage is 0%, but the description fully explains both parameters: 'item' controls scope (all banks vs one) and 'type' filters account type. It also describes response fields and behavior changes, adding 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 returns accounts with specific fields (balance, number, type, etc.) for bank connections. It distinguishes from siblings by explaining when to omit or pass 'item' and references openfinance_list_credit_card_bills for billing 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?

Explicitly describes when to use 'item' vs omit it: 'OMIT item to list accounts across ALL linked banks...' and 'Pass item to target a single bank'. Also warns about 'balance' being connector-dependent and directs to a sibling tool for standardized billing.

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. The description adds valuable context: caching, single aggregated response, no batch ids. 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 well-structured sentences, front-loaded with main purpose, then details. Could be slightly tighter, but information density is good.

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, good annotations, and description adding caching and relationship to update tool, it is complete. No output schema, but entry fields are fully described.

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; baseline for 0 params is 4. Description does not need to add parameter 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?

The description clearly states it returns Pluggy's transaction category taxonomy, cached for the session. It specifies the structure (id, description, etc.) and links to openfinance_update_transaction_category, distinguishing 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?

The description implies usage before openfinance_update_transaction_category by noting the id field is used by that tool. It does not explicitly state when not to use it, but with no sibling category tools, the context is clear.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds specific return fields and indicates an add_connection_url is provided, enhancing understanding 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?

Single sentence, front-loaded with the core purpose, every word adds value. No wasted content.

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

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

Given no parameters, read-only, and annotations covering safety, the description fully specifies return content. No output schema needed because fields are listed.

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%. Baseline 4 applies as per rules with no need for additional 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?

The description clearly states it returns saved bank connections and specifies the fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling 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?

No guidance on when to use this tool versus alternatives. Sibling tools exist for listing other entities but no contextual or when-not advice 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds significant behavioral context: payment status derivation logic, connector asymmetry for open bills, that the tool returns a warning instead of failing if CREDIT_CARDS is not enabled, and how payments[] relate to bills. 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 lengthy but front-loaded with the main purpose. It details complex payment semantics and connector behaviors, which are necessary for correct use. While some redundancy may exist, every major section adds value given the tool's complexity. Could be slightly more streamlined but generally efficient.

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

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

Given no output schema, the description thoroughly explains return fields including payments[], payment_status, open_bill, future_bills[], and derived values. It also covers edge cases (connector asymmetry, unconfirmed payment, warning on disabled product). For a complex tool, this is comprehensive and leaves little ambiguity.

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 5 parameters with 0% description coverage, so the description must compensate. It explicitly explains include_open_bill and account_ids (bulk support), and implies account_id. However, page and page_size parameters are not mentioned in the description, leaving some reliance on schema names. Overall, it provides meaningful semantics for most 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 starts with 'Returns CLOSED credit card bills for a CREDIT-type account', clearly indicating the verb (returns) and resource (closed credit card bills). It distinguishes from sibling tools like openfinance_get_credit_card_bill (single bill) and openfinance_list_transactions (itemized transactions) by explicitly stating that this tool returns bill-level summaries, not individual 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 provides explicit guidance on when to use this tool vs alternatives. It explains the opt-in include_open_bill parameter, warns about connector asymmetry, and explicitly says 'To see itemized purchases/charges per bill, use openfinance_list_transactions'. It also gives instructions on interpreting payment_status and advises against calling a bill 'vencida' categorically.

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

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

Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: it returns a structured warning object instead of throwing on 403 errors, and details the returned fields. Could mention authentication or rate limits but adds meaningful transparency.

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

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

Two sentences front-load the main purpose and key details. The first sentence lists covered investment types and fields efficiently; the second handles error behavior. No extraneous content.

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

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

The description explains the output structure sufficiently given no output schema, covering return fields and error handling. However, it lacks explanations for parameters like page_size and type, leaving gaps for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, and the description does not explain any of the four parameters (item, page, type, page_size). The tool's input semantics are entirely opaque, requiring the agent to infer meanings from names alone.

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

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

The description clearly states the tool returns investment portfolio data for a connection, listing specific types (FIIs, stocks, ETFs, etc.) and fields. It distinguishes from siblings like openfinance_list_investment_transactions by focusing on portfolio overview rather than 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 specifies using this tool for connections with the INVESTMENTS product enabled and explains the error handling when not enabled. It does not explicitly exclude alternatives but implies the scope; a more explicit link to sibling tools would improve clarity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds value by detailing the return fields and bulk support. No contradictions; the description aligns with readOnlyHint as a read 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?

Two short paragraphs: first lists transaction types and fields, second states prerequisite and bulk support. No filler, front-loaded with key information.

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

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

Despite no output schema, the description lists key return fields, explains prerequisite, and mentions bulk functionality. Covers essential context for selecting and invoking the tool, complete given the moderate 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 clarifies the meaning of investment_id (from previous tool) and investment_ids (bulk), but does not explain page and page_size, leaving their role in pagination unaddressed.

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

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

The description clearly states it returns 'movement history for a specific investment position' and lists transaction types (BUY/SELL/TAX/etc.), distinguishing it from siblings like openfinance_list_investments (lists positions) and openfinance_list_transactions (likely general 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 instructs to use after openfinance_list_investments to get the investment_id, and mentions bulk support via investment_ids. Does not explicitly state when not to use or list alternatives, but the prerequisite is clearly communicated.

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, idempotent, non-destructive. Description adds key behavioral details: sequential queries with rate-limit spacing, and return structure per connection ({ results, errors }). 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?

Three sentences, front-loaded with purpose. No redundant information. Every sentence adds value.

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

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

Covers essential aspects: parameter use, two modes, rate-limiting, return format. Lacks mention of pagination or error handling specifics, but for a list tool with optional parameter, it is largely complete.

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

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

With 0% schema description coverage, the description fully compensates by explaining the 'items' parameter as an array of connection selectors (item_id, connector_id, or connector_name) and its optionality. Adds critical meaning beyond raw schema.

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

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

The description clearly states the action ('Lists loan contracts per bank connection') and the resource, distinguishing it from sibling list tools by specifying it operates per bank connection with connection selectors.

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

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

Provides explicit usage guidance: when to include items vs omit it ('OMIT items to list loans across ALL linked banks'). Mentions sequential querying with rate-limit spacing. Does not explicitly exclude alternatives among siblings, 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 well beyond annotations by detailing pagination behavior (auto-pagination vs manual page walking with explicit page parameter), truncation warning at 5000 items, error handling (returns structured error object instead of throwing), detail levels and their trade-offs (compact vs rich vs raw), credit card timing nuances (PENDING vs POSTED varies by connector), and bulk support via account_ids. All behavioral traits are transparently disclosed.

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

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

The description is richly informative but somewhat verbose. It includes multiple paragraphs with some repetition (e.g., 'Same query, different coverage per bank (upstream)' appears twice in similar context). However, it is well-organized into logical sections (purpose, credit card specifics, search, pagination, error handling, detail levels) and front-loaded with the most important information. Minor tightening could improve conciseness but it remains clear and readable.

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 and 8 parameters, the description covers all necessary context for an AI agent to use the tool correctly: purpose, alternatives, pagination behavior, error handling, detail levels and their effects, credit card specifics (billId linking), search semantics, and cross-references to sibling tools for related info. It also addresses edge cases (total=0, connection health). The description is self-contained and 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?

Given that the input schema has 0% description coverage, the description fully compensates by explaining every parameter: from/to as ISO date filters, page and page_size for pagination, detail enum with meanings, search_queries as case-/accent-insensitive substring match with OR semantics, account_id as required, and account_ids for bulk. This adds complete semantic 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 returns transactions for bank accounts (BANK or CREDIT types). It distinguishes itself from siblings by specifying that for CREDIT accounts it is the only way to get itemized transactions and links to related tools like openfinance_list_credit_card_bills. The verb 'Returns transactions' and resource 'bank account' are specific and unambiguous.

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

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

The description provides explicit when-to-use and when-not-to-use guidance. It states that for CREDIT accounts this is the ONLY way to get itemized transactions, and directs users to openfinance_list_credit_card_bills for standardized open-bill totals, to openfinance_list_accounts for closing/due dates, and to openfinance_get_item_status for connection health. This gives clear 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, destructiveHint=false. Description adds substantial behavioral context: resolves accounts internally, caps at 5000/account with truncation flag, default granularity response structure, and behavior when omitting item. 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 front-loaded with main purpose and packed with useful details. Every sentence adds value, but length could be slightly reduced for skimming. Still efficient for the complexity.

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

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

Despite no output schema, description explains output structure (total entradas/saídas, monthly evolution, top categories, per-account breakdown) and behavior of granularity/detail. Includes truncation limit and effect of omitting item. Comprehensive for 7 parameters.

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 fully explain parameters. It does: defines 'item' as connector_id/connector_name/item_id, 'from'/'to' as ISO dates, 'granularity' with monthly/raw, 'detail' with compact/rich/raw, 'type' with BANK/CREDIT, and 'top_n' for top items. Fully compensates.

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

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

Description clearly states the tool's purpose: consolidated cash-flow analysis for a bank connection in one call. Specific verbs (analyze, resolve, fan out) and resource (bank connection transactions) with clear differentiation from siblings like openfinance_list_transactions and 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?

Explicitly states when to use ('análise anual/mensal', 'fluxo de caixa', etc.) and when not to use raw transactions. Tells user they don't need to call openfinance_list_accounts first. Could be improved by explicitly naming sibling tools for alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich behavioral context: returns global indicator, degraded components, open incidents, and flags incidents affecting user's banks via your_banks_affected. 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?

The description is longer than necessary but well-structured, with purpose first followed by usage scenarios and return details. Could be slightly more concise, but 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?

Without an output schema, the description fully describes what the tool returns: global indicator, degraded components, open incidents, and your_banks_affected. It is comprehensive for a zero-parameter 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?

The input schema has zero parameters, so the description does not need to explain them. Baseline for no parameters is 4, and the description adds no confusion.

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

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

The description clearly states it checks the LIVE operational status of the Open Finance provider, distinguishing it from the sibling tool openfinance_get_item_status which checks your own connection. The verb 'checks' and resource 'provider status' are specific.

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

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

Explicitly states when to use: 'whenever data looks incomplete or stale even though a connection shows UPDATED'. It names the alternative tool openfinance_get_item_status, providing clear context 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 indicate read-only and idempotent. Description adds valuable context: returns ready connect_url, honors user plan, and includes caveat for non-Open-Finance connectors. 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?

Reasonably concise for the amount of detail; front-loaded with purpose. Slightly dense but 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?

No output schema, but description fully describes return fields (id, access, audience, connections, accounts, connect_url, caveat) and behavior with empty keywords. Complete for the tool's complexity.

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

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

Despite 0% schema coverage, description explains keywords with examples and states it's required, and explains include_accounts returns accounts when true. Fully compensates for missing schema documentation.

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

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

Description clearly states it searches bank connectors by name, lists what it returns, and distinguishes from other tools by positioning it as a prerequisite 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 states keywords[] is required and that it should be called before connecting. Mentions plan filtering but does not explicitly list when not to use or compare to alternatives like openfinance_list_connections.

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 critical behavior beyond annotations: overrides automatic categorization, teaches Pluggy via rule creation, batch error handling (per-item errors don't fail whole batch). Annotations only indicate non-readOnly, non-destructive, non-idempotent, non-openWorld; description adds rich context.

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

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

Single dense paragraph front-loads purpose, efficiently covers all key aspects without waste. 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 no output schema, description provides return shape, error handling, side effects, and parameter sources. Fully addresses the tool's complexity (mutation with batch processing and learning 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?

Despite 0% schema coverage, description fully explains the `items` parameter structure, required fields, and where to obtain values (from list tools), adding complete semantic 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?

Clearly states the action: 'Corrects the category of one or more transactions' with HTTP method and endpoint. Distinguishes from siblings by referencing where to get IDs from openfinance_list_transactions and openfinance_list_categories.

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

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

Explains when to use (fix miscategorized transactions, improve future accuracy) and the side effect of creating a Category Rule. References sibling tools for IDs, but does not explicitly state when not to use.

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

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

Annotations indicate idempotentHint true and destructiveHint false, but the description adds no behavioral context beyond asking for conversation. No disclosure of what happens upon submission or side effects.

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

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

Two concise sentences, front-loaded with the core action. No extraneous information, though it could be slightly more detailed.

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 and parameter descriptions, the description is incomplete. An agent would miss details about parameter semantics and the return type.

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 the description only clarifies the 'conversation' parameter. The 'context' and 'message' parameters remain unexplained, leaving ambiguity about their use.

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 specifies the tool's purpose: reporting bugs, missing features, or sending feedback. It distinguishes itself from sibling tools which are primarily for banking 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 alternatives provided. It only mentions including the conversation array, but lacks guidance on when this tool is appropriate versus other actions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no additional behavioral context beyond what annotations provide, meriting a baseline score.

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, concise sentence that conveys the tool's purpose with no unnecessary words. It is front-loaded and efficient.

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

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

For a simple read-only tool with no parameters, the description is complete enough. However, it lacks mention of the return format, which could be helpful.

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

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

The tool has zero parameters, and the description does not need to add parameter meaning. Baseline score of 4 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb ('Show') and resource ('MCP platform and adapter versions'). It is distinct from sibling tools, none of which provide version information.

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

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

The description clearly implies when to use (to check versions) but does not explicitly mention when not to or provide alternatives. Given the tool's simplicity, this is 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds what specific information is returned, but does not disclose any additional behavioral traits beyond that. No contradictions.

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

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

The description is a single sentence that is clear, front-loaded, and contains 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 has no parameters and no output schema, the description provides sufficient context about the type of data returned. However, it does not specify the exact structure or format of the output, 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?

The tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter information; baseline for 0 params is 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 returns toolkit state with specifics: installed MCPs, connection status, and catalog tool counts. It distinguishes from sibling tools like authenticate and connect, which perform actions rather than read state.

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 state, but does not explicitly state when or when not to use, nor does it mention alternatives. For a read-only info tool, this is acceptable but lacking explicit guidance.

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