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

The description discloses simulation behavior via multicall by default, which surfaces reverts before signing. It also clarifies the server's limitations (no private keys, no broadcasting). This adds significant context beyond the annotations, which already indicate non-read-only and idempotent.

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

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

The description is a single paragraph that is informative and not overly verbose. It could be slightly more structured with line breaks, but it is concise and front-loaded with the core 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?

Given the tool's complexity (multi-clause transaction building with optional simulation) and the presence of an output schema, the description adequately covers purpose, input format, behavior, and important caveats (no signing/broadcasting). It leaves no major gaps.

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

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

The input schema has 100% coverage, but the description enhances understanding by explaining the clause structure, mandatory address for erc20/erc721, and the meaning of each field. It also clarifies the args types and default value for valueWei.

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 builds a multi-clause VeChainThor transaction for signing, distinguishing it from read-only tools like callContract. It specifies the input (clauses array) and output (ready-to-sign clauses), and explicitly states it never signs or broadcasts.

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

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

The description provides clear context on when to use (building multi-clause transactions for signing) and what the tool does not do (never holds keys or broadcasts). However, it does not explicitly mention alternatives or when not to use this tool, though the sibling list suggests callContract for single calls.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context, such as the clause format, address override behavior for erc20/erc721, return format (success, primary value, decoded array), and bigint stringification. 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 two sentences, front-loaded with the purpose, then providing detailed breakdown. It is appropriately sized and each sentence adds value. Slight room for improvement in structuring the details, but overall concise and effective.

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

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

Given the complexity (one parameter with nested objects, many sibling tools), the description sufficiently explains usage, conventions, and output format. The presence of an output schema reduces the burden for return value documentation, but the description still adds clarity on return structure. It is complete enough for correct tool invocation.

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

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

Schema coverage is 100% with descriptions for each field. The description goes beyond by explaining the purpose of each clause field, the special meaning of 'address', and the return structure. This adds meaning beyond the schema, such as the fact that bigint values are stringified.

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 executes read-only contract calls in a single multicall, which is distinct from sibling tools that perform individual contract reads. The verb 'execute' and resource 'read-only contract calls' are specific, and the title emphasizes multicall aggregation, distinguishing it from single-call tools.

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

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

The description explicitly advises using this tool 'instead of one call per round-trip whenever you need multiple values.' This gives clear context for when to prefer it. It does not explicitly list when not to use it, but the guidance is sufficient given the sibling tools.

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

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

Annotations already cover readOnly, idempotent, and destructive hints. Description adds the two modes (per-interval vs cumulative) and pagination support, which are useful behavioral traits.

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

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

Two well-structured sentences that front-load the main action and resource, with all information earning its place.

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

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

Given the tool's simplicity, the description, schema, annotations, and output schema together provide a complete picture. No missing critical information.

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

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

Schema has 100% coverage, so baseline 3. Description adds meaning by explaining the timeFrame parameter's two modes and mentions pagination, providing marginal extra value.

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 retrieves total unique VeChain accounts by timeframe, distinguishing between providing timeFrame for per-interval totals vs omitting for cumulative. References specific API endpoint.

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?

Describes when to provide timeFrame vs omit, but no explicit alternatives or when-not-to-use. Context signals are clear and sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds a behavioral guarantee: 'Always return app URL when available', which provides specific context beyond annotations. No contradictions with annotations.

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

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

The description is two concise sentences, front-loading the primary action and key filtering capabilities, then adding a promise about return values. Every sentence earns its place with no wasted words.

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

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

Given the tool's complexity (4 optional parameters, no required parameters, output schema exists), the description covers the core functionality and return behavior. It adequately sets expectations for a list endpoint without requiring details about pagination or result limits, which are assumed to be in the 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?

Input schema has 100% coverage with descriptions for all four parameters. The description paraphrases these filters but does not add significant new meaning beyond the schema. Baseline 3 is appropriate since schema already conveys parameter semantics.

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 'list' and the specific resource 'official apps from VeChain App Hub', and enumerates supported filters (category, tag, VeWorld support, free-text search). This distinguishes it from sibling tools like getVeBetterDaoApps which lists different apps.

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 indicates what the tool does but does not provide guidance on when to use it versus alternatives (e.g., when not to use it, or comparisons with similar tools). There is clear context for usage but no exclusions or 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the tool is clearly safe and idempotent. The description adds the API endpoint but no additional behavioral traits (e.g., rate limits, response structure). It does not contradict 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. The first sentence states purpose and endpoint; the second provides critical usage guidance. It is front-loaded and compact.

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 has 6 parameters including pagination controls (page, size, after, before, direction). The description covers the required appId resolution but omits guidance on how to use pagination or filtering. Given the output schema exists, return values need not be explained, but the pagination parameters are not discussed, leaving a gap for a complete usage context.

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

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

Schema coverage is about 67% (descriptions for appId, after, before, direction; page and size lack descriptions). The description amplifies the appId parameter by explaining how to resolve it from a human-readable name, adding value beyond the schema. However, it does not compensate for the missing descriptions on page and size, so the baseline of 3 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 fetches B3TR actions for a VeBetterDAO app via a specific API endpoint. It distinguishes itself from sibling tools like getB3TRActionsForUser by focusing on a single app's actions. The mention of resolving appId from app-hub clarifies its scope.

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

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

