Unicred MCP

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

Annotations already provide idempotentHint, destructiveHint, and readOnlyHint. The description adds value by explaining that calling without token returns a link for browser login, and with token it directly authenticates. This transparently discloses the two-step flow and behavioral expectations, which is more than the annotations alone convey.

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 that efficiently covers purpose and usage. It could be slightly more structured (e.g., bullet points for modes), but it is front-loaded with the most important information and contains 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 (single optional parameter, no output schema), the description adequately covers the authentication flow. It explains both token-based and config-based methods. However, it omits details like error messages or token validation behavior, which would improve completeness.

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

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

The input schema has 0% description coverage for the single parameter 'token'. The description fully compensates by explaining that the token is a JWT for session login, and that omitting it returns an authentication link. This adds essential 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 clearly states the tool is for authentication with a specific verb ('log in') and resource (access token). It explains two distinct usage modes (permanent config vs session) and distinguishes itself by providing a link when called without token. This effectively differentiates from sibling tools like 'connect'.

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

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

The description provides explicit guidance on when to use the tool with or without the token parameter, and recommends the permanent config approach. It does not directly address when not to use it or compare to siblings, but the usage scenarios are clearly delineated.

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=true, destructiveHint=false. Description adds value by detailing the two states and that URLs are returned, which is not in annotations. 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?

Two sentences, front-loaded with main purpose, no redundant information. Every part 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?

Tool has no parameters and no output schema. Description explains the two possible states and references URLs, which is complete for a status check tool with low 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?

No parameters exist, so the baseline is 4. Description adds no parameter information, but none is needed.

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

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

Description clearly states that the tool returns connection status and URLs, using a specific verb and resource. It explains behavior for two distinct states (all connected vs. missing credentials), which distinguishes it from sibling tools like 'authenticate'.

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

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

Description implies when to use (check connection status) but does not explicitly state when not to use or mention alternatives. The context of checking credentials and pending connections is clear, but no exclusions are given.

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 it is not read-only, not idempotent, and open world. The description adds that writes require workspace owner/admin, and describes various mutating actions (install, uninstall, subscribe, cancel). It does not contradict annotations and provides useful behavioral context beyond the structured fields.

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

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

The description is a single dense paragraph that tries to cover too much information. It lacks clear structure (e.g., bullet points or separate sections for different actions) and is difficult to parse quickly. Every sentence carries weight but the organization is poor.

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

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

Given the tool's complexity (13 parameters, multiple actions, no output schema), the description leaves significant gaps. It does not specify outputs or detailed behavior for each action (e.g., what does 'invoke' return?). The description is incomplete for an agent to fully understand how to invoke the tool in various scenarios.

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

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

Schema description coverage is 0%, so the description must compensate. While it mentions some parameters in context (e.g., action, query, mcp_id), it fails to explain many others like 'immediate', 'tier_slug', 'conversation', etc. Parameter semantics are insufficient for an agent to use the tool correctly.

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

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

The description clearly states that this is the official marketplace for discovering and managing MCPs/tools. It specifies when to use this tool (e.g., for searching before external registries) and lists the various actions, making the purpose understandable. However, the tool serves as a multi-action dispatcher, which slightly dilutes focus.

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 the user wants a new capability... use THIS tool FIRST') and contrasts it with external registries. It also provides guidance on actions like list_tools and invoke for specific scenarios. Missing explicit 'when not to use' but adequate overall.

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 set destructiveHint=true. The description adds context: data will no longer be available and it returns an add_connection_url for re-connection, which is valuable beyond annotations. 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 two concise sentences, front-loaded with purpose, 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?

The tool is simple with one parameter and no output schema. The description covers purpose, behavior, and return value. However, it lacks explanation of the 'item' parameter, making it slightly incomplete for an agent to know how to invoke correctly.

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

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

There is one required parameter 'item' (type string) with 0% schema description coverage. The description does not explain what 'item' represents (likely a bank identifier). In low coverage scenarios, the description must compensate, but it fails to do so.

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 (revokes/deletes) and resource (bank consent/connection data). It distinguishes from sibling tools like 'connect' or 'openfinance_list_connections' by specifying the disconnection action.

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

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

