asktian

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 mentions returning top 3 best windows and windows to avoid, but does not disclose side effects, authorization needs, error handling (e.g., invalid birthdate), or any limitations. Marketing language ('most useful tool') adds no behavioral value.

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

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

The description is two sentences, with purpose stated first. The final sentence ('most useful tool...') is slightly promotional but does not detract from clarity. It could be more concise by trimming that sentence, but 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.

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

The description explains the return format (top 3 best windows and windows to avoid) and mentions action types and range. However, it lacks details about how 'auspicious' is determined, timezone handling, or potential error cases. Given the absence of an output schema and no behavioral annotations, these gaps reduce completeness.

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

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

Schema coverage is 100% with each parameter described. The description adds value beyond the schema by advising to 'pick the closest match; use 'generic' if unsure' for the action parameter. This additional guidance merits a score above the baseline of 3.

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

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

The description clearly states it finds auspicious time windows for a specific action, with concrete examples like asking when to do something or move a meeting. It distinguishes itself from sibling tools (e.g., asktian_today_energy) by focusing on scheduling advice rather than daily readings or compatibility.

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

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

The description explicitly lists when to use the tool: 'when the user asks 'when should I do X', 'should I move this meeting', etc.' This provides clear context. It does not mention when not to use it or alternatives, but the sibling tools cover different domains, so 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.

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

No annotations provided; description carries full burden. Discloses key behavioral trait: numeric score is hidden if <60, with design reasoning. Also mentions methodology (八字 pairing, 5-element generation/clash). No contradictions.

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

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

Two sentences, front-loaded with purpose, no redundant details. Every sentence adds value: first states action and methodology, second states output format and behavioral nuance.

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

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

Covers output format, hidden score behavior, and general purpose. However, does not explain the meaning of the 'dimension' enum values or the range of qualitative labels beyond an example. Given no output schema, slightly more detail would be ideal.

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

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

Schema description coverage is 100%; all parameters have descriptions. The tool description adds no additional parameter-level meaning beyond what schema provides, so baseline score of 3 applies.

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

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

Description clearly states the tool computes fate compatibility using Chinese metaphysics (八字, 5-element). It specifies output format: qualitative label first, numeric score second. No sibling tool overlaps, so purpose is distinct.

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

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

Explicitly indicates usefulness when user asks about compatibility, fit, or 'will this person and I work'. No explicit when-not or alternatives, but sibling tools cover different domains (e.g., market, name analysis), so context is adequate.

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

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

No annotations provided, so description must carry behavioral info. It discloses input parameters and what is returned, but does not mention if it is read-only or any side effects. Since it's a prediction tool, the behavior is implied but not explicitly stated beyond the return content.

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

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

Three sentences, front-loaded with purpose and details, no redundancy. Every sentence is informative and earns its place.

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

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

Given no output schema, the description adequately lists return elements (archetype, energy, colors, direction, hours, advice, caution). All three parameters are described. However, the temporal scope ('today's') is clear from name and description, but could be explicitly reinforced.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the gender parameter ('some traditions weigh gender') and birth_hour default ('defaults to noon'), which aids correct parameter specification beyond the schema.

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

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

The description clearly states it provides a personalized Chinese metaphysics reading for today, including specific elements like archetype, energy, colors, direction, hours, advice, and caution. This distinguishes it from siblings like asktian_best_time_for_action or asktian_compatibility.

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

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

Explicit instructions: 'Use this when the user asks how today will be for them, what colors to wear, where to face their desk, or for general daily guidance.' This provides clear context and implicitly tells when not to use it (e.g., for best action times or compatibility).

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool is for entertainment, not financial advice, that it uses reasoning from resolution date energy, and that it returns a mandatory disclaimer. It describes the output as a 'lean (yes/no/neutral), a confidence, the 五行 reasoning, and a mandatory disclaimer'. No contradictions with annotations.

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

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

The description is well-structured and front-loaded with purpose. Every sentence adds value, but it is slightly verbose with repeated emphasis on entertainment nature. A minor trim could improve conciseness.

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

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

Given the tool's complexity (Chinese metaphysics on prediction markets) and no output schema, the description fully covers what the tool does, when to use it, what it returns (lean, confidence, reasoning, disclaimer), and its non-advisory nature. It is complete for the context.

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

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

Schema description coverage is 100%, and the description adds context beyond the schema. For example, it explains that 'subject_birthdate' is optional and 'adds their bazi element to the read' for person-centric markets. The 'resolve_date' is explained as optional with a default. This adds meaningful semantics.

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

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

The description clearly states the tool's purpose: 'Get a Chinese-metaphysics signal on a binary prediction-market question'. It specifies the type of questions (Polymarket/Kalshi style yes/no outcomes) and distinguishes itself from sibling tools by focusing on market prediction, not actions, compatibility, or daily readings.

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

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

The description explicitly tells when to use the tool: 'Use when a user — or a trading agent — wants an UNCORRELATED, for-fun read on a market'. It provides example questions and includes explicit guidance: 'Always present it as a novelty signal, never as a recommendation to place a bet.'

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

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

No annotations provided, so the description carries the full burden. It states the output is a 'one-line vibe + dominant element guess' and implies it's quick and non-invasive. However, it doesn't disclose methodology, limitations, or whether it's based on cultural systems (e.g., Chinese numerology).

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

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

Two sentences front-load purpose and usage. Every sentence adds value. No redundant or filler content.

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

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

For a simple tool with 2 parameters, no output schema, and no annotations, the description covers purpose, usage scenarios, and output format. It is adequate, though additional context on cultural basis or limitations would improve completeness.

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

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

Schema coverage is 100%; both parameters have descriptions. The description adds that 'name' can be in any script, which is already in the schema, and does not add new meaning beyond what the schema provides. Baseline 3 is appropriate.

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

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

Description clearly states it provides a 'quick energetic profile of a name' and lists specific use cases (baby names, company names). It differentiates from sibling tools by focusing on name analysis. However, 'energetic profile' is somewhat vague and could be more specific about what is returned (e.g., elements, traits).

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

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

The description gives explicit scenarios for use (when user asks about someone's name, baby name, etc.) and notes it's useful when no birthdate is available. It does not explicitly state when not to use or mention alternatives among siblings, but the context is clear.

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

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

No annotations are provided, so the description carries the full burden. It only describes the output but does not disclose behavioral traits like read-only nature, side effects, permissions, or data freshness. For a safety-critical evaluation, this 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.

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

Two sentences, front-loaded with the core purpose and usage context. No redundant words; every sentence adds value.

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

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

The description covers the main purpose and use cases but omits output format details (no output schema), data source (traditional Chinese calendar), and limitations. Adequate for a simple tool but with noticeable gaps.

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

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

The description focuses on 'today' but the optional 'date' parameter can specify any date, creating potential confusion. It adds no extra meaning beyond the schema's parameter description, which already covers the format and default.

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

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

The description clearly states the verb 'Get', the resource 'today's GENERAL energy', and the specific output (stem+branch and dominant 5-element). It distinguishes from sibling tools by noting no person needed, making it unique among the listed tools like asktian_best_time_for_action or asktian_compatibility.

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

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

It provides explicit use cases such as 'what kind of day is it' and when to add cosmic context without needing birthdate. It implicitly excludes personalized readings, but lacks an explicit 'when not to use' statement.

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