The description explicitly states that appId is required and provides guidance: if a human-readable app name is given, call getAppHubApps first. This is a clear usage instruction. However, it does not explicitly list when not to use this tool in favor of alternatives, which would make it a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint hints. The description adds context about returning impacts and optional filtering but does not contradict annotations or provide additional behavioral traits beyond what annotations cover.

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, concise and to the point. It front-loads the core purpose and endpoint. Minor improvement could be adding structure for clarity, but overall 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?

The description covers the main purpose and optional filters. With output schema present, return values are not needed. However, it omits pagination parameters (page, size) and direction, which reduces completeness for a 7-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 57%, with descriptions for after, before, appId, wallet. The description does not add new parameter semantics beyond the schema; it only restates optional filtering. Given partial schema coverage, a baseline score of 3 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 verb 'Get', the resource 'B3TR actions for a user', and the endpoint path. It distinguishes from sibling tools like getB3TRActionsForApp by specifying 'for a user'.

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 optional filters but does not explicitly state when to use this tool over alternatives like getB3TRActionsForApp or getB3TRUserOverview. No when-not or prerequisite guidance is provided.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds details about the data returned (rewards, actions, sustainability, rankings) and the filtering constraints (mutually exclusive date/roundId). No contradictions with annotations.

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

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

Three sentences efficiently convey purpose, endpoint, return values, and critical usage notes (bolded warning). No unnecessary words; front-loaded with key information.

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

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

Given the presence of an output schema (context shows 'Has output schema: true'), the description sufficiently covers what the tool returns. Annotations cover safety. Sibling list shows this is one of many B3TR tools, and the description distinguishes it well.

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 context beyond schema, especially for appId: clarifying it must be a 32-byte hex veBetterDaoId and instructing to use getAppHubApps for name resolution. This is not present in the schema description.

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

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

Description clearly states it gets an APP overview for a specific app listed on veBetterDao, specifying the endpoint and listing returned data (totals, rewards, rankings). It distinguishes from siblings like getB3TRAppsLeaderboard, which returns a leaderboard, and getB3TRActionsForApp, which returns 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?

Explicitly states when to use: for a specific app overview. Provides critical guidance on appId format (veBetterDaoId, not app name) and advises to call getAppHubApps first if user provides a name. Also notes mutual exclusivity of date and roundId filters.

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?

While annotations already indicate read-only and idempotent behavior, the description adds valuable context such as mutual exclusivity of filters, supported sort fields, and cursor pagination, which are not fully captured by the schema alone.

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

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

The description is three sentences with no redundancy, directly stating purpose, usage constraints, and key features. Every sentence serves a clear function.

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

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

For a read-only leaderboard tool with an output schema, the description covers all essential aspects: resource, endpoint, optional filters with mutual exclusivity, sort options, and pagination. No critical information is missing.

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 parameter descriptions, but the description adds the key constraint of mutual exclusivity between date and roundId, as well as clarifying pagination and sorting 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 action ('Get') and the specific resource ('app B3TR action leaderboard'), distinguishing it from sibling tools like getB3TRAppUsersLeaderboard and getB3TRUsersLeaderboard by focusing on apps rather than users.

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 constraints (mutually exclusive roundId and date filters) and pagination details, but does not explicitly guide when to use this tool versus alternatives like getB3TRGlobalOverview.

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, so the description's behavioral additions (pagination, mutual exclusivity) are helpful but not critical. 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?

Single sentence, 27 words, front-loaded with main action. No redundant or trivial 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 presence of an output schema, the description adequately covers pagination, filters, and endpoint. It provides sufficient context for a read-only leaderboard 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% and the description adds extra context: mutual exclusivity between date and roundId, and a resolution hint for appId (resolve via getAppHubApps). Not all parameters are described, but the added info is valuable.

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 'Get' and specific resource 'user B3TR action leaderboard for a given app', differentiating from sibling tools like getB3TRUsersLeaderboard (global) or getB3TRAppsLeaderboard (app-level). The API endpoint is explicitly mentioned.

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 lists optional filters and pagination but does not explicitly state when to use this vs alternatives (e.g., getB3TRUsersLeaderboard for global leaderboard). Usage context is implied through the app-specific scope but not directly clarified.

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 the tool as read-only, idempotent, and non-destructive. The description adds the mutual exclusivity constraint and API endpoint, providing some extra context but not extensive behavioral traits.

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

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

Two concise sentences with no fluff, front-loading the tool's purpose immediately. 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 simple tool with two optional parameters and an output schema, the description adequately covers purpose, filtering options, and constraints. No additional details needed.

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

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

Input schema has 100% coverage with both parameters described. The description adds the critical mutual exclusivity constraint and date format, going beyond the schema definitions.

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

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

The description clearly states the tool retrieves a global B3TR action overview, specifying the API endpoint. It distinguishes from sibling tools like getB3TRAppOverview or getB3TRActionsForApp by focusing on the global scope.

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

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

The description explicitly states that roundId and date are mutually exclusive and provides the date format, offering clear guidance on parameter usage. It does not cover when-not-to-use but given the simplicity this 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 a safe, read-only operation. Description adds value by clarifying that comments are only from on-chain voters and that filtering by support type is supported. No contradictions.

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

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

Description is concise but includes a valuable note about Discourse alternative. Could be slightly more structured, but every sentence adds value.

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

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

Given that an output schema exists, description need not explain return values. Covers purpose, usage, limitations, and filtering options. 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 parameters are already well-documented. Description adds minimal extra meaning beyond the schema, only echoing the filter by support type. At baseline 3.

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

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

Description clearly states it gets on-chain voting comments/reasons for a specific B3TR proposal, specifying the API endpoint and distinguishing from broader community discussion. Verb 'get' and resource 'on-chain proposal comments' are specific.

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

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

