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

With no annotations, the description carries full burden and discloses that token data is public on-chain with no secrets or keychain involvement, reassuring about safety and side effects. It also implies the operation is additive (no destruction).

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 well-structured paragraph that efficiently covers purpose, usage, privacy, and all inputs without redundancy. Every sentence adds value, and it is appropriately front-loaded with the core action.

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

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

Given the complexity (5 required params, no output schema), the description thoroughly explains the tool's purpose, when to use, each parameter with examples, and security context. It is complete for an agent to select and 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?

Schema coverage is 100% with descriptive parameter names and constraints. The description adds extra context like typical decimal values (18, 6) and clarifies contract address is public, enhancing understanding 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 adds a project-specific ERC-20 token to a MetaMask tracked-tokens list, distinguishes from default tokens, and gives concrete use-case examples like 'track ARB token'. It differentiates from sibling tools (list_custom_tokens, remove_custom_token).

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 'Use when the user asks: ...' and implies common tokens are already tracked, so not for those. Provides scenarios and contrasts with default tracked tokens, giving clear when-to-use and when-not-to-use guidance.

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?

No annotations provided, so description carries full weight. It explains that the new address shares parent settings, no secrets are stored, and it just updates the addresses[] field. Good behavioral disclosure for a non-destructive operation.

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

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