The description implies usage when needing to remove consent and data, but does not explicitly state when to use this tool versus alternatives (e.g., openfinance_force_sync). No exclusions or prerequisites 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?

Describes polling up to 60s, no disconnect, return fields including needs_action and timed_out, and side effect of advancing lastUpdatedAt. Annotations only give non-read/non-destructive, so description fully compensates.

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 with logical flow: action, use case, parameters, return values, errors, option. Every sentence adds value without redundancy.

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

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

Covers all essential aspects: purpose, parameters (both), behavior (sync, wait, timeout), return structure, error recovery, and relation to sibling tools. No output schema needed given the description.

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

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

With 0% schema coverage, description fully explains both parameters: items as selectors (including types) and wait as fire-and-forget flag. Adds 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?

Clearly states the tool forces bank connections to re-sync and waits for completion, using PATCH and polling. Differentiates from disconnect/reconnect and mentions fire-and-forget option.

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

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

Explicitly says to use when data looks stale, provides examples of selectors, and tells when to use openfinance_get_item_status for fallback. Also explains wait parameter 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?

Beyond annotations (read-only, idempotent, non-destructive), the description adds that credit accounts may return warnings and specifies the response shape (results and errors arrays). This provides useful behavioral context for 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 very concise: three sentences with no fluff. It front-loads the purpose and efficiently covers usage, behavioral notes, and response shape.

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

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

Given the single parameter, annotations, and no output schema, the description covers parameter constraints, error handling, and response structure. It is mostly complete but omits context like authentication or that account IDs must belong to the user.

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 partly compensates by stating account_ids is an array of strings with a size limit of 1-50. However, it does not explain what each string represents (account IDs) or any formatting expectations.

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 real-time balance per account ID and specifies the HTTP endpoint. It distinguishes from siblings like openfinance_list_accounts by focusing on balance retrieval, though explicit differentiation is lacking.

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 guidance on parameter usage (array of 1-50 account IDs) and warns about special behavior for credit accounts (BALANCE_FETCH_ERROR returns warning instead of throwing). However, it does not mention when not to use this tool or suggest alternatives.

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

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

Adds batch shape, array input, and error object details beyond annotations. Annotations already indicate read-only and idempotent behavior.

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

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

Two sentences with no fluff: first states purpose and endpoint, second gives input format and output shape.

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, input constraints, and output shape despite no output schema. Minor omission: no details on error types or auth requirements.

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

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

With 0% schema coverage, description compensates by specifying array type and cardinality constraint (1–50), adding value 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?

Clearly states it returns full account objects with extended creditData by ID. Distinguishes from list tools by specifying per-ID batch 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?

Provides input format and batch size (1–50) but does not explicitly state when to use this over alternatives 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 indicate readOnly, idempotent, non-destructive. Description adds: no transaction data, payments[] are not necessarily payments of this bill, no paid/status field from Pluggy, batch response shape. Goes beyond annotations with critical behavioral details.

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: purpose, what's included/excluded, usage steps, caveats. Slightly long but every sentence adds value. Could be tightened without losing 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?

With no output schema, description covers key fields and batch shape. Mentions limitations (no paid status). Adequate for a simple read endpoint, but could specify the full response structure more explicitly.

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?

Single parameter bill_ids is described: must be an array, and how to obtain values via a sibling tool. Since schema has no description (0% coverage), the description compensates well. Could mention that each is a string, but it's clear.

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

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

The description clearly states it returns bill-level detail for credit card bills, explicitly lists included fields (financeCharges, payments) and excludes individual transactions. It distinguishes from the sibling tool 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?

Provides explicit usage context: use for bill detail, not for transactions. Instructs to use openfinance_list_credit_card_bills first to discover bill_ids. Warns about misinterpretation of payments[] and suggests alternative tool for 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 the tool is read-only, idempotent, and non-destructive. The description adds context about the return structure (`{ count, items }` for all, and single object for individual) and mentions it returns executionStatus and connector metadata, which is valuable beyond annotations.

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

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