Provides explicit guidance: use for on-chain voter comments, and for broader community discussion, use Discourse tools. Mentions getDiscourseTopic as alternative and when to use it, along with providing forum URL for manual viewing.

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, openWorldHint, idempotentHint true. The description adds behavioral context: returns proposals with voting results and CIDs, requires further steps to get full data, and that using proposalId avoids unnecessary fetching. No contradictions, and it provides useful workflow info 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 longer than necessary but well-structured with bold emphasis and a numbered list. Every sentence adds value, and the front-loading of the main purpose and critical usage note makes it effective. Slight redundancy between the IMPORTANT note and workflow step 1, but overall acceptable.

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

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

Complete in context: explains what the tool returns, how to use it for specific vs general queries, and provides a full workflow involving other tools for a complete view. With annotations covering safety and output schema present, the description covers all necessary 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 description coverage is 100%, so the schema already documents all parameters. The description adds a usage note about proposalId but no additional semantic details for other parameters. Baseline of 3 is appropriate.

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

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

The description clearly states it gets B3TR proposal results, specifying the API endpoint and the data returned (voting results and IPFS description CIDs). It distinguishes itself from sibling tools through the integrated workflow that references getIPFSContent, getDiscourseTopic, and getB3TRProposalComments, making its role in the broader process explicit.

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

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

Provides explicit guidance: use proposalId for specific proposals (with caution not to fetch all), and a numbered workflow detailing steps from this tool through related tools. It clearly states when to use this tool versus alternatives, including when to browse all proposals or use other tools for full details.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. Description adds key behavioral details: the API endpoint, mutual exclusivity of filters, and that appId must be a 32-byte hex. 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?

Concise single paragraph that front-loads the purpose. All sentences add value (API path, return summary, appId resolution hint, filter constraints). No wasted words, though could be slightly tighter.

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 output schema exists, description does not need to explain return values. It sufficiently covers input constraints (appId format, filter mutual exclusivity) and provides necessary context for correct usage. 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 already covers all 4 parameters with descriptions, achieving 100% coverage. Description reinforces the appId format and mutual exclusivity of date/roundId, but adds no new parameter semantics beyond what the schema provides. Baseline 3 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?

Clearly states 'Get a users overview for a specific app' and lists exact return fields (B3TR rewards, rewarded actions, sustainability impact totals, global rankings). Distinct from sibling tools like getB3TRAppOverview (app-level) and getB3TRUserOverview (user-level without app specificity).

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 resolve app name to veBetterDaoId via getAppHubApps, and warns that roundId and date are mutually exclusive. Does not explicitly state when not to use, but context is clear enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns total B3TR rewards, number of rewarded actions, and sustainability impact totals, plus the date format requirement. This enriches behavioral understanding beyond annotations.

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

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

The description is two concise sentences. The first sentence states the purpose and endpoint, the second details return values and a format constraint. No unnecessary words, 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 an output schema present, the description does not need to detail return values. However, it omits information about pagination and sorting parameters, and lacks usage context. It covers core functionality but is minimally complete.

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

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

Schema description coverage is only 17%, with only wallet, startDate, and endDate having descriptions. The description adds that dates must be UTC in yyyy-MM-dd, but does not explain pagination parameters (page, size) or sorting direction. Given low coverage, the description should compensate more.

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 gets daily action summaries for a specific user within a date range, mentions the API endpoint, and lists the returned data. This distinguishes it from sibling B3TR tools like getB3TRActionsForUser or getB3TRUserOverview.

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 retrieving summarized daily actions but does not explicitly state when to use this tool over alternatives or provide when-not-to-use conditions. It lacks guidance on context or exclusions.

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 the API endpoint and the mutual exclusivity constraint, which are useful behavioral details beyond the annotations. It does not contradict 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 concise (two sentences) and front-loaded with the core purpose. Every sentence provides necessary information 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 the presence of an output schema (not shown but indicated), the description doesn't need to detail return values. It covers the key inputs and their constraints. However, it could briefly mention that the tool is for a single wallet and provides aggregate totals, which it does.

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 for all three parameters. The description adds value by explaining the mutual exclusivity between 'date' and 'roundId', and clarifying the date format (yyyy-MM-dd UTC). This goes beyond what the schema provides.

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 gets the B3TR action overview for a specific wallet, listing specific return fields (total rewards, rewarded actions, sustainability impact, rankings, X-App interactions). It also provides the API endpoint, which distinguishes it from sibling tools like getB3TRActionsForUser or getB3TRUserAppOverview by specifying the aggregate nature of the response.

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 mentions the optional filters (roundId and date) and states they are mutually exclusive, which guides correct usage. However, it does not provide any guidance on when to use this tool versus sibling tools like getB3TRUserAppOverview or getB3TRUserDailySummaries.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds behavioral details beyond annotations: mutual exclusivity of filters, date format (UTC), and pagination with cursor, which are not captured by annotations alone.

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 endpoint and purpose, then concise details on filtering, sorting, and pagination. No unnecessary words; 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?

With zero required parameters, an output schema, and 100% schema coverage, the description covers all user needs: filtering constraints, sorting, pagination. It is 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 description coverage is 100%, but the description adds operational semantics: mutual exclusivity between roundId and date, date format specification, and the meaning of sortBy values. This enhances parameter understanding 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 explicitly states 'Get leaderboard of users' B3TR actions' with the API endpoint, making the verb and resource clear. It distinguishes from sibling tools like getB3TRAppsLeaderboard by specifying 'users' leaderboard.

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

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

