x402-mcp

Official

by x402node

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Tools are grouped into distinct domains (cn402 Chinese culture, x402node utilities), but within these groups many tools have overlapping purposes, such as multiple BaZi endpoints and two color palette generators. Descriptions are detailed enough to distinguish most tools, but some near-duplicates (e.g., cn402_today vs cn402_festival_today) cause confusion.
Naming Consistency4/5
Two clear prefixes (cn402_ and x402node_) with a consistent category_function pattern. Most tools follow this, but exceptions like x402node_generate_color-palette (vs x402node_color_palette) and hyphenated names (email-security) slightly reduce consistency.
Tool Count1/5
117 tools is far too many for a single MCP server, indicating a lack of focus. The server mixes Chinese culture, general utilities, cryptography, etc., resembling a collection rather than a cohesive service. Typically 3-15 tools per server is appropriate; this is extreme overreach.
Completeness4/5
Despite the large count, the server covers a vast range of functionality comprehensively, especially Chinese culture (BaZi, Feng Shui, I Ching, etc.) and developer utilities (crypto, text, URL, validation). There are few obvious gaps within each subdomain, though the overall surface is bloated.
Average 3.3/5 across 117 of 117 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 6 community issues answered or closed in the last 6 months
- 14 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only hints at returned data (trigram parent, element, yin/yang). It omits output format, side effects, rate limits, or that it is a read-only lookup. The irrelevant price line adds confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, listing multiple synonyms in the first sentence, and includes an irrelevant pricing line. It could be condensed to one sentence stating the lookup action and returned data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and numerous siblings, the description fails to specify the operation type or provide examples. The agent cannot deduce whether the tool returns a single result or a list, or how to use the optional parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for degree and name. The description adds minimal extra context (e.g., each span 15°) but does not clarify relationship between parameters or when to use each. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines what the 24-Mountain compass is but does not state the action (e.g., lookup, retrieve). It reads like a textbook entry rather than a tool purpose, making it vague for an AI agent to understand what the tool actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling fengshui tools like cn402_fengshui_direction or cn402_fengshui_bagua-direction. The agent is left to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description adds no behavioral traits beyond the input schema. It does not disclose rate limits, idempotency, output format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a long list of redundant synonyms, then the functional sentence. The price information is irrelevant. Not front-loaded, and includes unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description lacks completeness. It does not specify output format, error handling, or character set details for the conversion result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which already documents the parameter. The description adds synonyms but no extra semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts Simplified Chinese to Traditional Chinese (Taiwan standard). It uses specific verb and resource, and the sibling 't2s' implies the reverse, so purpose is clear, but not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Mentions price but not usage context, prerequisites, or exclusions. Sibling tools exist but no comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool provides 'real-time weather data' and mentions a price, but does not disclose any behavioral traits such as read-only nature, rate limits, authentication needs, or side effects. The price note is vague and does not clarify cost implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences. The first sentence is informative about the tool's function. The second sentence about pricing is extra but not essential. No wasted words, though the structure could be improved by separating functional details from cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, no annotations, and a mismatch between description and input schema, the description is incomplete. It does not explain how to use the tool effectively, what the response format is, or how to handle the apparent parameter discrepancy. The price mention adds minimal context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description introduces a query parameter 'city' without defining it in the schema. This inconsistency undermines the tool's usability. The description adds meaning but in a way that contradicts the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Real-time weather data for any city worldwide,' which clearly indicates the tool's purpose. However, the mention of a query parameter '?city=Beijing' conflicts with the input schema that defines zero parameters, causing confusion and reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like cn402_almanac or cn402_solar. The description does not mention any prerequisites, limitations, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions default date and price but lacks key behaviors like how date is sent (mentions query param but schema has none). Contradicts schema, causing confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but includes unnecessary price info. Could be more structured. Not excessively long but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description lacks details on return structure. Input mechanism unclear due to schema-description mismatch. Insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, so description adds no meaning. Instead, it introduces a query parameter not in schema, which is misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a Chinese Almanac with auspicious/inauspicious activities and 15+ fields. It distinguishes from siblings focused on specific aspects like bazi or iching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral characteristics (e.g., read-only, mutability, rate limits). The price note is informational, not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with synonyms and examples, and the price line is irrelevant. Lacks clear structure, though it conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and complex domain, the description should explain output format, how pillars are derived, or timezone handling. It provides none of these, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no additional semantics beyond stating it computes Na Yin for four pillars; the schema already documents the datetime parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes Na Yin names for the four pillars of a BaZi chart, using alternatives and examples. This specific verb-resource pairing distinguishes it from other BaZi tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus siblings like cn402_bazi_full or cn402_bazi_sizhu. The description does not indicate prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, prerequisites, or cost implications (price is mentioned but not behavioral). It only says 'compute relationships', leaving the agent unaware of any constraints or outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with multiple names and a price statement that is irrelevant to function. The core purpose is buried, and the information is not front-loaded. It could be significantly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not explain what the output contains. Given the complexity of Ten Gods and the many sibling BaZi tools, the description is incomplete and leaves the agent guessing about return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with a description, achieving 100% schema description coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool computes Ten Gods relationships in a BaZi chart relative to the Day Master. It uses multiple names but the core purpose is evident. However, it does not explicitly differentiate from sibling BaZi tools that may also include Ten Gods information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cn402_bazi_full or cn402_bazi_wuxing. The description merely states it is 'core of Chinese astrology analysis' but does not provide when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions analysis of Five Elements, stroke total, and auspicious meaning but does not specify the output format, whether it is read-only, or any side effects. The mention of 'Price: unknown' is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with redundant keyword phrases before the main sentence, and the irrelevant 'Price: unknown on Base' line adds noise. The key functional sentence is present but not front-loaded, wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description only vaguely lists what is analyzed (Five Elements, stroke total, auspicious meaning) but lacks detail on the return format or structure. The mention of BaZi compatibility is unclear, and the price info distracts from completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'name' is already described in the schema as 'Chinese name (required, 2-4 hanzi)'. The tool description adds no new meaning beyond the schema, so the baseline score of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool analyzes a Chinese name's Five Elements composition, stroke total, and traditional auspicious meaning, providing a clear verb and resource. While it lists many related keywords, the core purpose is distinguishable from sibling hanzi and bazi tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives like cn402_hanzi_wuxing or cn402_bazi_wuxing. The usage context is only implied by the name and keyword list, leaving the agent without clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions cost (auto-paid in USDC) but fails to disclose output format, limitations, or any side effects. Important behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose with repeated keywords in multiple languages. The first sentence is a clutter of synonyms. It could be condensed significantly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the array of similar siblings, the description should explain what the output contains (e.g., text report, structured data) and any additional requirements. It does not, leaving the agent uncertain about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the only parameter (datetime) with a clear format description. The description adds no extra meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes health from a BaZi birth chart using TCM, and provides diet/lifestyle recommendations. It distinguishes from other bazi and tcm tools by focusing on health, but the listing of multiple keywords and languages adds noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like cn402_tcm_constitution or cn402_bazi_full. The description does not mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'lookup' but does not describe side effects, authorization needs, or what happens if the herb is not found. The price note is confusing and does not clarify behavior. There is no mention of read-only or destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and repetitive, listing many synonyms for Chinese herbs and properties. The price sentence is unnecessary and adds noise. It is not front-loaded with the most critical information; the first sentence is a keyword dump rather than a clear statement of action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return format. It mentions 'properties (nature, taste, meridian) and clinical uses' but does not specify how the output is structured or what fields to expect. For a simple one-param tool, this is incomplete, as an agent might need to know the output shape to chain calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single required parameter 'name', with a description already providing examples. The tool description adds no additional semantic meaning beyond the schema's documentation. Baseline 3 is appropriate since the schema fully specifies the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'TCM herb lookup' tool for looking up Chinese herbs with traditional properties and clinical uses. It uses multiple keywords (herb properties, meridian, temperature, taste) to specify the domain, and it distinguishes itself from sibling TCM tools like cn402_tcm_constitution and cn402_tcm_meridian by focusing on herbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any when-to-use or when-not-to-use guidance. It does not mention alternatives or prerequisites, such as using other TCM tools for constitution or bazi. The inclusion of 'Price: unknown on Base' is irrelevant and does not help with usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions a price ('Price: unknown on Base (auto-paid in USDC)'), indicating a paid tool, but does not clarify if this is a cost, authentication requirement, or rate limit. It also does not state whether the operation is read-only or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a long string of slash-separated keywords, which is not front-loaded or concise. The main explanation is short, but the structure is cluttered, with price information at the end. Valuable real estate is wasted on repetitive keywords.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return format or what the generated palette contains (e.g., array of hex codes, number of colors). For a generation tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with both parameters described clearly. The description adds extra synonyms for the 'type' parameter values but does not provide significant new meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a color palette from a base color using standard color theory schemes, listing specific scheme types. However, the name 'x402node_color_palette' already implies a color palette tool, and the description's initial barrage of keywords could be streamlined. It does not distinguish itself from the sibling 'x402node_generate_color-palette' directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as the similar sibling 'x402node_generate_color-palette'. No explicit context for usage or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source for behavioral traits. It mentions 'bidirectional' and 'pretty-print', but omits any constraints, error behavior, or side effects. Unclear about handling of invalid input or formatting specifics beyond pretty-print.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with redundant keywords and extraneous price information. It could be condensed to a single clear sentence. The structure is not front-loaded with essential information, requiring parsing through noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (bidirectional conversion), the description is incomplete. It lacks details on error handling, input validation, output formatting specifics, or any limitations beyond the schema's max length. No output schema exists, so the description should clarify return format, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'content' and 'from'. The description adds no new parameter meaning beyond what the schema provides, such as detailing the 'from' values ('json' or 'yaml') or clarifying the 'content' format. Baseline 3 is appropriate due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Bidirectional convert between JSON and YAML with pretty-print', which clearly identifies the verb (convert) and the resources (JSON, YAML). It distinguishes from sibling conversion tools (e.g., CSV, Markdown) via the name and context, though not explicitly in the description. The keyword clutter reduces clarity slightly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like x402node_convert_csv-json or x402node_convert_markdown-html. No exclusions, prerequisites, or context about when the conversion is appropriate, limiting the agent's ability to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It mentions returning 'structured datetime' but lacks details on the format or limitations. Irrelevant pricing info adds confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and redundant, listing multiple similar phrases ('Natural language date parser', 'parse date string', etc.) before a structured sentence. Includes an irrelevant price note, making it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on the output structure ('structured datetime'), error handling, or edge cases. With no output schema, the description should clarify the return format to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described. The description adds examples like 'today' and '+3d', but these are already implied by the schema's description. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it parses natural language and ISO dates into structured datetime, with examples like 'today' and '+3d'. It effectively explains the tool's purpose and input types, though it could better differentiate from time-formatting siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include other time parsers like cn402_timepoint and x402node_convert_timestamp, but no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, any rate limits, authorization needs, or return format. The lack of any behavioral context reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, opening with a long string of aliases that adds clutter. The core functionality is buried in the second sentence. Pricing information is extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It does not explain result format, error handling, or any constraints (e.g., domain validation). Use cases are listed but not connected to tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both 'domain' and 'type' that already include allowed values and default. The description adds no further semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves DNS records and lists supported record types (A, AAAA, MX, TXT, NS, CNAME, SOA). However, it does not differentiate from sibling tools like x402node_domain_email-security or x402node_url_check-status, which may overlap in domain-related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The description lists many use cases but does not exclude scenarios or point to sibling tools. The pricing note is irrelevant to usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, read-only nature, or any limitations. The mention of auto-payment in USDC hints at cost but does not clarify the tool's operational behavior (e.g., mutability).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a list of keywords and synonyms, which is redundant and not concise. The core sentence is clear, but the overall structure is messy with extra information (price).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fails to specify what the agent should expect as output (e.g., numeric values, chart, etc.). It also lacks details on constraints like date validity, timezone handling, or payment mechanics beyond a vague note on price.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the two parameters with date format descriptions. The description adds no additional semantic meaning beyond restating the purpose, meeting the baseline expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes personal biorhythm cycles from birth date to target date, specifying the three cycles. It is specific and distinguishable from sibling tools like bazi or almanac. The inclusion of synonyms is extraneous but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over other similar tools (e.g., bazi or almanac). It lacks any context on prerequisites, appropriate scenarios, or cases where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states a read-like operation ('look up') but provides no details on side effects, permissions, rate limits, or behavior when parameters conflict or return no results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with repetitive keywords and a pricing note, which are unnecessary for an AI agent. The core sentence is clear but buried under excess text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description provides the basic function but lacks details on return format, error handling, and how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds no extra meaning beyond the schema's parameter descriptions; it only restates that the tool accepts a date or festival name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool looks up traditional customs, food, and rituals for a Chinese festival by date or name. However, the keyword-stuffed header and lack of differentiation from siblings like cn402_festival_cn slightly reduce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., cn402_festival_cn, cn402_festival_today). The description implies use for custom lookups but does not specify 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only mentions pricing ('Price: unknown on Base (auto-paid in USDC)'), which is about cost, not behavioral traits. It does not disclose side effects, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains verbose and repetitive elements (multiple translations and synonyms) before the core sentence. The pricing line is irrelevant for tool invocation. The key information is buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description covers what data is returned (trigrams with mappings). However, it lacks detail on output format and default behavior (both pre- and post-Heaven). Without an output schema, more context on returned structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the one parameter 'type' with description 'preHeaven | postHeaven (optional, default both)'. The description adds minimal value beyond repeating 'Pre-Heaven Post-Heaven' in the title, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get all 8 trigrams (Ba Gua) with element, direction, family role, body part, and natural symbol mappings,' which clearly identifies the tool's purpose. It distinguishes from siblings like iching_coin or iching_divine by focusing on retrieving trigram mappings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other I Ching tools (e.g., iching_hexagram, iching_yao) or when to choose preHeaven vs postHeaven. No usage context or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions a price (auto-paid in USDC), indicating a paid tool, which is a key behavioral trait. However, it does not describe what the tool returns (e.g., lines, hexagram number) or whether the operation has side effects. The payment detail adds transparency but remains vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with a long list of synonyms and alternative names, which could be condensed. The actual functional description is only one short sentence. The pricing info is appended awkwardly. It is not concisely front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (divination method) and has no output schema. The description does not explain what the output looks like (e.g., hexagram, lines, interpretation). Among many I Ching siblings, it lacks details that would help an agent choose correctly. Missing return format and use context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 says 'from given numbers (time, date, or arbitrary)' which aligns with the parameters n1 and n2. It adds little beyond the schema: the schema already indicates n1 defaults to current time. No extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool casts a hexagram using the Plum Blossom Numerology method from numbers. The multitude of names (Plum Blossom Yi Numerology, 梅花易数, etc.) helps identify the method, distinguishing it from other I Ching tools like coin or random hexagram generation. However, the initial list is somewhat cluttered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 instead of other I Ching tools (e.g., cn402_iching_coin, cn402_iching_random). It does not specify prerequisites, when not to use, or mention alternatives. An agent would have to infer usage from the method name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the password is 'cryptographically random' and mentions a price ('auto-paid in USDC'), which hints at cost. However, it does not clarify whether the tool is idempotent, whether it has side effects, how parameters combine, or what happens on invalid input (e.g., length out of range). The disclosure is partial but covers the key security trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with an excessive keyword list (e.g., 'Password generator / strong password / random password...') that is redundant and wastes space. The functional sentence is clear, but the keyword stuffing and the separate price note make it less concise. It could be reduced to one or two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters and no output schema, the description provides a basic functional overview and hints at cost. However, it does not explain the return format (expected to be a string), how parameters interact (e.g., if all false), or any constraints. It adequately covers the essentials but is not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, each parameter with a clear default and purpose (e.g., 'Include digits (optional, default true)'). The tool description adds no new semantic information beyond the schema; it only rephrases 'custom length and character set rules.' Thus, per the baseline, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate cryptographically random password with custom length and character set rules.' This provides a specific verb (generate), resource (password), and customization. While the initial keyword list is noisy, the core purpose is evident. It distinguishes from siblings like x402node_crypto_random-bytes and other generate tools, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., random bytes for non-password uses, or other password generators). There is no mention of prerequisites, such as requiring a paid plan (the price note hints at cost but does not clarify usage conditions). The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, authorization needs, or output format. The cryptic note about price ('Price: unknown on Base') adds confusion rather than clarity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes an extraneous and unclear sentence about price. It front-loads use case keywords but could remove the price line for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks details on return value format, error handling (e.g., division by zero), or edge cases. Given no output schema, this is a gap, though the operations are straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description reinforces the meanings of the 'op' parameter (e.g., 'of', 'change') but does not add new information beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists multiple percentage operations and their interpretations (e.g., 'X percent of Y', 'percent change'), making the tool's purpose clear and distinguishing it from siblings like x402node_math_interest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates use cases but provides no guidance on when to prefer this tool over alternatives (e.g., x402node_math_interest) or when not to use it. No exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions 'cryptographically secure' and optional batch count, but lacks details on side effects, idempotence, error handling, or cost implications (price note is not behavioral). No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with an extensive list of aliases before the core sentence. While functional, it could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with well-documented parameters, the description provides adequate context. However, it does not describe the output format (e.g., single number vs. array), and includes irrelevant price information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters (count, min, max, type). The description adds no extra semantic depth beyond what the schema already provides, achieving baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates cryptographically secure random numbers in a range with optional batch count. The aliases list covers diverse use cases like dice roll or coin flip, but it does not differentiate from related siblings like x402node_crypto_random-bytes or cn402_iching_random.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. The aliases imply general random number tasks, but no comparative context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose important behavioral traits such as rate limits, precision, or the fact that it may be a paid tool (the price note is ambiguous).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a list of examples and a price note, making it somewhat verbose. Could be streamlined to state the primary function more directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unit converter, the description covers core functionality but lacks details on supported units, error handling, and output format. Without annotations or output schema, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for each parameter. The description provides examples but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a unit converter for various measurement types (length, weight, temperature, etc.), with examples. However, it could be more concise and does not differentiate from sibling tools, as no other unit converter is present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description only states its function without mentioning prerequisites or situations where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full responsibility for behavioral disclosure. However, the description omits critical behavior details such as idempotency, side effects, performance considerations, or authentication requirements. The pricing note (`Price: unknown on Base`) is irrelevant to tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but front-loaded with a long list of synonyms (e.g., 'Text diff / text comparison / ...') that adds redundancy. The inclusion of a pricing line (`Price: unknown...`) is extraneous and slightly violates conciseness. The core purpose and granularity details are clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only three simple parameters and no output schema, the description adequately covers what the tool does. However, it does not describe the return format or structure of the diff output, which would be helpful. The description is sufficient but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with clear descriptions for all three parameters. The tool description adds no additional meaning beyond what the schema already provides. Therefore, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing two texts and returning diffs with added/removed/unchanged segments. It specifies granularity options (line, word, char) and uses multiple synonyms for discoverability. It is distinct from sibling tools, which are mostly Chinese astrology or utility functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides many synonyms but no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where a different tool might be preferred. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions pricing (unknown on Base, auto-paid in USDC). It does not disclose whether the tool is read-only, destructive, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains redundant synonyms (Day Master strength / 起旺 / 旺衰) and a pricing note, making it somewhat verbose. However, it front-loads the purpose and is structurally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fails to specify the output format (e.g., strong/weak/balanced or numeric). For a simple evaluation tool, this omission makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the datetime parameter, and the description does not add extra meaning beyond what the schema provides (birth datetime). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates Day Master strength (strong/weak/balanced) using a birth datetime, distinguishing it from sibling BaZi tools that provide full charts or other analyses. The verb 'evaluate' and resource 'strength of Day Master' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cn402_bazi_full or cn402_bazi_dayun. The description does not indicate prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as whether the tool returns only star names or also interpretations, or if it requires specific input formats beyond the datetime. The payment note is irrelevant to behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with repetitive synonyms and examples. While it front-loads key terms, it could be more concise. The payment information is unnecessary for tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the output contains (e.g., list of stars, interpretations, or formatting). For a tool computing stars, this is insufficient for an agent to understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'datetime' with 100% schema coverage. The description does not add any extra meaning beyond the schema's 'Birth datetime YYYY-MM-DD HH:MM (required)'. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes all major shensha (auspicious/inauspicious stars) in a BaZi chart, using specific examples like Tian Yi Gui Ren, Tao Hua, Yi Ma. It distinguishes from sibling tools that compute other BaZi elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cn402_bazi_full. No mention of prerequisites or exclusions. The description is silent on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, or output format. The tool computes pillars from datetime, but no details on edge cases or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains multiple synonyms and redundant phrases, and includes irrelevant pricing information. However, the core functionality is front-loaded in a single sentence. Acceptable but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns. It fails to do so, leaving the agent uncertain. Sibling tools like cn402_bazi_full suggest this tool's scope is limited, but the description does not clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema. The optional gender parameter's role in Four Pillars calculation is not clarified. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Compute Four Pillars of Destiny (year/month/day/hour gan-zhi) from any Western birth datetime,' providing a specific verb and resource. It includes synonyms for clarity and distinguishes itself from sibling tools like cn402_bazi_full by focusing on the four pillars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives among many sibling bazi tools. The phrase 'Foundation of Chinese astrology analysis' implies it is basic, but lacks clear when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions the tool is paid ('auto-paid in USDC') but does not specify side effects, required permissions, or any constraints beyond computing a score. For a read-only compute tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a long list of redundant synonyms (e.g., 'Zodiac compatibility / Chinese zodiac matching / 生肖配对 / ...'), which wastes space. The core functional description is concise, but the keyword padding could be trimmed for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description only mentions 'compatibility score and analysis' without detailing the output format. With many sibling tools and no annotations, the description lacks completeness for an agent to fully understand the tool's behavior and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds examples of animals (rat/ox/tiger) and the context of compatibility, but does not significantly enhance the schema's meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes compatibility score and analysis between two Chinese zodiac animals, providing examples like 'rat/ox/tiger/...'. It distinguishes from sibling tools like cn402_zodiac which likely gives individual zodiac info, and the title includes many synonyms for discoverability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives among the many sibling tools (e.g., bazi, iching). The description does not mention when not to use or any prerequisites, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the tool is paid (price unknown, auto-paid in USDC), which is useful, but it does not discuss idempotency, error handling, rate limits, authentication, or side effects. The description focuses on output content rather than behavioral characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a long, cluttered list of synonyms and keywords separated by slashes, which is not concise or well-structured. The core explanation is embedded within this noise. The price note at the end adds extraneous information. It lacks clear sectioning or front-loading of the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description provides adequate context about the conversion purpose and output fields. However, it fails to specify the output format (e.g., JSON structure) and does not include an example response. The price note is somewhat irrelevant for usage. Completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes one optional parameter (date) with full description (format, optional, default today). The description adds that it converts any Gregorian date, which slightly reinforces the parameter's purpose but does not add significant new meaning beyond the schema. Baseline 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: converting Gregorian dates to Chinese lunar dates with full traditional context. It lists specific output fields (lunar year-month-day, gan-zhi pillars, zodiac animal, leap month flag) and provides multiple synonyms in Chinese and English, making it unambiguous among sibling tools like cn402_solar or cn402_almanac.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites, constraints, or typical use cases. With many sibling tools in similar domains, explicit usage directives are missing, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'computes' a chart, but does not clarify if it has side effects, requires authentication, or has cost implications (except a vague price mention). It does not describe read-only or destructive nature, nor any other 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes several alternative names and transliterations that may be extraneous. The price mention is irrelevant for usage. The core functionality is stated upfront, but the extra details add clutter without significant value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (divination chart with multiple components), but no output schema is provided. The description names components (Heaven plate, Earth plate, etc.) but does not explain the output format or how to interpret results. This leaves the agent uncertain about what the tool returns, making it incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the one parameter 'datetime'. The description merely restates that it takes a datetime, adding no new information beyond the schema's description 'Datetime YYYY-MM-DD HH:MM (optional)'. Thus, the description adds no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as computing the Da Liu Ren divination chart (Heaven plate, Earth plate, 4 lessons, 3 transmissions) for a given datetime. It distinguishes the specific method from sibling tools like cn402_zhanbu_liuyao or cn402_zhanbu_qimen by using specific terminology (Liu Ren, Da Liu Ren, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or scenarios where Liu Ren divination is appropriate compared to other divination methods available among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions the algorithm and return values but omits potential errors, performance implications, or any destructive actions. The inclusion of an irrelevant price note adds noise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with a list of keywords and an irrelevant price statement. While the core instruction is clear, the extras reduce conciseness and could be confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should fully explain the return structure. It mentions IV, ciphertext, and tag but not their format (e.g., hex or base64) or if they are bundled. This incomplete specification, combined with irrelevant content, limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented. The description adds context about the algorithm and key size but does not significantly enhance understanding beyond the schema, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool encrypts plaintext using AES-256-GCM with a 32-byte key, clearly distinguishing it from siblings like the decrypt tool. 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description lacks context for appropriate usage scenarios or exclusions, leaving the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the tool performs read-only DNS queries, requires permissions, or has rate limits. The mention of pricing ('auto-paid in USDC') is not about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded, but includes an unnecessary pricing line. Overall, it earns its place without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and missing details on return format. The contradictory schema vs description leaves a significant gap for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description implies a 'domain' parameter. This contradiction is seriously misleading; the description adds no meaningful parameter semantics and instead creates confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks SPF/DKIM/DMARC for a domain, with specific verbs ('detects') and resource ('email security posture'). It distinguishes itself from siblings which are mostly unrelated Chinese astrology or utility tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using '?domain=example.com', indicating how to specify the domain, but lacks explicit when-to-use or alternatives. The input schema is empty, contradicting the stated parameter, which could confuse an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions output includes pillar and start age but does not disclose edge cases, error handling, or data sources. The price note is irrelevant to behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes multiple synonyms and a price note that adds no value for tool selection. It is not optimally concise; the core statement is clear but padded with unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return format more thoroughly. It mentions 'each with gan-zhi pillar and start age' but lacks structure details. Adequate but not fully complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, and the description adds no additional meaning beyond the schema's descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compute the lifelong sequence of 10-year major luck cycles, each with gan-zhi pillar and start age.' It uses specific verbs and resource terms, and effectively distinguishes from sibling bazi tools by focusing on Dayun cycles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cn402_bazi_full or cn402_bazi_sizhu. No prerequisites or context provided. The description only states functionality without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It fails to indicate that the tool is read-only, idempotent, or any constraints like rate limits or required permissions. The price note is not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a long list of synonyms that clutter the start and a price note irrelevant to functionality. The core instruction is concise, but the extra verbiage reduces efficiency. It is adequately but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at what the tool returns; it does not specify the output format. The price mention is tangential. The basic purpose and parameter are covered, but completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description already specifies the parameter 'scheme' with allowed values and default. The description adds minimal extra meaning; synonyms are not directly parameter-related. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Get direction mapping for each of the 8 trigrams in both Pre-Heaven and Post-Heaven schemes.' It uses specific verbs and resources, differentiating it from sibling fengshui tools that focus on other aspects like bed or business directions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It lacks context such as prerequisites or comparisons with sibling tools like cn402_fengshui_direction, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions the algorithm (haversine) and implies output in kilometers via the synonym 'kilometer between two coordinates', but it does not specify the exact return format, units, error handling (e.g., invalid coordinates), or performance characteristics. The pricing note is extraneous and does not aid core behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bloated with a long list of alternative names that are redundant given the tool name. The core functionality is covered in one sentence; the rest is unnecessary. The pricing note is irrelevant and adds noise. The description should be front-loaded with the computation sentence and omit the synonym list and pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain the return value (e.g., distance in kilometers, numeric type) and any constraints (e.g., valid lat/lng ranges, handling of edge cases). It fails to do so, leaving the agent uncertain about what the tool returns and how to interpret errors. The completeneness is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with basic parameter descriptions ('First point latitude'). The description adds value by clarifying that the output unit is kilometers (via the phrase 'kilometer between two coordinates'), which is not in the schema. This additional semantic helps the agent understand the expected output, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes great-circle (haversine) distance between two lat/lng coordinates, using multiple synonyms to reinforce the purpose. It clearly differentiates from sibling geo tools like cn402_geo_cn_city (city lookup) and cn402_geo_timezone. The verb 'compute' and resource 'distance' are highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as other geo tools or distance calculators. It does not state prerequisites (e.g., valid coordinate ranges) or when it might be inappropriate (e.g., for short distances where great-circle approximation is fine but not specified). The context of payment is mentioned but not relevant to usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pricing ('Price: unknown on Base') but fails to mention other behavioral traits like rate limits, authentication, or safety aspects. The description does not contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a long list of redundant synonyms before the core sentence, making it wordy. The price information is useful but should be integrated concisely. Overall, it could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description provides basic functionality and price context. However, it lacks details on output format, error handling, or character limit beyond schema, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds little beyond the schema for the two parameters. The 'style' parameter is explained via keywords, but the schema already provides options. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts Chinese characters to Pinyin with tone marks, and the tool name 'cn402_hanzi_pinyin' further clarifies the purpose. It distinguishes from sibling tools like stroke count or radical lookup, though the description is slightly redundant with multiple synonyms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'For AI agents handling Chinese text-to-speech, Chinese language learning apps,' which gives context but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Price: unknown on Base (auto-paid in USDC)' hinting at a cost, but does not clearly disclose whether the tool is read-only, modifies state, or requires authentication. Behavioral traits are incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose, repeating the same concept in multiple languages and including tangential price info. While front-loaded with purpose, it could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool, the description and schema provide adequate context. However, missing output format details and unclear cost behavior reduce completeness. It is minimally viable but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for parameter 'q'. The description adds synonyms (animal, situation, object) but does not significantly extend the schema's meaning. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for Chinese dream interpretation using Zhou Gong's dictionary, specifying input keywords (animal, situation, object) and output as traditional reading. It distinguishes itself from sibling zhanbu tools which are different divination methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., other zhanbu or Chinese culture tools). Usage context is only implied through the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it computes stats and mentions a price, but does not disclose whether it is read-only, any side effects, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is fairly concise but has redundant lists and repetition (e.g., 'Statistics calculator / mean median mode / ...' followed by 'Compute statistical measures: mean, median, ...'). Could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description lists all measures but does not explain if all are returned at once or output format. Leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 lists computed measures but adds no extra meaning to the 'data' parameter beyond the schema example. Does not clarify input formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a statistics calculator and lists all computed measures (mean, median, mode, stddev, variance, min, max, range). Differentiates from siblings which are mostly Chinese culture tools or other math tools like math_interest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not provide context like 'use for dataset analysis' or when to use other math tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description does not mention side effects, safety, error handling, or any behavioral constraints beyond the conversion itself. The price note is irrelevant to tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive (cases listed twice) and includes an irrelevant price line. It could be more concise but is still short.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return format is undocumented. Missing edge-case handling (e.g., mixed case input). Adequate for a simple converter but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (100% coverage). The description lists cases but adds no extra meaning beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it converts strings between multiple case formats (camelCase, snake_case, etc.). It clearly distinguishes itself from sibling text tools like slugify or diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Siblings include other text utilities, but no comparison or usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions it's comprehensive but gives no behavioral details such as whether it's a read operation, what the response format is, any authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with repetitive phrasing ('complete BaZi reading / full Chinese astrology…') and includes a pricing note that seems tangential. It front-loads the purpose but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a full BaZi reading and the absence of an output schema, the description should explain what the output contains and how to interpret it. It lists components but lacks details on format or structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond what the schema already provides for the datetime and gender parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'complete BaZi reading' and 'single comprehensive endpoint combining all BaZi analyses', explicitly distinguishing it from the many specialized sibling tools like cn402_bazi_sizhu or cn402_bazi_wuxing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a full BaZi reading, but does not explicitly state when to use this tool versus the individual BaZi components or when not to use it. Alternatives are only implied by the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return behavior (list of festivals or empty) but does not disclose side effects, authentication needs, or rate limits. For a read-only lookup, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a pricing note. It is front-loaded with the core purpose. The pricing information is not essential but does not significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description provides sufficient context about input and output. It specifies the date format and return type, making it complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'date', and the schema already describes the format and optionality. The tool description adds no additional meaning beyond the schema, meeting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes multiple aliases and clearly states the tool returns Chinese festivals for a given date, with an empty list if none. It specifies the resource (Chinese festivals) and action (return), making purpose clear. However, it does not explicitly distinguish from sibling 'cn402_festival_cn', which could be similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no mention of when to use this tool versus alternatives like 'cn402_festival_cn' or other festival-related tools. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a payment requirement ('Price: unknown on Base (auto-paid in USDC)'), which is important. However, with no annotations, it lacks details about error handling, output format, or any side effects beyond the basic algorithm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes many redundant keywords and translations (e.g., '个人幸运颜色', 'Chinese Feng Shui colors') which clutter the core message. It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not specify what the tool returns (e.g., color names, codes). The price mention is vague ('unknown'). The agent lacks enough context to fully interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'birth' described as 'Birth date YYYY-MM-DD'. The description adds context about Five Elements but does not add new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Determine personal lucky and unlucky colors from birth date based on Five Elements (Wu Xing) compatibility.' It uses a specific verb and resource, and distinguishes itself from siblings like 'cn402_folk_lucky-number' by focusing on colors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives. Among many folk tools, there is no mention of when to choose lucky-color over lucky-number or other BaZi tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the core function but omits key behavioral details such as how stroke counts are returned (per character or total), whether input may contain non-Chinese characters, or how pricing affects usage. The mention of 'Price: unknown' adds a transactional note but does not clarify tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with multiple redundant synonyms and extraneous text like 'Price: unknown on Base (auto-paid in USDC)'. The core action is not front-loaded; it is buried after the synonym list. This reduces conciseness and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description states the purpose and sample use cases but does not explain the output format (e.g., whether it returns a list of stroke counts or a total). Given the simplicity, it is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for its single parameter 'text', describing it as 'Chinese text (required, max 100 chars)'. The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Chinese stroke counter with multiple synonyms and explicitly states 'Get stroke count for each Chinese character.' It distinguishes itself from sibling tools like cn402_hanzi_bushou (radicals) by focusing on stroke count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists use cases ('handwriting apps, Hanzi learning, character grading') implying when to use it, but it does not explicitly state when not to use it or compare it to alternative tools. No guidance is given for differentiating from other Hanzi tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions a price/autopay note which is irrelevant to tool behavior, but fails to disclose read/write operations, error handling, rate limits, or any side effects. The output format is also unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with keyword repetitions (e.g., many translations of 'five elements') and ends with an irrelevant pricing note. The core message could be conveyed in two sentences; the extra verbiage detracts from clarity for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 no output schema, the description covers the purpose and use cases. However, it lacks details on output format, error handling, and examples, which would be helpful for an agent to interpret results. The pricing info is extraneous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the param 'text' is fully documented. The description does not add meaningful info beyond the schema's description ('Chinese text (required, max 100 chars)'). It repeats the same constraints without providing examples or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: 'Determine Five Elements (Wu Xing) attribute of each Chinese character.' It also mentions use cases like Chinese naming and Feng Shui, distinguishing it from sibling hanzi tools (e.g., stroke count, pinyin) which focus on other attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool ('Chinese naming consultations and Feng Shui'), but lacks explicit guidance on when not to use it or how it differs from similar siblings like cn402_bazi_wuxing. The differentiation is implied but not stated directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It mentions 'drawing a fortune slip' and 'price unknown on Base' but does not explain mechanics, randomness, or any side effects. For a tool performing a divination draw, crucial behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes an excessive list of redundant synonyms (eight phrasings for the same concept). The price note ('unknown on Base') is out of place for a divination tool. While functional, the structure could be cleaner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (divination with optional temple parameter and no output schema), the description fails to explain what the user receives (e.g., slip text, interpretation, or prediction format). The mention of 'interpretation and prediction' is vague. The price note adds confusion rather than clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'temple' has schema coverage 100% with description 'Temple slip set'. The tool description adds concrete examples ('观音, 关帝'), providing extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as drawing a Chinese temple fortune slip (qiānzi) with traditional interpretation and prediction. It provides multiple synonyms and names (求签, 签文, Guanyin temple lottery) that uniquely distinguish it from sibling divination tools like cn402_zhanbu_liuren or cn402_iching_divine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives. The description lacks any context about appropriate scenarios, exclusions, or comparisons to other divination tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It specifies the output format (base64 PNG data URL) and mentions a price note, but lacks details on error handling, side effects, or performance characteristics. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with many aliases ('QR code generator / QR generator / ...') which are redundant and reduce conciseness. The essential information is present but buried, making it less efficient than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does a moderate job by stating the return format. However, it does not outline error cases, performance constraints, or detailed output structure, leaving some gaps for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds little beyond the schema's own descriptions. It offers context for the 'text' parameter (URL, wifi credentials) but does not provide syntax or formatting rules, so the value added is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate QR code as base64 PNG data URL' and lists common use cases (URL, wifi credentials, business cards). This clearly identifies the tool's verb and resource, and it distinguishes itself from sibling tools which are mostly unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions appropriate use cases but does not explicitly state when to use this tool versus others or when not to use it. There is no comparison with sibling generation tools like x402node_generate_password, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention if the operation is read-only, what side effects occur (network call to the domain), any authentication or rate limits, or pricing (only a vague 'Price: unknown on Base (auto-paid in USDC)'). The description omits important 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and redundant with a long list of synonyms (e.g., 'ssl certificate', 'SSL certificate checker', etc.) that add noise. It front-loads repetitive keywords without clear structure. Several sentences could be merged or removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description usefully enumerates key return fields (issuer, subject, SANs, etc.), which partially compensates. However, it omits error handling, response format details, and prerequisites (e.g., domain must be resolvable). The inclusion of payment info is irrelevant for tool usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so baseline is 3. The description adds limited extra meaning beyond the schema (e.g., lists return details like issuer, subject, SANs), but does not provide parameter-specific details that aren't already in the schema. Overall, it does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Get' and resource 'full TLS handshake details'. It lists multiple synonyms and use cases, making the function unmistakable. It distinguishes from sibling URL tools like dns-lookup and check-status by focusing specifically on SSL certificate inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use ('For AI agents, security audits, monitoring, HTTPS infrastructure pipelines') but does not explicitly state when not to use it or mention alternatives among siblings. It lacks explicit guidance on selecting this tool over other URL-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It does not mention side effects, authentication, rate limits, or whether external calls are made. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat cluttered with multiple slash-separated phrases and includes pricing info. It could be more structured and concise, but it still conveys key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; the description does not explain the return format or what information is provided (e.g., JSON with classification). This leaves the agent guessing about the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic description. The tool description adds value by listing classification categories (public/private/loopback/link-local/multicast/reserved) and detection capabilities beyond just validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates and classifies IP addresses (IPv4/IPv6) into categories like public/private/loopback, with specific verbs 'validate' and 'classify'. It is distinct from sibling tools that handle Chinese astrology, Feng Shui, or other validations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description lacks context for when IP validation is needed compared to other validation tools like validate_email or validate_url.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, authentication needs, rate limits, or edge case handling (e.g., future birth dates). The only additional information is a price note, which is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a cluttered list of synonyms and includes a price note, which adds noise. The core functionality is stated in a single sentence, but the opening could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists four outputs but does not explain their format or provide error handling details. No output schema exists, so the description should be more complete to cover return values and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, both parameters are described in the schema. The description restates the schema but does not add new semantic meaning beyond 'birth' and 'on' dates. The price note is irrelevant to parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes Chinese nominal age (xu sui), Western actual age, days lived, and lunar birthday from any birth date. It uses specific verbs and resources, and the list of sibling tools shows it is distinct from other Chinese calendar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for age calculations but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance. With many sibling tools, more explicit context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It does not disclose whether the tool is read-only, any side effects, or the meaning of 'price unknown'. The mention of USDC payment is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat cluttered with multiple terms for the same concept and a separate price note. It could be more streamlined without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description hints at output usage but not format. For a single-parameter tool, this is acceptable but could be more complete given the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'datetime', describing it as a birth datetime. The description adds no extra parameter-level meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: determining the Useful God (favorable element) for a BaZi chart. It explains what the output guides (lucky directions, colors, life choices), and the name 'yongshen' distinguishes it from siblings like 'cn402_bazi_full' or 'cn402_bazi_wuxing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding a favorable element but lacks explicit guidance on when to use this tool versus other bazi tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the output (festivals with Gregorian dates) but lacks full behavioral details like data freshness, output format, or potential side effects. No annotations are provided, so the description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with examples but includes extraneous pricing info that is not tool behavior. It could be more concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and basic output but misses details like output structure, pagination, or data source. For a simple tool, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'year' is fully described in the schema with format and default. The description adds no additional parameter meaning, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides all traditional Chinese festivals for a given year with Gregorian dates, listing examples and use cases. However, it does not explicitly differentiate from sibling tools like cn402_festival_today.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests use cases for cultural events and holiday planning, providing some context. It does not specify when to use this tool versus alternatives, such as cn402_festival_today for today's festivals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions return fields and price (unknown, auto-paid in USDC) but does not disclose case sensitivity or error handling. Some transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is cluttered with a redundant keyword list before the main sentence. Not concise; could be streamlined to one clear sentence plus price note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup with one parameter and no output schema, the description adequately covers input and output fields. Lacks edge case details but still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'name' has schema description indicating required and Chinese/English. Tool description adds no new semantic value beyond what schema provides, so baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for looking up China city information, listing specific fields like name, province, tier, coordinates, population. It distinguishes itself from sibling cn402_geo_cn_province by focusing on cities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like cn402_geo_cn_province or cn402_geo_distance. No when-not-to-use or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions lookup by name or code and lists return fields, but does not disclose behavior when no parameters are given, error handling, or whether both parameters can be used together. It also includes an ambiguous pricing line that adds no functional clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with repetitive keywords in multiple languages (e.g., 'China province lookup', '中国省份查询'). The pricing note ('Price: unknown on Base...') is extraneous and potentially confusing, detracting from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two optional parameters and no annotations, the description should clarify default behavior (e.g., if no parameters are provided), output structure, and error conditions. It only partially describes the return fields but omits how results are returned (single vs. multiple provinces) and lacks any output schema or cross-reference to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by enumerating the returned fields (capital, area, population, region), which aids understanding beyond the parameter names and basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it looks up China province information by name or code, and lists the fields (name, capital, area, population, region). It distinguishes from the sibling tool cn402_geo_cn_city by focusing on provinces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as cn402_geo_cn_city for cities. It also fails to mention prerequisites or exclusions (e.g., only mainland China provinces).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions DST-aware lookup, which adds behavioral context beyond the schema. However, no annotations are provided, and it omits error handling, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a cluttered list of keywords and pricing info unrelated to functionality. It could be more streamlined and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description is somewhat complete but lacks details on ambiguous city names, error cases, or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool's description adds examples (北京/Beijing/Tokyo) but doesn't significantly enhance meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up IANA timezone, UTC offset, and current local time for a city, using specific verbs and resource. It distinguishes from siblings like cn402_geo_cn_city which are purely geographic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives like cn402_timepoint or cn402_time_timezone-convert. It only lists keywords without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions 'Price: unknown on Base (auto-paid in USDC)', which adds context about cost. However, it does not disclose what 'full traditional interpretation' includes (e.g., judgment, image, lines) or whether the operation is read-only, making the behavior somewhat opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overloaded with keywords and translations (e.g., 'I Ching hexagram lookup / 卦象查询 / 64 hexagrams reference / ...') that are not concise and do not add clarity for an AI agent. The actual functional sentence is solid, but the extra fluff harms conciseness. The pricing line is also non-essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should detail what the output includes, but it only says 'full traditional interpretation', which is vague. It does not mention structure (e.g., name, judgment, image, lines) or format. Given many sibling tools, more specifics are needed for an agent to correctly interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter 'number' described as 'Hexagram number 1-64 (required)'. The description adds that it is a lookup by number and yields a full interpretation, but does not enhance parameter meaning beyond the schema. Baseline 3 applies since schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Look up a specific I Ching hexagram by number (1-64) and get its full traditional interpretation.' The verb 'look up' and resource 'I Ching hexagram' are specific, and it distinguishes from siblings like cn402_iching_list (list all) or cn402_iching_divine (random divination).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used when you have a specific hexagram number, but it does not provide explicit guidance on when to use this versus alternatives such as cn402_iching_divine or cn402_iching_full. No when-not-to-use or alternative tool suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It states it outputs dates but does not describe format, structure, or any side effects. The price note is irrelevant to agent behavior. Lacks disclosure of mutations, auth needs, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat cluttered with a keyword dump at the start followed by explanatory text and a price note. The key information is present but could be more concise and better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional param and no output schema, the description explains the output concept (dates for 6 periods) but lacks detail on format or structure. The price note adds noise. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the sole optional parameter 'year'. The description adds no extra meaning beyond the schema's 'Year YYYY (optional, default current year)'. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides exact dates for sanfu and sanjiu periods for a given year, specifying both Chinese terms and English descriptions. It distinguishes from siblings like cn402_jieqi or cn402_lunar by focusing specifically on these folk seasonal periods used in TCM.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions it is used in traditional Chinese medicine seasonal therapy, implying context, but does not explicitly state when to use vs. alternatives like cn402_tcm_season or cn402_jieqi. No when-not guidance or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool uses folk numerology and derives a hexagram, and mentions a vague price ('unknown on Base'). However, it does not describe the response format, rate limits, or behavior for invalid input, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a list of synonyms ('Number divination / 数字占卜 / numerology oracle / ...') which is repetitive and wastes space. The core instruction is clear, but the synonyms could be trimmed to improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately conveys the purpose and input but lacks details on the output format (hexagram, interpretation) and pricing implications. It provides sufficient context for basic usage but not full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the sole parameter 'digits', so baseline is 3. The description adds that digits should be '3-6 random digits' and are used to 'derive a divinatory hexagram or interpretation', which provides context but mostly restates schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it is a 'Number divination / numerology oracle / digit-based fortune telling' tool that takes 3-6 digits and derives a divinatory hexagram or interpretation. This clearly distinguishes it from sibling tools like 'iching_coin' or 'cn402_zhanbu_liuren' which use different methods (coin toss, six ren).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or comparative advantages over other divination tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains the decomposition process but omits important details: what happens if input is not a single character, what output format or structure to expect, any cost implications (price is mentioned but as 'unknown'), and whether it is deterministic. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes many redundant synonyms and a price line that may not be essential for tool selection. While not overly long, it could be more concise by keeping only the core explanation. The structure is adequate but not optimized for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should outline what the returned data contains. It only mentions 'auspicious/inauspicious meanings' without specifying format, components, or confidence. For a complex divination method, more detail is needed to set expectations. However, the tool is relatively simple in input, so it is moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'word' has a schema description that matches the tool's purpose. The tool description adds context that the character is decomposed for interpretation. With 100% schema coverage and the description clarifying the divination goal, the parameter semantics are well-supported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: divination by decomposing a Chinese character. It provides multiple synonyms (Ce Zi, character oracle) and explicitly says 'Divine the future by decomposing a Chinese character into components and interpreting their auspicious/inauspicious meanings.' This is a specific verb+resource and distinguishes it from sibling tools like iching_coin or zhanbu_liuren.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention scenarios where character divination is preferred over other methods like eight characters (bazi) or Liuren. Without such context, an agent may struggle to select appropriately among many divination tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention if conversion is synchronous, output format, failure modes, or any side effects. The price note is vague and does not clarify behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads a redundant list of synonyms, which is not concise. The core message is short, but the keyword dump wastes space. The price note at the end is out of place and not structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to specify what the tool returns (HTML or markdown). The pricing mention is unclear and does not compensate for missing output specification. The tool needs more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal value beyond the schema. It clarifies that direction is controlled by the 'from' parameter, but does not add new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Bidirectional convert between Markdown and HTML', clearly defining the tool's core function. It uses multiple synonyms but the purpose is unambiguous and distinct from sibling conversion tools like convert_csv-json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates direction via the 'from' param, but lacks explicit guidance on when not to use it or alternatives. The purpose is clear from the name and description, but no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the basic function (derive key from password using PBKDF2) and configurable parameters, but does not mention whether the operation is deterministic, idempotent, or any security considerations (e.g., salt should be random, iteration counts affect speed). The price note is commercial, not behavioral. Significant gaps remain for a cryptographic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (two sentences plus a price note). The first sentence is a tag list that could be more efficient (redundant synonyms), but the core purpose is front-loaded. The price note is extraneous but brief. Overall, it earns a 4 for being mostly concise with minor fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a cryptographic tool and the absence of an output schema or annotations, the description lacks critical completeness. It does not describe the output format (e.g., hex, base64, raw bytes), any constraints on parameter values, or security warnings. The inclusion of a price note without functional details leaves the agent underinformed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with defaults documented, so baseline is 3. The description lists 'configurable iterations, salt, and hash algorithm' but omits 'keylen' and does not explain parameter semantics beyond what the schema already provides. The description adds marginal value by grouping parameters, but fails to fully compensate for the missing output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as PBKDF2 key derivation and password hashing, listing multiple synonyms (KDF, scrypt alternative, etc.) and explicitly stating it derives a cryptographic key from a password. This distinguishes it from sibling cryptographic tools like AES encryption or HMAC, as none of those perform password-based key derivation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'scrypt alternative' but provides no explicit guidance on when to use PBKDF2 versus other KDFs or password hashing methods. It does not state when not to use this tool or list alternatives within the toolset. The context is implicit through the tool name and purpose, but lacks explicit why/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention whether the tool has side effects, requires authentication, has rate limits, or is read-only. The tool is likely safe (parsing only), but this is not stated. The price mention is not behavioral. The lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a long list of synonyms (parser/decoder/validator/calculator/...) that are redundant. The core purpose is front-loaded, but the list wastes words. It is not overly verbose, but could be tighter. Score 3 reflects adequate but not optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain return values. It states 'Returns human description + upcoming timestamps,' which is vague but gives a general idea. The input parameters are documented. However, it does not specify the format of the description or timestamps. For a simple tool, it is minimally sufficient but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions for 'cron' (required) and 'count' (optional). The description adds context: 'Parse 5-field cron expressions' and 'Returns human description + upcoming timestamps,' which helps clarify the output but adds little beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a cron expression parser/validator/next run calculator. It states the exact function: parse 5-field cron expressions and compute next N execution times. This distinguishes it from sibling tools, most of which are unrelated (e.g., bazi, almanac, time_parse). The purpose is unambiguous and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases: 'For AI agents, schedule debug, automation pipelines, infra config validation.' This gives context on when to use the tool. However, it does not explicitly state when NOT to use it or provide alternatives among the many sibling tools. There is no comparison to other time-related tools (e.g., x402node_time_parse). The guidance is present but basic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the algorithm selection and hex digest output but omits details like behavior on empty input, performance characteristics, or whether the function is deterministic and side-effect free. The odd pricing note adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but starts with a keyword soup that is hard to parse. The functional sentence is clear, but the inclusion of 'Price: unknown on Base (auto-paid in USDC)' is irrelevant and distracts from the tool's purpose. It could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality (hash computation) and mentions the return format (hex digest). However, it lacks details on edge cases (e.g., handling non-string input) and does not specify the output schema given none is provided. It is minimally adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage). The description mentions 'hex digest' (explaining output format) and 'Default: sha256' but these are largely redundant with the schema. The description adds minimal value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a cryptographic hash using multiple algorithms (MD5, SHA-1, SHA-256, SHA-384, SHA-512) and returns a hex digest. It lists specific use cases like integrity checks and deduplication, making the purpose unambiguous and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios (integrity checks, deduplication, content addressing) but does not explicitly differentiate from alternatives like other crypto tools (e.g., HMAC, PBKDF2). It mentions 'password hashing prep' but lacks guidance on when not to use it (e.g., for secure password storage).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a behavioral trait: 'Price: unknown on Base (auto-paid in USDC)', indicating a paid tool. However, it does not address other behaviors like read-only nature, rate limits, or response format, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a cluttered list of keywords separated by slashes, which is redundant and not front-loaded. The key sentence appears after the keyword list. The price line adds minor value but could be integrated better. Overall, moderately concise but structurally suboptimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers basic purpose and payment context. However, it lacks details about output format, default values, or how to interpret results, and does not differentiate from the sibling x402node_color_palette.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description repeats the parameter descriptions (base hex, scheme options) but does not add significant new meaning beyond what the schema provides, such as format constraints or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a harmonious color palette from a base color using color theory, with a specific verb (generate) and resource (color palette). Although there is an extraneous line about price, the purpose is unambiguous and distinguishes it from sibling tools like x402node_color_palette (likely similar) by specifying 'using color theory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as the sibling x402node_color_palette. There are no exclusions or usage scenarios described, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It mentions 'Price: unknown on Base (auto-paid in USDC)' implying a cost, but does not clarify if the computation is local or requires an external call, or any side effects. For a pure calculation tool, this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a keyword list (not ideal), then a sentence, then pricing info. Could be more concise and front-loaded. It is not excessively long, but has some fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculator with full schema descriptions, the description adds minimal value beyond what's in the schema. It omits behavioral details and output format. No output schema, so agents lack return information. Pricing info is extra but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds the insight of 'configurable compounding frequency' but does not elaborate beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes simple/compound interest or annuity loan payments with configurable compounding frequency, matching the tool name. The sibling tools are all different domains (astrology, color, etc.), so this tool is clearly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. However, given the sibling tools are unrelated, the context implies this is for financial interest calculations. No 'when-not' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description gives basic behavior: strip diacritics, lowercase, replace spaces with hyphens. But lacks details on handling special characters, unicode, or empty input. Adequate for a simple transformation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains redundant synonyms and an irrelevant price line, wasting space. The core sentence is clear but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with no output schema, the description covers basic functionality but lacks edge-case details (unicode, empty string) that would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions in the schema. The description adds no extra meaning beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists numerous synonyms (URL slug generator, slugify text, etc.) and explains the action: convert any string to URL-friendly slug, strip diacritics, lowercase, replace spaces with hyphens. This clearly states the verb and resource, and distinguishes it from sibling tools like x402node_text_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like x402node_text_case or others. The odd mention of price does not provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as error handling, edge cases, or authentication needs. It only mentions a pricing note which is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but includes a list of aliases and a pricing note that add noise. The main point is front-loaded, making it functional but not optimally clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not specify the output format beyond examples. Given the low complexity, it is partially complete but could benefit from clarifying the return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The description adds context by explaining the default base and providing example outputs, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: formatting a datetime as relative to now or another base, with examples like '3 hours ago' and 'in 2 days'. It distinguishes from sibling time tools by focusing on relative formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when to use this tool over alternatives or when not to use it. No guidance on prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'Price: unknown on Base (auto-paid in USDC)' which indicates a cost mechanism, but it does not describe rate limits, auth requirements, or potential side effects. The description also does not clarify that this is a read-only operation or what happens if the page is not parseable. Given no annotations, the description is insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and uses many synonyms to convey capability quickly. It includes a relevant cost note. While somewhat verbose with repetitive synonyms, it is still concise for the amount of information. It could be slightly more streamlined, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 1 parameter and no output schema. The description does not specify the structure of the returned data (e.g., JSON format, field names, nesting). For a tool that extracts structured meta, this is a notable gap. The description implies what it extracts but not how it is returned, making it incomplete for an agent to fully understand the output without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('url') with 100% coverage and a detailed description including scheme requirement and size limit. The function description lists what meta fields are extracted but adds no extra parameter-specific semantics beyond the schema. Since the schema already provides the necessary details, the description adds marginal value, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly lists multiple synonyms that all point to the same core function: extracting meta tags from URLs. It specifies exact outputs (title, description, keywords, canonical, favicon, language, OpenGraph, Twitter Card). The sibling tools include other URL utilities (status check, DNS, SSL, validation), so this tool is well-distinguished as a meta extractor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: 'For AI agents, link preview, SEO audits, content discovery, bookmarking pipelines.' However, it does not explicitly state when NOT to use this tool or suggest alternative tools for other scenarios. The usage guidance is implied but lacks explicit exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only describes the function (scoring elements) but does not disclose side effects, authentication requirements, rate limits, or whether the operation is read-only. The price note is non-behavioral. This leaves the agent with little insight into how the tool behaves beyond its core function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a long list of redundant keywords and a price note that does not aid tool selection. It is front-loaded with synonyms, but the actual functional description is clear. Some trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Ba Zi wuxing analysis, the description adequately explains the output (scoring and highlighting strong/weak elements). No output schema is provided, so the description effectively communicates what the agent can expect. A bit more detail on the output format would be beneficial, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter 'datetime' with a clear description. The description adds no additional meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes the five elements (wuxing) from a birth chart and scores each element's strength. It uses multiple synonyms and keywords, making the purpose unmistakable. Among sibling tools, this one is distinct by focusing specifically on wuxing analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for analyzing element distribution from a birth datetime, but it does not explicitly state when to use it versus other Ba Zi tools, nor does it mention when not to use it. Context hints at usage within Chinese cosmology, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions 'Compute' which implies a non-destructive operation but does not confirm read-only behavior, authentication needs, or payment implications. The pricing note is unclear and does not clarify 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single clear sentence after a list of keywords. It is front-loaded but includes redundant synonyms that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, the description is mostly adequate but lacks details on the output format or what the 'chart' contains. No output schema exists, so more context on return value would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'year and house orientation' but adds no additional meaning beyond what the parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes a Flying Stars chart for a given year and sitting direction, using multiple keywords for clarity. It distinguishes itself from sibling fengshui tools by focusing on the 9-grid star chart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus other fengshui tools. The description implies usage for computing flying stars but lacks exclusions or mentions of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions considering birth year and traditional moving rules, and notes a price (unknown on Base, auto-paid in USDC). However, it lacks details on what the output looks like (e.g., list of dates) and any limitations. No annotations are present, so the description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with synonyms in multiple languages, which may aid discoverability but adds redundancy. The price line is separate. It is not overly long but could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify the output format (e.g., list of dates, calendar view) or any result details. Given no output schema, this is a significant gap. The price context is useful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions are clear. The description adds that birthYear is for zodiac clash, but this 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Feng Shui moving date selector with multiple keywords and specifics ('Find auspicious days for moving house within a date range'), which distinguishes it from sibling tools like cn402_almanac or other fengshui tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving date selection but does not explicitly state when to use this tool versus alternatives like the generic almanac. No when-not or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains the computational method (BaZi day master Five Elements) and includes pricing information (auto-paid in USDC), which is important behavioral context. It does not indicate any destructive side effects, which is appropriate for a read-only computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, with multiple synonyms for 'personal lucky numbers' listed at the beginning. This repetition wastes space and is not concise. The key information (computation method and use case) is present but could be conveyed in one or two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and method but fails to describe the output format (e.g., list of numbers, count). Since there is no output schema, the description should clarify what the agent can expect as a return value. The inclusion of pricing is extra but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'birth', is already documented in the input schema with format YYYY-MM-DD. The description does not add new meaning beyond stating that it uses the birth date for computation. Schema coverage is 100%, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes personal lucky numbers from birth date using BaZi day master Five Elements. It is specific to lucky numbers, differentiating it from other bazi or folk tools like cn402_bazi_wuxing or cn402_folk_lucky-color. However, the title is null and the description includes many synonyms that are unnecessary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is for AI agents handling lottery suggestions and lucky number recommendations, providing some context. However, it does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks behavioral traits such as idempotency, side effects, or limitations beyond the max 100 chars constraint. The mention of pricing is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with a long list of keywords (synonyms) before the main sentence. It is not front-loaded and wastes space on redundant terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers input and purpose. It lacks details on output format (e.g., returns a single radical or mapping for multiple characters) but is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, which is well-described. The description adds context about the output (Kangxi radical) but does not add significant new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the Kangxi radical (部首) for each Chinese character', with a specific verb ('Get') and resource ('Kangxi radical'). It distinguishes itself from sibling hanzi tools like pinyin or stroke count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating it's for 'Chinese dictionary lookups, character decomposition, hanzi learning.' However, it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It correctly notes that it handles leap months and is a conversion function. However, it omits details about output format, error handling for invalid dates, or any required authentication. The price mention is irrelevant to tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with the core purpose but then repeats equivalents in different languages and adds an irrelevant price line. It could be streamlined to a single clear sentence. The structure is adequate but not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain the return value format (e.g., a date string like '2026-01-15'). It does not. It also doesn't mention constraints like valid lunar year ranges or error behavior. The description is incomplete for safe agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 little beyond the schema: it restates the valid ranges (day 1-30, month 1-12) and mentions the 'leap' parameter defaults to false, but these are already in the schema descriptions. No additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states multiple phrasings for the conversion (lunar to solar, Gregorian, Western calendar) and uses specific verbs like 'Convert' and 'reverse lookup'. It clearly distinguishes from sibling tools like cn402_lunar which likely does the opposite conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies it is for lunar-to-solar conversion and mentions 'reverse lunar calendar lookup', it does not explicitly state when to use this tool versus alternatives like cn402_lunar (solar-to-lunar) or other calendar tools. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses bidirectional conversion and header usage, but does not mention error handling, character encoding, response format, or pricing details (price unknown is noted but not behavioral). Limited transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description includes a redundant keyword list followed by two clear sentences and a pricing note. Key information is concise, but the keyword stuffing adds noise. Could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 params and no output schema. Description lacks details on expected input/output structures (e.g., for JSON to CSV, does it expect an array of objects?). No examples or error handling info. Incomplete for a clear understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. Description adds value by stating 'CSV first row used as headers', which is not in schema. Baseline 3 is exceeded due to this additional context about behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states bidirectional conversion between CSV and JSON, and specifies CSV first row used as headers. This is a specific verb+resource. Distinguishes from sibling conversion tools that target different formats (JSON-YAML, Markdown-HTML, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. The purpose implies usage for CSV/JSON conversion, but no alternatives are mentioned. Siblings are different conversion types, so context is somewhat clear, but lacking explicit guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions an unknown price and auto-pay mechanism, which hints at cost but is vague. It does not specify idempotency, error handling on invalid input, or output format. The description lacks important behavioral context for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with many repetitive synonyms, which is somewhat redundant. The core conversion sentence and auto-detect note are concise, but the price line feels tacked on. It could be more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fails to explain the return value format or error behavior. It is adequate for input but incomplete for output context. Additionally, it does not differentiate from the many sibling time tools, leaving the agent to guess when to use this converter over others.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the single parameter 'value'. The description adds value by stating 'Auto-detect input format', which goes beyond the schema's literal description and clarifies the tool's flexibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses multiple clear synonyms and explicitly states the core function: 'Convert between unix epoch (sec or ms), ISO 8601, and human-readable date strings.' It distinguishes itself from sibling tools like timezone-convert or business-days by focusing on timestamp format conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for conversions with 'Auto-detect input format', but it does not provide explicit guidance on when to use this tool versus sibling time tools (e.g., x402node_time_timezone-convert for timezone conversion, x402node_time_business-days for business day calculations). No exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions only the 'max 64k' input limit (in schema description) and a note about pricing, but fails to describe output format, potential privacy concerns, or that the tool is read-only and safe. The payment note is tangential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is adequately sized but contains redundant synonyms ('text statistics / word count / ...' and 'count words in text') that could be condensed. The core information is front-loaded in the second sentence, but the opening is noisy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description conveys the core functionality well. It lacks details about the return format (e.g., whether results are an object or array), but the tool's straightforward nature and absence of an output schema make that omission less critical. The payment note is an odd inclusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 only repeats the parameter's existence ('Text to analyze (required, max 64k)') without adding semantic context like encoding, language support, or special characters handling. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly lists all statistics provided (word count, character count, etc.) and includes a concise statement 'Get word/char/line/paragraph/sentence count and reading time estimate.' It distinguishes itself from sibling tools like text_case or text_lorem, which focus on transformation rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 versus alternatives. While the purpose is specific, the description lacks comparison with similar text tools (e.g., text_diff, text_slugify) or conditions under which this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions conversion and IANA timezones but does not disclose any behavioral traits such as whether the operation is safe/mutating, authentication requirements, rate limits, or what happens if inputs are invalid. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but the first sentence is a keyword-stuffed list (redundant phrases like 'world clock' and 'international time'). The price note is irrelevant but does not detract much. It is reasonably concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema. The description explains the core function but does not describe the output format (e.g., datetime string, object) or default behavior for missing parameters (though schema implies defaults). It is adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a description in the schema. The description adds example timezone strings and the phrase 'any IANA timezone,' which provides context but does not significantly extend meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a timezone converter, specifies converting between IANA timezones, and lists common abbreviations (UTC, PST, etc.). It distinguishes itself from sibling time tools like x402node_time_business-days and x402node_time_duration by focusing on timezone conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool converts datetime between any two IANA timezones but does not explicitly tell when to use it versus alternatives or mention any prerequisites or exclusions. The context of many siblings suggests a need for clearer guidance, but the basic usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, cost implications (though price is mentioned vaguely), or safety concerns. It only lists capabilities, missing important operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a series of keywords followed by a sentence and pricing info. It is somewhat repetitive and lacks clear structure. While not overly long, the information could be better organized for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description provides sufficient detail on what the tool checks (HTTP status, response time, etc.) and typical use cases. However, it could mention error handling or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (url) with 100% description coverage, so the baseline is 3. The description does not add any extra meaning or format hints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs and resources: 'Check any public URL for HTTP status, response time, content-type, content-length, redirect chain, server header.' It also distinguishes from sibling tools like x402node_url_dns-lookup and x402node_url_ssl-check, which cover different URL aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions use cases ('AI agents, monitoring pipelines, security audits, and link validation') but does not explicitly compare with alternatives or provide when-to-use vs when-not-to-use guidance. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the computation method and mentions an auto-paid price, but does not disclose the output format, potential errors, or any side effects. The behavioral information is adequate for a simple deterministic tool but lacks explicit details about cost implications or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes multiple synonyms and a price note, which adds redundancy and extraneous information. The core functional sentence is clear, but the structure could be streamlined to remove the price line and repetitive translations without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description explains the method and purpose well. However, it does not describe the output (e.g., returns a direction like 'East'), which leaves the agent guessing. With no output schema, this is a notable omission. The completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage but only provides minimal descriptions ('M | F', 'Birth year YYYY'). The description adds significant context by explaining that these parameters are used to compute the kua number via the Ba Zhai method, thereby linking parameters to the underlying logic. This goes beyond schema basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: to calculate the optimal bed direction based on kua number using Ba Zhai method. It provides multiple synonyms and clarifies the specific kind of direction (head direction). This clearly distinguishes it from sibling tools that focus on other fengshui aspects like business direction or general direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool over alternatives. It omits prerequisites (like needing the user's kua number) and does not mention scenarios where it would be inappropriate. No guidance is given on choosing this tool among the many fengshui tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool recommends auspicious directions and wealth corners based on inputs, and it discloses a pricing model (auto-paid in USDC). However, it does not describe rate limits, data sources, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and redundant, repeating similar phrases in multiple languages (e.g., 'shop entrance Feng Shui / 商铺方向 / store door direction / business luck direction'). It could be more concise. The essential sentence is buried in the middle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the tool returns (e.g., direction name, degrees, etc.). It lacks details about prerequisites or how the recommendation is formatted. For a tool with only 3 parameters, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by explaining that gender and year are used to compute kua, and industry indicates business type. No additional detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to recommend the most auspicious door-facing direction and wealth corner for a business based on owner's kua and business type. It distinguishes itself from sibling tools like cn402_fengshui_direction and cn402_fengshui_bed-direction by focusing on commercial feng shui.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (business/shop entrance feng shui) and lists required parameters. It implies usage by mentioning 'owner's kua' (derived from gender and year) and business type. However, it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the computation method but lacks detail on output format, potential costs beyond the price note, or any side effects. The price note about Base and USDC is present but is not core behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with multiple keywords and Chinese translations, which reduces clarity. It includes a price sentence that may not be essential. While informative for multilingual users, it could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 2 parameters and no output schema, the description explains the method and inputs competently but omits details on the output structure (e.g., list of lucky/unlucky directions). The price note adds context but not functional completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for both parameters (gender, year). The description adds meaning by linking them to 'birth year and gender' and the 'Eight Mansions method,' and introduces the concept of 'personal kua number direction' which helps understand the output semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Feng Shui direction analysis' and specifies 'Compute lucky and unlucky directions based on birth year and gender using Eight Mansions (Ba Zhai) method.' It differentiates from siblings like cn402_fengshui_24shan and cn402_fengshui_bagua-direction by focusing on personal kua number direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for personal direction luck analysis but does not explicitly state when or when not to use it, nor does it mention alternatives among the many fengshui siblings. The context signals show many similar tools, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions output components (lines, judgment, image, meaning) but lacks details on response format, cost implications ('Price: unknown'), or any side effects. A generative tool should disclose more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes redundant synonyms and multilingual keywords, which adds fluff. The core sentence ('Generate a random I Ching hexagram...') is clear but could be tighter. Some sentences are uncredited for the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description should fully specify what the agent receives. It mentions output components but not their exact structure or format. For a simple tool, it is mostly adequate but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so coverage is 100%. With 0 params, baseline is 4. Description adds no parameter info because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action ('Generate a random I Ching hexagram') and the resource (hexagram with lines, judgment, image, meaning). It distinguishes itself from siblings like iching_full or iching_coin by emphasizing random quick draw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for 'casual Yi Jing reading' and quick divination but does not explicitly state when to use this tool versus other iching siblings (e.g., iching_coin, iching_divine). No when-not or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It accurately states the tool returns three types of related hexagrams, which is sufficient for a straightforward read operation. It includes an irrelevant note about pricing, which does not add behavioral transparency. The description does not disclose any side effects or additional behaviors beyond the basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains unnecessary information such as 'Price: unknown on Base (auto-paid in USDC).' which is irrelevant for tool selection and invocation. The main functional description is clear, but the extra noise reduces conciseness. The structure is somewhat cluttered with Chinese characters and mixed content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately explains what it does. It names the three types of derived hexagrams, which is sufficient for an agent to understand the output. However, it does not specify the format or structure of the return value, but for a simple tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one required parameter 'number' described as 'Hexagram number 1-64'. The description does not add additional meaning beyond what the schema provides, but given high coverage, the baseline score of 3 is appropriate. The description could have added context about the range or required nature, but it is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: for a given hexagram number, it returns three types of related hexagrams (nuclear, inverse, opposite). It uses specific verbs ('return') and identifies the exact relations, distinguishing it from sibling I Ching tools like 'cn402_iching_hexagram' or 'cn402_iching_divine'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the derived relations of a hexagram, but it does not explicitly state when to use this tool versus alternatives like 'cn402_iching_hexagram' (which might give the full hexagram description) or 'cn402_iching_coin' (for coin divination). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the tool computes a chart for a given datetime, but lacks details on mutability, output format, or any side effects. The billing note adds marginal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes several synonyms and a billing note, which adds clutter. It is not poorly structured, but could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Tai Yi divination and no output schema, the description lacks detail on the result format or interpretation. It covers the input and purpose adequately, but falls short for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional datetime parameter, and the description reiterates it. The description does not add meaningful new detail beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a Tai Yi divination chart for a given datetime, using multiple names and specifying 'nine-palace cosmic oracle'. It effectively distinguishes from sibling divination tools like liuren and liuyao by naming Tai Yi specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'traditionally used for high-level forecasting' and 'national fate', implying a high-level scope, but does not explicitly state when to use this tool versus other divination methods or provide usage exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'authenticated decryption' and required inputs, but does not disclose error behavior (e.g., authentication failure), security considerations, or return value. Basic behavioral info is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, but the first line of redundant synonyms adds noise. The pricing line is not directly relevant. Overall, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should specify the output format (e.g., plaintext hex) and error conditions (e.g., authentication failure). It fails to do so, leaving the agent without key information for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds algorithm context (AES-256-GCM) and implies key/IV lengths, but does not significantly enhance meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'AES-256-GCM decrypt', lists synonyms, and specifies the operation (decrypt ciphertext given key, IV, authentication tag). It distinguishes from sibling x402node_crypto_aes-encrypt and other crypto tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions decryption but does not explicitly state when to use this tool, when not, or provide alternatives. It implies usage by naming the operation, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It notes a price ('Price: unknown on Base (auto-paid in USDC)'), which is a behavioral trait, but does not disclose whether the tool is read-only, destructive, or has side effects. It lacks essential safety and behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences. The first sentence lists synonyms, which aids discoverability but is slightly redundant. The second sentence concisely explains usage. Front-loaded keywords are effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generator tool with no output schema, the description covers purpose, parameters, and cost. It does not specify return format, but the output is inherently understood. Overall, it provides sufficient context for an agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 repeats information already in the schema (default values, max count, unit options) without adding new meaning or clarifying expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates Lorem ipsum placeholder text with customizable word, sentence, or paragraph counts. It lists many synonyms (e.g., 'placeholder text', 'dummy text') that reinforce the purpose and distinguish it from sibling tools, which are mostly Chinese culture or utility tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for design, mockups, and test content through synonyms, but does not provide explicit guidance on when to use or avoid this tool versus alternatives. No prerequisites or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It states the output is a human-readable breakdown of years, months, days, hours, minutes, seconds, but does not explain timezone handling, behavior for inverted dates, or what happens when `end` is omitted (though schema says default now). The price note is irrelevant to behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an irrelevant price line. The first sentence is a list of 12 synonyms, which is somewhat redundant and wastes space. The core purpose is front-loaded in the second sentence. The price line adds no value for tool selection or invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description provides a basic understanding but lacks details on return format structure, timezone handling, error cases, or limits. It mentions 'human-readable breakdown' but does not specify the exact fields or order, which would be helpful for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already provides parameter descriptions. The description adds no additional meaning beyond what is in the schema (e.g., format constraints, examples). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compute the duration between two timestamps with human-readable breakdown.' It also lists multiple alternative phrasings (duration calculator, time difference, etc.), but the core verb+resource is explicit and distinct from sibling tools like cn402_age_calc and x402node_time_format-relative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists many use cases (days between dates, hours between times, age calculator, etc.) implying when to use it, but it does not provide explicit guidance on when to prefer this tool over siblings or when not to use it. No exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but lacks behavioral disclosure. It does not mention output format, whether changes are reversible, authentication needs, or any side effects. The pricing note is irrelevant to behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a pricing note. The core action is front-loaded, and every word adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the niche topic and no output schema, the description is insufficient. It does not explain what 'pillars' are, how gender affects the result, or what the output looks like, leaving the agent with limited context to correctly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the two parameters (datetime, gender), so the description adds no additional meaning beyond what the schema already provides. No examples, constraints, or format details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes annual minor luck pillars for early life, distinguishing it from sibling tools like cn402_bazi_dayun (major luck) and cn402_bazi_full. It includes both English and Chinese terms, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: for childhood years before Da Yun starts. It implies the tool is for early life periods, but does not explicitly exclude usage for other ages or compare with alternatives beyond the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates real-time operation and hints at pricing ('Price: unknown on Base (auto-paid in USDC)'), adding some transparency beyond no annotations. However, it does not disclose rate limits, supported pair details, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with purpose. However, the pricing line is tangential and may confuse; it could be restructured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple forex tool, the description covers basic purpose and a usage hint. It lacks details on return format, supported pairs beyond CNY, and whether rates are delayed. Output schema absence is not compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, but the description introduces a query param (`?pair=USDCNY`) with examples, which is critical information beyond the schema. This adds significant value despite the inconsistency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name 'cn402_forex' and description 'Real-time foreign exchange rate' clearly indicate the tool provides forex rates. Mentioning support for major CNY pairs and majors further specifies scope. Sibling tools are for unrelated domains (bazi, fengshui, etc.), so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it specify prerequisites or exclusions. While no sibling tools offer forex, usage context is not addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Price: unknown on Base (auto-paid in USDC)', which indicates a cost and payment method, adding some behavioral context. However, it does not disclose authentication, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The functional sentence is clear and front-loaded. However, the description includes redundant synonyms ('I Ching line meaning / 爻辞 / individual line text / yao ci...') that add noise. The price note is useful but not essential. Overall, slightly verbose but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description only says 'Get the text and meaning' without specifying the format (e.g., plain text, JSON, fields included). It does not mention error handling or edge cases. For a tool with two params and no output schema, more detail on the return structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema (100% coverage). The description adds example line names (初九, 九二等) and clarifies that line 1 is the bottom, but this reinforces rather than adds significant new meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the text and meaning of a specific line (1-6) of a specific hexagram. It uses specific verbs and resources, and the mention of 'individual line text' distinguishes it from siblings like 'iching_hexagram' which likely gives whole hexagram info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool should be used when you need a specific line's meaning, but it does not explicitly state when to use it versus alternatives (e.g., iching_hexagram, iching_full) or provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the tool is auto-paid in USDC and identifies body type, but does not disclose error handling, latency, or output format. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Core purpose is front-loaded in a clear sentence. However, extensive keyword listing in multiple languages makes it longer than necessary. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool, the description covers purpose and input format minimally. Lacks output description, pricing details beyond 'unknown', and error conditions. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully (comma-separated numeric scores). The description adds context about body types but no additional syntax or format details beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies TCM body type from questionnaire answers and provides health recommendations. It lists the 9 body types and distinguishes itself from sibling tcm_ tools by focusing on constitution assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when questionnaire answers are available but does not explicitly state when to use this tool versus alternatives like cn402_tcm_bazi-health. No exclusion criteria or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, if it modifies state, or any side effects. It mentions a price note but lacks typical behavioral traits like authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with keywords. The price note is slightly extraneous but does not impede clarity. It efficiently conveys the tool's purpose without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple HMAC calculator, the description covers algorithm choices and use cases. However, it does not describe the output format (e.g., hex string). Given no output schema, this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description adds context about algorithm options and default, but does not significantly enhance meaning beyond the schema descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes HMAC using standard hash algorithms, and lists common use cases like API request signing, webhook signature, and JWT signature. It distinguishes itself from sibling tools which are unrelated (e.g., astrology, text manipulation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific use case contexts (signing, authentication), which helps the agent decide when to use this tool. However, it does not explicitly state when not to use it or provide alternatives, but given sibling tools are unrelated, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool generates cryptographically secure bytes and mentions 'Price: unknown on Base (auto-paid in USDC),' hinting at a paid API. However, it lacks explicit read-only/destructive hints, rate limits, or clarification on cost implications, leaving behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is cluttered with a redundant list of synonyms in the first line, followed by a functional sentence and an out-of-place price statement. This disorganized structure makes it less efficient and harder to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and use cases, but given no output schema and a paid model, it should specify return format (hex/base64 string) and clarify cost implications. The price mention is incomplete ('unknown'), leaving agents uncertain about invocation risks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with clear descriptions. The description adds value by repeating the encoding options (hex/base64) and length range in prose, but does not provide additional syntax or behavioral details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates cryptographically secure random bytes, listing multiple synonyms (CSPRNG, random token, nonce, etc.) that align with security contexts. This distinguishes it from sibling tools like x402node_math_random, which likely provides non-cryptographic randomness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions use cases such as random token, nonce, session key, and API secret, providing clear context for when to use the tool. However, it does not specify when not to use it or mention alternatives like x402node_generate_password for password generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'binary safe encoding' but does not disclose error handling, input limitations, or behavior for invalid data. An agent would need to infer standard base64 behavior, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with a list of synonyms and use cases, and includes an irrelevant price note. It could be more streamlined without losing meaning. It is functional but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and complete schema coverage, the description provides sufficient context for typical base64 operations. The inclusion of use cases aids agent selection, though behavioral details are lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described. The description adds no additional parameter-level information beyond listing use cases. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a Base64 encoder/decoder with URL-safe variant, listing specific use cases like JWT, data URI, API tokens, and email MIME. It is specific and distinguishes from siblings which are unrelated encoding/decoding tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (e.g., JWT manipulation, API token handling, data URI generation) but does not explicitly state when not to use or compare to alternatives. This provides useful guidance but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral information. It mentions format validation, MX record checking, and disposable email detection. However, it does not describe the output format, error handling, or rate limits. The pricing note is helpful but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat repetitive with multiple synonyms in a list, and includes a pricing line that may not be essential for tool selection. It could be more concise while retaining key information. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns (e.g., boolean, object with details). It does not, leaving a significant gap. Also missing error behavior or performance considerations. The addition of pricing is extra but not core to completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reiterates the 'optional MX check' aspect but does not add new semantic details beyond what the schema provides. It offers context but no deeper parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates email addresses, lists multiple synonyms (format check, RFC 5322, etc.), and explicitly mentions optional MX record checking and disposable email detection. It differentiates from sibling validation tools by focusing solely on email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies use cases: 'signup pipelines, lead validation, bot filtering.' This gives context for when to use it. However, it does not explicitly state when not to use it or compare to other sibling validation tools, so some guidance is implicit but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only describes the function (validation and parsing) but does not disclose behaviors like error handling, rate limits, permissions, or side effects. Pricing is noted but not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a long list of synonyms that adds redundancy. The core information (validation and parsing) is present, but the list is verbose. The price note is extraneous. It is front-loaded but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description explains what the tool returns (components). This is sufficient for an agent to understand the output. It lacks details on output format or error scenarios, but for a simple validator, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the single 'url' parameter. The tool description adds value by listing the parsed output components (protocol, hostname, etc.), which goes beyond the schema and helps the agent understand the return data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool validates URL syntax and parses it into components (protocol, hostname, etc.). It lists many synonyms but the core function is unmistakable. Among siblings, it is the only URL syntax validator, distinguishing it from other URL tools like url_check-status or url_dns-lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for URL validation and parsing, but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or comparisons are provided, leaving the agent to infer application based on the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks any behavioral details such as read-only nature, security considerations, or side effects. Only mentions price, which is not a behavioral trait. For a tool with no annotations, transparency is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with key purpose and components. Includes Chinese translation and price info which, while not strictly functional, does not detract. Slightly verbose but well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and no output schema, description adequately lists all output components. Agent can understand what the tool returns without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema fully describes the single parameter (hexagram number 1-64). Description adds no extra meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a complete I Ching analysis with exhaustive list of components (hexagram, line texts, nuclear/inverse/opposite hexagrams, trigrams, judgment, image). Distinguishes from sibling tools like cn402_iching_hexagram by emphasizing 'full' and 'single-call'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when a comprehensive, all-in-one reading is needed. Does not explicitly exclude specific use cases or name alternatives, but the context of 'complete' vs smaller tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a pricing note ('auto-paid in USDC'), which is a behavioral trait. However, it lacks details on error handling, permissions, or side effects beyond computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with many spaced terms and abbreviations, which is messy. It includes a pricing sentence at the end that could be separated. Adequate but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex divination tool, the description explains the chart type but does not detail the output structure (e.g., what fields are returned). No output schema exists, so more completeness would be beneficial. It's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'datetime' is fully described in the schema with format and optionality. The description adds explicit format 'YYYY-MM-DD HH:MM' and default behavior, providing meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it computes a Qi Men Dun Jia chart (9-palace with stars/doors/gods) for a given datetime, used for strategic decision making. The purpose is clear and distinct from sibling tools like cn402_zhanbu_liuren or cn402_zhanbu_liuyao due to the specific named technique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'strategic decision making' as a use case, implying when to use this divination method, but lacks explicit guidance on when to prefer this over siblings or any exclusions. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does mention 'Price: unknown on Base (auto-paid in USDC)', hinting at a cost, but fails to state whether the tool is read-only, idempotent, or has any side effects. This is insufficient for a tool that may incur cost.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, with two paragraphs. The first paragraph lists many synonymous terms which, while redundant, ensures cultural relevance. The second paragraph contains the functional core and price note. Could be more concise but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is fairly complete: it states the return values include animal, element, and sexagenary name. It also adds pricing context. However, it does not specify the format or structure of the response, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'year', which is described as 'Year YYYY (optional, default current year)'. The description reinforces this with 'for any year' but adds no additional semantic detail beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get the Chinese zodiac animal for any year, including element and 60-year sexagenary name', lists all 12 animals in English and Chinese, and includes terms like '生肖' and 'shengxiao', making the purpose extremely clear and distinct from sibling tools like cn402_fengshui_*, cn402_iching_*, cn402_tcm_*, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the user when to use this tool: when they need the Chinese zodiac animal, element, or sexagenary name for a year. However, it does not explicitly state when not to use it or provide alternatives. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It states the tool does not include holiday data, which is important. However, it does not mention any other behavioral traits (e.g., error handling, edge cases).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is redundant ('business days calculator / working days between dates / weekdays counter') and includes an irrelevant pricing line. It could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the core function and a key limitation. However, it does not specify the output format (e.g., returns a number), which would help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add new meaning beyond what the schema provides. It repeats the date format but with no extra constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calculates business days between dates, excluding weekends, with multiple synonyms reinforcing the purpose. It distinguishes itself from sibling time tools like time_duration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that it only excludes weekends (no holidays), which hints at limitations but does not explicitly mention when to use alternatives. It provides clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It mentions 'Price: unknown on Base (auto-paid in USDC),' indicating potential cost. However, it lacks other behavioral details such as authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with redundant synonyms and Chinese translations (e.g., 'I Ching 64 hexagrams full list / all Yijing gua / hexagram catalog / King Wen sequence / 易经六十四卦目录 / 64 trigrams pairs'). This could be streamlined to a single clear sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description briefly mentions what is returned (name, number, sequence). It is minimally adequate but could elaborate on the output structure (e.g., array of objects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty with 100% coverage. The description adds no parameter info, but the baseline for zero parameters is 4, as no further clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns all 64 I Ching hexagrams with name, number, and traditional sequence. It specifies the resource (full list) and distinguishes from sibling tools like iching_hexagram or iching_divine that focus on specific hexagrams or divination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via terms like 'full list' and 'catalog,' contrasting with more specific iching tools. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Includes price note about auto-payment, which is helpful behavioral context beyond function. Missing auth or rate limit details, but tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description includes some redundancy (organ associations repeated in Chinese) and a separate price note, making it less concise than ideal. Could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description adequately indicates return contents (diet, lifestyle, key organ). Simple input (one optional date) means description covers core usage well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'date' fully described in schema with format and optional nature. Description adds no extra semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool provides TCM seasonal health advice linking seasons to organs. Includes English and Chinese terms for clarity. Distinct from sibling TCM tools like constitution or bazi-health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for obtaining seasonal health advice via optional date parameter but does not explicitly differentiate from other TCM tools or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the return content (name, zodiac animal, elemental association) and notes the price ('unknown on Base'), but lacks details on behavior for invalid inputs, defaults, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences that clearly state purpose and output. The price note is slightly extraneous but does not detract from clarity. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, high schema coverage, and no output schema, the description adequately explains the tool's return values. It lacks detail on edge cases or error responses, but it is sufficient for a simple conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The description adds value by explaining that the output includes shichen name, zodiac animal, and elemental association, though it does not elaborate on the parameter format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Convert') and clearly identifies the resource ('time of day' to 'Chinese shichen'), listing the output components (name, zodiac animal, elemental association). It distinguishes from sibling tools focused on other Chinese time or astrology aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools (e.g., cn402_bazi_*, cn402_lunar, cn402_solar), an explicit note about when to choose this shichen converter would be helpful. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It lists the output components (lunar date, gan-zhi, etc.) but does not disclose behavioral traits such as read-only nature, data freshness, or potential limitations. The mention of pricing is unusual but adds some context. Overall, adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with repetitions of 'today' and includes an extraneous pricing line. It could be more concise and front-loaded. The key information is present but not tightly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as an aggregator and the absence of an output schema, the description provides a good list of included elements (yi/ji, festivals, solar term, etc.). However, it does not detail the return format or data types, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (single optional date parameter). The description repeats that the date is optional and defaults to today, which is already in the schema. No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive summary of Chinese calendar context for today or any date, listing specific components (lunar date, gan-zhi, zodiac, yi/ji, festivals, solar term, etc.). The phrase 'one-call snapshot' distinguishes it from more specialized sibling tools like cn402_festival_today or cn402_lunar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool for a broad overview via 'one-call snapshot', but it does not explicitly state when to use alternatives or when not to use this tool. Sibling tools are numerous and more specific, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states that the tool returns matches, capture groups, and indices, and mentions it uses JavaScript regex. However, it does not disclose what happens on invalid patterns, whether it is read-only, or any side effects. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a long list of synonyms that is redundant. While the core message is clear, the initial clutter reduces conciseness. The rest is relatively compact. Could be trimmed to fewer words without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema, no annotations), the description covers purpose, output type, and example use cases. It is nearly complete, but lacks explicit mention of error handling or safety guarantees, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for flags, pattern, and text. The description adds nothing beyond the schema for parameter semantics; it only restates the tool's general function. Hence baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool tests regex patterns against text and returns all matches with capture groups and indices. It also lists multiple synonyms and use cases, making the purpose unmistakable and distinguishing it from all sibling tools which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Test any regex pattern against text' and provides use cases like pattern extraction and text validation. While it does not explicitly contrast with alternatives, the sibling tools are all different domains (Chinese astrology, crypto, etc.), so usage context is clear. A slight deduction for lacking explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the simulation process (6 throws, original and transformed hexagrams) and notes the payment mechanism (auto-paid in USDC). It does not mention side effects or authentication, but for a divination tool this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with aliases, which adds some noise, but the core functional sentence is concise. The price info is useful but could be separated. Overall, it is clear and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional param and no output schema, the description adequately explains the output (original + transformed hexagrams) and the process (6 throws). It lacks detail on output structure but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one optional parameter 'question' is fully described in schema). The description adds no additional semantics beyond what the schema provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool simulates the three-coin Yi Jing divination, producing original and transformed hexagrams with changing lines. It uses specific verbs and includes multiple aliases, distinguishing it from other I Ching methods among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for three-coin divination but does not explicitly guide when to use this tool versus alternative I Ching methods (e.g., cn402_iching_meihua, cn402_iching_random). No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool is a read operation (get) and includes pricing info, adding value beyond simple verb. No side effects or auth details are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus pricing line. Front-loaded with purpose, no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides purpose, example, and use cases but lacks details on return format or error handling. Without output schema, the description could be more specific about the returned data structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, but description implies package and version as query parameters. This adds practical guidance but creates inconsistency with the empty schema, reducing reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves NPM package dependency tree with counts and version constraints, using a sample query. It distinguishes from siblings as no other tool covers npm dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Built for dependency audit and bundle bloat analysis', providing context but no explicit guidance on when not to use or alternatives. With no sibling npm tools, usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It discloses beta status, active verification, and warns against production reliance. However, it does not state whether the operation is read-only, whether authentication is required, or mention rate limits. The pricing note adds some context but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with three main sentences: a warning, a purpose statement, and a use-case hint. It front-loads the critical beta warning. Some examples (campaign names) are slightly extraneous but not overly verbose. Could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clearly describe what the tool returns. It mentions listing active campaigns but does not specify the format or whether it returns IOCs per campaign, campaign metadata, or just names. The lack of output detail leaves an agent guessing about what will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline is 4. The description does not need to add parameter details, and it appropriately uses no param descriptions. The output is not clarified, but that is not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active supply chain attack campaigns for npm, PyPI, and Composer. It uses the verb 'list' and distinguishes from sibling tools (e.g., x402node_supply_campaign for specific campaigns, x402node_supply_ioc-scan for scanning). The examples of campaigns provide concrete context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a clear use case ('For coding agents pre-install audit') and warns about beta status and not relying on matches in production. However, it does not explicitly exclude alternatives or provide conditions when not to use this tool, missing full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly marks the tool as BETA, includes a verification date, and warns against production use. It explains the scan action, matching against campaigns, and the output as a risk score. Missing details on error behavior or rate limits are acceptable for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs efficiently convey all key information: beta warning, action, accepted files, output, and pricing. Every sentence is meaningful and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return (risk score 0-100) and the types of input files. It covers key context like beta status and pricing. However, it could elaborate on what 'active campaigns' refers to or the scoring methodology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds value by specifying the expected input (file uploads of specific types). This compensates for the lack of parameters and clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'Lockfile supply chain scan' on specific file types and returns a risk score. It differentiates from siblings like x402node_supply_ioc-list through the name and scanning action, though explicit contrast is lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists accepted file formats (package-lock.json, etc.) and warns not to rely on matches for production. However, it does not provide when to use this tool versus siblings like x402node_supply_ioc-list or x402node_supply_campaign, nor does it state prerequisites or error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses algorithm (Luhn), output (validity, card type, masked number), and non-payment nature. No annotations provided, so description carries full burden and does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose with redundant synonym list ('validator / Luhn check / verification / detector') and an irrelevant pricing note. Could be trimmed to single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool with no output schema, description covers purpose, return values, and boundary (no payment). Lacks only minor details like exact return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter description. Tool description repeats the parameter but adds no new semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool validates credit card numbers using Luhn algorithm and identifies card brand. It distinguishes itself from sibling validation tools (email, IP, phone, URL) by specific resource and verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'No payment processing, validation only', setting clear boundary. Among siblings, it's obvious for credit card validation, but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral detail: it performs a full divination workflow, uses the three-coin method, and returns hexagram, changing lines, and interpretation. The price note hints at a payment requirement, adding transparency. However, it does not disclose potential state changes or auth needs beyond payment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, including useful multi-language text and workflow details. It front-loads the main purpose but includes extra information about price and method that could be more integrated. Still, it is not overly verbose and earns its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description sufficiently explains the return value (hexagram, changing lines, interpretation) and method (three-coin). It covers the essential behavioral aspects needed for an agent to understand what the tool provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description for 'question'. The tool description reinforces that the parameter is the user's question but adds no new semantic details like format or length constraints. Baseline 3 is appropriate as schema already covers the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for I Ching divination by question, detailing the workflow: takes a question, casts hexagram via three-coin method, returns hexagram, changing lines, and interpretation. This distinguishes it from sibling tools like cn402_iching_hexagram or cn402_iching_coin by emphasizing the question-driven full divination process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for specific questions ('by question') but does not explicitly state when to use this tool over alternatives like cn402_iching_full or cn402_iching_random. It mentions price and auto-payment but lacks clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses that the tool returns exact UTC timestamps and mentions the price model (auto-paid in USDC). It does not mention any destructive side effects, but the tool is clearly read-only, and the description adds useful context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose due to the list of keywords and synonyms, but the core information is front-loaded. The structure is clear: a list of related terms, a concise statement of functionality, use case, and pricing. Could be tightened by removing redundant keywords.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter list and no output schema, the description adequately explains what the tool returns (all 24 solar terms with timestamps). It also includes price info. While the exact output format is not detailed, it is sufficient for a retrieval tool and fits the context of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'year' with 100% description coverage (format YYYY, default current year). The description only repeats that it works 'for a given year' without adding new details beyond the schema, so no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns all 24 Chinese solar terms for a given year with exact UTC timestamps, using multiple keywords like '24 Chinese solar terms', 'jieqi', etc. It distinguishes itself from sibling tools like cn402_solar and cn402_lunar by explicitly focusing on the 24 solar terms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the intended use cases: 'For AI agents handling Chinese seasonal queries, agricultural planning, traditional culture content.' This provides clear context for when to use the tool, but it does not explicitly contrast with sibling tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content (original+transformed hexagram, changing lines, interpretation) and mentions the payment aspect ('Price: unknown on Base'). However, it does not describe idempotency, error behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with all necessary information up front. It could be slightly more concise by reducing the listing of alternative names, but overall it efficiently conveys the tool's function and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple parameters and no output schema. The description comprehensively explains the return value (original+transformed hexagram, changing lines, interpretation) and includes the price note, making it complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for both optional parameters. The description repeats that question and date are optional but adds no further semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Six Lines divination / Liu Yao' with specific verb 'Cast' and resource 'Six-Line divination'. Among siblings with other iching methods, this one clearly specializes in the Liu Yao method, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the tool performs Six Lines divination with optional question and date, implying use for that method. However, no explicit guidance is given on when to use this versus alternative divination tools (e.g., iching_coin, iching_meihua) 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It notes 'cryptographically random' for v4 and 'time-sortable' for v7, and batch up to 100. However, it lacks details on potential side effects or performance characteristics, though it is a simple generator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly verbose with a line of keywords separated by slashes, then a sentence, then use cases, then a note about pricing. It could be more structured and concise; every sentence is not earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generator with no output schema, the description covers the main functionalities: versions, batch, use cases, and pricing. It is complete enough for an AI agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value beyond the schema by explaining 'cryptographically random' and 'time-sortable' for versions, and clarifying batch generation (1-100) even though schema repeats it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'UUID generator' and specifies UUIDv4 and UUIDv7 with batch generation. It distinguishes from sibling tools (e.g., password generator, hash) by focusing on UUIDs and unique identifier use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'For AI agents, distributed systems, database row IDs, request tracking.' It does not mention when not to use or alternatives, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates that the tool returns specific meridian data and mentions a price (suggesting cost), but does not clarify if the operation is read-only, any rate limits, or effects. The price note adds some transparency but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat keyword-heavy with Chinese characters and lists, but the key sentence 'Look up the 12 main TCM meridians...' is clear and front-loaded. The price line is separate. Could be more streamlined, but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description covers the main outputs and usage. It lacks details on exact name formats or error cases, but is sufficient for a basic lookup tool. The price mention adds contextual completeness about cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'name' with description). The description adds value by explaining the default behavior (returns all meridians if name omitted) and detailing what fields are returned (element, organ system, flow time, key acupoints), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for looking up TCM meridians with specific attributes (element, organ system, flow time, key acupoints). It uses multiple related terms and explicitly distinguishes its domain from sibling tools like tcm_herb or tcm_constitution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for meridian-related queries and mentions the optional name parameter, but does not explicitly compare with siblings or state when not to use it. The context is clear enough for most agents, but lacks explicit guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes format validation but does not clarify if it performs live verification or is purely syntactic. The price mention adds little to behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with key purpose phrases. The price information is extraneous but does not significantly detract. It could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is adequate. It defines the validation scope and format, though it does not mention return structure or errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter description is basic. The tool description adds format details (E.164, + optional) that enhance understanding of the expected input beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates phone numbers against E.164 format, with specific format details. It distinguishes from sibling validation tools by explicitly naming phone validation and providing format rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is clear about what it validates (phone numbers) but does not provide explicit when-to-use or when-not-to-use guidance. However, the sibling tools are distinctly named (email, IP, URL, creditcard), making selection straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly describes the conversion behavior and direction. However, it does not disclose non-obvious traits like side effects, but given it's a conversion tool, the behavior is straightforward. Price mention is not behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is verbose with redundant synonyms separated by slashes. The core message is clear but could be more concise. Price information is marginally relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter conversion tool, the description provides adequate context about what the tool does and the input expectations. No output schema, but the output is self-evident. Missing details about encoding or error handling are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes parameter with 100% coverage. Description adds context about regional variants (Taiwan/HK vs mainland) and synonyms, which helps clarify the expected input format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it converts Traditional Chinese (Taiwan/HK) to Simplified Chinese (mainland China). Multiple synonyms reinforce the purpose. Distinguishes from sibling cn402_hanzi_s2t which does the reverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when you need T2S conversion. No explicit alternatives mentioned, but the sibling tool name makes the alternative obvious. However, lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It clearly states the signature is not verified, which is a critical behavioral trait. It could mention that it has no side effects, but this is adequate for a read-only decode operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, though the list of synonyms is somewhat redundant. It efficiently conveys the core purpose and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 no output schema, the description fully covers the function, behavior, use cases, and pricing, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the token parameter with 100% coverage, so the description adds minimal extra semantics beyond restating the purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses multiple clear synonyms and explicitly states the tool decodes JWT header and payload, distinguishing it from any sibling tools by clearly defining its non-verification scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides specific use cases like OAuth flow debug and API token inspection, making the context clear, though it does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the tool returns IOCs, compromised versions, remediation, and mentions pricing. However, it does not state if the operation is read-only, whether permissions are required, or any side effects. It provides some behavioral context but not full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences. The first sentence covers purpose and content, the second adds context, and the third notes pricing. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the key aspects: what it does, what it returns (IOCs, etc.), and where to get the ID. It could be improved by describing the return structure, but it is sufficiently complete for an agent to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the ID format (e.g., 'mini-shai-hulud-tanstack-2026-05') and sourcing from /supply/ioc-list, which aids in correct parameter usage beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Supply chain campaign detail by id' which clearly states the action (detail) and resource (campaign). It lists specific contents (IOCs, compromised versions, remediation) and context (incident response). This distinguishes it from siblings like x402node_supply_ioc-list (list) and x402node_supply_ioc-scan (scan).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates 'For incident response' providing clear context for when to use. However, it does not explicitly mention when not to use or name alternative tools, but the sibling tools are distinct enough that usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![x402-mcp MCP server](https://glama.ai/mcp/servers/x402node/x402-mcp/badges/card.svg)](https://glama.ai/mcp/servers/x402node/x402-mcp)

Score Badge

Copy to your README.md:

[![x402-mcp MCP server](https://glama.ai/mcp/servers/x402node/x402-mcp/badges/score.svg)](https://glama.ai/mcp/servers/x402node/x402-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/x402node/x402-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server