The description is two sentences with no unnecessary words. It front-loads the purpose and efficiently covers both usage modes. 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 the simplicity of the tool (one optional parameter, no output schema), the description is complete. It explains the input behavior and the shape of the output for both cases, leaving no 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 0% coverage for parameter descriptions, so the description fully compensates by explaining that omitting `item` returns status for all linked banks (with `count` and `items`) and passing it returns status for a single bank. This is complete and clear.

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

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

The description clearly states the tool returns the current status of a bank connection, specifying possible values (UPDATED, UPDATING, LOGIN_ERROR, etc.), executionStatus, and connector metadata. It also distinguishes between retrieving status for all linked banks vs a single one, which 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 or pass the `item` parameter to get status for all banks vs a single bank. However, it does not explicitly mention when not to use this tool or compare it 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?

Annotations already indicate readOnlyHint and idempotentHint, but the description adds critical behavioral insights: the meaning of `balance` for CREDIT accounts is connector-dependent, and the `name` field is not the brand. It also clarifies that omitting `item` aggregates accounts across connections.

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 yet well-structured. It front-loads the core function, then progressively adds nuance: field clarifications, parameter usage, and caveats. Every sentence serves a purpose, and the text is organized for easy scanning.

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

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

Given the tool's complexity, no output schema, and only two parameters, the description covers all necessary aspects: return structure, parameter behavior, edge cases (balance meaning), and cross-references to related tools. It is fully self-contained for an AI agent to use correctly.

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

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

With 0% schema description coverage, the description compensates by explaining the effect of the `item` parameter (filtering by bank) and the nature of the `type` parameter (BANK vs CREDIT). However, it does not explicitly state that `type` is a filter, instead implying it from context. Still adds significant value 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 explicitly states the tool returns accounts for bank connections, listing specific data fields (balance, number, type, subtype, bankData, creditData) and distinguishes between BANK and CREDIT account types. It clearly defines the tool's purpose beyond the name.

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 omit or pass the `item` parameter, explaining the use case for listing across all banks versus targeting a single bank. Also warns about the connector-dependent nature of CREDIT balance and directs users to the appropriate sibling tool for standardized billing data.

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 caching behavior and confirms a single aggregated response with no batch ids, providing useful context beyond annotations.

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

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

The description is four sentences, front-loaded with the main purpose, and every sentence provides essential information without waste. Efficiently structured.

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

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

Given no input schema fields and no output schema, the description comprehensively explains what the tool returns, including field names, meanings, and usage hints. It is complete for this simple tool.

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

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

With zero parameters and 100% schema coverage, the baseline is 4. The description does not add parameter info (none exist) but explains the output fields, which is valuable for understanding the response.

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, and explains the structure of each entry. It links the 'id' field to its use in openfinance_update_transaction_category, distinguishing it from sibling tools.

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

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

Explicitly states that the 'id' field is used by openfinance_update_transaction_category, directly indicating when to use this tool (to get category IDs for updating). No alternative tools are needed for this specific listing task.

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 specifying return fields and the purpose of add_connection_url, going 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 sentence that efficiently conveys the tool's purpose. While it could be structured with bullet points, it remains concise 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 tool's simplicity (no parameters, no output schema), the description adequately explains what is returned. However, it could mention if the list is static or dynamic, but it's not critical.

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

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

No parameters exist, so the description doesn't need to explain them. The schema coverage is 100%, and the description adds no extra parameter info, which is acceptable.

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

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

The description clearly states the tool returns saved bank connections and lists specific fields (connector_id, item_id, bank name, add_connection_url). It distinguishes from sibling tools that handle different resources (e.g., accounts, transactions).

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

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

No explicit guidance on when to use this tool vs. alternatives. However, the simplicity (no parameters) implies it's for listing all saved connections, but context like 'use before connecting' is missing.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds extensive context about payment semantics, derived payment_status logic, cross-bill matching, connector asymmetry, and the meaning of open_bill and total_pending_debt. 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 very long (over 500 words) and contains a lot of detail, some of which could be condensed. It lacks clear section breaks or bullet points, making it dense to parse.

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 domain and no output schema, the description thoroughly outlines return fields (dueDate, payments, payment_status, open_bill, etc.) and explains derived values. It also covers optional parameters and edge cases like connector asymmetry, making it complete for an 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?