The description clearly explains the mutual exclusivity of roundId and date parameters, sorting options (totalRewardAmount or actionsRewarded), and pagination support. It provides specific usage guidance but does not explicitly contrast with alternative tools.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe. The description adds behavioral context beyond annotations: it reveals that calling without filters on a large ABI returns only function names and asks for refinement, which is important for an agent to understand to avoid unexpected results.

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, well-front-loaded with the main purpose. Each sentence adds value: purpose, preference for filters, behavior with no filters, and how to use the result. It is not overly verbose but could be slightly more concise by removing the suggestion about 'use the returned fragments' which is implied.

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 4 parameters, 100% schema coverage, and an output schema, the description does not need to detail return values. It covers the key behaviors: filtering, large ABI warning, and usage with other tools. Missing details like error handling for unknown contracts are minor, so the description is sufficiently complete.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: it provides concrete examples for methodNames (e.g., 'balanceOf', 'transfer'), explains the default for fragmentType, and suggests using stateMutability 'view' for read-only methods. This helps in writing correct queries.

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 ABI of a registered contract, with optional filters to reduce payload size. The verb 'Return' and resource 'ABI of a contract' are specific, and the mention of using fragments with callContract/buildContractTransaction distinguishes this tool from sibling tools that perform different operations.

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

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

The description provides explicit usage advice: prefer the most specific filters, gives examples like methodNames and stateMutability, and explains the server's behavior when no filters are applied on a large ABI. It also suggests using the returned fragments with callContract, but does not explicitly state when not to use this tool or compare to alternatives.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds only that it queries a specific API and supports pagination, which is already implicit. No contradictions, but minimal added value beyond annotations.

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

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

Two sentences, no filler, front-loaded with the core action. Every word earns its place.

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

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

Given the presence of an output schema and fully annotated parameters, the description is adequate for a read-only paginated query. Could optionally mention rate limits or result trimming, but not essential.

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?

All 8 parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning beyond stating pagination support. Baseline 3 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 verb 'Query' and the resource 'transactions for a contract', including the specific API endpoint. This distinguishes it from sibling tools like getTransactions (general) and getTransfersFrom.

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 contract transactions but provides no explicit guidance on when to use this tool versus alternatives such as getTransactions or getTransfersFrom.

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 no side effects. Description adds that it queries the smart contract directly and returns real-time on-chain value, providing useful behavioral context beyond annotations.

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

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

Three sentences, front-loaded with key action, every sentence adds value: purpose, explanation of rounds, and usage guidance. 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 no parameters, rich annotations, and existence of output schema, the description fully covers what the agent needs: what it does, why it's useful (for filtering), and that it returns real-time data. No gaps.

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

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

No parameters exist, so baseline is 4. Description doesn't need to add param info.

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

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

The description clearly states the action 'Get the current VeBetterDAO round ID' and specifies the resource (round ID) and method (querying smart contract directly). It distinguishes from sibling tools by focusing on a simple, real-time value retrieval, unlike more complex queries.

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 instructs to use the round ID to filter other queries like getB3TRGlobalOverview and getB3TRAppOverview, providing clear context. It doesn't specify when not to use it, but the purpose is narrow enough that it's implied.

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, covering the safety profile. The description adds the endpoint detail and pagination support, which is useful context but does not significantly extend behavioral transparency beyond annotations.

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

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

Two sentences, no filler: the first explains the core function, the second notes pagination support. Highly 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?

With a well-described schema and output schema present (not shown), the description captures the essential purpose. It misses explicit mention of time filters and sort direction, but the schema covers them, so it is almost 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?

All 8 parameters are fully described in the input schema (100% coverage). The description reinforces the delegator parameter and pagination concept but adds no new meaning beyond the schema's detailed 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 specifies the resource (delegated transactions) and action (query by delegator address) with the specific endpoint. It is distinct from siblings by focusing on delegated transactions, though no explicit sibling differentiation is given.

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 states the purpose and the key parameter (delegator) and mentions pagination, but does not provide guidance on when to use this tool versus other transaction tools like getTransactions or getContractTransactions.

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 the tool as readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds critical behavioral context: the tool depends on a separately running Discourse MCP server, and if not available, recommends an external workaround. 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 consists of two efficient sentences: the first defines the core purpose, and the second explains the optional dependency and fallback. No superfluous information, well 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?

For a simple no-parameter, no-output-schema tool with rich annotations, the description covers purpose, dependency, and alternative. It does not describe the return format (e.g., structure of categories), which would be beneficial but not critical. Complete enough for practical use.

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, so schema coverage is 100%. The description implicitly indicates that all categories are fetched without filters, which aligns with the lack of parameters. Baseline for 0 parameters is 4, and no additional parameter semantics are needed.

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

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

The description clearly states 'Get all available categories from the VeBetterDAO Discourse forum,' specifying the verb (get) and resource (categories). It differentiates from sibling tools like getDiscourseLatestTopics, getDiscoursePost, getDiscourseTopic, and searchDiscourseForum by focusing solely on categories.

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

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

Explicitly states that the tool requires the Discourse MCP server running separately and provides a clear fallback: suggest visiting the URL to browse categories. This tells the agent when to use the tool and what to do if it's unavailable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context about default page size, optional pagination, and the dependency on a separate MCP server, which goes beyond annotations.

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

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

The description is concise (two sentences plus a parenthetical note), front-loaded with the main purpose, and 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 explains the input and default behavior adequately. It could be more explicit about the output format, but the combination with annotations (read-only, idempotent) makes it relatively complete.

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

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