The description is efficient, front-loading the core purpose and usage hints, then detailing behavior and parameter specifics. Every sentence adds value without fluff or 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 explains what gets updated (addresses[] field) and notes security (no secrets). It could mention error handling (e.g., if account doesn't exist or address already present) but covers most essential aspects.

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 100%, but description adds significant value by clarifying each parameter's role, providing examples (e.g., 'metamask:0xabc...'), and specifying address formats (0x-hex for EVM, base58 for Solana). This goes beyond the schema's basic 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 it adds a wallet address to an existing MetaMask or Solana account, using a specific verb and resource. It distinguishes from siblings like add_custom_token or setup_connector.

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 lists example user queries that trigger use, such as 'add another wallet' or 'track a second address'. However, it does not specify when not to use or mention alternative tools, though the sibling list provides 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It does not explicitly state the tool is read-only or mention side effects, auth requirements, or rate limits. The description focuses on functionality and output, but a statement about safety would improve 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?

The description is concise at ~150 words, well-structured with a clear first sentence, followed by use cases, grouping options, output format, and parameter details. 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?

Despite no output schema, the description specifies the return fields (label, currentValue, percentOfTotal, holdingCount) and sort order. The two parameters are fully explained. The tool is simple and well-documented for an agent 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?

The input schema has 100% description coverage, but the description adds significant value by explaining each enum option's meaning (e.g., 'chain' is only meaningful for MetaMask) and the default for 'by'. It also clarifies the 'top' parameter behavior, going beyond the schema's minimal 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 tool returns a portfolio allocation breakdown grouped by a chosen dimension, with specific verb 'Returns' and resource 'portfolio allocation breakdown'. It distinguishes itself from sibling tools like get_holdings by focusing on aggregated breakdowns rather than raw positions.

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 provides example queries for when to use the tool, such as 'how is my portfolio split' and 'allocation breakdown'. It also details each grouping dimension and their context (e.g., 'chain' only for MetaMask). However, it does not explicitly contrast with sibling tools or state 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?

No annotations provided, so description fully carries the burden. Discloses caching times per connector, notes that non-USD conversion is a display-layer convenience, and states that underlying data is unchanged. Could be slightly improved by mentioning idempotency, but is thorough.

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 with bullet points and clear sections. Every sentence adds value, though slightly verbose for an AI agent. Front-loaded with purpose and examples.

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?

Completes all needed context: purpose, parameters, return structure, caching, disclaimers. No output schema but description details what each holding includes. Sufficient for agent to decide and 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?

Schema description coverage is 100%, so baseline is 3. The description adds meaningful context: explains omitting account_id queries all, provides example formats, defines asset_class special values, and clarifies currency conversion behavior. Adds significant value beyond schema.

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

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

The description clearly states the tool returns current portfolio holdings across all connected accounts. It lists specific user queries that trigger this tool, distinguishing it from siblings like get_allocations, get_pnl, and get_polymarket_positions.

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 advises when to use (user asks about holdings) and when to use an alternative (use refresh_data for fresh data). Provides clear context and excludes financial advice.

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?

With no annotations, the description fully covers behavioral traits: approximation caveats for windowDelta, CoinGecko limitations, skipping Polymarket and tokens without mapping, extra round-trips for include_history, cost basis method effects, and currency conversion with source disclosure. It also includes a disclaimer.

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 and detailed, which can hinder quick parsing by an AI agent. While it is well-structured with front-loaded purpose, the verbosity could be reduced for better conciseness.

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 and caveats (currentValue, costBasis, realizedPnl, etc.). It covers edge cases like Polymarket, unknown cost basis, and currency conversion, making it complete for a tool of this complexity.

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

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

Schema coverage is 100%, but the description adds significant value beyond the schema for each parameter: account_id omitting for cross-account, timeframe approximation and granularity, include_history trade-offs, method selection based on user language, and currency conversion details. This far exceeds baseline.

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

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

The description explicitly states it returns aggregate profit/loss across all accounts and gives specific user queries that trigger its use (e.g., 'how am I doing', 'what's my P&L'). It clearly distinguishes from sibling tools like get_holdings and get_transactions by focusing on P&L summary.

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 triggers for when to use the tool and detailed guidelines for parameters (e.g., when to set include_history, timeframe, method, currency). It does not explicitly list when not to use it, but the context implies alternatives exist for specific positions.

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?

No annotations are provided, so the description carries the full burden of transparency. It details the output fields (market title, outcome, quantity, currentPrice, etc.), explains defaults for optional parameters, and includes a disclaimer ('Not financial advice'). It does not mention authentication or rate limits, but the behavioral description is thorough and consistent.

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

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

The description is well-structured: purpose statement first, then usage guidance, then output field details, then parameter descriptions. Every sentence adds necessary information; there is no redundancy. It is appropriately sized and front-loaded with the key purpose.

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

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

Despite lacking an output schema, the description compensates by thoroughly enumerating the returned fields. It covers inputs and outputs adequately for an AI agent to understand the tool's behavior. Minor omissions (e.g., error handling, rate limits) prevent a perfect score.

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

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

Schema coverage is 100%, so each parameter already has a description. The description adds extra value by explaining defaults (group_by_event defaults true, resolved_only defaults false) and provides context on when to use each parameter. This goes beyond the schema 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 that the tool returns Polymarket prediction-market positions grouped by event. It provides specific example queries and distinguishes itself from the sibling tool get_holdings, which is intended for general portfolio queries. The verb 'returns' and resource 'Polymarket positions' are precise.

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

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

The description explicitly tells when to use this tool ('when the user asks about their Polymarket bets') with concrete examples, and when not to use it ('for general portfolio queries...prefer get_holdings'). It also suggests an alternative filter for get_holdings. This is exemplary guidance.

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?

No annotations are provided, so the description carries the full burden. It discloses return format, default behavior (last 50 transactions per account), and limitations per connector. It lacks an explicit read-only assertion, but the informative nature 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?

The description is well-structured with a clear purpose first, followed by usage, output format, inputs, and caveats. It is slightly verbose but every section adds information; could be trimmed slightly.

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

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

Absent an output schema, the description fully explains the return fields (type, symbol, quantity, etc.) and covers connector-specific behavior. It includes necessary caveats (V0, not financial advice) making it 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?

Schema coverage is 100%, so the description adds value by providing examples (e.g., time shorthand '24h', account_id format) and elaborating on default behavior. This goes beyond the schema's basic 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 explicitly states it returns transaction history across configured accounts, listing types (trades, deposits, etc.) and providing example user queries. This clearly distinguishes it from siblings like get_holdings or get_pnl.

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 examples ('Use this when the user asks: ...') and covers connector-specific caveats. However, it does not explicitly state when not to use this tool in favor of 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?

Despite no annotations, the description fully discloses that credentials are never returned and stay in the OS keychain, and lists the exact fields returned (id, connectorId, label, createdAt, connector-specific metadata).

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 informative with multiple sentences, but all content is necessary. Front-loaded with the tool's purpose and examples. Slightly verbose but no redundancy.

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

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

Given the tool's simplicity (one optional parameter, list operation), the description fully covers behavior, return fields, and usage boundaries. Without an output schema, the description compensates with detailed return info.

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

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

The optional 'connector' parameter is explained in the description (omit for all accounts, include to filter), adding context beyond the enum list. Schema coverage is 100%, so baseline 3; the description adds clear usage guidance.

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

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

The description clearly states it lists configured PORTFOLIO TRACKER accounts (specific exchange/wallet types) and distinguishes from sibling tools by explicitly excluding unrelated account types (email, social media, 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?

Provides explicit usage examples (user queries) and states when NOT to use the tool (other account domains), giving clear guidance on when to invoke this tool vs alternatives.

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

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

With no annotations provided, the description carries the full burden. It explicitly states 'Public data; no secrets involved,' which is helpful for safety. It does not mention any destructive behavior or side effects, but for a read-only list operation, this is adequate.

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

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

The description is concise with two sentences, front-loading the main purpose. It includes usage examples and parameter explanation without unnecessary verbosity. Every sentence serves a 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 simple tool with one optional parameter and no output schema, the description is fairly complete. It covers purpose, usage, safety, and parameter behavior. However, it does not describe the return format or any pagination, but these may be implied.

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 100% with one parameter. The description adds value by explaining that omitting 'account_id' lists across all accounts, which is not explicitly stated in the schema. This provides context 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 what the tool does: 'Lists custom ERC-20 tokens tracked by MetaMask accounts.' It uses a specific verb ('lists') and resource ('custom ERC-20 tokens'). This distinguishes it from sibling tools like 'add_custom_token' and 'remove_custom_token' which perform different actions.

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

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

The description provides example user queries ('which custom tokens am I tracking', 'show my project tokens') to guide when to use the tool. It also mentions 'Public data; no secrets involved' indicating safety. However, it does not explicitly state when not to use it 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?

With no annotations, the description fully carries the burden of behavioral disclosure. It explains that the tool only invalidates the cache, does not trigger fetches, and optionally scopes to a single connector. It also warns of the scope without a parameter (invalidates everything tracker-related).

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

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

The description is well-structured with front-loaded key information and clear sections. However, it is somewhat lengthy (5 sentences) and could be slightly more concise without losing meaning.

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 does not mention return values or status indications. However, it covers usage, scope, follow-up, and exclusions comprehensively. Missing return value info is a minor gap.

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 100% coverage with one parameter (connector) enumerated. The description adds value by explaining that omitting the parameter invalidates all connectors, and providing context about connector options (bybit, binance, metamask, etc.).

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 invalidates the PORTFOLIO TRACKER cache and forces a fresh fetch on next call, with specific examples of user queries ('refresh my portfolio', 'update my holdings', etc.). It distinguishes from sibling tools by focusing on cache invalidation rather than data retrieval (e.g., get_holdings).

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 (user asks for portfolio refresh/update/fetch) and when not to use (refreshing webpage, OAuth token, browser cache, non-tracker MCP server). Also provides follow-up guidance to call get_holdings after invalidation.

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?

Since no annotations are provided, the description fully carries the burden. It discloses the operation is ONE-WAY, deletes from AccountStore and OS keychain, and specifies return values and error conditions. This is thorough and honest.

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 informative but could be more streamlined. It includes usage examples, input details, and returns in a natural flow, but some redundancy exists (e.g., repeating 'ONE-WAY'). Still, it is not overly verbose.

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 annotations or output schema, the description covers the essential aspects: irreversible operation, target, return values, and error case. It could mention prerequisites like user authentication, but overall it is comprehensive enough for a single-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?

Schema coverage is 100%, so baseline is 3. The description adds value by providing format examples (e.g., 'bybit:UNIFIED') and reiterating the one-way nature, which goes beyond the schema's simple 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 it deletes an account and its credentials, and provides specific example phrases like 'remove the Bybit account' that cue the agent. It distinguishes from sibling tools like remove_custom_token by focusing on 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?

The description gives explicit when-to-use guidance by listing user queries. It mentions the Settings UI requires confirmation, implying appropriate timing. However, it does not explicitly contrast with alternatives like remove_custom_token or note 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?

No annotations provided, so description carries full burden. Discloses 'Public on-chain data, no keychain involvement' and describes return behavior (ok or not_found error). Sufficiently transparent for a simple removal 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?

Concise, well-structured description at about 100 words. Includes overview, usage examples, parameter list, and return info without 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?

For a simple 3-param tool with no output schema and no annotations, the description fully covers purpose, usage, parameter details, and error handling. 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?

Schema coverage is 100% and description adds value beyond schema: provides example for account_id, lists common chain_id values, and specifies contract address format. Also explains return behavior, which is not in 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?

Description clearly states it removes a custom ERC-20 token from a MetaMask tracked-tokens list. Provides specific verb and resource, and example user queries. Distinguishes from sibling tools like add_custom_token and list_custom_tokens.

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 'Use when the user asks...' with concrete examples (e.g., 'stop tracking ARB'). Does not explicitly mention when not to use, but the examples make it 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?

Despite no annotations, the description reveals key behaviors: the tool returns a textual confirmation if MCP Apps are not supported, the iframe makes its own tool calls, and parameters are initial only (user can switch live). It lacks mention of authentication or rate limits, but for a render tool these are not critical.

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

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

The description is relatively long but well-structured, with front-loaded purpose and clear sections. Every sentence adds value, though some repetition (e.g., 'User can switch live' said twice) could be tightened.

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 (2 optional params, no output schema, no annotations), the description is thorough: it covers purpose, usage, behavior, param details, and fallback behavior. No critical gaps remain.

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 description adds context to both parameters beyond the schema: it clarifies that they are initial values and users can switch live. The enum values are listed and defaults are implied. This adds significant value for an 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 it renders a portfolio tracker dashboard with specific tabs and features. It distinguishes from other types of dashboards and specifies exact user prompts that should trigger this 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?

The description explicitly states when to use ('show my portfolio dashboard', etc.) and when not to use (other dashboards like Vercel, Sentry, etc.). It advises to ask the user for clarification if ambiguous, and explains that the iframe handles its own tool calls, reducing agent burden.

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?

With no annotations, the description fully discloses behavioral traits: it's a live UI panel with tabs, includes security disclosures, and instructs not to echo credentials, providing a behavior contract.

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 well-structured, with front-loaded purpose and clear sections. Every sentence adds value, though slight trimming could improve conciseness.

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 annotations or output schema, the description covers all essential aspects: inputs, UI layout, security notes, use cases, and exclusions, leaving no gaps.

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

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

The single parameter 'tab' is fully described with enum; the description adds default value and live-switching behavior, going beyond the schema.

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

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

The description clearly states the tool renders the PORTFOLIO TRACKER Settings panel, listing specific user queries it handles, and differentiates from sibling tools like render_dashboard and setup_connector.

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 specifies when to use (portfolio settings, adding accounts) and when not to (app settings, system preferences), with guidance to ask for clarification if ambiguous.

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?

With no annotations, the description fully discloses behavior: credentials are read-only, validated against upstream API before writing, stored in OS keychain, and a 'BEHAVIOR CONTRACT' for the LLM to never echo credentials. All five connector types are explained as using read-only credentials by design.

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 comprehensive but verbose, including detailed parameter lists that largely duplicate schema descriptions. The structure is clear (purpose, usage, behavior, inputs), but the length could be reduced without losing information. Still, it is well-organized 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 complexity (6 parameters, nested objects, no output schema), the description covers key aspects: validation, storage, credential nature, and a behavior contract. It lacks return value details but that is acceptable without output schema. The description is largely complete for an agent to use correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond schema by explaining the context for each connector (e.g., 'Etherscan API key — a public-data rate-limit token'), the purpose of optional parameters (e.g., accountTypes, includeFutures), and the read-only nature. This justifies a 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 'Creates a new account by writing READ-ONLY credentials to the OS keychain' and lists specific user queries like 'add a Bybit account' or 'connect my Solana wallet'. It distinguishes from siblings (e.g., add_custom_token adds tokens, not connectors). The scope and verb+resource are explicit.

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

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

The description provides explicit usage triggers (e.g., 'Use when the user asks: ...') and a when-not scenario: 'If the user pastes credentials inline in chat, suggest they use the Settings UI (render_settings tool) form instead.' This clearly guides when to use this tool versus alternatives.

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