With 0% schema description coverage, the description compensates well by explaining include_open_bill, account_id, account_ids, and their implications. However, page and page_size parameters are not explicitly described beyond default behavior, 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 CLOSED credit card bills for a CREDIT-type account, distinguishing it from siblings like openfinance_get_credit_card_bill (singular bill) and openfinance_list_transactions (itemized transactions). It explicitly says it does not return 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?

Provides explicit when-to-use guidance, e.g., for itemized purchases use openfinance_list_transactions, and for open bill data use include_open_bill opt-in. Also warns about connector asymmetry and not to assume payment status from payments alone.

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=false. The description adds context on error handling (returns fallback instead of throwing) and enumerates the investment types and fields returned. This goes beyond annotations, though rate limits or authentication needs are not discussed.

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 that efficiently conveys the purpose and key details without excessive verbosity. It front-loads the main function. Minor improvement would be structuring with bullet points or separating parameter details.

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

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

Given the absence of an output schema, the description covers return format and error behavior adequately. However, it fails to document the parameters or pagination, which are present in the schema but unexplained. This leaves gaps for effective usage.

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

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

Schema description coverage is 0%, meaning the input schema lacks descriptions for any of the 4 parameters (item, page, type, page_size). The description provides no explanation of these parameters, leaving the agent to guess their meaning and usage.

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

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

The description clearly states it returns the investment portfolio for a connection, listing specific investment types (FIIs, stocks, ETFs, fixed income, mutual funds, retirement, COE) and key fields. This distinguishes it 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 mentions a fallback behavior (returns a warning structure on errors), which provides some guidance, but does not explicitly state when to use this tool versus alternatives or exclude cases. It lacks usage context differentiation.

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, so the description adds value by detailing the returned fields (quantity, value, expenses breakdown) and bulk support. However, it omits pagination behavior or rate limits, which are minor gaps given strong annotation support.

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

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

Two sentences with high information density. The first sentence fronts the main purpose and lists key data points. The second is very brief but adds value. Could be slightly more structured (e.g., bullet points) but remains efficient.

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

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

Provides sequencing context and output fields, but lacks documentation for page and page_size parameters. With no output schema, the description should cover all inputs and outputs more thoroughly. Missing pagination limits the completeness for a list operation.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. It covers investment_id and investment_ids but ignores page and page_size, leaving two parameters undocumented. This is insufficient for a tool with no 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 'Returns the movement history for a specific investment position' with specific transaction types (BUY, SELL, etc.), distinguishing it from sibling tools like openfinance_list_investments which list positions, not transactions.

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

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

Explicitly instructs to use after openfinance_list_investments to obtain the investment_id, providing clear sequencing. Also mentions bulk support with investment_ids, but does not contrast with sibling tools like openfinance_list_transactions.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds value by noting sequential queries with rate-limit spacing and the return format '{ results, errors }' per connection. 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?

Two sentences that front-load the purpose and efficiently cover usage, behavior, and parameter details. Every sentence is necessary.

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

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

For a list tool with one parameter, no output schema, and annotations providing safety, the description covers how to use items, the effect of omission, and return structure. It is fully complete.

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

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

The schema has 0% coverage for the 'items' parameter, but the description explains it accepts connection selectors (item_id uuid, connector_id, or connector_name) and that each entry represents a connection. This significantly aids the agent 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 clearly states 'Lists loan contracts per bank connection' and references the endpoint 'GET /loans'. It distinguishes from sibling tools like openfinance_list_accounts by specifying the resource (loans).

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

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

The description explains when to pass 'items' for specific connections and when to omit for all banks, providing clear context. It doesn't explicitly mention alternatives, but siblings are distinct enough to avoid confusion.

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

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

Provides extensive behavioral context: PENDING vs POSTED variation by connector, error handling (returns warning instead of throwing), bulk support, search aggregation limit (5000), and link to connection health. 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?