Schema description coverage is 100% with clear descriptions for all three parameters. The description adds value by indicating defaults ('Returns standard page size by default') and optionality, enhancing meaning beyond the schema.

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

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

The description clearly states the verb 'Get' and resource 'latest topics from the VeBetterDAO Discourse forum', distinguishing it from sibling tools like getDiscourseCategories, getDiscoursePost, and searchDiscourseForum.

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

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

The description provides clear context for usage, including an optional feature requirement, a fallback alternative, and specific use cases (browsing discussions, finding proposals, monitoring sentiment). It lacks explicit 'when not to use' guidance, 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 mark the tool as readOnly and non-destructive. The description adds a key behavioral trait: it requires a separate Discourse MCP server running, which is critical for agent invocation.

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 succinct sentences that front-load the primary action and purpose, with no extraneous information.

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

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

Reasonably complete for a simple get-by-ID tool, but lacks description of return values (no output schema) and could better differentiate from sibling tools like getDiscourseTopic.

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 a single required parameter 'postId' described in the schema. The description merely restates 'by post ID', adding no new semantic value.

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 retrieves a specific post by ID from the VeBetterDAO Discourse forum, distinguishing it from sibling tools like getDiscourseLatestTopics or getDiscourseTopic which deal with lists or topics.

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 usage context ('useful for reading specific replies or comments in detail') but does not explicitly guide when to use this tool versus alternatives like getDiscourseTopic for multiple posts.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety and idempotency. The description adds: returns 5 posts by default, an optional post_limit, and that the tool is optional (requires external server). It could mention error behavior if server is unavailable, but overall adds 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 a single paragraph but well-structured with bold markers for emphasis. It is front-loaded with the main purpose. There is some redundancy (e.g., 'OPTIONAL FEATURE' repeated), but no filler sentences. Could be slightly more concise with bullet points, but overall 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?

The tool has 2 parameters, rich annotations, and no output schema. The description explains the optional nature, critical use case, default behavior, and provides an example. However, it does not describe the return format or error handling, which would be helpful given no output schema. Still, it is sufficiently 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?

Schema coverage is 100%, with both parameters described. The description adds meaning: for topicId, gives an example of extraction from a URL; for post_limit, states default is 5, range 1-20, and advises using higher values only when needed. This enriches the schema information.

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

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

Clearly states 'Get detailed information about a specific Discourse forum topic, including posts and replies.' This is a specific verb+resource combination. It distinguishes from sibling tools like getDiscourseLatestTopics and searchDiscourseForum by focusing on a single topic. Also includes a critical use case for B3TR proposals.

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

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

Provides explicit guidance on when to use: requires Discourse MCP server (optional), and when not available suggests providing direct URL. Also advises on post_limit: 'Use higher values only when full discussion context is specifically needed.' Includes example of extracting topicId from a URL, which is helpful context.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by explaining the cumulative/sampled nature of the results and the need to compute deltas, which is beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the core purpose and endpoint, followed by concise details on parameters and result interpretation. 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 description covers the essential aspects: what the tool returns, how to query, and how to interpret the results. Given the presence of an output schema and the simplicity of the tool, this is complete.

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

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

Schema coverage is 100%, and the description repeats the parameter names with additional context ('Unix seconds, inclusive'). This adds minor clarifying detail but does not significantly expand 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 verb 'Get' and the resource 'block usage statistics', specifying the data fields (gas, tx counts, clauses, base fee) and the API endpoint. It distinguishes itself from sibling tools which are different types of queries.

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 the query parameters and the nature of the result (cumulative counters at sampled points, requiring client-side delta computation). It provides clear context for when to use this tool, though it does not explicitly mention alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the endpoint and usage hint but does not provide additional behavioral context beyond what annotations offer.

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 extremely concise: two sentences that cover purpose, usage hint, and endpoint. No unnecessary words 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 the presence of annotations, output schema, and full schema coverage, the description is complete enough. It explains the tool's purpose and relationship to getTokenRegistry, which is sufficient for an agent to decide when to use 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?

Schema coverage is 100%, so the description does not need to add parameter details. It adds no extra semantics beyond the schema, so a baseline score of 3 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 verb 'List', the resource 'fungible token contract addresses', and the scope 'for a wallet'. It distinguishes from sibling tools like getTokenRegistry by mentioning it as a companion tool for metadata.

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 a clear usage hint: 'Use with getTokenRegistry for metadata.' This implies when to use this tool (to get contract addresses) and suggests an alternative for metadata. However, it does not explicitly state when not to use it or compare with other list tools.

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

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

Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) are present. The description adds transparency about the hybrid approach (cached indexer vs. smart contract) and return details. 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 concise, front-loads the purpose, and provides all key information in a few sentences without unnecessary detail.

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

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

Given the moderate complexity, one parameter, and presence of an output schema, the description covers the hybrid approach and return type. It adds context about Galaxy Member NFTs' governance role. Minor missing details like error handling, but overall complete enough.

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 schema already documents the 'address' parameter clearly. The description does not add meaningful semantic information beyond what the schema provides.

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

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

The description clearly states the tool checks if a wallet address owns a Galaxy Member NFT and gets its details, specifying the hybrid approach and return elements. It is distinct from sibling tools, which cover different functionalities.

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 GM NFT status but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Given the sibling list, no direct overlap is apparent, but guidance is minimal.

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

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

The description adds significant behavioral context beyond annotations: it explains the efficiency of array usage, pagination behavior, timestamp format (seconds vs milliseconds), and the purpose of each filter. Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is 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 with headings and bullet points, but it is very long and includes redundant examples (e.g., full event type lists repeated in query patterns). It could be more concise without losing clarity.

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

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

Given the complexity (10 parameters, 1 required, many enums, output schema present), the description covers all facets: filters, pagination, event types, and usage patterns. It is thorough and leaves no major gaps.

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

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

Schema coverage is 100%, but the description adds meaning by explaining timestamp formats, common query patterns, and how to combine parameters. It provides examples that go beyond the schema descriptions.

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

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

The description clearly states the purpose: 'Retrieve transaction history for a VeChain address with filtering support.' It uses a specific verb and resource, and distinguishes this tool from siblings like getTransactions or getTransfersOfAccount by focusing on account-specific history with extensive event type filtering.

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 using arrays for event names to improve efficiency, and includes common query patterns. However, it does not explicitly compare to sibling tools or state when to use this tool over alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. Description adds transparency about the proxy URL and post-processing behavior (extracting Discourse links), which goes beyond annotations. No contradictions.

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

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

Description is front-loaded with core purpose and includes necessary post-processing instructions. Slightly lengthy but each sentence adds value; could be slightly more concise but overall well-structured.

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

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

For a single-parameter tool with comprehensive annotations and an output schema, the description covers usage context, proxy, common use case, and subsequent steps, making it fully complete for agent decision-making.

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% for the single 'cid' parameter with description 'IPFS Content Identifier (CID)'. The description does not add new semantics beyond the schema, so baseline 3 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?

Clearly states the tool fetches IPFS content by CID using the VeChain gateway proxy. Specifies a common use case (B3TR proposal descriptions) and distinguishes from sibling tools like getDiscourseTopic by instructing post-processing.

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

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

Explicitly provides when to use (fetch IPFS content, especially proposals) and when to use siblings (extract Discourse links, optionally call getDiscourseTopic). Gives clear context and alternatives.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying the endpoint and pagination details (page/size/direction/cursor). It does not contradict annotations and provides extra behavioral context about the API-based nature of the tool.

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

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

Two sentences, no fluff. The description front-loads the main action ('Get all NFT contract addresses for a given owner') and then provides structured details. Every sentence earns its place.

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

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

Given the 6 parameters and existence of an output schema, the description is mostly complete. It covers the core purpose and key parameter groups. However, it could elaborate on the interplay between cursor and page-based pagination, but that is a minor gap. The output schema compensates for return format details.

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 baseline is 3. The description briefly mentions 'address and pagination (page/size/direction or cursor),' but this adds minimal meaning beyond what the schema already provides. It does not clarify nuances like the relationship between cursor and page/size or the format of the 'owner' parameter.

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 retrieves NFT contract addresses for a given owner, with specific mention of the VeWorld Indexer and endpoint. The verb 'Get' and resource 'NFT contract addresses by owner' are explicit, and it distinguishes from sibling tools like 'getNFTs' which likely returns individual 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?