Dense but well-structured: main purpose, CREDIT specifics, date/pagination/search, error handling, bulk support. Each sentence adds value, though slightly long.

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?

Comprehensive given no output schema: covers key use cases, edge cases (PENDING/POSTED, truncated warning), and integration with siblings. Could mention output structure, but error format is 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?

Schema has 0% description coverage, but the description explains key parameters: from/to (ISO YYYY-MM-DD), pagination (max 500/page), search_queries (case-insensitive, OR semantics, aggregation). Account_ids is noted for bulk. Minor gap: page and page_size could include defaults or format hints.

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 or CREDIT accounts. It distinguishes from siblings like openfinance_list_credit_card_bills and openfinance_list_transactions_by_item, 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?

Explicitly explains when to use this tool (for CREDIT, it's the only way for itemized transactions) and when to use an alternative (openfinance_list_credit_card_bills for standardized totals). Also advises checking connection health if total is 0.

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 safety profile (read-only, idempotent). Description adds beyond: resolves accounts internally, returns compact summary vs raw rows, and mentions scan cap of 5000 transactions per account with truncated flag. This is valuable context despite high annotation coverage.

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

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

The description is detailed and every sentence adds value, though slightly long. It is well-structured with clear sections and front-loaded with the core purpose. Minor redundancy (compact summary mentioned twice) but not enough to detract significantly.

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

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

Given 6 parameters, no output schema, and complexity, the description is remarkably complete. It explains all inputs, output structure (compact summary with totals, monthly evolution, top expenses, per-account breakdown), and the cap/truncation behavior. Users and agents have full understanding of what to expect.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining all 6 parameters: item, from, to (ISO dates), granularity (monthly/raw), type (BANK/CREDIT), and top_n (implied via top_despesas). Defaults and formats are explicitly stated.

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 provides consolidated cash-flow analysis for a bank connection over a period in one call, resolving accounts internally. It distinguishes itself from siblings like openfinance_list_accounts and openfinance_list_transactions by avoiding the need for separate calls and carrying account IDs.

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

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

Explicit guidance: use for specific queries like annual/monthly analysis, cash flow, etc. Clearly says when not to use alternatives (no need to call openfinance_list_accounts first). Explains effects of omitting item (analyze all linked banks) and differences between granularity options.

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 behavioral context by explaining it checks provider health (not connection), returns specific indicators, and flags incidents affecting your banks. 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 somewhat lengthy but efficiently packs essential information: purpose, usage scenario, and return values. It is front-loaded with the main action. A bit more conciseness could be achieved, but it remains 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 no parameters and no output schema, the description fully explains what the tool does and what it returns (global indicator, degraded components, incidents, your_banks_affected). It provides complete context for an agent to invoke it correctly.

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

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

The tool has zero parameters, and schema coverage is 100%. With 0 params, baseline is 4 as per guidelines. The description does not need to add parameter info because there are none.

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' and distinguishes it from sibling tool openfinance_get_item_status, which checks connection status. The specific verb 'Checks' and resource 'LIVE operational status' are clear and unique.

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

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

Explicitly says to use it 'whenever data looks incomplete or stale even though a connection shows UPDATED' and explains it reveals upstream outages. It also indirectly tells not to use it for checking connection health, as that is covered by openfinance_get_item_status.

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

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds behavioral details: honors user's plan (PF hides PJ banks), returns accounts when include_accounts=true, and returns a hint if keywords omitted. 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 concise (3-4 sentences) and front-loaded with the main purpose. Every sentence adds value without redundancy.

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

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

Given no output schema, the description adequately describes the return value (connector id, access, audience, linked connections/accounts, connect_url) and plan filtering. Could be enhanced with mention of no-match behavior or result limits, but overall sufficient.

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

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

Schema coverage is 0%, but the description covers both parameters with examples (e.g., ['nubank','btg']) and explains the effect of include_accounts=true. Provides useful context 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 searches bank connectors by name (keywords) and returns connector details and a connect_url. The verb 'searches' and resource 'bank connectors' are specific and distinct from sibling tools like connect or 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?

Explicitly says 'Call this BEFORE connecting to hand the user a one-click link to the right bank' and warns that keywords[] is REQUIRED, otherwise returns a hint. Provides clear context and prerequisite, though no direct alternatives 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?

The description reveals key behavioral traits: overrides Pluggy's categorization, teaches Pluggy by creating Category Rules for future similarity, and describes batch error handling (per-item errors do not fail batch). Annotations provide no such detail, so description adds significant value.

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

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

The description is a single paragraph but packs essential information without redundancy. It is front-loaded with the action and then provides details. Minor improvement could be breaking into sentences for readability, but it is efficient.

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

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

Given the complexity (batch update with side effects) and absence of output schema, the description is remarkably complete. It covers prerequisite data sources, side effects, error handling, and response format.

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 fully explains the 'items' parameter: it's an array of objects with transaction_id and category_id, and sources for these IDs. It also describes the response shape, compensating for missing schema 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 action: 'Corrects the category of one or more transactions' and specifies the HTTP method and endpoint. It distinguishes from sibling tools like list tools by focusing on update 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 explains when to use it (fix miscategorized transactions), prerequisites (transaction_id from list, category_id from list), and side effects (creates Category Rule). It does not explicitly state when not to use it, but the context is sufficient.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false, so the tool is safe and idempotent. The description adds the behavioral detail of including the conversation array, but does not disclose other traits like confirmation responses or rate limits. This is adequate but not exceptional.

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 purpose, and contains no unnecessary words. It is concise and well-structured.

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

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

With no output schema and minimal parameter description, the tool lacks completeness. The agent doesn't know what happens after reporting (e.g., confirmation, ticket ID). The description is insufficient for a tool with three parameters and no output schema.

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

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

Schema description coverage is 0%, so the description must add meaning. It only mentions the 'conversation' parameter indirectly via 'Include the conversation array'. The 'context' and 'message' parameters are not explained. This leaves significant gaps for the agent.

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

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

The description clearly states the tool's purpose: 'Report a bug, missing feature, or send feedback.' It uses specific verbs and resources, and distinguishes itself from the sibling tools (which are mostly for OpenFinance and authentication) by focusing on bug reporting and feedback.

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 includes guidance on when to use the tool ('Report a bug...') and what to provide ('Include the conversation array with recent messages for reproduction.'). It does not explicitly state when not to use it or provide alternatives, but the context is clear enough for an agent.

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 that it returns 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 concise sentence that immediately states the tool's purpose. There is no redundant or 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 a straightforward output (version strings), the description is complete. The output schema is absent, but the tool's simplicity does not require it.

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

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

There are zero parameters (schema coverage 100%). According to guidelines, baseline is 4. No parameter info is needed, and the description adds no further semantics, which 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 function: showing current MCP platform and adapter versions. It uses a specific verb ('Show') and resource ('MCP platform and adapter versions'), distinguishing it from sibling tools that focus on authentication, finance operations, etc.

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 guides use: it is for retrieving version information. No explicit when-not-to-use or alternatives are provided, but the tool's simplicity makes this acceptable.

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, so the description does not need to restate safety. It adds value by specifying the exact data returned (installed MCPs, connection status, catalog tools), 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?

Single sentence, front-loaded with the verb 'Returns', and contains no extraneous information. Every word is necessary and contributes to understanding.

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

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

Given zero parameters, no output schema, and rich annotations, the description is fully complete. It specifies exactly what the tool returns, which is sufficient for an agent to select and invoke it correctly.

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

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

No parameters exist (empty schema with 100% coverage). Description does not need to provide parameter details. Baseline score of 4 is appropriate for zero-parameter tools.

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 toolkit state including installed MCPs, connection status, and catalog tools count. This distinguishes it from all sibling tools which serve different purposes like authentication, connection management, or financial data 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 implies usage for checking toolkit state but does not explicitly state when to use it (e.g., after installation, before connecting, etc.). While the tool is simple and has no parameters, explicit guidance on use context would improve clarity.

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