The description tells the agent when to use it (for owner's NFT contract addresses) but does not explicitly mention when not to use it or point to alternative tools. For example, it could note that 'getNFTs' retrieves individual NFT tokens, while this tool lists contract addresses. The guidance is implicit but could be clearer.

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 the endpoint and pagination behavior, which provides useful context beyond the annotations.

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

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

Only two sentences: the first states the core action, the second provides endpoint and parameter details. No irrelevant 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?

With a read-only, open-world tool and an output schema available, the description covers the essentials. It could mention error handling or rate limits but is otherwise sufficient.

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

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

Schema coverage is 100%, so the description's parameter summary ('address, optional contractAddress, and pagination') adds no new meaning beyond the schema, earning the baseline score.

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 'Get all NFTs owned by an address' using a specific indexer and endpoint, distinguishing it from siblings like getNFTContracts which likely focus on contracts.

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

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

It describes the context (VeWorld Indexer) and lists accepted parameters, but does not explicitly state when not to use it or compare to sibling tools beyond the endpoint hint.

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 behavior. The description adds that each element corresponds to an interval at the selected granularity, which clarifies the output structure.

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

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

Two sentences, no wasted words. The main purpose and key options are stated upfront.

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

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

For a simple tool with one parameter and an output schema, the description fully explains what the tool returns and the input options. 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?

Schema coverage is 100% and the parameter description matches the schema. The tool description lists the allowed period values (DAY, WEEK, MONTH, YEAR, ALL), which are not in the schema as enums, thus adding semantic value.

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 a time-series of total Stargate NFT holders by period, listing the allowed granularities (DAY, WEEK, MONTH, YEAR, ALL). This clearly distinguishes it from siblings like getStargateNftHoldersTotal (single total) and getStargateNftHoldersHistoric (raw historic data).

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 the available periods and that the output is a time-series. It implies usage for aggregated trends over time but does not explicitly contrast with siblings or state when-not-to-use.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds context that it provides a 'running-total time series', which is a behavioral trait (historical aggregation over time) not captured by annotations.

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

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

Single, information-dense sentence plus endpoint. No wasted words; front-loaded with 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?

Output schema exists, so return values are covered elsewhere. With high schema coverage and comprehensive annotations, the description provides sufficient context for the tool's function and parameters.

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

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

Schema coverage is 100% with both parameters described (level enum, range enum). Description reiterates that level is optional and range is preset, adding little 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?

Description clearly states it provides a 'running-total time series of total NFT holders' with optional NFT level filtering. This distinguishes it from sibling tools like getStargateNftHoldersTotal and getStargateNftHoldersByPeriod.

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 (for historic running totals) but does not explicitly state when not to use or compare with alternatives. No direct guidance on choosing this over other Stargate NFT holder tools.

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

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

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds the return structure (block metadata, total, byLevel) but no further behavioral traits 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?

Two sentences efficiently convey purpose and return format with no unnecessary words. 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?

With no parameters, existing output schema, and rich annotations, the description fully covers what the tool returns, making it complete for this simple read 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?

No parameters exist in the input schema, so the description cannot add parameter meaning. Baseline for 0 parameters is 4, and the description correctly reflects the tool's simplicity.

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 'get total number' and resource 'Stargate NFTs' with breakdown by level, distinguishing it from siblings like getStargateNftHoldersByPeriod and getStargateNftHoldersHistoric.

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

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

The description provides clear context that this returns the total count and breakdown, allowing inference of when to use it versus sibling tools. However, it lacks explicit 'when not to use' or alternative tool references.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that rewards are earned over time and not claimable until end of cycle, which is valuable behavioral context not in annotations. It does not contradict annotations.

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

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

Two sentences, zero waste. First sentence delivers purpose and critical behavioral nuance; second sentence enumerates supported features. Every word earns its place.

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

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

Given the tool has 7 parameters (2 required), full schema coverage, and an output schema, the description adequately covers purpose, usage distinction, and key options like periodType (with values), validator filter, and pagination. It also cross-references a sibling tool for token lookup. 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?

Schema coverage is 100%, but the description adds meaning: it lists periodType enum values explicitly ('CYCLE, DAY, WEEK, MONTH, YEAR, ALL') which the schema does not enumerate, and clarifies tokenId is 'NOT the level name' and points to getStargateTokens. 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 the tool provides an 'Overview of rewards earned by a Stargate NFT delegation to a validator over time.' It distinguishes itself from the related 'claimed' rewards and from other Stargate tools by focusing on token rewards. The purpose is specific and unambiguous.

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

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

The description explicitly notes this is 'Not the same as “claimed” (claimable only at end of cycle),' giving a clear when-not-to-use context. It also references getStargateTokens for finding token IDs, indicating a prerequisite. However, it does not explicitly compare against all sibling tools like getStargateTotalVetStaked, leaving some ambiguity 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 read-only, idempotent, and non-destructive behavior. The description adds value by listing the data fields returned (VET staked, rewards, level, etc.) and the API endpoint, providing additional 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 a single concise sentence that front-loads the main action and key details. Every part is informative, with 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 presence of an output schema and thorough parameter documentation, the description sufficiently covers the tool's core function. It lacks explicit guidance on pagination behavior or response format, but the output schema fills that 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description adds minor extra context (e.g., default page size, filter options) but does not significantly enhance 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 the tool fetches Stargate NFT information with specific data fields and API endpoint. It distinguishes itself among many sibling tools by focusing on individual token details.

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

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

The description specifies filtering and pagination support, implying when to use this tool (general NFT info extraction). However, it does not explicitly contrast with sibling tools like getStargateTokenRewards or getStargateTotalVetStaked, leaving the agent to infer the best tool for specific metrics.

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

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds return structure (block metadata, total, byLevel) beyond annotations, but does not mention rate limits or authentication, though likely unnecessary given the hints.

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

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

Two efficient sentences, no wasted words, front-loaded with verb and resource.

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

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

For a read-only tool with one optional parameter and an output schema, the description adequately explains purpose and return fields. Annotations cover safety, so 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?

Schema coverage is 100% for blockNumber, and the description 'at latest or at a specific block' mirrors the schema's description, adding no new meaning.

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

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

The description clearly states it retrieves total VET staked in Stargate, with optional block number. It distinguishes from sibling getStargateTotalVetStakedHistoric by specifying 'latest or at a specific block'.

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 querying total staked VET at a point in time, but does not explicitly guide when to use alternatives like getStargateTotalVetStakedHistoric for historical ranges.

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 the tool as read-only, idempotent, non-destructive, and open-world. The description adds that it returns a 'running-total time series' and provides the endpoint, but does not disclose additional behavioral traits like pagination or rate limits. Annotations carry the burden here, so the description adds modest 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 two sentences, front-loads the core purpose, and includes the endpoint. Every word is necessary; no redundancy or fluff.

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

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

Given the tool's moderate complexity (historic time series, optional filter), the presence of an output schema, and full annotation coverage, the description is sufficiently complete. It clearly states what the tool does and provides the endpoint, which is enough for an AI agent to understand its 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?

The input schema has 100% description coverage for both parameters (range and level), with full enum values explained. The description only adds that the filter is optional, which is already implied by the schema's optional property flag. No additional semantic detail 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 returns a 'running-total time series of total VET staked in Stargate' and mentions the optional filter by NFT level. It distinguishes from sibling tools like getStargateTotalVetStaked (non-historic) and other historic Stargate tools by specifying the metric and endpoint.

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 retrieving historic total VET staked with optional NFT level filtering but does not explicitly state when to avoid using it or mention alternatives. The context is clear but lacks explicit exclusions or comparative 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?

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds value by specifying the return format ('encoded as a JSON string'), which goes beyond annotations.

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

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

Three sentences: purpose, return format, optional parameters. Front-loaded, concise, no wasted words.

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

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

Given the output schema exists and annotations cover safety, the description is complete for this simple fetch tool. No missing behavioral details.

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 restates the parameter purposes but does not add new meaning beyond the schema.

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

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

The description clearly states the tool fetches the total VTHO claimed by Stargate users from delegation rewards, distinguishing it from per-account or historic variants among siblings.

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

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

No explicit guidance on when to use this tool vs alternatives like getStargateTotalVthoClaimedByAccount or getStargateTotalVthoClaimedHistoric. Usage is implied by the name and description but not directly stated.

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

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

Description adds endpoint detail and filter semantics beyond annotations which already declare readOnly, idempotent, and non-destructive. No contradiction; transparency is adequate for a read query.

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

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

Two concise sentences, front-loaded with the endpoint path, no extraneous words 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 the presence of an output schema and high parameter coverage, the description sufficiently explains the tool's purpose and filter options. Could note the return type, but output schema likely handles that.

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 the description adds value by explaining the filter values (LEGACY vs DELEGATION) more concretely than the schema's generic 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?

Description explicitly states 'Get total VTHO claimed by a given account' and includes the endpoint path, distinguishing it from sibling tools like getStargateTotalVthoClaimed (global) and getStargateTotalVthoClaimedByAccountToken (by account+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?

Describes the optional rewardsType filter with clear explanations of LEGACY and DELEGATION values, and notes that omitting the filter includes all rewards. Does not explicitly compare to siblings, but context is clear enough for selection.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds minor context (endpoint path, optional filter values) but does not disclose any additional behavioral traits beyond what annotations provide.

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

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

The description is two sentences: first states the core purpose, second explains the optional filter. No wasted words, front-loaded with the main 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 presence of an output schema and high schema coverage, the description covers the essential inputs and the filter nuance. It lacks explicit mention of output format but output schema fills that 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?

Schema coverage is 100% (all parameters described). The description adds useful context explaining the rewardsType filter values (LEGACY vs DELEGATION) and their meanings, which adds value 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 verb 'Get', the resource 'total VTHO claimed by a given account and token', and the endpoint path. It distinguishes from siblings like getStargateTotalVthoClaimed and getStargateTotalVthoClaimedByAccount by including both account and token parameters.

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 does not provide guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when-not-to-use, or comparisons with similar tools like getStargateTotalVthoClaimed or getStargateTokenRewards.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it returns a time series (running total), but does not elaborate on data freshness, pagination, or authentication. The added context is minimal and within expectations given 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?

Two succinct sentences: the first explains the purpose, the second provides the endpoint. No unnecessary words. Ideal for quick comprehension.

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 historic data retrieval tool with one parameter, rich schema, output schema present, and complete annotations, the description is nearly sufficient. It lacks detail on output structure (e.g., time series format) but the presence of an output schema mitigates this. Slight gap in what 'running-total time series' entails.

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% with a clear enum for 'range.' The tool description mentions the endpoint template but adds no additional semantics beyond the schema. Baseline 3 is appropriate as the schema fully describes the parameter.

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 a 'Running-total time series of total VTHO claimed across Stargate.' Combined with the title 'Historic total VTHO claimed,' it specifies the verb (retrieve) and resource (historic total VTHO claimed) and differentiates from the non-historic sibling getStargateTotalVthoClaimed.

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 no guidance on when to use this tool versus alternatives. Given siblings like getStargateTotalVthoClaimed, the agent must infer from names alone. No explicit when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by clarifying 'aggregate produced, whether or not claimed' and 'Returns a numeric value encoded as a JSON string', which are behavioral details beyond annotations. No contradictions.

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

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

Two sentences, no redundant words. The first sentence clearly states the core purpose, and the second adds return format and parameter hint. Front-loaded and efficient.

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

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

Given the presence of an output schema, the description adequately covers the function's purpose, aggregate nature, optional historical parameter, and return format. It provides sufficient context for a simple read-only tool, though it could explicitly mention the default latest block behavior.

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

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

Schema coverage is 100%, and the description mentions 'Optional: blockNumber for historical snapshots', which essentially mirrors the schema's own description. No additional parameter meaning is added beyond what the schema already provides. Baseline 3 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 'Fetch the total VTHO generated by Stargate delegations from validators’ block rewards', specifying the resource (total VTHO generated) and action (fetch). It distinguishes this from sibling tools like getStargateTotalVthoClaimed and getStargateTotalVetStaked by highlighting 'generated' vs 'claimed' and 'VTHO' vs 'VET'.

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 a usage hint: 'Optional: blockNumber for historical snapshots', which advises when to use the blockNumber parameter. However, it does not explicitly compare to siblings like getStargateTotalVthoGeneratedHistoric or explain when to use this tool over others. The context of sibling tools implies differentiation by metric, but more explicit guidance would improve.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the behavioral safety profile is clear. The description adds that it's a 'running-total time series' but does not disclose additional details like response structure or pagination. Minimal extra value beyond annotations.

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

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

The description is extremely concise: one sentence describing the tool's purpose followed by the endpoint path. Every word is meaningful, with no redundancy.

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

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

For a simple tool with one parameter and an existing output schema, the description covers the core purpose and endpoint. It is sufficiently complete given the low complexity and rich annotations/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?

The input schema provides full documentation for the single 'range' parameter with enum values and description (100% coverage). The description adds no further parameter semantics, achieving baseline adequacy without improvement.

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

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

The description clearly states it provides a 'running-total time series of total VTHO generated across Stargate', specifying the resource (total VTHO) and temporal nature (historic time series). This distinguishes it from siblings like getStargateTotalVthoGenerated (non-historic) and other Stargate 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?