astroway-mcp

Official

by astroway

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.5.0
Disambiguation2/5
With 633 tools, there is substantial overlap among similar functions across different traditions (e.g., multiple dasha systems, multiple compatibility tools). While descriptions are detailed, the sheer volume makes it difficult for an agent to distinguish between many closely related tools.
Naming Consistency4/5
Most tools follow a consistent snake_case pattern with domain prefixes (e.g., vedic_, bazi_, tarot_). Some exceptions like 'acg' and 'ai_chat' break the pattern, but overall the naming is systematic and hierarchical.
Tool Count1/5
633 tools is far too many for any single server. This overwhelms the agent's ability to navigate and select appropriate tools. The scope should be significantly narrowed.
Completeness2/5
The server is broad but shallow. Many areas have only a few endpoints (e.g., Western predictive techniques are sparse), while others are over-represented. Several tools are deprecated or marked as MVP, leaving gaps in coverage.
Average 3.1/5 across 577 of 633 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds no additional 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief, but under-specified rather than concise. Lacks structure and fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is one of many geomancy figures, the description is severely incomplete. It does not explain what the tool returns or how it fits into the system.
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 coverage is 100% with one parameter 'body'. Description points to an example request body but that example is empty, adding minimal clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Crowd, gathering, public' and a group label, but lacks an action verb or explicit statement of what the tool does. It does not differentiate from sibling geomancy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 sibling list is extensive with no distinguishing 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds no behavioral context beyond annotations, missing details like input requirements or output format.
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 very short but under-specified. Conciseness is achieved at the cost of completeness, providing insufficient information for an agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and many siblings, the description fails to provide essential context such as input type (e.g., a palm image), output structure, or how the marriage line is interpreted. No output schema exists to compensate.
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 single 'body' parameter is described in the schema as 'Raw JSON body — see the example in the tool description for required fields'. The description only provides an empty example '{}', which adds minimal semantic insight and may mislead about required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Significant partnerships' is vague and lacks a verb or specific action. It does not state what the tool does (e.g., 'Analyze the marriage line'), nor does it distinguish from sibling tools like palmistry_heart_line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other palmistry tools. No mention of prerequisites or context for 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description does not need to repeat those. However, it adds no other behavioral context, and the example request body is a placeholder. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but the example request body is a placeholder and adds no value. The structure is not front-loaded with actionable information; the group line is helpful but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and many sibling tools, the description is grossly inadequate. It fails to cover return values, parameter interactions, or use cases.
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?
Schema description coverage is 0%, meaning no parameters are explained in the description. The description does not clarify the meaning or usage of any of the 12 parameters, including required ones like date and time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides only the title and a brief mention of 'Lefeldt-Brummund 22.5° subdivisions' without a verb or explicit action. It does not clearly state what the tool does or how it differs from siblings like cosmobiology_cosmogram or cosmobiology_midpoint_pictures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 any context for appropriate usage scenarios 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and idempotent. The description adds no behavioral detail beyond the cryptic meaning of 'unfinished karma.' It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines), but this is under-specification rather than conciseness. It lacks structure and fails to communicate essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and a cryptic description, the tool is severely under-documented. The description does not cover inputs, outputs, or behavior, making it inadequate for correct selection and invocation.
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?
With 11 parameters and 0% schema description coverage, the description fails to explain any parameter. The example request body uses a placeholder and adds no meaning to the properties. The description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Planets squaring nodal axis = unfinished karma,' which hints at the tool's purpose but does not clearly specify that it identifies or calculates such planets. It lacks a clear verb and resource, making it ambiguous. The group label 'Evolutionary Astrology' provides context but does not differentiate this tool from siblings like evolutionary_nodal_axis_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its siblings or alternatives. There are no exclusions, prerequisites, or contextual hints. The description is entirely silent on 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds minimal behavioral context beyond the cryptic phrase, not clarifying side effects or output format. With annotations, the bar is lower, but the description does not significantly enhance 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 very short but includes an unhelpful example and a group marker. It front-loads minimal information but lacks structure and substantive content, making it inefficient for decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a cryptic two-line description, the tool is severely underspecified. An agent cannot determine what the tool computes, what to expect as output, or how to use the parameters correctly.
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?
Schema description coverage is 0%, and the description provides no clarification on parameters. The example request body references a '...chart' field not in the schema, and no parameter purpose or format is explained. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'JWG's 4-type by Pluto house quadrant' and places it in 'Evolutionary Astrology', but does not explain what the tool actually computes or returns. The purpose is vague and does not clearly differentiate from sibling tools like evolutionary_nodal_axis_detail or evolutionary_pluto_natal_condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnly and idempotent hints, but the description adds no further behavioral context (e.g., what the 'axis' means, if it returns text or chart). It does not explain the output or side effects beyond what annotations already indicate.
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 extremely brief (two short lines), but the content is too vague to be useful. It is under-specified, not concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema), the description provides almost no useful context. It does not explain return format, required versus optional parameters, or how the tool fits among siblings.
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?
With 0% schema coverage and 11 parameters, the description fails to explain any parameter meaning. It only shows a trivial example body, adding no semantic value. The agent cannot determine how to fill parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Spirit-Fortune axis as primary chart spine') without a verb indicating what the tool does. It does not specify whether it calculates, interprets, or renders something. This fails to clearly state the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the many other Hellenistic tools or any alternatives. Missing explicit context for usage or exclusions.
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?
Annotations already provide readOnlyHint and idempotentHint. Description adds no behavioral traits beyond the example request body, which is unhelpful and does not match the schema. No mention of output, side effects, or validation.
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?
Extremely short but lacks essential information. The example is misleading and does not align with the schema. Under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 2 required, no output schema, and many sibling tools, the description is severely incomplete. It fails to explain what the tool returns, how parameters affect results, or how it fits among alternatives.
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?
Schema description coverage is 0% and the description fails to explain any of the 11 parameters. The example request body uses 'chart' which is not a parameter, offering no meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description restates the title 'Duodecima' and adds '2.5° micro-sign per planet', but lacks a verb or action indicating what the tool does (e.g., computes, returns). It does not clearly distinguish from similar sibling tools like hellenistic_greenbaum_dodekatemoria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With many Hellenistic Greenbaum siblings, the description provides no 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe operation. The description adds no further behavioral context such as return behavior 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?
While brief (2 sentences), it is too sparse to be useful. The example is not informative and critical information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no parameter descriptions, the description fails to make the tool usable. It is severely incomplete.
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?
Schema description coverage is 0%, so the description must explain parameters. It only gives a vague example request body without clarifying any of the 11 parameters' meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Seven primary Lots per Hand' but does not clearly state what the tool does beyond restating the name. It lacks a verb and does not differentiate from many sibling Hellenistic hand tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. No context for when it is appropriate or not.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's lack of behavioral detail is partially compensated. However, the description adds no context about what the tool does beyond a vague pattern label, missing an opportunity to clarify behavioral traits like return format 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 extremely concise but not effectively structured. It contains a single vague sentence and a group label, plus an example that offers no real information. The brevity wastes the opportunity to convey essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a minimal description, the tool is severely underdocumented. An AI agent cannot accurately determine required inputs or expected outputs. The description offers no context for the complex astrological computation implied by the name.
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?
Schema description coverage is 0%, so the description must compensate for parameter meanings. It fails entirely: the only example shows an empty chart placeholder. None of the 11 parameters (e.g., date, time, houseSystem, zodiacType) are explained, leaving the agent guessing their role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Water-house trauma patterns' provides a vague indication of the tool's domain but lacks a specific verb or resource. It does not clearly state what the tool computes or returns, making it difficult for an AI agent to understand its exact purpose. The title 'Arroyo — Water Houses Trauma' hints at a psychological astrological interpretation but is insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool vs. alternatives, nor does it mention any prerequisites or contraindications. With many sibling tools like 'modern_arroyo_cycle_of_becoming', an agent has no basis 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond these—no mention of response format, side effects, or constraints. It adds minimal value.
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 extremely short (two lines plus group and example). While concise, it omits essential information, making it under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values. It provides none. Geomancy interpretation requires context about the figure's meaning or application, which is entirely absent.
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 coverage is 100% but the parameter 'body' is described generically. The example request body '{}' is empty and fails to specify required fields or structure. The description does not enhance the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ('Union, meeting, partnership.') merely translates the title 'Coniunctio — Conjunction' without specifying what the tool does. It does not state any verb or action, making it a tautology.
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 geomancy figure tool versus its many siblings (e.g., geomancy_acquisitio, geomancy_albus). There is no context for appropriate use cases or exclusions.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is clearly safe and deterministic. The description adds no behavioral context beyond that, failing to explain what the tool computes or returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. Important details are missing, making it ineffective. Every sentence should add value, but here only a vague phrase and an incomplete example are given.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a highly specialized concept (contra-antiscia), the description provides almost no useful context. It does not explain the underlying astronomy/astrology, the expected input chart format, or the return value structure.
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?
Schema description coverage is 0%, so the description must compensate. It only provides an example request body with a placeholder for "chart", leaving all 11 parameters unexplained. This does not help an agent understand parameter meanings or required formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Equinoctial contra-antiscia' is a jargon-heavy technical phrase that does not explain what the tool does in plain language. It fails to distinguish itself from sibling tools like 'antiscia' or 'hellenistic_greenbaum_antiscia_hellenistic', leaving the agent without a clear 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 versus alternatives (e.g., antiscia, or other Hellenistic tools). There is no mention of prerequisites or context, so an agent cannot determine the appropriate scenario for invoking this tool.
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?
Annotations indicate read-only, non-destructive, idempotent behavior, but the description adds no additional behavioral context beyond what annotations already convey.
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 very short (two lines plus an example snippet), which is concise but sacrifices clarity. It is front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no parameter descriptions or output schema, the description fails to provide essential context for agent use.
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?
Schema coverage is 0% and the description does not explain any of the 11 parameters. The only example request body is incomplete and unhelpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Saturn-as-shadow integration work' is vague and does not specify what the tool returns or computes. Among siblings like modern_greene_archetypal_figures, it lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There is no 'when to use' or 'when not to use' information 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?
The description does not contradict annotations but provides no behavioral context beyond the cryptic phrase. It does not explain what 'A=B/C structures' entail or what the tool returns, leaving the agent without essential behavioral insights.
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 very short but not effectively concise; the cryptic content and irrelevant example waste space without conveying necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 12 parameters, no output schema, and the specialized cosmobiology domain, the description is severely incomplete. It fails to clarify key concepts like 'A=B/C structures' or 'sentence form', making the tool almost unusable for an AI.
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?
With 0% schema description coverage, the description offers no explanation for any of the 12 parameters. The example mentions a 'chart' field not present in the schema, misleading the agent about valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'A=B/C structures with sentence form' is cryptic and does not clearly state what the tool does. The example request body includes parameters not in the input schema, adding confusion. It mentions the cosmobiology group but fails to specify the tool's function.
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 its siblings, such as cosmobiology_cosmogram or cosmobiology_dial_90. There is no context about appropriate scenarios or alternative 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?
The description adds no behavioral context beyond what annotations already state (readOnlyHint=true, idempotentHint=true). Annotations cover safety, but there is no mention of output format, performance, or other 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 short but at the expense of informativeness. It does not convey essential details, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters and no output schema, the description is woefully incomplete. It lacks any explanation of inputs, outputs, or behavior, leaving the agent unable to use the tool effectively.
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?
Schema description coverage is 0%, yet the description provides no information about any of the 12 parameters (e.g., date, time, latitude). The example request body is a placeholder with no real guidance, failing to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tree per personal point' is vague. It does not specify what 'tree' or 'personal point' means, nor does it distinguish this tool from many similar cosmobiology sibling tools like cosmobiology_sensitive_points or cosmobiology_midpoint_pictures.
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 vs alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision-making 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?
Annotations already indicate readOnly=true, idempotent, not destructive, so safety is clear. The description adds the meaning of the figure but no additional behavioral traits like output format 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two lines plus example) and front-loaded with the meaning. However, the example is incomplete, and the structure is acceptable but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many geomancy tools, nested object parameter, no output schema), the description is far from complete. It does not explain what the tool returns, how to structure the request properly, or any contextual cues.
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 schema has 100% coverage but the parameter description merely points to an example in the tool description, which only shows an empty object. The description fails to clarify what fields the 'body' parameter requires.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a tagline 'Greater Fortune — lasting success' which vaguely suggests the tool returns an interpretation of the Fortuna Major geomantic figure, but it does not explicitly state what the tool does. Among many geomancy siblings, it lacks differentiation beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, what context necessitates it, or alternatives are mentioned. The description gives no 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?
Annotations already mark the tool as readOnlyHint=true and idempotentHint=true. The description adds no behavioral details beyond what annotations provide. It includes an example request body but no explanation of side effects, output structure, or limitations.
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?
While the description is short, it lacks substance. True conciseness would convey meaning efficiently; here, the brevity results in omission of critical information. The example request body is vague and not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and a specialized astrological concept (critical degrees), the description is grossly incomplete. It fails to explain what critical degrees are, how modality is used, or what the output will be. An agent cannot reasonably use this tool based on the description alone.
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?
With 0% schema description coverage, the description must compensate but does not. The only parameter mention is a placeholder in the example body ('"...chart":"..."'). None of the 11 parameters (date, time, timezoneOffset, etc.) are explained or linked to the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Critical degrees by modality' is vague and lacks a verb or specific resource. It does not clearly state what the tool does, such as 'calculate' or 'display'. Among many similar Hellenistic tools, it fails to distinguish itself.
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 like hellenistic_hand_bounds or hellenistic_greenbaum_dodekatemoria. No context about prerequisites or typical use cases.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety and idempotency. The description adds no behavioral details beyond 'Derived-house technique', failing to explain what the tool returns or any side effects (e.g., does it modify anything? No, but that's not stated). The description adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but that reflects under-specification rather than good conciseness. It includes a group tag and an incomplete example, but lacks a clear, standalone purpose statement. The structure is minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and 0% schema coverage, the description is severely incomplete. It does not describe what 'derivative houses' are, what inputs are required beyond date/time, or what the tool returns. The agent would be unable to use this tool correctly without external knowledge.
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?
Schema description coverage is 0%, so the description must explain parameters. It only provides a truncated example request body with no explanation of any of the 11 parameters. The agent has no way to know what 'name', 'city', 'cosmogram', etc. mean in this context. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Derived-house technique' which is vague and barely explains what the tool does. It mentions the group and tradition but does not clearly indicate that it calculates derivative houses from a chart. Among many siblings like 'houses' and other Hellenistic tools, it does not differentiate itself.
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. It does not compare to similar tools like 'houses' or other Hellenistic methods. The context of use is implied only by the group name, but no explicit usage instructions or prerequisites 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context (e.g., what the classification produces, what happens with invalid input). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but this is under-specification, not conciseness. It lacks essential information and the structure is minimal. The example is incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and many siblings, the description is severely incomplete. It does not explain what the tool returns, how to construct a valid request, or how it differs from other classification tools.
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?
Schema coverage is 0% and the description does not explain any of the 11 parameters. The example request body '{...chart...}' is misleading because the schema has no 'chart' parameter. No parameter meaning is conveyed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is essentially a tautology: 'Nine fates classification' restates the tool title 'Ennea Mooirai' which means nine fates. It does not use a specific verb or clarify the resource being classified. The group tag provides some context but does not distinguish the tool from sibling Hellenistic Schmidt 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 guidance on when to use this tool versus alternatives. There are many sibling Hellenistic Schmidt tools, but the description does not explain when one would need a 'nine fates classification' over other classification methods.
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?
Annotations indicate read-only, safe, idempotent behavior. The description adds no behavioral or contextual information beyond what annotations already provide, such as return value characteristics or processing expectations.
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 very short but under-specified rather than effectively concise. It lacks essential information and does not earn its place with valuable content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no schema descriptions, and no output schema, the description is extremely incomplete. It fails to explain what 'causation tiers' are, what data is needed, or what the output represents.
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?
Schema description coverage is 0%, but the description does not elaborate any parameters. The example request body is malformed and uninformative. No parameter meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Schmidt's causation tiers' is a brief label that essentially restates the tool name without an explicit verb or action. It does not clearly state what the tool does, nor does it differentiate from many sibling tools with similar naming patterns.
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?
There is no guidance on when to use this tool versus alternatives. No context is provided about use cases, prerequisites, or conditions 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds no extra behavioral context, such as details about output format or processing constraints.
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 very short, but it is underspecified. While concise, it lacks necessary detail, making it unhelpful for correct tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and zero parameter documentation, the description is grossly incomplete. It fails to convey what analysis is performed or what the output contains.
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?
Schema coverage is 0%, meaning no parameter descriptions in the schema. The description provides only an example with a 'chart' object, leaving 11 parameters (including required date and time) completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Qualitative + quantitative analysis' and provides a group identifier, but lacks a specific verb and resource. It does not distinguish this tool from many similar hellenistic_schmidt_* sibling tools, making its purpose unclear.
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 versus alternatives. The description only includes a group label and an example request body snippet, but no context about appropriate use cases or exclusions.
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?
Annotations indicate readOnlyHint=true and idempotentHint=true, so no contradiction. However, the description adds no behavioral context beyond the annotations, such as what the tool computes or typical input requirements.
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 short but wastes space with a group label and unclear example. It lacks structured, useful information and does not earn its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and zero schema coverage, the description is severely incomplete. It provides no information on how to use the tool or interpret results.
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?
Schema description coverage is 0%, so the description must explain parameters. It only shows a vague example body with no parameter meaning, leaving the 11 parameters completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stoic doctrine of elemental natures' is vague and does not specify the tool's operation or output. It fails to distinguish from many hellenistic_schmidt_* siblings, lacking a clear verb or resource.
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 guidance is provided. There is no mention of when to use this tool versus its many siblings, nor any 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds no behavioral context (e.g., what output to expect, whether it requires authentication, or any side effects beyond the annotations).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It lacks structure, useful headings, or a clear breakdown. The example is malformed and unhelpful. Conciseness should not come at the cost of essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, 0% schema coverage), the description fails to provide even minimal context about what the tool returns, how parameters relate, or what 'strategies for integrating weak elements' entails. The example is confusing, making the tool nearly unusable without external knowledge.
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?
With 0% schema description coverage, the description must compensate. It only provides a broken example '{...chart:...}', which fails to clarify any of the 11 parameters (e.g., date, time, location, house system, etc.). No parameter meanings are conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Strategies for integrating weak elements' is vague and does not specify what the tool does with a clear verb and resource. It does not distinguish it from sibling tools like modern_arroyo_element_balance or interpret_element. The example request body is incomplete, offering no 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 its siblings or other element-related tools. There is no mention of context, exclusions, or alternatives, leaving the agent to guess the appropriate use case.
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?
The description adds no behavioral context beyond the annotations. Annotations indicate read-only, but the description does not clarify what the map produces or any required inputs.
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?
While brief, the description sacrifices essential information. The example is garbled and unhelpful, making the conciseness counterproductive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, many siblings), the description is severely incomplete. It does not explain the output, intended use, or how the map functions.
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?
With 0% schema description coverage and 11 parameters, the description provides no parameter explanations. The incomplete example request body does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Relational element compatibility map' provides only a vague sense of purpose. It does not specify a clear verb or distinct resource, and fails to differentiate from siblings like 'element_balance' or 'element_integration'.
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 versus alternatives. The description omits any context about suitable scenarios or prerequisites.
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?
Annotations indicate readOnly and idempotent, but the description implies a name parameter not in schema. No explanation of how location parameters affect calculation. Contradicts annotations by suggesting a write-like operation (calculating from name) that doesn't align with schema.
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?
Short but includes a misleading example request body that doesn't match the schema. The description is not well-structured and wastes space on incorrect information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet the description does not explain what the tool returns. It also fails to reconcile the discrepancy between the described input (name) and actual schema (date/location). Leaves many open questions.
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 description introduces a non-existent parameter (name) and fails to clarify the role of latitude, longitude, and timezoneOffset. Despite 100% schema coverage, the description adds confusion rather than value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it calculates the Balance number from initials, but the input schema does not include a name field, only date and location. This contradiction undermines 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 siblings like numerology_pythagorean_birthday. No context for choosing among many similar numerology 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?
The description does not disclose any behavioral traits beyond what is implied by the name. Annotations indicate readOnly and idempotent, but the description adds no context about what the tool actually computes or returns.
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 extremely short, but it sacrifices essential information for brevity. It is under-specified and unhelpful, not truly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex tool with 7 parameters, the description fails to provide enough context for an agent to use the tool correctly. The purpose and output remain unclear.
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 input schema already describes the parameters. The description adds no additional meaning beyond the schema, warranting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trine elemental partners with natural synergy' is vague and does not clearly state what the tool does. It lacks a specific verb and resource, making it hard to distinguish from siblings like 'business_team_compatibility'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There is no mention of context, prerequisites, or exclusion 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context ('All chart points in 90° cardinal modulus' and an example with 'withTnp'), but does not explain what 'cardinal modulus' means or other behavior like return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus example), which is concise but at the cost of informativeness. It could be more structured and include parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no schema descriptions, no output schema, and a terse description, the tool is severely under-documented. The description fails to provide sufficient context for correct invocation.
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?
Schema description coverage is 0%, yet the description only provides an example with '...chart' and 'withTnp'. It does not explain any of the 12 parameters, including required ones like date and time.
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 'All chart points in 90° cardinal modulus', giving a basic idea of the tool's output. However, it lacks a verb like 'generate' or 'calculate' and does not differentiate from other cosmobiology tools such as 'cosmobiology_cosmogram'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 only mentions the group but does not specify appropriate contexts, prerequisites, or exclusions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds no behavioral context beyond the group tag. It does not describe what happens during execution (e.g., returns signatures, requires multiple charts).
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 extremely short (one line plus group tag), which is concise but at the cost of informativeness. It is not structured to aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides almost no context for a complex tool with a nested array parameter and no output schema. It lacks details on what 'signatures' are, how many members required, or any examples. Completely inadequate.
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 single parameter 'members' is not explained in the description. Though the schema includes a description for the items, the tool description itself adds nothing. With schema description coverage at 0% per context, the description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses vague noun phrase 'System-level family astrological signatures' without a verb or clear action. It does not specify what the tool does (e.g., computes, analyzes, lists). Compared to siblings like 'family_genogram' which imply a structure, this is ambiguous.
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 family_genogram, family_parent_child_deep, etc. No context for selection 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?
Annotations already indicate read-only and non-destructive behavior. The description adds no behavioral context, such as whether it generates or retrieves data, 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 is extremely short, but it is concise. However, it sacrifices informativeness for brevity, making it less useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a single under-defined parameter, the description should explain what the tool returns and how to construct the body. It fails to do so, leaving the agent with insufficient information to use the tool correctly.
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 requires a 'body' object but provides no structure. The description references an example which is empty '{}', offering no clarity. The parameter description is minimal, and the tool description adds no meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Wisdom, peace, clarity.' which is vague and does not explicitly state that this tool returns or interprets the geomancy figure Albus. The title and group hint at the domain, but the purpose is unclear.
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 other geomancy tools (e.g., geomancy_fortuna_major). There is no mention of context 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no further behavioral context (e.g., what 'Restriction' means in practice, permissions needed, or if it returns textual analysis vs. data).
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 extremely short but not concise in a helpful way; it lacks clarity and important details. The group annotation is minimal, and the example is empty.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of return value, the agent cannot anticipate what the tool returns. The description fails to compensate for the missing output schema and incomplete parameter example.
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 only parameter 'body' has a schema that refers to an example in the description, but the description provides only 'Example request body: {}' with no actual fields. This leaves the agent without guidance on required or optional properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses abstract terms 'Restriction, confinement, isolation' without a verb, leaving the agent unsure if the tool interprets, generates, or analyzes the Carcer figure. It relies on the name 'geomancy_carcer' for context, but lacks specificity.
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 other geomancy_* tools. The agent is given no criteria to distinguish Carcer from related figures like geomancy_acquisitio or geomancy_albus.
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 adds no behavioral traits beyond annotations (readOnlyHint, idempotentHint). 'Synchronistic quality' is not 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?
Very short, but does not waste words; however lacks substance. Could be more informative without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No explanation of parameters, no output schema, and minimal description. Agent cannot understand what to provide or expect.
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?
Schema has 11 parameters with 0% description coverage. Description does not explain any parameter; example mentions 'chart' which is not a schema parameter, misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is vague: 'Synchronistic quality of a moment.' Does not state what the tool computes or returns. No differentiation from many Hellenistic Greenbaum 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 vs alternatives. No context or exclusions 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description does not add any behavioral context beyond what annotations provide, such as what is computed, what data is read, or any limitations. It misses an opportunity to explain the output nature 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus an example), which is concise in terms of length but at the expense of critical information. It is not overly verbose, but it lacks substantive content. Conciseness without completeness is not a virtue, so a middling score is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, many siblings), the description is severely incomplete. It fails to explain what sect classes are, what parameters are required, or what the output looks like. The agent would be unable to determine how to invoke this tool effectively.
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?
Schema description coverage is 0%, meaning the description does not explain any of the 11 parameters. Despite a rich input schema with fields like date, time, latitude, etc., the description offers no explanation of their role or how they relate to sect classifications. The incomplete example does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sect classifications per Schmidt' which is vague and does not clarify what sect classes are or what the tool returns. It places the tool in the Hellenistic tradition but does not distinguish it from many similar sibling tools (e.g., hellenistic_schmidt_aspectual_typology, hellenistic_schmidt_derivative_houses_method). The example request body is incomplete and unhelpful.
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. Given the extensive list of sibling tools, the description should explicitly state when this tool is appropriate and when another would be better. The context signals indicate many similar tools, yet no differentiation is offered.
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?
Annotations already mark the tool as read-only and idempotent. The description adds no behavioral context, such as what computations occur or what the output represents, despite having the burden to do so.
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 extremely brief (one phrase plus group label), which is concise but sacrifices usefulness. It is front-loaded but lacks substantive content to justify its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 11 parameters, 2 required fields, and no output schema, the description provides almost no context on how to use it or interpret results. It fails to meet the needs of a complex astrological 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?
With 0% schema description coverage, the description must explain parameter meaning but fails entirely. The example placeholder '{"...chart":"..."}' offers no semantic insight, leaving all 11 parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Element distribution and integration' is vague and does not specify what kind of element or what the tool computes. It fails to differentiate from the similar sibling tool 'modern_arroyo_element_integration', providing no unique 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 given on when to use this tool versus alternatives like 'modern_arroyo_element_integration' or 'modern_arroyo_relational_element_map'. There is no mention of prerequisites or contexts.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds '3-level cascade' which offers minimal behavioral insight beyond annotations. It does not disclose what data is returned, any side effects, or computational scope.
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 extremely short, consisting of a single line and an example. While concise, it sacrifices informativeness. No structured sections or clear presentation of tool behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (many sibling dasha tools, nested schema, no output schema), the description is critically incomplete. It does not explain what the tool computes, how to interpret results, or any constraints. Missing essential context 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?
Input schema has 100% description coverage with explicit details for birth data and target fields. The tool description itself adds no parameter explanation, but schema descriptions are sufficient, yielding a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description merely states 'Shoola Pratyantardasha — 3-level cascade,' which is a tautology of the title and name. It does not explain what a pratyantardasha is or how it differs from sibling tools like antar or sookshma. The verb 'cascade' is vague, failing to specify the tool's computation or output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its many siblings. The description lacks context for selecting pratyantar over antar or sookshma levels, or any prerequisites. Complete omission of 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no additional behavioral context beyond these annotations, such as what computations are performed, assumptions, or any side effects (e.g., cost implications). The cost mention is present in a separate line but not part of the behavioral description.
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 extremely concise (one line plus example and metadata) but at the cost of being under-specified. Important information about the dasha system, computation, and output is missing, making it insufficient for an agent to correctly select and invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 fails to explain what the tool returns (e.g., dasha periods, dates, interpretations). With many sibling dasha tools at different levels, the lack of context makes it nearly impossible for an agent to distinguish this tool from others without prior domain knowledge.
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 detailed descriptions for the 'body' parameter including birth date, time, timezone, etc. The tool description does not add any further meaning to the parameters beyond the schema's own descriptions. Per guidelines, baseline is 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Yogini Pranadasha — 5-level cascade (finest grain)', which is cryptic and heavy on jargon without explaining what the tool computes or returns. It does not clearly state the verb+resource, making it difficult for an agent to infer the tool's purpose without domain knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the many sibling dasha tools at different levels (maha, antar, pratyantar, sookshma) or other dasha systems. The description does not mention any context or alternatives, forcing the agent to rely solely on the tool name.
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?
The description does not disclose behavioral traits beyond what annotations provide. Annotations indicate readOnlyHint=true, but the description does not confirm read-only behavior or mention any auth requirements, rate limits, or output 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 is extremely short but lacks structure and informative content. The group label and example request body do not compensate for the lack of clear explanation, making it under-specified rather than 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 tool has nested objects, 4 parameters, and no output schema, the description is incomplete. It does not explain what the coaching produces, how to interpret results, or any additional context needed for correct 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 coverage is 50%, and the description only provides an example request body without explaining parameter semantics. The question and language parameters are not elaborated, adding little value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Coach two charts on relationship dynamics' is vague. 'Coach' is an ambiguous verb, and the tool does not clearly state that it performs AI-powered astrological comparison. It fails to differentiate from sibling tools like synastry or horoscope_compatibility.
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. Among many sibling tools for relationship analysis, there is no description of context or exclusions, 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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint as true/false. The description adds no behavioral context beyond an example request body, which does not enhance 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 very short but not effectively structured. It includes a group label and an example request body, but essential information is missing. Conciseness without substance is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no schema descriptions, no output schema, and a complex domain, the description is severely incomplete. It does not explain the output format, parameter meanings, or use cases.
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?
Schema description coverage is 0%, and the description does not explain any of the 12 parameters. The example request body is vague and unhelpful. The description fails to compensate for the lack of schema descriptions.
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 mentions 'Ebertin's personal points midpoint hits' which references a specific concept, providing some purpose clarity, but it lacks a clear verb and does not distinguish from sibling tools like cosmobiology_midpoint_pictures or cosmobiology_personal_point_tree.
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 does not mention conditions, exclusions, or related tools among the many cosmobiology 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond stating the resource. It does not describe what the tool computes or how it uses inputs, so it adds no value over the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but poorly structured. The group label is helpful, but the example is vague and mismatched with the schema. The description is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no parameter explanations, the description is grossly incomplete. An agent cannot determine what data to provide or what the tool returns, making it unsuitable for use.
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?
Schema description coverage is 0%. The description does not explain any of the 11 parameters, even required ones like date and time. The example request body is incomplete and includes a 'chart' field not present in the schema, which is confusing. This leaves the agent without essential guidance for providing valid inputs.
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 '8 Hamburg trans-Neptunian bodies', specifying the resource but lacking an explicit verb like 'get' or 'list'. The title 'Uranian TNPs' provides context, but the purpose is only implied. It distinguishes from siblings by mentioning 'Hamburg' and 'trans-Neptunian', but the lack of an action reduces 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 alternatives. There are many sibling cosmobiology tools, but the description does not compare or contrast them. The agent is left 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and idempotentHint true, so the tool is a safe read operation. The description adds no additional behavioral traits, such as data requirements, rate limits, or side effects. It merely restates the calculation formula.
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 very short, but its brevity comes at the expense of essential information. It front-loads the formula but lacks structure and completeness. The placeholder example is not useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and numerous sibling tools, the description is severely incomplete. It does not describe the output, differentiate from similar tools like cosmobiology_midpoint_pictures, or provide any context on how the parameters interact.
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?
Schema description coverage is 0%, and the description fails to compensate. It does not explain any of the 12 parameters, including critical ones like date, time, zodiacType, or cosmogram. The example request body is a placeholder with no detail. The AI agent gets no meaningful parameter guidance.
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 mentions 'Witte planetary pictures A+B-C=D' and groups it under Cosmobiology, giving a formula. However, it does not clearly define what a Witte planetary picture is or what the tool computes. It provides some specificity but lacks a clear statement of the tool's function for an AI agent.
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 its many cosmobiology siblings. The description does not mention prerequisites, appropriate contexts, or alternatives. It simply states the formula and group.
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?
Annotations declare read-only, non-destructive, idempotent, and closed-world behavior, but the description adds no behavioral context beyond these. It does not disclose return type, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three lines), which is concise, but it sacrifices completeness. Every sentence earns its place but omits critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain what the tool returns or how to interpret its output. With no output schema and a sparse description, the agent lacks essential context for effective use.
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 single 'body' parameter is described as 'Raw JSON body — see the example in the tool description for required fields,' but the example is '{}', implying no required fields. Schema coverage is 100% but the description adds no meaningful constraints or format expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only thematic keywords ('Happiness, optimism, healing') without a verb or action. It does not state what the tool does (e.g., 'Returns an interpretation of the Laetitia figure'), making it vague. The title and group hint at geomancy but not a specific operation.
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 its many siblings (e.g., other geomancy figures). The description does not mention context, prerequisites, or exclusions, leaving the agent without selection 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds no behavioral context beyond 'bounds rulers'—it does not disclose output format, pagination, or constraints. With annotations covering safety, description should explain what the computed data represents but fails to do so.
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 extremely short (two sentences plus group label and example). While brief, it omits critical information and is under-specified rather than concise. Important context about output or usage is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a large sibling list, the description is vastly incomplete. It does not explain what 'bounds' are, how to interpret results, or how to use parameters. The agent would lack sufficient context to invoke the tool correctly.
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?
Input schema has 11 parameters with 0% description coverage. The description does not explain any parameter; it only shows an example with '...chart' which is not a field in the schema. The description fails to add any meaning beyond the schema's basic types and defaults, leaving the agent without understanding of parameter usage.
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 title 'Egyptian Bounds' and description 'Ptolemaic Egyptian bounds rulers' indicate the tool computes Hellenistic bounds/terms. However, it does not clearly state what is returned (e.g., bounds for each planet) or how it differs from siblings like 'hellenistic_hand_decanic_rulers'. The group label adds context, but the purpose is only moderately 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?
No explicit guidance on when to use this tool versus alternatives. The 'Hellenistic — Hand tradition' group implies a context but does not state when this is appropriate or when to avoid it. 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds nothing beyond these, except a group label. It does not contradict annotations, but also doesn't disclose any additional behavioral traits (e.g., that it requires a chart input).
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 extremely short but unstructured. The example is truncated and unhelpful. While conciseness is valued, this lacks necessary detail, making it more of an omission than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a specialized domain (Hellenistic astrology), the description provides almost no context. It does not explain what 'sect-light dignity' is, how the score is derived, or which parameters are critical for the computation.
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?
Schema description coverage is 0%, so the description bears full responsibility. It only shows a partial example request body with '...chart' and does not explain any of the 11 parameters, their roles, or how they affect the scoring. The agent has no clue what each parameter means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Numerical sect-light dignity scoring' which hints at the function but lacks a clear verb and resource. The title 'Sect Strength Score' adds some context, but the purpose is not explicitly stated in plain language. It fails to distinguish what specific calculation is performed.
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 the many sibling tools (e.g., hellenistic_hand_bounds, hellenistic_hand_critical_degrees). There is no mention of prerequisites or alternatives, leaving the agent 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it is safe and idempotent. The description adds no additional behavioral context such as what the tool returns, how it processes inputs, or any side effects. Since annotations cover safety, the description contributes little.
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 extremely short, which is not conciseness but under-specification. It lacks essential information and does not use the space effectively. The example request body is not useful and potentially confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, 11 parameters, 0% schema coverage, and a minimal description, the tool is severely under-documented. The agent cannot determine how to correctly invoke the tool or what to expect from the response.
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?
Schema description coverage is 0%, meaning no parameter descriptions in the schema. The description only offers a misleading example request body with '...chart' which does not match any parameter in the schema. No parameter details are provided, leaving the agent to guess the meaning of 11 parameters.
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 'Arroyo's evolutionary cycle', which indicates a specific system (Arroyo) and a conceptual area (evolutionary cycle), but lacks a verb to clarify whether it calculates, interprets, or generates content. It does not distinguish from the sibling tool 'modern_rudhyar_cycles_of_becoming', which shares a similar naming pattern.
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 prerequisites, typical use cases, or scenarios where another tool might be more appropriate.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Archetypal patterns in the chart', which implies a read operation, but provides no further behavioral context (e.g., whether it computes new data, requires network, or has side effects). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus group label), but it is under-specified rather than concise. It omits essential information, making it inefficient for agent usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, many siblings), the description is severely incomplete. It does not explain return values, how archetypal patterns are derived, or how to interpret the output. The agent cannot effectively decide to invoke this tool based on the available information.
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?
Schema coverage is 0% (no parameter descriptions), and the description explains none of the 11 parameters. The example request body includes a non-schema field '...chart' which is unclear. The agent receives no guidance on parameter meaning or required inputs beyond the schema structure.
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 'Archetypal patterns in the chart per Liz Greene' provides a basic idea but is vague. The title and group hint at modern psychological astrology, but it doesn't specify what the tool outputs (e.g., a list of archetypes, interpretations) or how it differs from siblings like modern_greene_individuation_path.
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 guidelines on when to use this tool versus alternatives. The description does not mention prerequisites, context, or cases where this tool is preferred over other Greene-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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is safe and idempotent. The description adds no behavioral context beyond 'analysis', missing details like what data is used, whether it requires a full chart, or what happens to the input.
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 very short but sacrifices clarity. The group label '[Group: Modern Psychological]' is a clutter, and the example is incomplete. The core sentence is front-loaded but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and only minimal annotations, the description should provide operational context. It fails to explain what the tool returns, how parameters interact, or what 'parental imagos analysis' means in practice. This is critically incomplete for a complex 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?
Schema description coverage is 0%, and the description provides no explanation for any of the 11 parameters (e.g., date, time, houseSystem, zodiacType). The only mention is a malformed example snippet that does not clarify parameter meanings.
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 'Parental imagos analysis', indicating the tool performs analysis on parental image archetypes in astrology. However, it lacks a specific verb like 'calculates' or 'interprets', and does not differentiate from sibling tools such as modern_greene_lunar_myth or modern_greene_saturn_shadow. The broken example request body adds confusion rather than 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 alternatives. The sibling tools list is extensive but the description gives no hints about appropriate contexts, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral insight beyond this, such as what the response contains or any side effects. The example body '{}' hints at an image but 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (3 words plus group and example) but lacks substance. While concise, it is under-specified and fails to convey necessary information. Front-loading is present but content is insufficient.
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 involves palmistry interpretation and has no output schema, the description should explain input expectations and output nature. It only mentions 'Vitality, health, life force.' and a group, leaving the agent without enough context to use the tool correctly.
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 parameter 'body' is described only as 'Raw JSON body — see the example in the tool description for required fields'. However, the example is an empty object '{}', which provides no meaningful guidance on what fields or format are expected. Schema coverage is 100% but the description adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Vitality, health, life force.' which are attributes of the life line but does not clarify what the tool does (e.g., interpret, analyze, or generate a reading). The verb is missing, making it unclear whether this tool provides an interpretation, an image, or something else.
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 other palmistry tools like palmistry_fate_line or palmistry_head_line. There is no mention of context, prerequisites, or alternatives, leaving the agent to guess.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds no additional behavioral details (e.g., computation process, output structure) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes an example, but it lacks structured presentation (e.g., bullets, sections). The brevity is acceptable but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested input schema, the many sibling tools, and the absence of an output schema, the description is severely incomplete. It does not explain what the tool returns, how the 4-level cascade works, or how to 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 schema itself includes a clear description of the required birth data parameters. The tool description adds an example request body but no further semantic information, so it does not improve upon the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Shoola Sookshmadasha — 4-level cascade' is too vague and does not clearly state that the tool performs a specific sub-dasha calculation for the Shoola system. It fails to distinguish from many sibling dashas tools like vedic_dashas_shoola_maha or antar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 its many alternatives. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer from the 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no additional behavioral context, such as what the tool does beyond being a read action. The example request body is incomplete and does not clarify 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 very short (one line plus a group tag and an incomplete example). It is concise but lacks essential details, sacrificing utility for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters (2 required), no output schema, and zero schema descriptions, the description is severely incomplete. It does not specify what data the tool returns, how to construct input, or any constraints, making it nearly unusable for an agent.
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?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the 11 parameters (date, time, latitude, etc.). The example mentions 'chart' which is not a parameter, providing no added semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Forrest 2008 past-life method' but does not specify what the tool actually calculates or returns. The name 'evolutionary_yesterday_sky' hints at a chart for the day before birth, but the purpose remains vague. It does not distinguish itself from sibling tools like evolutionary_nodal_axis_detail.
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, or any context about prerequisites or exclusions. The '[Group: Evolutionary Astrology]' tag implies a domain but offers no actionable 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?
Annotations confirm read-only and idempotent behavior, but the description adds no behavioral context beyond the schema; it omits details like the computational method or that it relies on birth data.
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 very brief (2 lines) but front-loads the key phrase; however, it omits essential information, making it under-specified rather than 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?
Given 7 parameters and no output schema, the description lacks details on return values, interpretation, and the gematria method; it is insufficient for an AI agent to understand the tool's output.
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 does not add meaning beyond the schema, though the example provides a sample request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Gematria-style number set per sign.' is vague; it does not clearly state that the tool returns financial lucky numbers, nor does it differentiate from sibling tools like financial_lucky_day or financial_market_timing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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; the description provides only an example request body without any 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?
Annotations clearly indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description 'Movement, change, journey' does not add or contradict these; it adds no behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line of keywords, a group reference, and an example) but at the expense of clarity. It is not well-structured for an agent to understand 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?
Given no output schema and a vague description, the tool is incomplete. An agent cannot infer what the tool returns or how to properly call it, despite annotations providing some safety 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 one parameter 'body' described as 'Raw JSON body — see the example in the tool description for required fields', but the example is empty '{}'. The description does not clarify the expected structure or required fields, adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Movement, change, journey' is vague and does not specify a verb or resource. It merely restates the title 'Via — The Way', acting as a tautology. Among many geomancy sibling tools (e.g., geomancy_acquisitio), there is no differentiation.
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 any context about situations where 'Via' is relevant compared to other geomancy figures or 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?
Annotations already indicate readOnlyHint=true and destructibleHint=false. The description adds nothing beyond what is already in atrunctions, failing to disclose any behavioral aspects like side effects, input constraints, or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this brevity sacrifices clarity and completeness. It is not well-structured; it reads as a fragment rather than a coherent explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema) and the large set of sibling tools, the description fails to convey essential context, such as what 'planetary joys' means, what the tool computes, or how to use it.
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 11 parameters with 0% description coverage. The description does not explain any parameter, not even the required 'date' and 'time'. The example request body shows a chart field but lacks explanation.
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 mentions 'Classical planetary joys (Sun-Leo-9th, etc.)' and groups it by tradition, but does not explicitly state the tool's action (e.g., 'computes' or 'returns'). The purpose is vague and could apply to multiple 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 guidance is provided on when to use this tool versus its many siblings (e.g., 'hellenistic_brennan_bonifications_maltreatments'). There is no mention of prerequisites or typical use cases.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context beyond the source text and tradition, with no mention of what is returned, permission needs, or 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 very concise at two sentences plus a group tag and incomplete example. It is front-loaded with the key technique, but the content is too sparse to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and many sibling tools, the description is far too minimal. It fails to explain what hyleg/alcocoden are, how inputs affect results, or what the tool returns, leaving the agent without essential context.
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?
Schema description coverage is 0%, but the description does not explain any of the 11 parameters. It only shows an example with a 'chart' key, leaving the agent without guidance on how to use date, time, coordinates, etc.
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 'Tetrabiblos III.10 hyleg + alcocoden' and mentions the Hellenistic Hand tradition, giving a specific astrological technique. However, it lacks an explicit verb+resource structure like 'Calculates the hyleg and alcocoden' and does not distinguish from the sibling tool 'hyleg'.
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 'hyleg' sibling or other hellenistic_hand_* tools. The description provides no 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety is clear. The description adds no behavioral context beyond 'Aspect classes per Schmidt,' lacking details on side effects, permissions, or output 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 brief but wastes space with an unhelpful example request body that implies a non-existent parameter. The content is not front-loaded effectively and lacks structured 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 tool's complexity (11 parameters, no output schema, many siblings), the description fails to cover prerequisites, return format, or how to invoke it correctly. It is insufficient for an agent to select or use this tool effectively.
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?
Schema description coverage is 0%, yet the description does not explain any of the 11 parameters. The example request body includes a 'chart' parameter not present in the schema, which is misleading and offers no value.
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 'Aspect classes per Schmidt,' which identifies the specific tradition and resource. However, it does not differentiate from sibling tools like hellenistic_schmidt_qualities_and_quantities, leaving room for ambiguity.
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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites provided. The description is purely definitional.
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?
Annotations already indicate a safe, idempotent read operation (readOnlyHint=true, destructiveHint=false). The description adds minimal behavioral context beyond the subject. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus group label), but it fails to convey essential information. It is concise but not effectively structured to aid understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 2 required, and no output schema, the description is severely incomplete. It does not explain what the tool returns, how parameters are used, or any typical use case.
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?
With 0% schema description coverage and 11 parameters, the description provides no parameter explanations. The truncated example request body is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Outer-planet cycles as becoming' gives a vague subject area but lacks a clear action verb (e.g., compute, interpret). It does not distinguish between this and the similar sibling 'modern_arroyo_cycle_of_becoming'.
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 'modern_arroyo_cycle_of_becoming'. No prerequisites, exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds no behavioral context beyond what annotations provide, but does not contradict them.
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 very short but sacrifices essential information. While concise, it does not effectively communicate the tool's purpose or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, many sibling tools, and no output schema, the description is severely incomplete. It fails to explain the concept of 'personality keynote', input requirements, or expected output.
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?
Schema has 11 parameters with 0% description coverage. The description only provides an example request body with a 'chart' field that does not match the schema, which is misleading. No parameter meanings are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Single-keynote signature for the chart' which is vague and does not clarify what a personality keynote is. It groups under 'Modern Psychological' but fails to differentiate from sibling tools like modern_rudhyar_cycles_of_becoming or modern_rudhyar_lunation_phase.
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 any context for choosing this tool over other Rudhyar or modern psychological 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?
Annotations indicate readOnly, non-destructive, idempotent. The description states it calculates, consistent with read-only. However, no extra behavioral context beyond what annotations already provide.
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 short but contains inaccurate information. Conciseness is not valuable if it misleads. The example contradicts the schema.
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 large number of sibling tools and lack of output schema, the description fails to explain what the Personality number is, how consonants are derived, or what the response contains. Incomplete for effective use.
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?
Schema has 100% coverage but description references a 'name' parameter not in the schema, and the example shows 'name' and 'date' while schema only has 'date'. This misalignment undermines parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it calculates the Personality number from consonants of the full birth name, but the input schema does not include a 'name' parameter, only date and optional location. This mismatch makes the purpose unclear and potentially misleading.
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 the many similar numerology personality tools (e.g., strict, Pythagorean). No alternatives or conditions 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?
Annotations indicate safe read operation, but the description's example includes a non-existent 'name' parameter, contradicting the actual input schema. This misleads about what inputs are needed.
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 short, but the example is misleading and the group label adds noise. Could be more accurate and direct.
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 fails to explain what the Balance number represents, how it's calculated, or the significance of the 'Mathers strict' system. No output schema, so more context needed.
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 coverage is 100% with descriptions, but the description introduces a 'name' example not in the schema, causing confusion. It does not clarify that the tool actually requires only date and optional location parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it calculates the Balance number from initials of the full name, but the required input schema parameter is only 'date', with no 'name' parameter. This mismatch makes the purpose unclear and misleading.
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 siblings like numerology_kabbalistic_balance or other system-specific balance tools. No context or alternatives provided.
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?
The description contradicts the input schema: it says calculations use the full birth name, but the schema requires only date (no name parameter). Annotations indicate read-only and idempotent, which are correct, but the description introduces a misleading 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?
Very short and includes an example, but the example is inaccurate (name field not in schema). Conciseness is undermined by misinformation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no description of what the Soul Urge number represents or its range. The tool is part of a complex numerology domain, yet the description fails to provide essential context about the calculation or expected output.
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?
Schema coverage is 100%, but the description does not explain schema parameters and instead references a non-existent 'name' parameter. The example includes 'name' which is not in the schema, actively misleading the agent.
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 calculates the Soul Urge number from vowels of the full birth name, specifying the Kabbalistic (Mathers strict) system. However, the input schema lacks a name parameter, causing confusion about what input is actually required.
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 other soul urge calculators (e.g., chaldean, pythagorean, or non-strict kabbalistic). The description does not differentiate among the many numerology 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?
Annotations already indicate read-only and idempotent behavior. The description adds no new behavioral context (e.g., return format, error handling). The mismatch between the example and schema further obscures 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 short but includes an inaccurate example that contradicts the schema. Conciseness without correctness is detrimental.
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 fails to specify that the required input is a date and location, not a name. With no output schema, it also omits what the calculation returns. For a tool in a large family, this is insufficient.
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 description introduces a 'name' parameter in the example that does not exist in the schema, while the actual parameters (date, latitude, longitude, timezoneOffset) receive no semantic explanation beyond the schema itself. This is misleading.
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 it calculates the Soul Urge number from vowels of the full birth name, which is a clear verb and resource. However, this is inconsistent with the input schema which requires date and location instead of a name, 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 explicit guidance on when to use this tool versus the many sibling numerology soul urge tools (e.g., Chaldean, Kabbalistic). The group label 'Numerology — Pythagorean' provides some context but no advice on 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?
Annotations include readOnlyHint=true, destructiveHint=false, idempotentHint=true, but the description adds no behavioral context beyond 'Preferred play and toy types.' It does not describe what the output looks like or any side effects, missing an opportunity to add value.
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 very short (one sentence plus group label and example), but it sacrifices clarity for brevity. It earns its place poorly because it does not convey the tool's purpose fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and many sibling tools, the description is incomplete. It does not explain what the tool returns, how to interpret results, or any prerequisites. The lack of output schema worsens the 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 coverage is 100%, so baseline is 3. The description includes an example request body, but this duplicates schema information. No additional meaning is added beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase 'Preferred play and toy types.' It lacks a verb and does not explicitly state what the tool does, e.g., 'Calculate' or 'Provide.' It is vague and does not distinguish from sibling tools like pet_personality or pet_temperament.
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 pet_personality or pet_training_style. There are many pet-related tools, but the description offers no 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?
Annotations (readOnlyHint, idempotentHint) already indicate safety. The description adds '4-level cascade' hinting at output structure, but does not disclose details like computation behavior, required input fields beyond schema, or that targetDate is essential. No behavioral contradictions.
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 extremely short (two lines plus example), which is concise but at the cost of clarity. It lacks necessary information to be useful.
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 Vedic dashas with multiple levels and cascades, the description is insufficient. It does not explain what '4-level cascade' means, how the sookshma level fits, or what the output contains. No output schema exacerbates this.
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 descriptions already cover the main parameters with 100% coverage. The description includes an example request showing targetDate, which provides minimal additional context but does not explain the semantics of targetDate or the cascade level. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Yogini Sookshmadasha — 4-level cascade,' which is vague and does not clearly explain that this tool calculates the Sookshma sub-period of the Yogini Dasha. It fails to differentiate from sibling tools like vedic_dashas_yogini_antar or vedic_dashas_yogini_prana.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other dashas or sub-levels. There is no mention of prerequisites, alternative tools, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds no additional behavioral traits (e.g., no mention of error handling, rate limits, or data scope). With annotations present, a score of 3 is appropriate as description doesn't contradict but adds minimal value.
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 extremely brief (one line plus group and example). It lacks structure and does not convey essential information. While concise, it is under-specified and does not earn its sentences by providing clear value. Example is helpful but insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 what the tool returns (e.g., interpretation, numerical data, visual representation). It only mentions 'Income, material prosperity' but no details on output format, depth of analysis, or how parameters affect results. Incomplete for a tool with 4 parameters and a specialized domain.
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 has 100% description coverage for all 4 parameters (date, latitude, longitude, timezoneOffset), so the description adds no extra meaning beyond the schema. The example only shows date, not the optional parameters. Baseline score of 3 for adequate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Income, material prosperity' and title 'Wealth Palace (Caibo)', which indicate the domain but lack a verb specifying the action (e.g., 'calculate', 'interpret', 'get'). Compared to sibling tools like 'ziwei_palace_career', it fails to differentiate clearly what this tool outputs or how it operates. Purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other palace tools (e.g., ziwei_palace_destiny) or other wealth-related tools (e.g., financial_wealth_house). No context about prerequisites, input constraints, or appropriate scenarios. Completely absent.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is clear. The description adds minimal behavioral context beyond 'per natal chart,' which is consistent but does not elaborate on output or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a group label and placeholder), but it omits essential information for a tool with 11 parameters. The lack of structure and the unhelpful example make it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, no schema descriptions), the description is grossly incomplete. It fails to explain the tool's core function, input requirements, or return values, leaving the agent with insufficient information to use it correctly.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. The example request body is a placeholder and provides no parameter guidance. The agent receives no help on what inputs like date, time, latitude, etc., mean.
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 'Individuation arc per natal chart,' which identifies the resource but is vague and does not differentiate from sibling tools like modern_greene_archetypal_figures or modern_greene_lunar_myth. The term 'individuation arc' is specialized and may not be clear to an AI agent without additional context.
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. There is no mention of prerequisites, when to prefer this over other modern_greene tools, or what input conditions warrant its use.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds no extra behavioral context but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an inconsistent example and a group bracket with no apparent benefit; structure is poor for 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?
No output schema, so description should explain return format; it neither describes the output nor explains why latitude/longitude/tz are needed for a numerology calculation.
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 coverage is 100%, but the description introduces a non-existent 'name' parameter in the example, confusing parameter expectations and adding no value to the actual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it calculates the Soul Urge number from vowels of the full birth name, but the input schema lacks a 'name' parameter, making the purpose misleading for an AI agent.
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; among many sibling numerology tools, there is no differentiation 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?
The description adds no behavioral context beyond the annotations, which already indicate it's read-only, non-destructive, and idempotent. While the annotations cover safety, the description does not elaborate on any additional 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 very short but under-specified. It lacks essential information about the tool's output or expected input, making it insufficiently informative despite its brevity.
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 and many sibling tools, the description is incomplete. It does not explain what the tool returns or how it operates, leaving the agent underinformed.
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 schema has 100% coverage but the 'body' parameter description merely says 'see the example', and the example is an empty object {}. This does not clarify required fields or structure, providing little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Career, life direction' is too vague and does not differentiate from sibling palmistry tools like palmistry_head_line or palmistry_life_line. It lacks a specific verb or action, making it unclear what the tool does beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like other palmistry tools. The description does not mention when to use it, when not to, or suggest alternative tools.
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?
The description includes an example with parameters ('gender', 'count') not present in the input schema, creating a dangerous inconsistency. It fails to explain the role of latitude/longitude/timezoneOffset defined in the schema. Annotations already cover read-only and idempotent hints; the description adds no further behavioral clarity.
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 short and includes a group tag, but the inconsistent example undermines its usefulness. Conciseness is not helpful if it introduces confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 explain what the 'sequence' contains or how to interpret the result. It also does not mention that the schema accepts location parameters, and the example's 'count' is unexplained. This leaves the agent underinformed.
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?
While the schema provides adequate coverage (100% with descriptions), the description adds no value and actually misleads by showing example parameters not in the schema. This reduces the semantic clarity for the agent.
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 '10-year luck pillars sequence' and clarifies the direction logic based on gender and year-stem polarity. This sufficiently identifies the tool's purpose as computing a sequence of luck pillars, distinguishing 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 guidance on when to use this tool versus alternatives like bazi_monthly or bazi_yearly. The description does not mention context, prerequisites, or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds 'render data' but no further behavioral context (e.g., return format, data structure, performance). With annotations covering safety, this is acceptable 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three sentences), but brevity comes at the cost of clarity. It lacks structure and fails to deliver key information. Every sentence should earn its place; the example is misleading and the group tag adds little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no output schema, and no parameter descriptions, the description is far from complete. It does not state what data the tool returns, what inputs are critical, or how it relates to other tools. A complete description would explain the cosmogram data structure and required inputs.
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?
Schema description coverage is 0%, yet the description explains none of the 12 parameters. The example request body hints at a 'chart' parameter not present in the schema, which is confusing. This extreme lack of parameter documentation renders the description useless for correct invocation.
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 'Ebertin cosmogram render data', giving a resource and implied verb. However, it's vague about what the tool actually does (calculates positions? returns JSON?). Among siblings, render_cosmogram likely renders an image, so 'data' hints at a difference but not explicitly. A clearer verb like 'calculate' or 'generate' would help.
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 sibling set includes many cosmobiology tools (e.g., cosmobiology_dial_90) and render_cosmogram, but the description offers no criteria for selection or exclusion. Example usage context is missing.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds the note 'ill omen' but does not supplement behavioral details like return format or required permissions. It does not contradict annotations, but adds minimal value.
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 very short (three sentences), which is concise but at the expense of missing critical information. It is structured with a poetic line and a group label, but lacks a clear functional statement.
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 large sibling set (many geomancy figures), the description is incomplete. It does not explain the tool's output, input requirements beyond an empty example, or how it differs from other geomancy tools. No output schema further limits completeness.
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 100% coverage for the 'body' parameter, but the description only provides an empty example '{}' and no additional semantic meaning. It does not clarify what fields are expected inside 'body' beyond the generic schema note, so the description adds little value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Passion, anger, blood — ill omen' merely restates the symbolic meaning of the Rubeus figure without stating what the tool does (e.g., 'returns the interpretation of the Rubeus geomancy figure'). It is a tautology of the title and does not clarify the tool's function or distinguish it from sibling geomancy 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 guidance is provided on when to use this tool versus sibling geomancy tools or other tools. There is no mention of context, 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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, but the description adds no extra behavioral context (e.g., no mention of output structure, query limitations, or required permissions). The discrepancy between required body and example empty body is not addressed.
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 extremely short (three mini-lines), which is concise but at the cost of necessary detail. It front-loads the emotional keywords but fails to explain tool usage or output, earning a middling score for balancing brevity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's context (geomancy figure with many siblings, nested input schema, no output schema), the description is severely incomplete. It does not specify the output format, interpretation content, or how the 'body' parameter affects results, leaving the agent with insufficient information to invoke correctly.
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 describes the 'body' parameter as 'Raw JSON body — see the example in the tool description for required fields', but the example is empty '{}'. This inconsistency undermines clarity. No guidance is given on valid fields or structure, leaving the agent without actionable parameter semantics.
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 name and title clearly indicate the tool relates to the Tristitia geomantic figure representing sorrow. The description lists keywords like 'Sadness, depression, melancholy' but lacks a verb specifying what the tool does (e.g., returns interpretation, generates chart). The example request body '{}' contrasts with the required body parameter, causing ambiguity.
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 places the tool in the 'Geomancy (Agrippa)' group, hinting it is one of many geomancy figure tools. However, it provides no explicit guidance on when to use this tool versus siblings (e.g., to get meaning of Tristitia), nor any exclusions or 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?
Annotations already provide read-only and idempotent hints. Description adds no further behavioral traits, but does not contradict annotations. Adequate given annotations, but description could disclose more about computation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short and front-loaded with the key term, but the example is poorly formed and overall lacks substance. Not wasteful, but too minimal to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and many siblings, the description is critically incomplete. It fails to specify return values, parameter roles, or when to select this tool over similar hellenistic tools.
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?
Schema coverage is 0%, and the description provides no meaning for any of the 11 parameters. The example request body is vague ('...chart...') and does not compensate. Agent has no guidance on parameter semantics.
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?
Description states 'Dorothean triplicity rulers' which identifies the specific resource but lacks a verb indicating the action (e.g., calculates, returns). The grouping and example are present, but purpose is only vaguely implied.
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. No mention of prerequisites, context, or exclusions. The example request body is incomplete and does not aid decision-making.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond what annotations provide, such as whether it calculates date ranges or requires specific chart conditions.
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 short but at the expense of clarity. It uses two sentences to state purpose, group, and an example, but the example is incomplete and lacks contextual 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?
Given the complexity of the astrological technique, the description fails to explain what 'peak periods' are, what the output represents, or how to interpret the result. No output schema is provided, leaving significant 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 includes detailed descriptions for the body parameter (birth data requirements), achieving high coverage. The tool description itself adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Peak periods in ZR (angular signs from Lot)' is vague and assumes prior knowledge of 'ZR' and 'Lot'. It does not clearly state what the tool computes or how it differs from similar sibling tools like hellenistic_brennan_zr_loosing_of_bond.
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 lacks any context for appropriate usage scenarios or exclusions.
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?
Annotations indicate readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond 'timing.' It does not explain what the computation produces or any side effects, failing to add value beyond structured annotations.
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 extremely short, but the example request body is malformed and unhelpful. It is not effectively front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested schema, many sibling tools, and no output schema, the description critically lacks context. It does not explain what 'perfection-of-aspects' means, that targetAge is required, or what the tool returns.
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 provides no additional parameter details and an incomplete example, but does not degrade from the baseline.
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 says 'Perfection-of-aspects timing,' which is a technical term but not a clear verb+resource. It does not differentiate from sibling tools like hellenistic_hand_bounds or hellenistic_hand_critical_degrees. The purpose is vague for an AI agent unfamiliar with the domain.
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 about when perfection-of-aspects timing is appropriate or when to choose other Hellenistic Hand 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, which inform the agent about safety. However, the description adds no behavioral context beyond a vague classification. It does not explain return values, potential inputs beyond the example, or any 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus group label and an example). While brevity is valued, the example is inaccurate, and the minimal text does not earn its place by providing sufficient guidance. Important details are omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 0% schema coverage, no output schema, and a vague description, the tool is severely incomplete. The agent has little understanding of inputs, outputs, or how this tool differs from dozens of similar hellenistic siblings. The example with a non-existent 'chart' parameter adds confusion.
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?
Schema description coverage is 0%, yet the description fails to explain any parameters. The example request body includes a 'chart' key that does not exist in the input schema ('chart' is not a property), which is misleading and could cause errors. No parameter semantics are clarified.
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's purpose: 'Morning vs evening star classification.' It specifies the tradition (Hellenistic — Schmidt), which helps distinguish it from other hellenistic tools. However, it lacks detail about what exactly is classified (e.g., which planets) and the output format.
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 sibling list contains many similar hellenistic tools, but no conditions, prerequisites, or exclusions are mentioned. 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?
The description says 'computes' and 'returns 0-100 score', which aligns with annotations (readOnlyHint, idempotentHint). However, the major inconsistency between the example (two date objects) and the schema (single date property) undermines transparency, as the agent cannot infer the correct input structure. This is a critical omission.
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 the main action and score range front-loaded. The group tag and example are additional but not excessive. The example helps clarify usage despite schema mismatch, though it could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 mentions a '0-100 score', which is insufficient. More critically, the input specification is incomplete: the practical invocation requires two dates, but the schema only provides one, making it impossible for the agent to correctly call the tool without external knowledge.
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 100% coverage but only describes properties for a single date. The description adds no value by explaining how to input two people; in fact, the example contradicts the schema, leaving parameters ambiguous. Latitude, longitude, and timezoneOffset are not mentioned or tied to the two-person input.
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 Mayan compatibility between two people based on Tzolkin alignment, returning a 0-100 score. The verb 'pair compatibility' and resource are specific, distinguishing it from other compatibility tools in the sibling list. However, the schema only defines a single 'date' field, which contradicts the example with two dates, causing slight confusion.
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 over alternatives like human_design_compatibility or synastry. It includes a group tag '[Group: Mayan Calendars]' but no explicit when-to-use or when-not-to-use instructions, leaving selection unclear.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no additional behavioral context, such as what output to expect or any limitations. Given the annotations, the bar is lower, but the description still fails to add value.
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 extremely short, which could be conciseness, but it is under-specified. The inclusion of a cryptic example and a group label does not provide useful structure. It is more minimal than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and a very brief description, the tool is poorly contextualized. The description does not explain what the analysis returns, what inputs are essential, or how to differentiate from many similar sibling tools. Annotations provide safety but not task context.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. The example request body is vague and does not clarify parameter usage. This is a critical gap, as the description should compensate for missing schema 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 'Symbolic-degree analysis' clearly indicates the tool performs analysis of symbolic degrees based on Rudhyar's system. The name and group 'Modern Psychological' further clarify its domain. However, it lacks specifics on what the analysis entails (e.g., interpretation, calculation), which slightly reduces 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 usage guidelines are provided. The description does not mention when to use this tool versus other symbolic-degree tools like sabian_symbols or other modern_rudhyar tools. The group label is implicit but insufficient for guiding tool selection.
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?
The description mentions a 'name' parameter and example request with 'name', but the input schema does not include 'name'. This discrepancy misrepresents the tool's interface. Annotations are fine but the description undermines 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 short but includes an incorrect example and extraneous parameter. Conciseness is compromised by inaccuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks output schema; no description of return values. The presence of location parameters (latitude, longitude, timezoneOffset) is not explained. The description is incomplete for effective agent use.
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 coverage is 100%, so schema descriptions already cover parameters. However, the description introduces a 'name' parameter not in the schema, which is misleading and adds confusion. The example further reinforces this error.
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 verb 'calculate' and resource 'Personality number from consonants of full birth name'. The title and group help distinguish it from sibling numerology tools, but no explicit differentiation from other Pythagorean 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 guidance on when to use this tool versus alternatives like other Pythagorean numerology tools or other systems. The example shows name and date, but the context of use is not discussed.
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?
Annotations declare readOnlyHint=true, so no side effects. The description provides insight into the scoring logic (how fortune is calculated) but does not describe the output structure or any other behavioral details. Adds some value beyond annotations 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and includes an example, but the structure could be improved. It lacks clear separation between purpose, scoring, and example. Acceptable conciseness but at cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no description of return values, the description is severely incomplete. It does not enable an agent to understand what the tool returns or how to set parameters beyond the example.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. The example request body shows values but no semantics. Without parameter guidance, the tool is hard to use correctly.
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?
Description indicates it computes a 'fortune score' using Lal Kitab rules (pakka ghar, own sign, exalted, debilitated) and cites a reference, but does not explicitly state the overall function or distinguish from other vedic_lal_kitab_* tools. Purpose is implicit rather than clear 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 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 any context about appropriate use cases, prerequisites, or comparisons to sibling 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?
The description adds no behavioral context beyond what annotations already provide. Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is safe, but the description does not mention any additional traits like how parameters affect the result or what the output contains.
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 very short, which is concise, but it lacks a proper sentence structure. It opens with a one-line concept, then a group label and example. It is acceptable but sacrifices completeness for brevity.
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 and many sibling tools, the description is incomplete. It does not describe what the tool returns or how to interpret results. Annotations provide safety but not functional context. The agent has insufficient information to use the tool 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?
Input schema has 100% coverage, so the baseline is 3. The description adds no parameter information beyond the schema, but it does include an example with date. While not enriching, it is adequate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Brothers, sisters, peer relationships' is vague and does not clearly state what the tool does. It provides no verb or action, leaving the agent to infer that it retrieves Siblings Palace information for a Zi Wei Dou Shu chart. The title and group label help but the description itself is insufficient.
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. There are many other ziwei_palace_* tools (career, children, etc.), but the description does not differentiate or offer usage context. The agent must rely solely on the name.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds only that it uses Eastern-school Bagua and maps life areas, but does not explain how the input date or other parameters affect the mapping, nor the output format.
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?
Two sentences plus a group label and example. The core description is clear but the example is misplaced and confusing. Could be more structured and front-loaded with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (1 required) and no output schema. The description does not explain the output, how to interpret the mapping, or what the compass sectors mean. It is incomplete for an effective tool invocation.
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?
Schema coverage is 100%, but the description adds no value beyond the schema. Worse, the example includes 'gender' which is not a parameter, misleading the agent about required inputs. No explanation of how date, latitude, longitude, or timezoneOffset are used.
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 maps 9 life areas onto compass sectors, using Eastern-school Bagua. The verb 'mapping' and resource 'life areas' are specific. It distinguishes from sibling tools like chinese_feng_shui_kua (Kua number) and chinese_feng_shui_lucky_directions (lucky directions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 example includes gender, which is not a parameter in the schema, providing confusing and potentially misleading usage 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?
The example body includes a 'time' field ('14:30:00') that is not defined in the input schema, creating a misleading contradiction. Annotations correctly mark the tool as read-only and idempotent, but the description's implied requirement for time is inconsistent with the schema, undermining trust.
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 short but includes a misleading example that does not match the schema. While efficient, the inaccuracy harms its structure and reliability.
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 lacks explanation of optional parameters and does not describe the return output (no output schema). The time requirement mismatch and missing context for latitude/longitude reduce completeness for a tool with moderate complexity.
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, so baseline is 3. The description adds a helpful example showing time format but does not explain optional parameters like latitude, longitude, or timezoneOffset. Value added is minimal.
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 the 'hour-of-birth branch animal' representing the 'deepest self', which distinguishes it from sibling tools like chinese_zodiac_animal and chinese_zodiac_inner_animal. The verb and resource 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?
The description mentions 'Requires birth time' but does not provide explicit guidance on when to use this tool over alternatives, nor does it explain when not to use it. No comparison to sibling tools 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which inform the agent of safety and idempotency. However, the description adds no additional behavioral context (e.g., output format, data dependencies, or performance constraints), so it does not enhance transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief—listing aspect angles, group affiliation, and an example placeholder. It avoids verbosity, but critical information is missing. While every sentence is concise, the brevity results in under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, no output schema), the description is severely incomplete. It fails to explain the return value, how parameters affect the output, or when the tool is appropriate. Even with annotations covering safety, the overall context is insufficient for reliable tool selection.
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?
With 12 parameters and 0% schema description coverage, the burden falls entirely on the description. The description offers no explanation for any parameter (e.g., 'date', 'time', 'timezoneOffset', 'cosmogram', 'withTnp'). The example request includes a placeholder '{...chart:...}' but does not clarify parameter purpose, leaving the agent without guidance.
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 title '8H Aspect Grid' and description listing specific aspect angles (22.5°, 45°, 67.5°, 90°, 135°) clearly indicate the tool computes and returns an eight-harmonic aspect grid for the Cosmobiology/Hamburg School tradition. It distinguishes from sibling tools like 'aspects' (standard aspects) and 'synastry_aspect_grid' (synastry-focused) by specifying the esoteric subgroup and unique angles.
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 (e.g., 'aspects', 'synastry_aspect_grid'). It lacks prerequisites, context for appropriate use, or exclusions, leaving the agent to infer from the title and angles 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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description only adds 'Full NN/SN with rulers + conjuncts', which aligns but does not disclose any additional behavioral traits such as output format, pagination, or error handling. Minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (about 10 words plus a group label and example), but this brevity sacrifices useful content. It lacks structure beyond the group label. While it is front-loaded, it does not earn its place as it omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and no parameter descriptions. For a complex astrology calculation tool, the description is severely inadequate. It fails to provide enough context for an agent to correctly invoke the tool or understand its output.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. The example request body is a placeholder with no actual parameter values. The agent receives no guidance on how to fill parameters like 'date', 'time', or 'houseSystem'.
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 'Full NN/SN with rulers + conjuncts', clearly indicating it provides nodal axis details with rulers and conjuncts. The title 'Nodal Axis Detail' reinforces this. However, it does not differentiate from sibling tools like 'evolutionary_pluto_natal_condition' or 'evolutionary_skipped_steps', lacking explicit distinction.
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 prerequisites, exclusions, or typical use cases. Given the extensive sibling list, the agent would need to infer usage from the tool name 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?
Annotations already declare the tool as read-only, idempotent, etc. The description adds no behavioral context beyond stating the output fields. It does not disclose any additional 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?
Very short (two sentences plus example), but the first sentence is cryptic ('JWG:') and the example is minimally helpful. Could be more concise, but lacks substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description is critically incomplete. It does not clarify required parameters beyond date/time, return format, or how to use the chart parameter. The group label is the only contextual help.
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?
Schema description coverage is 0%, yet the description does not explain any parameter. It only shows an example with a 'chart' field not in the schema, failing to compensate for the complete lack of parameter documentation.
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 it computes 'Pluto sign+house+ruler+hard aspects', which is clear. The group label 'Evolutionary Astrology' helps categorize, but does not distinguish from several sibling evolutionary tools like 'evolutionary_nodal_axis_detail' or 'evolutionary_skipped_steps'.
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 group label provides context but no exclusions or comparisons with sibling tools 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond the annotations, such as how the lucky day is determined or if it requires a full birth chart. It does not contradict annotations, but also does not add value.
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 very short: one sentence plus example. While concise, it lacks structure and does not earn its place fully. The group label 'Financial Astrology' helps, but overall it could be more informative without losing brevity.
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 present, so the description should explain what the tool returns. The description says 'Days traditionally aligned with the sign' but does not clarify if it returns a single day, multiple days, or additional context. For a tool with 7 parameters, the description is incomplete and leaves the agent guessing about 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 coverage is 100%, so baseline is 3. The description provides an example request body but no additional meaning for parameters beyond what the schema defines. For instance, it does not explain how latitude/longitude affect results or what houseSystem means in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Days traditionally aligned with the sign' is vague. It does not specify which sign (presumably zodiac sign from birth chart) or what constitutes a lucky day. The title 'Lucky Day of Week' suggests output is a day of the week, but the description does not confirm this. Sibling tools like 'financial_lucky_numbers' have clearer purposes, making this tool's purpose ambiguous.
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 provides no context for usage, e.g., whether it is for selecting auspicious days for financial decisions or general luck. Sibling tools like 'financial_market_timing' suggest similar domains but no differentiation 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?
Annotations already provide readOnlyHint true and destructiveHint false, but description adds no behavioral context (e.g., what output to expect, any constraints). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short description, but it is structured with a group label and example. However, it is under-specified; not every sentence earns its place due to lack of useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex astrological tool with 7 parameters and no output schema, the description is completely inadequate; it does not explain what the output contains, how the spending pattern is derived, or any interpretation 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% with descriptions for all 7 parameters; description adds no additional semantics beyond the example request body, which is already clear from the schema.
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 'Sign-specific spending pattern' indicates a verb and resource but is vague; it does not distinguish from siblings like financial_career_money_style or financial_investor_archetype which also deal with spending or money style.
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; no mention of context, exclusions, or prerequisites.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint, establishing safety. The description adds no additional behavioral context (e.g., output format, side effects) but does not contradict annotations. Minimal value added beyond structured data.
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?
Extremely concise (two short lines plus example), but at the expense of clarity. The group annotation in brackets is useful, but the description lacks a proper sentence structure and front-loads a cryptic phrase.
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 large set of sibling geomancy tools, a single parameter, and no output schema, the description is incomplete. It does not explain what the tool returns, how the body should be structured (beyond empty example), or how to integrate it into a geomancy reading flow.
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% for the lone 'body' parameter, which already describes it as raw JSON. The description provides an empty example ('{}') but does not clarify required fields or structure. Baseline 3 applies; the example is marginally helpful but not sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Lesser Fortune — quick gains' restates the title and gives a vague outcome but no explicit verb-resource statement. It fails to clarify what the tool does (e.g., interpret the figure, provide a reading). Sibling tools like geomancy_fortuna_major likely have similar descriptions, offering no differentiation.
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 the many other geomancy tools. No mention of prerequisites, context, or alternatives. The implied use from the name and group is insufficient.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate safety. However, the description adds no behavioral context beyond the annotations, such as what data is returned 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 is extremely short but not effectively structured. It lacks a clear explanation of the tool's function or required inputs, wasting the limited space on vague 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?
Given the tool is part of a large geomancy family with many sibling tools, the description lacks essential context about its purpose, output, and how it differs from others. The absence of an output schema further compounds the incompleteness.
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 (body) with 100% description coverage. The description only points to an example request body that is empty, offering no additional meaning beyond the schema's raw JSON specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only provides poetic attributes ('Beauty, harmony, love') and a group label, but does not explicitly state that this tool interprets the Puella geomantic figure. The purpose is implied but vague.
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 indication of when to use this tool over its many sibling geomantic tools (e.g., geomancy_puer, geomancy_coniunctio).
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?
Annotations already indicate read-only safety. The description adds no behavioral context (e.g., what input fields are required, how results are structured). The example empty body offers some insight but is too 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 brief and front-loaded with the figure's meaning. It avoids redundancy, but the brevity comes at the cost of 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?
With no output schema and a free-form body parameter, the description fails to specify return value structure or input format requirements. This is insufficient for safe 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?
The input schema has 100% description coverage, so the baseline is 3. The description notes 'Raw JSON body' and points to the example, but does not clarify expected properties or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a vague interpretation of the figure ('Young man, energy, impulse') but does not state what the tool actually does (e.g., retrieve, interpret, or compute). It does not distinguish it from the many sibling geomancy 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 guidance is given on when to use this tool versus other geomancy figures. The group label is present but does not help the agent choose among 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?
Annotations already indicate read-only and idempotent behavior. The description adds no additional behavioral details (e.g., response structure, error handling), relying solely on the annotated traits. No contradiction, but minimal value added.
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 group label, front-loading the core purpose. However, the example request body appears to be copy-pasted and may not be valid, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and many siblings, the description is grossly incomplete. It fails to explain the '9 categories' or how to interpret results, leaving the agent without sufficient context to use the tool effectively.
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?
Schema description coverage is 0%, and the description does not clarify any of the 11 parameters. The example shows a 'chart' field, but no semantic meaning is provided for required or optional parameters, severely limiting usability.
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 'Planet conditions per Valens — 9 categories,' which specifies a verb ('provides') and resource ('planet conditions'). However, it does not differentiate this tool from many similar Hellenistic tools in the sibling list, missing a key opportunity to clarify its unique 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 on when to use this tool versus alternatives. The description mentions the tradition but fails to specify context or prerequisites, leaving the agent without decision-making information.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotence. The description adds the 'solstitial' convention but discloses almost no additional behavioral traits (e.g., output format, pagination, auth requirements), leaving the agent underinformed.
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 very concise at two sentences, with no unnecessary words. However, the example is broken and unhelpful, slightly reducing efficiency. 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and exists among hundreds of siblings, the description is grossly incomplete. It omits what the tool returns, how to interpret results, and any essential usage context, making it nearly useless for an agent.
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?
With schema description coverage at 0% and 11 parameters, the description must compensate but completely fails to. The truncated example '{...chart...}' adds no value. No parameter meanings, defaults, or constraints are explained 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 states 'Solstitial antiscia per Hellenistic conventions' which clearly identifies the resource (antiscia) and the specific tradition (Hellenistic Greenbaum). However, it does not explain what antiscia are or differentiate from sibling 'hellenistic_greenbaum_contra_antiscia', missing an opportunity to distinguish.
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 when-to-use or when-not-to-use guidance is provided. The tradition is mentioned, but with many sibling tools (e.g., 'antiscia', 'hellenistic_greenbaum_contra_antiscia'), an agent would have no basis to choose this tool over others.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond stating what it computes—no mention of side effects, required permissions, or output format. It contributes minimal extra transparency, so the score is low.
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 very short—one line of functional text plus group and example. It is concise but not efficiently structured; the example request body is incomplete and not helpful. It could be improved by front-loading a clearer purpose and adding essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and a large sibling set, the description is severely incomplete. It does not explain return values, how to interpret results, or how to properly construct a request (e.g., required chart format). The agent cannot confidently invoke this tool based solely on this description.
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 11 parameters with 0% description coverage. The tool description does not explain any parameter, leaving their meaning and usage entirely to the schema. With no parameter documentation, the description fails to add value for parameter semantics.
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 action ('Bodies trining the rising sign'), specifying a verb ('trining') and resource ('rising sign'). It indicates the tool identifies celestial bodies in trine aspect to the ascendant. However, it does not distinguish this from sibling Hellenistic Hand tools like 'hellenistic_hand_bounds' or 'hellenistic_hand_critical_degrees', leaving ambiguity about its unique function.
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. There is no mention of prerequisites, context, or exclusions. The description lacks any 'when' or 'when not' conditions, which is insufficient for an AI agent to make an informed choice among many similar 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?
Annotations already declare readOnlyHint=true, so the tool is read-only. The description adds no further behavioral context—no mention of how selection is computed, any prerequisites, or output 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?
Extremely brief but lacks structure. The example request body is incomplete and not helpful. The description would not be considered efficient; it is under-specified.
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 and minimal description, the tool lacks context on return values, interpretation, and what 'predictive significator selection' entails. The schema partially covers input, but the overall completeness is low.
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 provides parameter details. The description offers only a partial example request body ('{"...chart":"..."}'), which adds little beyond the schema. Baseline 3 applies.
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 'Predictive significator selection,' which indicates a verb and resource. However, it is vague and does not differentiate from numerous siblings like 'hellenistic_schmidt_levels_of_causation' or 'hellenistic_schmidt_aspectual_typology', leaving ambiguity about what exactly this tool selects.
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 group label '[Group: Hellenistic — Schmidt tradition]' is insufficient to distinguish usage from the many hellenistic_schmidt_* 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?
Annotations already indicate readOnly and idempotent; the description adds no behavioral context beyond them.
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 the example is poorly structured and contradicts the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and 0% schema coverage, the description is critically incomplete.
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?
No parameters are explained; the example request body references a 'chart' key not in the 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 states 'Heliacal phases and stations' which clearly identifies the tool's purpose, but it does not differentiate from sibling Hellenistic Schmidt 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 guidance is provided on when to use this tool versus alternatives; only a group label 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?
Annotations declare readOnlyHint, destructiveHint, and idempotentHint. The description adds no behavioral information beyond these annotations, missing details like deterministic behavior or seed purpose.
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 very short, front-loading the output. While concise, it lacks sufficient detail.
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?
Despite having only one parameter and no output schema, the description does not explain what transformed hexagrams are or how the tool works, leaving incompleteness.
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 coverage is 0%, and the description only provides an example body without explaining the 'seed' parameter's role, leaving semantics unclear.
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 it returns 'Primary + transformed hexagrams', which names the resource but lacks a clear verb. It does not distinguish from sibling I Ching tools like 'iching' or 'iching_daily'.
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 example request body hints at input but does not specify context or prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description's brief mention of SSE-stream does not contradict and adds minimal context. The description does not elaborate on stream behavior (e.g., event types, termination), which is acceptable given annotation completeness.
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 very short (two lines), which is concise but at the expense of clarity. It could include more useful information without being verbose. The group label adds some structure but is not fully earned.
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 is a streaming endpoint with three parameters and no output schema, the description is incomplete. It does not explain the streaming mechanics, expected output format, or any usage constraints, making it insufficient for proper agent invocation.
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?
Schema description coverage is 0%, and the description does not mention any of the three parameters (tool, args, language). The agent must rely solely on the schema, which lacks descriptions for 'tool' and 'args'. This is a critical gap.
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 'SSE-stream of a tool call envelope', which indicates a specific resource and action, but uses jargon that may be unclear to an agent. It differentiates from siblings by being a generic streaming tool, but the purpose is somewhat vague.
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 versus alternatives. It mentions 'Group: MCP Advanced' but does not provide context on scenarios or exclusions, leaving the agent to infer usage from the name 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only a high-level conceptual statement and does not disclose any behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one sentence plus group label and example snippet). It is not verbose, but the example is incomplete and potentially misleading. The group label adds some structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and no parameter descriptions, the description is grossly incomplete. It does not specify what the tool returns, how inputs are used, or any other operational context.
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?
Schema description coverage is 0%, and the description provides no explanation of any parameters. The only example includes a placeholder '...chart' that does not match any actual 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 'Reframe major transits as rebirth' clearly states the tool's purpose with a specific verb and resource. However, among many 'modern_rudhyar_' siblings, it does not clearly differentiate itself beyond the 'rebirth' concept.
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 does not mention any prerequisites, exclusions, or comparative context for 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?
The description indicates a read-only computation, consistent with annotations. However, the example request body includes 'name' while the schema has no such parameter, misleadingly suggesting a parameter that doesn't exist. This undermines transparency about actual 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 short and to the point, but the inclusion of a misleading example wastes space and reduces effectiveness. Better to omit the example or align it with the schema.
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 tool returns (e.g., a number, interpretation). Given the complexity of the topic and the lack of output documentation, the tool is incomplete for an agent to use effectively.
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 coverage is 100% with adequate parameter descriptions, but the description introduces a non-existent 'name' parameter in the example, confusing the semantics. The description adds no value beyond the schema and actually degrades clarity.
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 clearly states it calculates the Expression/Destiny number using the Chaldean system from the full birth name. However, the example request body includes a 'name' parameter that is not present in the input schema, causing confusion about the actual required inputs.
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?
There is no guidance on when to use this tool versus the many other numerology_chaldean_* siblings. The description does not differentiate it from tools for life path, soul urge, etc., leaving the agent to guess.
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?
Annotations already cover safety (readOnly, idempotent). The description adds no behavioral details beyond the computation method. The schema mismatch (missing 'name' parameter) undermines 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 short and includes a group label, but the example contradicts the schema. It is concise but misleading.
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 value. The missing 'name' parameter in the schema leaves the tool functionally incomplete.
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 coverage is 100% with descriptions, but the description's example includes a 'name' parameter not in the schema, confusing parameter expectations. No additional parameter meaning is provided.
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 clearly states it calculates the Personality number from consonants of the full birth name. However, the input schema does not include a 'name' parameter, making the purpose misleading and unachievable as described.
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 the many sibling numerology tools (e.g., expression, soul urge). The description does not provide context 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?
Annotations already declare readOnly and idempotent hints. The description adds no behavioral context beyond the basic operation. It does not describe 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief description with one sentence, group label, and example. However, the example introduces a parameter not in the schema, reducing clarity. No wasted words, but structure is flawed due to inconsistency.
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?
Does not explain what the tool returns (only says it 'calculates'). With no output schema, the description should describe the result. The parameter mismatch further reduces completeness.
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 example request includes 'name' which is not in the input schema, while the schema lists date and location parameters that seem irrelevant for a name-based calculation. This mismatch severely undermines understanding of required inputs. Despite 100% schema description coverage, the description misleads by showing an undocumented 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 the tool calculates the Soul Urge number from vowels of the full birth name using the Chaldean system. It is specific and includes a group label, though it does not differentiate from sibling numerology 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 guidance on when to use this tool versus alternatives. The example shows a request but does not explain selection criteria among many similar numerology 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?
Annotations already indicate readOnly, nondestructive, idempotent. Description adds system detail but contradicts schema by implying a 'name' parameter is required. No mention of what the output contains.
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 short but includes an example with 'name' not in schema, making it incorrect. The group header is useful but doesn't offset the error.
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?
Among many siblings, no differentiation provided. Missing output schema and no explanation of what the result is. The contradictory example further reduces completeness.
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 coverage is 100%, so schema describes parameters. Description adds no semantic value and introduces a nonexistent 'name' parameter, misleading the agent.
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?
Description states it calculates the Expression/Destiny number from full birth name letters, which is clear. However, the input schema does not include a 'name' parameter, creating confusion about the actual required input.
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 like numerology_kabbalistic_strict_balance or other systems. Multiple very similar tools exist, and the description lacks differentiation.
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?
Annotations indicate read-only and idempotent, which is consistent. But description adds no further behavioral context (e.g., how score is derived, any side effects, or what happens with invalid input).
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 short but includes a group tag and an example. However, the example is long and the mismatch with schema reduces clarity. 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?
No output schema, so description should explain return format and fields. Only 'score (0-100)' is mentioned. Input structure is ambiguous. Overall lacks completeness for a computation tool.
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 100% coverage with parameter descriptions, but the description adds no additional meaning. Moreover, the example uses nested objects ('owner', 'pet') not reflected in the flat schema, causing confusion.
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?
Description states it computes a compatibility score (0-100) for owner-pet, but the phrase 'element + sign distance' is vague and the input structure is unclear due to mismatch between example (nested objects) and flat schema.
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 synastry or other pet tools. No prerequisites or exclusions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'Short temperament-only summary', which is consistent and implies a limited, non-destructive output. However, it does not disclose additional traits like required input format or returned data structure beyond the example body.
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 very short (one phrase plus group and example). It is front-loaded with the purpose summary, but the group bracket and example are clearly separate. Could be more structured; the example is helpful but not essential in the description.
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 7 parameters, 2 required, and no output schema, the description should explain what the tool returns (e.g., text, scores). 'Temperament-only summary' is insufficient. The example body shows inputs but not output. It lacks completeness for an AI agent to understand 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 coverage is 100% with all parameters described. The description provides an example request body but does not add semantic meaning beyond the schema. Baseline 3 is appropriate as the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Short temperament-only summary' which is vague. It does not state a clear verb+resource (e.g., 'returns a brief temperament description for a pet'). The phrase 'temperament-only' hints at output but lacks specificity. Sibling tools like pet_personality or pet_birth_chart suggest this is a distinct tool, but the description fails to differentiate.
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 '[Group: Pet Astrology]' provides category context but no comparative advice. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral insights beyond what annotations already provide (readOnlyHint, idempotentHint, etc.). It does not explain the output format (e.g., returns three runes and interpretations) or any side effects. The example request body hints at a seed parameter but no 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 is very short (two sentences plus an example). It is concise but wastes space on a group tag and example without adding critical information. It could be restructured to front-load purpose and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, three undocumented parameters, and many sibling rune tools, the description is extremely incomplete. It does not explain what the tool returns, how to interpret parameters, or when to select it over other rune tools. This severely hampers an agent's ability to use it correctly.
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 schema has 0% description coverage for all three parameters (seed, question, allowReversed). The description only shows an example with 'seed' but does not explain what seed controls (randomization?), the purpose of question (max 400 chars), or allowReversed (default true). No semantic meaning is added.
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 title 'Norn 3-Rune Cast' and description 'Past/Present/Future (Urdr/Verdandi/Skuld)' clearly state it casts three runes representing past, present, future. It is distinct from sibling rune tools (like runes_single or runes_nine) as it specifically does a three-rune spread focused on time. However, it does not explicitly differentiate why to choose this over other rune 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?
The description provides no guidance on when to use this tool vs alternatives (e.g., when a three-rune spread is desired, or when to use runes_single instead). No when-not-to-use or context 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?
Annotations provide openWorldHint: true and readOnlyHint: false, but the description adds no behavioral context beyond that. It does not disclose streaming behavior (e.g., continuous updates, connection requirements), authentication needs, or output frequency. With annotations present, the description's minimal contribution results in a low score.
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 very concise (two sentences plus group and example), which is efficient, but it sacrifices important details. Key information about parameters, output, and usage is missing. The structure is clear but overly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 (e.g., eclipse dates, totality path, coordinates). It does not. The streaming nature is mentioned only via group label, not elaborated. The description is insufficient for an agent to use this tool correctly in context.
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?
Schema coverage is 0%; the description does not mention latitude and longitude parameters at all. The example request body is empty, suggesting they are optional, but their purpose (likely location coordinates) is not explained. The description fails to compensate for the missing schema documentation.
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 provides 'Next solar+lunar eclipses with totality info,' which indicates the tool returns upcoming eclipse data with details about totality. This distinguishes it from sibling tools like 'eclipses' (general list) and 'stream_eclipse_incoming' (focused on incoming events). The group name 'Real-time Streaming' further clarifies its streaming nature, though the purpose could be more precise.
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 compared to alternatives. Among siblings there are many eclipse-related tools (e.g., 'eclipse_analysis', 'stream_eclipse_incoming') but no context for selection. There is no mention of prerequisites, when to avoid, or preferred use cases.
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?
Annotations indicate readOnly, destructive false, idempotent, but the description only adds '4-level cascade' which is vague. It does not disclose any other behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but not well-structured. It lacks headings or bullet points, though it is front-loaded with the tool name and example.
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 explain what the '4-level cascade' means or what the output contains. For a complex Vedic dasha calculation, the description is incomplete.
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 example request body provides practical context for parameter values, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Chara Sookshmadasha — 4-level cascade' but does not explicitly state that it computes or returns this dasha. It fails to differentiate from sibling tools like vedic_dashas_chara_maha or vedic_dashas_chara_antar, which also compute chara dashas at different levels.
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. With many sibling dashas tools, the description should indicate that this is for the sookshma level of chara dasha, but it does not.
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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds the '4-level cascade' context but does not disclose additional behavior (e.g., output format, limitations). 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks structure and essential details. It includes an example but no clear statement of purpose or output.
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, yet the description does not explain what the tool returns. The example shows only input, leaving the AI to guess the output format and content. Incomplete for a complex dasha 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 input schema has extensive descriptions (100% coverage), so the tool description adds no extra parameter meaning. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states 'Kalachakra Sookshmadasha — 4-level cascade' and provides an example, but lacks a clear verb and does not differentiate this tool from numerous sibling dasha tools (e.g., vedic_dashas_kalachakra_maha, antar, 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?
No guidance on when to use this specific level of Kalachakra dasha versus other levels (maha, antar, prana, etc.) or alternatives. The description only includes cost and group metadata.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds no behavioral context beyond what is in the annotations; it does not mention what the tool computes or returns.
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 very short (one line plus an example). It lacks structure such as separate sections for usage, parameters, or output. The example is helpful, but overall it is too minimal.
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., a list of periods, dates, effects). Given the large number of sibling dasha tools, the lack of output context makes it hard to understand the tool's role.
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% (the body parameter includes descriptions for sub-fields). The example request body provides a usage pattern but does not add semantic meaning 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name and title clearly indicate it's a Vedic dasha sub-period (Sthira Pratyantardasha), and '3-level cascade' hints at its nature. However, it does not explain what a pratyantardasha is or how it differs from other dasha levels (e.g., antar, prana), making it hard for an unfamiliar agent to distinguish among many 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 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 specific sub-period versus other dasha tools (e.g., vedic_dashas_sthira_antar, vedic_dashas_sthira_maha). The sibling list contains many similar tools, and the description offers no criteria 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?
Annotations indicate the tool is not idempotent, read-only, or destructive, but the description adds minimal context. It does not explain side effects of multiple registrations, how to manage webhooks, or authentication requirements. The description describes the webhook trigger behavior but not the registration 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 short, including only one sentence, a group label, and an example. While concise, it prioritizes describing the webhook event over the tool's action. The example is useful but the structure could front-load the registration 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?
Given the absence of an output schema and the tool's nature as a registration endpoint, the description fails to explain return values (e.g., a webhook ID or success status) or how to manage the registered webhook. Critical context for agent decision-making is missing.
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?
With 0% schema description coverage, the description should elaborate on parameters. It only provides a brief example showing the 'url' field, adding minimal meaning beyond the schema's type and format constraints. The description does not explain how to construct the URL or any other constraints.
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 title 'Register VOC-Start Webhook' clearly indicates the tool's function, but the description focuses on what the webhook does ('fires at the start of every VOC Moon period') rather than stating that the tool registers a webhook URL. Combining title and description yields understanding, but the description alone is vague about the tool's action.
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 alternative webhook registration tools or the streaming equivalent 'stream_void_of_course'. There is no mention of prerequisites, limitations, or best practices.
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?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds no behavioral context (e.g., permissions, rate limits, or side effects), but the example request is a minor positive. With annotations present, a score of 3 is appropriate as it neither adds nor contradicts.
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 very short and includes an example, but it lacks structure and a full sentence explaining the tool's purpose. It is concise but omits necessary detail, making it minimally adequate.
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?
For a tool in an esoteric system with no output schema, the description provides insufficient context. It does not explain what the career palace represents, what data it returns, or how it differs from other palace tools. The agent would lack understanding of the tool's output.
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 has 100% parameter description coverage, so the schema already documents parameters. The description does not add parameter meaning beyond the example request. Per guidelines, baseline 3 applies; the example is insufficient to raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides only keywords ('Profession, status, official position') and a group label, lacking a clear verb+resource statement of what the tool does. It does not explicitly state that it analyzes or retrieves the career palace in Zi Wei Dou Shu, making the purpose vague compared to 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 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 versus alternatives like ziwei_palace_health or ziwei_palace_wealth. The description does not specify contexts where this palace is relevant, leaving the agent without decision criteria.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. Description adds 'calculate' confirming read-only operation but does not disclose other behavioral traits like required input relationships (e.g., chart vs. transit) or output format.
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 and includes an example request, but the group/cost metadata line adds noise. Front-loaded with the main action, but the example could be integrated more concisely.
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 11 parameters, no output schema, and a technical astrological concept, the description is insufficient. It omits how 'natal planets' are determined, how aspects are returned, and what the result represents.
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?
Input schema has 11 parameters with 0% description coverage, and the description does not explain any parameter beyond an example request body. The agent receives no semantic guidance for the many optional fields.
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?
Description states 'Calculate antiscia and contra-antiscia, plus aspects to natal planets' with specific verb and resource. However, the term 'natal planets' is ambiguous given the single-chart input, and the tool is not differentiated from siblings like hellenistic_greenbaum_antiscia_hellenistic.
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 selecting this tool over related antiscia tools among the extensive sibling list.
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?
The description includes an example request body with a 'gender' field that is not present in the input schema, creating a misleading expectation about required parameters. This contradicts the actual behavior specified by 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short with two sentences and an example, but the example introduces a harmful inaccuracy. Otherwise, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks explanation of how the Kua number is derived, does not mention that gender is required but omitted from the schema, and provides no details about the output format. The example inconsistency makes the description incomplete and misleading.
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 description does not clarify the parameters beyond the schema, and the example includes an invalid parameter (gender). Since schema coverage is 100%, the description adds no meaningful value and instead misleads.
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 personal 4 lucky and 4 unlucky compass directions from Kua using standard Pa Kua mapping. The tool name and title align, and it distinguishes from related sibling tools like chinese_feng_shui_bagua and chinese_feng_shui_kua.
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. It includes a group tag but no context on use cases, prerequisites, or when to avoid 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?
Annotations provide readOnlyHint=true and idempotentHint=true, but the description adds no behavioral context beyond 'Generic caution windows'. It does not specify what happens with optional location parameters, whether location affects results, or 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 very short (two lines plus group and example), which is concise but may be under-specified. It front-loads the purpose, but lacks structure and additional detail that would fit in a few more sentences.
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 does not explain what the tool returns (e.g., list of caution windows, dates, intensity levels). For a tool with only one required parameter and optional location, the description should at least hint at the output format to be 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 clear descriptions for date, latitude, longitude, and timezoneOffset. The description adds an example request body but no additional parameter semantics 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Generic caution windows (Mercury Rx, eclipses, Mars Rx, major macro aspects)', which indicates the tool provides astrological market timing caution periods. However, it is vague about the exact output and does not clearly differentiate from sibling financial astrology tools like financial_lucky_day or financial_investor_archetype.
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 group hint '[Group: Financial Astrology]' is present, but there is no description of appropriate contexts, exclusions, or comparisons to other financial astrology 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds no behavioral detail about what the detection returns 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 is brief but lacks substance; the example is incomplete and does not aid understanding. Structure is minimal.
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?
For a niche astrological tool, the description fails to explain what 'loosing of bond' means, expected output, or conditions for use. Incomplete given complexity.
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 each parameter. The description adds a vague example but no meaningful semantics beyond the schema.
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 it detects 'loosing of bond' within the ZR sequence, but it does not explain what that means or differentiate from sibling tools like zodiacal_releasing_fortune or zr_peak_periods.
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 alternative Brennan ZR tools or other astrological tools. No context for appropriate scenarios.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds minimal behavioral context: it mentions 'scoring' but does not explain the scoring mechanism, output format, or any side effects (e.g., pagination, rate limits). For a read-only search tool, the description should at least hint at the result structure.
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 extremely short (one sentence plus group note), which is underspecified rather than concise. It omits crucial information like output format, parameter definitions, and usage context. While brevity is good, it must not come at the expense of completeness.
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 has 3 parameters (one nested object), no output schema, and many sibling tools, the description is insufficient. It does not explain what 'chart chunks' are, how scoring works, or what the response look like. An agent lacks the context to decide when to call this tool over alternatives.
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 coverage is only 33% (the 'chart' parameter has a description in the schema). The tool description does not add any meaning for the 'query' or 'topK' parameters, leaving them undocumented. The chart parameter description is helpful but is within the schema, not the tool description, and there is no compensation for the missing descriptions of the other two parameters.
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 'Keyword-tag scoring over chart chunks', which indicates a search/scoring operation over chart data. The verb 'scoring' and noun 'chart chunks' give a specific sense of what the tool does. However, it does not differentiate it from siblings like 'mcp_multi_chart_context' which might also retrieve chart data.
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 sibling list has many similar data retrieval tools (e.g., 'mcp_multi_chart_context'), but the description offers no comparison or usage context. The group note 'MCP Advanced' is present but does not clarify 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, but the description adds no behavioral context beyond the vague verb 'countdown'. It does not explain whether the tool initiates a stream, returns a one-time count, or requires ongoing polling. The example request body {} offers no clarity on expected 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 extremely short (one sentence plus group label and example), which achieves conciseness but sacrifices necessary detail. The group label provides mild structure, but the content is too sparse for adequate understanding. It could benefit from a few more sentences without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to address the tool's complexity as a streaming tool. No output schema is provided, and the description omits critical operational details such as whether the countdown is streamed or static, how to manage the stream, or typical response formats. Given the openWorldHint and the nature of real-time streaming, this description is woefully incomplete.
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 description coverage is 100%, but the schema description reads 'Raw JSON body — see the example in the tool description for required fields', and the tool description example is an empty object {}. This implies no fields are required, but the actual meaning of the body parameter remains underspecified. The description adds no structural detail beyond the schema's minimal text.
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 'Countdown to next 5 eclipses', which clearly identifies the action (countdown) and resource (next 5 eclipses). However, it does not differentiate from the sibling tool stream_eclipse_totality, which might have a similar focus on eclipses. The title reinforces the purpose of streaming upcoming eclipses.
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 stream_eclipse_totality or eclipse_analysis. The description only includes a group label '[Group: Real-time Streaming]' which weakly contextualizes it among streaming tools, but does not specify selection criteria or exclusions.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds only group and cost information, not behavioral traits like computation constraints, error handling, or the meaning of the 4-level cascade. The agent gains no additional transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus example and group/cost line). It is concise but at the expense of clarity and completeness. While efficient, it sacrifices explanatory content.
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 is part of a complex family of dasha calculators with no output schema, the description fails to explain what the tool returns (e.g., dates, periods). The '4-level cascade' is not elaborated, and the agent lacks enough context to understand the tool's output or usage sequence.
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%; the schema already describes the required fields. The description provides an example request body but no further elaboration on parameter meanings or constraints. Baseline of 3 is appropriate as the description adds minimal value.
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 'Ashtottari Sookshmadasha — 4-level cascade', which hints at the tool's function but does not clearly explain that it calculates the fourth-level sub-period within the Ashtottari Dasha system. The example provides a request body but lacks explicit purpose. It distinguishes itself from siblings only by name, not through a clear description.
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 other dasha tools (e.g., antar, prana). There is no mention of prerequisites or context for usage, leaving the agent without direction on appropriate 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds only the phrase '5-level cascade (finest grain)', which hints at computational depth but does not detail behavior (e.g., returns subdivisions, requires specific inputs). No annotation contradiction.
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 very short (one line plus example), which is concise but lacks substance. It front-loads the name and level but misses key details. While not verbose, it sacrifices informativeness for brevity.
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 high complexity of Vedic dasha systems and the presence of many sibling dasha tools, the description is insufficient. It does not explain what a 'pranadasha' is, the significance of 'finest grain', or what the output contains. An agent cannot reliably understand when to invoke this 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 description coverage is 100%, so the input schema already describes all parameters. The description adds no additional meaning beyond what is in the schema, providing no syntactic or semantic clarification. 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 names the dasha system ('Tribhagi Pranadasha') and mentions '5-level cascade (finest grain)', which hints at the tool's function. However, it lacks a clear verb+resource statement (e.g., 'computes the prana sub-period'). With many sibling dasha tools, this is insufficient to distinguish from similar tools like vedic_dashas_tribhagi_antar or vedic_dashas_tribhagi_sookshma.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention exclusions, prerequisites, or compare with other dasha tools. The example request body is present but does not clarify 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no behavioral context. The phrase '4-level cascade' is vague and does not explain what the tool returns 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 is very short (one line plus an example), which is concise but at the cost of completeness. It is front-loaded with the title and description, but the lack of essential information makes it insufficient.
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. Among many sibling dasha tools, the description fails to differentiate this one's output or use case. The example only covers input, not output.
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 already provides detailed descriptions for the input body and its fields, covering 100% of parameters. The description adds an example request, which is helpful for formatting but does not add new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Tribhagi Sookshmadasha — 4-level cascade' hints at the function but lacks an explicit verb like 'calculates' or 'returns'. The example request provides context, but the purpose is not clearly stated, leaving ambiguity among sibling dasha 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 guidance is given on when to use this tool versus alternative dasha levels (e.g., mahadasha, antardasha, pratyantardasha). The description does not mention prerequisites, exclusion criteria, or sibling 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?
Annotations already indicate read-only, idempotent, non-destructive. Description adds that it outputs triggers and remedies but no details on process, dependencies, or limitations. Minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus example, very concise but omits essential information. Not a model of conciseness when clarity suffers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no output schema, and many sibling tools, the description lacks completeness. No information on output format, interpretation of triggers/remedies, or prerequisite knowledge. Severely insufficient for effective tool selection/invocation.
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?
Schema description coverage is 0% and the description only provides an example with 5 of 11 parameters. No explanation of what each parameter means or how they affect the result. Required fields (date, time) are not described.
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 assesses Pitri Rin (paternal-debt dosha) using Lal Kitab patterns, with triggers and remedy. This distinguishes it from other dosha tools (e.g., Parashara, KP) by specifying the Lal Kitab system.
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 siblings like vedic_doshas_lal_kitab_full or vedic_doshas_parashara_pitru. Lacks explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, and idempotent. The description adds only 'element-based intensity + recommended/avoid activities', which does not disclose additional behavioral traits such as output format, required auth, or limitations.
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 very short and front-loaded, but it omits important details. It is concise but at the cost of completeness.
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 tool returns or how the input parameters relate to the output. The context of birth data usage is implied but not explicitly stated.
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 provides 100% coverage with descriptions for all 7 parameters. The description includes an example request body but adds no further semantic meaning beyond the schema.
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 'Element-based intensity + recommended/avoid activities' and the title says 'Exercise Recommendations', which gives a general idea but lacks a specific verb+resource. It does not clearly differentiate from sibling tools like wellness_yoga or wellness_diet.
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 other wellness tools. No exclusions, prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context (e.g., what the tool returns, side effects, or prerequisites). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise but at the expense of clarity. It front-loads keywords effectively but lacks a clear statement of the tool's function. The example is helpful but minimal.
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 Zi Wei Dou Shu and the existence of many palace siblings, the description is insufficient. It does not explain the output (no output schema), prerequisites, or how the tool fits into the broader system.
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 all parameters are documented in the input schema. The description provides an example request body, adding marginal value. However, it does not explain how the date relates to children/fertility interpretation.
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 'Children, fertility, juniors' which indicates the domain but does not specify the action (e.g., 'calculate', 'interpret', 'get'). The example request body hints at usage, but the purpose is vague for an agent selecting among many palace 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 guidance on when to use this tool versus sibling palace tools like ziwei_palace_career or ziwei_palace_wealth. The group label 'Zi Wei Dou Shu (Purple Star) — MVP' provides context but no differentiation from similar 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral traits beyond these, so it does not contradict but also does not add value. A score of 3 is appropriate since the annotations handle the safety profile adequately.
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 very concise at two lines plus an example, which is efficient but sacrifices completeness. Every sentence earns its place, but the example is vague and does not clarify parameter usage. It is appropriately front-loaded with the purpose and group.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (16 parameters, no output schema), the description is severely incomplete. It omits explanations for essential parameters like timezoneOffset, latitude, longitude, zodiacType, ayanamsaId, cosmogram, targetTime, converse, withTnp, etc. The agent cannot determine how to correctly set these parameters from the description alone.
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?
With 16 parameters and 0% schema description coverage, the description should compensate but fails to do so. The example only shows placeholders 'chart' and 'targetDate' without explaining any specific properties. No parameter semantics are provided beyond what is in the raw 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 computes transits hitting natal midpoints in a 90° dial, specifying the verb 'hitting' and the resources 'transits' and 'natal midpoints'. It distinguishes from general transit or midpoint tools by mentioning the 90° dial and the Cosmobiology group. However, it does not explicitly differentiate from other cosmobiology tools like 'cosmobiology_midpoint_pictures' or 'transits'.
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?
There is no guidance on when to use this tool versus alternatives. The description only mentions the Cosmobiology/Hamburg School group for context but does not state when-not-to-use or suggest sibling tools. The example request body is too vague to provide 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal behavioral context beyond annotations; it does not mention what is computed (e.g., specific return ages, number of returns), nor the output format. For a tool with complex behavior, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (2 lines) but includes a group tag. It is front-loaded with the main purpose, but the brevity sacrifices clarity. Every sentence earns its place, but there is too little substance for effective tool selection.
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 (calculating Saturn returns for up to 8 family members with detailed birth data), the description is woefully incomplete. There is no output schema, no mention of return types, and no explanation of the computation. The agent cannot infer what the tool actually produces or how to interpret results.
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 description coverage is 0% according to context, meaning no descriptions for individual properties. The tool description does not explain the 'members' parameter or any of its subfields, even though the schema includes a description for items. The description adds no value beyond the schema, leaving the agent unaware of requirements like date formats or location defaults.
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 'Saturn return timing across a family cohort' clearly indicates the tool calculates Saturn return timing for multiple family members, distinguishing it from many other family astrology tools. However, it lacks a verb like 'calculates' and does not specify what 'timing' entails (dates, intervals, etc.), and it does not differentiate from sibling tools such as family_genogram or family_sibling_dynamics.
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 such as family_genogram or family_system_pattern. There are no usage conditions, prerequisites, or hints about when to prefer this tool over others in the family astrology group.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds no behavioral context beyond the group tag. No mention of what the synastry entails or how it handles inputs.
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 very short (two sentences) with a clear group label. It is front-loaded but overly minimalist.
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 3 nested object parameters, the description is incomplete. It does not explain the relationship between sibling1, sibling2, and optional parent, nor what the computed dynamics include.
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 for the nested objects, describing required fields and defaults. The description adds no additional parameter meaning.
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 'Inter-sibling synastry and dynamics' which indicates the domain but lacks a specific verb. It does not clearly distinguish from other family astrology tools like family_genogram or family_parent_child_deep.
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. No mention of prerequisites or context. The description does not help the agent decide between this and sibling 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?
Annotations (readOnlyHint=true, idempotentHint=true) already indicate no side effects. The description adds no behavioral context beyond the figure's symbolic meaning. It does not disclose any traits like authentication needs, rate limits, or response characteristics.
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 very short (one line plus group and example). It is front-loaded with key symbolic meaning and is not wordy. It earns its place by being efficient, though it could be slightly more informative without bloat.
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 geomantic figures and the lack of an output schema, the description should explain what the tool returns (e.g., an interpretation, associated meanings, or usage). It fails to provide a complete understanding of the tool's functionality for an AI 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?
The input schema has 100% description coverage for the 'body' parameter, which instructs to see the tool description for required fields. However, the tool description only provides an empty example '{}', adding no further structure or meaning. Baseline 3 is appropriate as the schema handles the parameter definition.
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 the geomantic figure's meaning ('Loss, letting go, slipping away') and groups it under Geomancy (Agrippa), which helps identify the domain. However, it does not specify what the tool does (e.g., interprets, calculates, or returns details about the figure). The purpose is vague but not a complete tautology.
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 its many geomantic siblings (e.g., geomancy_acquisitio, geomancy_albus). The agent receives no context for selection based on user intent or other factors.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description's addition of 'endings, exit' adds metaphorical context but no operational behavioral details. It does not contradict annotations (no contradiction).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, including a group label and an empty example. While it is concise, it is not efficient because it omits crucial information, making the brevity a drawback rather than a virtue.
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 the loosely defined input, the description does not explain what the tool returns or how to interpret the output. Sibling tools are not referenced for consistency, leaving the context incomplete for an agent to use effectively.
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 a single 'body' parameter with a description that refers to an example, but the tool description provides only an empty JSON example ({}). This fails to clarify what fields or structure are expected, adding no meaningful semantics beyond the schema's own weak description.
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 associates the tool with 'Cauda Draconis — endings, exit', which provides thematic meaning and distinguishes it from sibling geomancy_caput_draconis. However, it lacks a specific verb (e.g., 'return', 'interpret') to state what the tool does, making the purpose somewhat vague.
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 versus its siblings (e.g., geomancy_caput_draconis for beginnings). The description does not mention context or alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds minimal behavioral context (tradition group) but does not contradict annotations. It does not delve into additional traits like auth requirements or rate limits, but annotations suffice.
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 very short (one line plus group/example), which is concise, but the example is unhelpful and the overall content lacks substance. It is not front-loaded with critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and a complex astrological concept, the description is severely incomplete. It does not explain what dodecatemoria are, what inputs are required, or what the output represents, leaving the agent with virtually no context.
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?
With 0% schema description coverage, the description must clarify parameters, but it only offers a placeholder example '{"...chart":"..."}'. None of the 11 parameters (e.g., date, time, zodiacType) are explained, leaving the agent to guess their meaning and format.
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 'Dodecatemoria sub-divisions of zodiac,' clearly indicating the tool computes these astrological sub-divisions. However, it does not differentiate from the similar sibling 'hellenistic_greenbaum_duodecima' (which also deals with 12th divisions), missing an opportunity to distinguish.
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 provides an example request body but lacks context about prerequisites, typical use cases, 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?
Annotations already indicate readOnlyHint, idempotentHint, and non-destructive behavior. The description adds group/tradition context but no additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but poorly structured; the example is unhelpful and the group notation adds minimal value. It is concise but lacks clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, specialized tradition), the description is severely lacking. It fails to explain what the tool returns or how input parameters are used.
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?
With 0% schema description coverage, the description must explain parameters, but it only provides a cryptic example ('{...chart:...}') with no actual semantics. None of the 11 parameters are described.
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 'Temple-house assignments per Greenbaum', which indicates a specific function within the Greenbaum tradition. However, it does not differentiate from many sibling tools with similar names, leaving ambiguity about what 'temple' means.
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 like other hellenistic_greenbaum tools. The agent has no basis for selection other than the name.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) cover basic safety and idempotency. The description adds no behavioral context beyond these, but does not contradict them. With annotations doing the heavy lifting, a score of 3 is appropriate.
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 very short (two sentences plus group and example), but it lacks structure and fails to include essential information. Conciseness is good, but at the expense of clarity and completeness.
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 11 parameters, 2 required, no output schema, and no parameter descriptions, the description is severely incomplete. It does not explain the output format, how parameters like cosmogram or houseSystem affect results, or what the example body signifies. The agent has insufficient context to use the tool effectively.
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 description coverage is 0%, so the description must provide parameter meaning. However, it only shows a cryptic example request body with a placeholder '{"...chart":"..."}', which adds no value. Parameters like ayanamsaId, cosmogram, and zodiacType remain unexplained, leaving the agent to guess from names.
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 'Zodiacal decans with attributions' and the group, indicating the tool provides decans from the Hellenistic Greenbaum tradition. However, 'attributions' is vague and doesn't specify what the output includes (e.g., degrees, rulers, interpretations). The purpose is clear enough to identify the subject matter but lacks precision.
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 its many siblings (e.g., hellenistic_greenbaum_dodekatemoria, hellenistic_greenbaum_antiscia). The description only mentions the group and an incomplete example, offering no context about prerequisites or 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it computes decan rulers per planet and belongs to the Hand tradition, which is consistent. No additional behavioral traits like rate limits or prerequisites are disclosed, but annotations cover the core safety profile.
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 very short and front-loaded with the purpose. However, the truncated example and lack of structure reduce clarity. It is concise but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description fails to provide essential context. It does not explain input effects, return values, or constraints, making it inadequate for accurate tool invocation.
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?
Schema description coverage is 0%, and the description provides no explanation of any parameter (e.g., date, time, zodiacType). The example is truncated and unhelpful. Without parameter semantics, the agent cannot correctly construct requests.
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 'Chaldean decan rulers per planet' which clearly indicates the tool computes decan rulers associated with planets. The group label 'Hellenistic — Hand tradition' further distinguishes it from other decan tools. However, it does not specify what exactly is returned (e.g., list of rulers, positions).
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 hellenistic_greenbaum_zodiacal_decans or hellenistic_hand_bounds. The description lacks context for selection, requiring the agent to infer from the tradition 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Seeded' which aligns with idempotency and indicates deterministic behavior. Mentions '3-coin method' which is a behavioral detail. However, does not describe what the tool returns or any side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short with two segments: a one-sentence description and an example. It is concise but at the expense of completeness. The structure is adequate but could be improved by front-loading key 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?
With no output schema and a single parameter, the description should at least hint at the output format (e.g., hexagram, lines). It does not. Annotations cover safety but the description lacks essential context for an AI agent to understand the tool's function fully.
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?
Only one parameter 'seed' with 0% schema description coverage. Description mentions 'seed' in example body but does not explain its purpose (e.g., for reproducibility) or allowed types (number/string). The tool does not compensate for the lack of schema description.
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?
Description states 'Seeded 3-coin method' which indicates the action (coin tossing) and the resource (I Ching hexagram generation), but it does not explicitly mention that it returns a hexagram or reading. Among siblings like iching, iching_by_question, etc., the differentiation is minimal. The name and title help but the description itself is vague.
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 iching or iching_with_changing_lines. The group marker '[Group: I Ching (Standalone)]' is present but does not provide usage context. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotent and read-only hints. The description adds no behavioral context, such as what data is returned, limits, or side effects. It merely repeats the concept of lunar archetypes.
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 very short (two sentences) and thus concise, but it sacrifices necessary detail. An example is given, though in an incomplete format.
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 11 parameters, no output schema, and many sibling tools, the description fails to explain what 'lunar archetypes' are, how sign and house are used, or what the output contains. The example is unhelpful.
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 description coverage is 0%, so the description must compensate, but it does not describe any parameters. The only clue is the mention of 'sign and house', which is not mapped to specific parameters. The example request body is incomplete and unhelpful.
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 'Lunar archetypes by sign and house' and groups it under 'Modern Psychological', which distinguishes it from other lunar tools like lunar_calendar or lunar_return. However, it does not explicitly differentiate from other Greene tools or specify exactly what 'archetypes' means.
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 only usage hint is an example request body, which is incomplete and does not clarify context 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?
Annotations provide readOnlyHint, destructiveHint, and idempotentHint. The description adds the behavioral detail that it performs an '8-phase classification', which is beyond annotations but still lacks specifics on the output or process.
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 very short, but the example request body is incomplete and not informative. While brevity is valued, the lack of substance reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters with no descriptions, no output schema, and the tool performing a specific astrological classification, the description is severely incomplete. It fails to explain what the 8 phases are, how to use the parameters, or what the output contains.
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?
Schema description coverage is 0% and the description does not explain any of the 11 parameters. The example body with '{...chart:...}' is vague and does not map to actual parameters.
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 '8-phase lunation classification', which clearly identifies the tool's purpose as classifying lunation phases into 8 phases. The group label 'Modern Psychological' helps distinguish it from other Rudhyar 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?
There is no guidance on when to use this tool versus alternatives. No context is provided about prerequisites, when not to use it, or comparisons with similar tools like 'moon_phase' or other modern_rudhyar_* tools.
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?
The description claims the tool calculates from initials of the full name, implying a 'name' input, but the input schema only contains date, latitude, longitude, and timezoneOffset. This mismatch is highly misleading for the 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 is short and includes an example, but the example is inconsistent with the input schema. Every part should be accurate.
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 present, and the description does not explain what the tool returns. The mismatch between description and schema leaves the agent lacking critical 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 the schema already describes the parameters. The description adds no additional parameter meaning beyond the existing schema descriptions. The example includes 'name' which is not a parameter, reducing reliability.
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 calculates the Balance number from initials of each part of the full name using the Kabbalistic phonetic system. However, it does not differentiate from the sibling 'numerology_kabbalistic_strict_balance' tool.
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 any when-to-use or when-not-to-use information.
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?
Annotations already indicate readOnlyHint and idempotentHint, which the description aligns with. However, the description adds little behavioral detail (e.g., what the output looks like, how the calculation works) and introduces confusion with an example that includes 'name' and 'year' fields not present in the input 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 brief and front-loaded with the action, but the example request body adds noise without matching the schema, reducing 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?
Without an output schema, the description should hint at the return value but does not. The parameter set (including location) is not justified for numerology, leaving the tool's completeness in question.
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 coverage is 100% but the description does not enhance understanding of the parameters. The purpose of latitude, longitude, and timezoneOffset for a numerology calculation is unexplained, and the example contradicts the schema by listing extra fields.
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 calculates the Personal Year number for a given calendar year within a 9-year cycle, and specifies it uses the Kabbalistic phonetic system. This distinguishes it from other numerology systems (e.g., Chaldean), but it does not differentiate from the 'strict' variant of the same system.
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?
There is no guidance on when to use this tool versus similar ones (e.g., Chaldean personal year) or what prerequisites are needed. No context is provided for the ideal scenario or 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no behavioral context beyond the calculation itself, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the example request body includes a 'name' key that does not match the schema, making it misleading. Concise but inaccurate.
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?
Many sibling tools (e.g., numerology_kabbalistic_strict_soul_urge) exist. The description fails to differentiate between Kabbalistic and other systems, or between 'strict' variants. Lacks completeness for an astrology/numerology domain.
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 description mentions a 'name' parameter in the example, but the input schema contains no 'name' property. Schema coverage is 100%, so the description misleads agents about required parameters rather than adding 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 the tool calculates the Soul Urge number from vowels of the full birth name, which is specific. However, it references a 'name' parameter not present in the schema, introducing confusion.
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 the many similar sibling numerology tools (e.g., Chaldean, Pythagorean, strict variants). No when-not-to-use or alternative mentions.
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?
Annotations provide readOnlyHint, destructiveHint, and idempotentHint, so the behavioral profile is clear. However, the description does not add extra behavioral context and introduces confusion by implying a 'name' input that is not in the schema, which could mislead the agent about required parameters.
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 with two sentences, a group label, and an example. However, the example does not match the schema, and the brevity leads to omission of critical input specification, reducing overall effectiveness.
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?
Missing crucial input 'name' that the calculation requires, and no output schema or description of return values. The tool's behavior is incomplete without knowing how to provide the name or what the response contains.
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 coverage is 100% but descriptions are minimal (e.g., 'Date YYYY-MM-DD'). The description adds no parameter explanations and presents an example with 'name', which is not a defined parameter, causing confusion instead of adding meaning.
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 calculates the Balance number from initials using the Vedic system, distinguishing it from sibling tools like numerology_chaldean_balance or numerology_pythagorean_balance. However, confusion arises because the example includes a 'name' field absent from the schema, slightly undermining 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 explicit guidance on when to use this tool versus alternatives. The group label 'Numerology — Vedic' hints at system selection, but there is no mention of use cases, exclusions, or comparisons to other numerology balance 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no extra behavioral context beyond what annotations provide (e.g., no mention of limitations, rate limits, or what the tool returns).
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, includes a group tag and an example, making it efficient. However, it could still be improved by adding more useful information without becoming 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?
Given the large number of sibling pet astrology tools, the description lacks differentiation and does not explain what the output is (no output schema). The tool's role in the broader pet astrology context is unclear.
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%, baseline is 3. The description includes an example request body that may help with format, but it does not explain any parameter semantics beyond what the schema already describes.
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 mentions 'Personality + temperament + best-suited household' which gives a general idea, but it does not explicitly state that it uses birth date to compute the sun sign. The example request body implies it, but the purpose remains somewhat vague, especially given sibling tools like pet_personality and pet_temperament.
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?
There is no guidance on when to use this tool versus similar sibling tools such as pet_personality, pet_temperament, or pet_birth_chart. No context about prerequisites or scenarios 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?
Annotations indicate readOnlyHint=false, but the description adds no behavioral context beyond that. It does not explain whether the tool opens a persistent stream, requires authentication, or has side effects, leaving critical behavioral details unspecified.
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 very short and to the point, with no wasted words. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a streaming tool with many parameters and no output schema, the description is critically incomplete. It does not explain the streaming mechanism, output format, or how the agent should handle the stream, making it hard to use correctly.
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 schema has 100% coverage for parameter descriptions, but the tool description adds minimal value—only an example body. It does not explain the 'hours' or 'orb' parameters beyond what the schema already 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 'Natal-transit hits within next N hours' clearly indicates the tool computes upcoming transit aspects to a natal chart. The title and group help, but the description does not explicitly state the verb (e.g., 'stream' or 'list') and lacks differentiation from other streaming transit 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 guidance is provided on when to use this tool versus alternatives. There are many sibling tools for transits and streaming, but the description gives no when/not-to-use advice or references to 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?
Annotations indicate the tool is not read-only, not destructive, not idempotent, and open-world, but the description adds minimal behavioral context. It does not explain what 'stream' means (e.g., SSE, WebSocket, polling), how the connection works, or whether authentication or rate limits apply.
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 very short and front-loads the purpose, then group, then example. This is concise but the structure is minimal, and the example is unhelpful (empty object). Some sentences lack actionable 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?
No output schema is provided, and the description does not explain the return format (e.g., JSON fields, streaming events). For a streaming tool, this omission is critical; the agent cannot know what data to expect or how to parse it.
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?
There is only one parameter ('body') with schema coverage 100%, but its description merely points to an empty example. The description does not explain what fields the body can contain or what the expected format is, leaving the agent confused.
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 returns 'Current Moon VOC + next ingress,' which is specific. However, it does not differentiate from sibling tools like 'moon_voc' or 'horary_moon_voc' that also deal with Moon void-of-course; the 'Stream' prefix and group hint at real-time updates but are not explicit.
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 streaming tool versus other Moon VOC tools or alternative streaming endpoints. The agent is left to infer usage from the name and group 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context ('4-level cascade') but does not disclose return behavior or computational details. With annotations, a score of 3 is appropriate.
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 extremely concise: one line plus an example. Every part is meaningful and no words are wasted. However, it could be slightly more informative without losing 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?
Given the tool's complexity (4-level cascade, many parameters, no output schema), the description does not explain what the tool returns or how to interpret results. It lacks context about the computation and output 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 description coverage is 100%, so the schema already explains the body parameter and its sub-properties. The description adds an example request, which is helpful but not necessary. Baseline 3 is correct.
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 'Sthira Sookshmadasha — 4-level cascade' which identifies the specific dasha type and level, but does not distinguish it from sibling tools like other sookshma dashes. The purpose is somewhat clear but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 other vedic dasha tools (e.g., maha, antar, prana). No 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, etc., providing a clear safety profile. The description adds an example request body but no additional behavioral context (e.g., what data is returned, side effects). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with key phrases. It includes a group label and an example request, both useful. Every sentence contributes value without excess.
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 lacks information about return values or output format, which is critical given no output schema. It does not explain when to use optional parameters (latitude, longitude, timezoneOffset) or what the response contains. For a complex astrology tool, this is insufficient.
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 provides an example request body showing the required date parameter, but adds no further meaning beyond what the schema already describes for each parameter.
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 'Life path, character, soul mission' gives a vague sense of the tool's purpose but does not clearly state that it provides an interpretation of the Destiny Palace in Zi Wei Dou Shu. It lacks specificity and does not distinguish from sibling tools like ziwei_palace_career or ziwei_main_stars.
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?
There is no guidance on when to use this tool vs alternatives, such as other ziwei palace tools. The description does not mention use cases, prerequisites, or situations 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns positions and mentions a credit cost, but does not disclose additional behavioral traits such as rate limits or required permissions. Value added is minimal beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a metadata group and cost. However, the example request is inconsistent with the schema, and the lack of parameter guidance makes it less useful. It could be more informative without adding much length.
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?
For a tool with 11 parameters, no output schema, and zero parameter descriptions, the description is incomplete. It fails to explain how to specify custom lots, the role of zodiac type, or the output structure. The example mismatch further reduces completeness.
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?
With 0% schema description coverage, the description must explain parameters but fails. The example includes a 'lots' array not present in the input schema, creating contradiction. Parameters like zodiacType and ayanamsaId are not explained, leaving critical ambiguity.
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 calculates Arabic parts (Lots) from a natal chart and returns positions for standard and custom lots. However, it does not differentiate from specialized sibling tools like hellenistic_brennan_lots_15 or hellenistic_greenbaum_lot_of_eros_detail, which may cause confusion.
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 lacks explicit when-to-use or when-not-to conditions, leaving the agent to guess based on tool 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description need not repeat safety traits. The description adds the figure's meaning but no additional behavioral context (e.g., whether it requires a chart or returns static text). It does not contradict annotations, so a baseline 3 is appropriate.
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 very short (three lines) and includes a group label, which aids categorization. It is front-loaded with the figure's meaning. However, it could be more informative while remaining concise; the brevity risks being insufficient.
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 single parameter, the description should explain what the tool returns and what the body input expects. It only states the figure's meaning and provides an empty example, leaving the tool's functional contract incomplete.
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 one required parameter 'body' described as 'Raw JSON body — see the example in the tool description for required fields'. The example is an empty object {}, providing minimal guidance. The description adds no meaning beyond the schema, leaving the agent uncertain about what properties to include or what the body represents.
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 the meaning of the geomantic figure Acquisitio as 'Gain, profit, abundance' and groups it under Geomancy (Agrippa), giving some context. However, it lacks a verb to indicate what the tool does (e.g., 'returns the interpretation'), and the purpose is not fully explicit. Among many geomancy sibling tools, this one is differentiated by its title, but the description is too vague to clearly distinguish its action.
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. There is no mention of prerequisites, context, or exclusions. The sibling tools include many other geomantic figures, but the description offers no criteria 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?
Annotations (readOnlyHint=true, destructInfo=false, idempotentHint=true) already establish the tool as safe and non-destructive. The description adds no behavioral context beyond the symbolic meaning, which does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (2 lines including group and example), which is efficient for a simple concept. No superfluous text, but could add more substance without becoming 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?
Missing details about return values (no output schema), and the parameter example is empty. For a tool with many geomancy siblings, more context is needed to distinguish its output and usage.
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 schema has 100% coverage but the parameter description only says 'Raw JSON body — see the example in the tool description for required fields', and the given example is an empty object {}. This provides no meaningful guidance on what fields the body should contain.
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 'beginnings, threshold' and groups it under Geomancy (Agrippa), which hints at the symbolic meaning of the Caput Draconis figure. However, it lacks an explicit verb or action (e.g., 'returns interpretation of') and does not differentiate from sibling geomancy 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 guidance on when to use this tool versus other geomancy figures like geomancy_cauda_draconis or geomancy_fortuna_major. The agent receives no 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds minimal behavioral context beyond listing the circuits/sub-circuits analyzed. No disclosure of response format, pagination, or 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. Extra info like group and cost is included but not excessive. However, it could be slightly more efficient by removing the example or moving cost info.
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 11 parameters, no output schema, and many sibling tools, the description is incomplete. It lacks parameter explanations, return value details, and differentiation from similar tools.
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 description coverage is 0%, yet the description does not explain the purpose or syntax of most parameters (e.g., houseSystem, zodiacType, cosmogram). Only an example is provided, leaving 9 undocumented parameters.
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 Circuit and Sub-circuit activation in a Human Design chart based on defined channels. It specifies the resource and output, distinguishing it from general HD tools like human_design. However, it does not explicitly differentiate from siblings like hd_group_overlay.
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 hd_group_overlay or hd_hologenetic. The description simply states what it does without usage context.
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 adds behavioral context beyond annotations: 'AI-written, ephemeris-grounded' and a cost note. However, the example request body shows parameters (natal, weekStart) not in the schema, which could mislead about actual tool behavior. Annotations already cover readOnly and idempotent nature, so the description adds limited value.
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 short and front-loaded, but it includes a misleading example with parameters not in the schema. The cost and group metadata are useful but add to visual clutter. Overall, it is moderately concise but structurally flawed.
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 4 parameters, 0% schema coverage, and no output schema, the description should provide more context about parameter usage and expected output. It includes cost and group info but lacks explanation of what the response contains or how to use the parameters correctly. The inconsistent example further reduces completeness.
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?
Schema description coverage is 0%. The description does not explain any of the 4 parameters (sign, date, language, disclaimer_inline). The example request body includes a completely different set of parameters (natal, weekStart) not in the schema, creating confusion rather than clarity. This significantly hinders correct invocation.
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 weekly horoscope with a 7-day window, key transit events, and themes, and notes it is AI-written and ephemeris-grounded. However, it does not explicitly differentiate from sibling tools like horoscope_daily or horoscope_monthly, and the example request body includes parameters not in the schema, causing some confusion.
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 the many other horoscope tools (e.g., horoscope_daily, horoscope_monthly). The group label '[Group: Horoscope]' is too vague. Without explicit usage context, an agent cannot easily decide when to invoke this tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds that the output is a 'multi-round transcript', which provides some behavioral context beyond annotations. However, no additional traits like response format or side effects are disclosed.
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 very short (two lines plus example), which is concise but at the cost of omitting important details. It front-loads the purpose, but the lack of structure (e.g., no bullet points or sections) reduces usability. It is not overly verbose but is insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, including a complex nested object (chart) and enum (language), the description is severely incomplete. It does not explain the chart parameter's role in a debate, the expected format of agent strings, the output transcript structure, or language support. Without an output schema, the description fails to convey what the tool returns.
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 coverage is only 17% (only 'chart' has a description). The overall description only repeats the parameter names in the example and does not explain what 'agentA' and 'agentB' represent (e.g., persona descriptions), nor the purpose of 'chart' or 'language'. The schema includes details for 'chart' but the description adds little beyond that.
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 '2 personas debate a topic, multi-round transcript' which specifies the verb (debate) and resource (personas). The example request body further clarifies the required parameters. While it doesn't explicitly differentiate from siblings, the tool name and purpose are distinct enough among the MCP tools (e.g., mcp_multi_agent_coordinate).
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 about prerequisites, when not to use, or comparisons with sibling tools like mcp_multi_agent_coordinate or mcp_multi_chart_context. The example is shown but without usage advice.
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?
Annotations (readOnlyHint=true, destructiveHint=false) already inform the agent of safety traits. The description adds no behavioral details beyond what annotations provide, so it neither contradicts nor enhances 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 extremely short (one sentence plus a group tag). While concise, it sacrifices informativeness for brevity. It could be restructured to include essential details without becoming bloated.
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 a complex parameter (array of objects with many fields), no output schema, and no description of return value, the description is incomplete. It fails to explain what 'context' is returned or how the tool behaves across multiple charts.
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 tool description itself offers no parameter guidance, but the input schema includes a description for the array items explaining required fields and defaults. However, the description does not clarify that 'inputs' accepts multiple birth data objects (minItems 2), which is a key semantic detail.
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 'Compact context for MCP agents working across multiple charts,' which indicates the general domain but does not specify the actual operation (e.g., compute, summarize, compare). It is too vague to distinguish from siblings like 'chart' or 'composite'.
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, nor are any prerequisites or exclusions mentioned. The description lacks any usage context.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, confirming a safe read operation. The description adds that the tool calculates symmetries, but it does not disclose any additional behavioral traits such as result format or pagination. The annotations carry the main transparency burden, so a score of 3 is appropriate.
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 and front-loaded with the core action. The group and cost lines are placed near the beginning. It is efficient with minimal fluff, but the brevity leaves some gaps in completeness.
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 11 parameters, 0% schema coverage, and no output schema, the description is insufficient. It does not explain what 'Uranian midpoint trees' or 'planetary pictures' are, nor what the output contains. Users are left to infer from the example, which is inadequate for a complex astrological calculation.
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?
With schema description coverage at 0%, the description must explain parameters but fails entirely. The example shows an 'orb' value but does not describe any parameter semantics. All 11 parameters remain undocumented, making it very difficult for an agent to construct correct requests.
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 calculates Uranian midpoint trees and planetary pictures for each focal planet within an orb. It uses specific terminology that distinguishes it from generic midpoint tools, though it does not explicitly differentiate from similar siblings like 'midpoints' or 'cosmobiology_midpoint_pictures'.
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 metadata (group, cost) and an example request body but offers no guidance on when to use this tool over sibling tools. It lacks explicit when-to-use, when-not-to-use, or alternative references.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description does not add behavioral context such as return format, limitations, or side effects. It does not contradict annotations, but it also does not enhance understanding beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line plus example), but it is too brief for a tool with 7 parameters and no output schema. While front-loading is fine, the content is insufficient to convey the tool's purpose and usage effectively. Every sentence earns its place, but there are too few sentences.
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 tool's custom nature (pet astrology diet), the description is incomplete. It does not explain what the output contains (e.g., dietary recommendations, foods, meal plans), how the element determines dietary focus, or any prerequisites. The group label helps but is insufficient for full 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?
The input schema has 100% description coverage, so all 7 parameters are adequately described in the schema. The description adds no additional meaning beyond the schema; it only provides an example request body. With high schema coverage, baseline score is 3.
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 'Element-based dietary focus' which hints at the tool's purpose but is vague. The title 'Diet by Sign' and the group label '[Group: Pet Astrology]' provide context, but the description does not explicitly state that it provides dietary recommendations for pets based on their astrological sign or element. It lacks specificity about the resource (pet diet) and action.
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. Sibling tools like 'wellness_diet', 'pet_sun_sign_meaning', or other pet-specific tools exist, but the description does not differentiate this tool or specify contexts where it is appropriate. No exclusions or when-not-to-use information is given.
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?
Description says 'Rectify' which implies a transformative action, but annotation declares readOnlyHint=true, creating a contradiction. No further behavioral traits beyond cost warning are disclosed.
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 purpose, includes group and cost warning, and provides an illustrative example. While the example adds length, it is justified. No extraneous content.
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 complex nested input and no output schema, yet the description omits what the tool returns (e.g., rectified time, confidence). Key parameters like methods and orb are not explained. The example is incomplete, lacking these parameters.
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 description coverage is only 17%, and the description adds no parameter explanations beyond the example. The schema provides limited descriptions for baseInput but not for other parameters like methods or orb, leaving the agent underinformed.
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?
Description clearly states the verb 'rectify' and resource 'birth time' with method 'using life events and transit/direction hits'. However, it does not explicitly differentiate from the sibling tool 'rectification_trutine', though the mention of transit/direction hits implies a different approach.
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 includes a cost warning ('Heavy — confirm with user') and provides an example request body, but no explicit guidance on when to use this tool versus alternatives like rectification_trutine. Usage is implied but not formally stated.
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?
Annotations declare readOnly=true, not destructive; description adds that it involves Rahu sub-lord chain but does not elaborate on output format or behavior, leaving gaps beyond 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?
Very short description, includes group tag and example; could be more informative but is appropriately 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 no description of return values; many optional parameters are unaccounted for, leaving the tool's overall behavior underspecified.
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 11 parameters with 0% description coverage; description only includes an example request body without explaining any parameter semantics or constraints.
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?
Description states it calculates Kalasarpa dosha with KP Rahu sub-lord chain, which is clear but does not distinguish from similar sibling tools like vedic_doshas_kp_full or vedic_doshas_parashara_kaal_sarp.
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, no prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, etc., and the description adds context about the meaning of blind houses (karma unilluminated, remedies essential). However, it does not describe output format or any side effects beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences plus a group note and example. It front-loads the key concept. However, the example is somewhat redundant with the schema and could be replaced with parameter guidance.
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?
For a specialized Lal Kitab tool, the description defines blind houses but lacks information on output content, interpretation, or prerequisites. The absence of an output schema further reduces completeness. The tool would be hard to use without additional context.
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?
With 11 parameters and 0% schema description coverage, the description adds no parameter information. The example request body is provided but does not explain parameters beyond what the schema already shows. The description fails to compensate for the lack of schema 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 clearly defines what a blind house is in Lal Kitab terminology, specifying conditions (no planet, no Parashari aspect). However, it does not differentiate from sibling tools like vedic_lal_kitab_sleeping_house or vedic_lal_kitab_planet_house_effect, so the uniqueness is implied but not explicit.
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 other Lal Kitab tools. The description lacks any when-to-use or when-not-to-use context, making it difficult for an agent to select it among many siblings.
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?
Annotations already declare idempotentHint=true, readOnlyHint=true, destructiveHint=false. The description does not contradict and adds the calculation formula, but does not discuss edge cases, required permissions, or error behavior. With annotations covering the safety profile, a 3 is appropriate.
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 very short (two lines plus example). It is not bloated, but it could include a brief explanation of the output and key parameters without becoming lengthy. The example is helpful but not 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 11 parameters, no output schema, and 0% schema coverage, the description is severely incomplete. It does not describe the result format, parameter dependencies, or how the calculation works with different zodiac/ayanamsa settings. The example only covers a subset of inputs.
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 description coverage is 0%, so the description must compensate. It provides an example with 5 of 11 parameters but does not explain the meaning of any parameter (e.g., houseSystem, zodiacType, ayanamsaId, cosmogram). Many parameters are directly relevant to the calculation but are left undocumented. The formula hint is not enough.
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 it computes 'Surya-Chandra Yoga (1-27)' with a formula, which gives a specific name. However, it does not clarify what the output represents (e.g., a yoga number or name) or distinguish it from sibling tools like vedic_panchang_full or vedic_panchang_tithi. The purpose is somewhat clear but not specific enough to differentiate within the group.
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. Sibling tools include many vedic_panchang_* functions for specific calendar elements, but the description does not mention when to pick this yoga calculator over others. The 'Group: Vedic' and cost note are not usage guidelines.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by noting that Yuddha (planetary war) is deferred and that Abda/Masa rulers are currently zeroed, which are important limitations. However, it does not describe the output format or any other side effects beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loads key information ("Kala Bala — sum of..."). However, the trailing ellipsis indicates truncation, suggesting incomplete content. The structure is a single paragraph with comma-separated lists, which is adequate but not exemplary.
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 (11 parameters, no output schema, 0% schema description coverage), the description is insufficient. It does not explain what the tool returns (e.g., per-planet Kala Bala values), nor does it adequately cover input requirements beyond the example request body which is separate. The description leaves significant gaps for an AI agent.
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?
With 0% schema description coverage, the description must compensate for parameter meanings. It entirely fails to do so—it does not describe any of the 11 input parameters (e.g., ayanamsaId, cosmogram). The agent must guess from parameter names alone, which is insufficient for correct invocation.
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 identifies the tool as computing Kala Bala (temporal strength) for Vedic astrology, listing its sub-components (Nathonnatha, Paksha, etc.). The title and group context help distinguish it from other shadbala tools (e.g., vedic_shadbala_cheshta, vedic_shadbala_dig). However, the ellipsis at the end suggests truncation, slightly 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 explicit guidance on when to use this tool versus its siblings (e.g., vedic_shadbala_full for all components). The description assumes the agent knows Vedic astrology and the role of Kala Bala in Shadbala, but does not provide comparative usage context.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds source references (Jaimini Sutras 2.x and Sanjay Rath commentary) and an example request body, which provides some behavioral context. However, it does not explain what happens if the yoga condition is not met (e.g., empty result or error), and the output format is not described.
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 (two sentences plus an example), front-loading the core purpose. While efficient, it could benefit from slightly more structure, such as separating the yoga condition from the example.
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 (11 parameters, 0% schema coverage, no output schema), the description is insufficient. It fails to explain the output structure, how to interpret results, or the significance of the yoga. Domain knowledge is assumed, leaving the AI agent with little guidance.
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?
Schema description coverage is 0%, so the description must compensate. It does not explain any parameters beyond implicitly showing an example. Many parameters (e.g., timezoneOffset, latitude, longitude, houseSystem) are essential for astrological calculations but are not described. This is a critical gap.
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's purpose: 'Jaimini Raja yoga: Atmakaraka in Lagna/Kendra OR conjunct Amatyakaraka.' It specifies the exact condition for the yoga, making the purpose clear. However, it lacks an explicit verb like 'compute' or 'return,' which slightly reduces 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?
The description provides no guidance on when to use this tool versus the many sibling yoga tools (e.g., vedic_yogas_jaimini_dhana, vedic_yogas_parashara_raja). There is no mention of when to avoid it or how it differs from 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?
Annotations already indicate read-only and idempotent behavior. The description adds no behavioral traits beyond 'powerful for status and prosperity,' which is interpretive. No mention of output format, errors, or constraints. Minimal additional value over annotations.
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 the definition. The example request is helpful. No superfluous content. However, it could be restructured to include parameter hints without losing 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 no output schema, the description should explain what the tool returns (e.g., list of yogas, boolean, interpretation) but does not. Given 11 parameters and many sibling tools, the description is too sparse for an agent to use correctly without additional 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?
Schema description coverage is 0%, yet the description fails to explain any parameters beyond offering an example request body. The example only covers a subset of parameters (date, time, location), leaving 9 undocumented parameters. The description does not add meaningful semantics 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 explicitly defines Adhi Yoga as benefics in houses 6-8 from Moon, and mentions Maha Adhi Yoga. It clearly identifies the tool's function. However, it does not differentiate from sibling tools like vedic_yogas_parashara_full or vedic_yogas_parashara_dhana, so it's clear but not distinct.
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 only defines the yoga, lacking any context about preferred use cases or when to avoid 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?
Annotations already provide read-only and idempotent traits. Description adds the 'exceptionally fortunate' characterization and example request, but does not disclose what happens when yoga is absent or response format.
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?
Relatively brief, includes group and cost metadata, and an example request. Somewhat front-loaded 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?
Lacks output description, no explanation of how results are presented. For an 11-parameter tool with no output schema, completeness is inadequate.
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 11 parameters with 0% description coverage. Description only shows an example body covering 5 parameters, leaving 6 undocumented (e.g., houseSystem, zodiacType, ayanamsaId, cosmogram).
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?
Description explains the yoga but does not explicitly state the tool's action (e.g., 'Calculates' or 'Determines'). The verb is implied by the title but not stated, making it vague for an agent.
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 other yoga tools (e.g., vedic_yogas_parashara_dhana). No context on prerequisites or 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?
Annotations already indicate readOnlyHint=true, which the description aligns with. However, the description adds minimal behavioral context beyond 'explain', such as what the output format is or that it performs a computation. Without annotations, this would be lower.
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 very short (two sentences plus an example), which is concise but fails to front-load critical information. Every sentence is used, but more detail is needed for a useful description.
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 (nested chart object, 6 parameters, no output schema), the description is incomplete. It does not explain what the returned explanation looks like, how to use the chart parameter, or the role of transitDate. The low schema coverage makes this gap significant.
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 description coverage is 17%, and the tool description does not elaborate on parameter meanings beyond the example. The chart parameter is described in the schema, but others like transitPlanet, natalPlanet are not explained. The agent might not know valid values or format.
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 explains a transit aspect hitting a natal chart. The verb 'Explain' and resource 'transit hitting your natal chart' are specific. However, it mentions 'current transit' but the schema requires a transitDate, which not necessarily current. It doesn't differentiate from siblings like ai_explain_aspect.
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?
Only an example request body is provided, but no explicit guidance on when to use this tool over alternatives like ai_explain_aspect or interpret_transits. No prerequisites or context are mentioned, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety traits. It adds no further behavioral details beyond the group and cost, which is acceptable but adds little value. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus metadata) and front-loaded with purpose, but lacks structured details like required/optional parameters or output format. It is concise but under-specifies for the number of parameters.
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 has 11 parameters, no output schema, and limited annotations, the description is incomplete. It does not explain the return format, the meaning of 'key chart positions', or the effect of optional parameters, leaving significant gaps for an agent.
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?
With 0% schema description coverage and 11 parameters, the description should explain parameters but only provides an example with 5 of them (date, time, timezoneOffset, latitude, longitude). Parameters like houseSystem, zodiacType, ayanamsaId, cosmogram are completely undocumented.
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 calculates 'the planet with the highest essential dignity score across the key chart positions', providing a specific verb and resource. However, it does not specify what the 'key chart positions' are, leaving some ambiguity, and does not explicitly differentiate it from the sibling 'essential_dignities' tool, which calculates individual dignity scores.
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 groups the tool under 'Dignities & Receptions' and provides an example, but offers no explicit guidance on when to use it versus alternatives like 'essential_dignities' or 'receptions'. It lacks when-not-to-use or selection criteria.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and non-destructive. The description adds only 'Concise leadership archetype + key strengths', which hints at output but provides no additional behavioral context (e.g., no mention of data sources, update frequency, or limitations). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The example request body is helpful for formatting. However, brevity comes at the cost of missing important information, but conciseness itself is high.
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 an output schema and the abundance of sibling tools, the description is incomplete. It does not explain return values, how to interpret results, or how this tool differs from others. With 7 parameters, more context is needed for effective tool selection.
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 parameters are well-documented in the schema. The description does not add any parameter-specific meaning beyond that; the example request is present but does not explain how parameters affect output. 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 'Concise leadership archetype + key strengths' vaguely indicates the tool generates a leadership style profile based on birth data. However, it lacks a specific verb (e.g., 'generate', 'analyze') and does not clarify whether it returns an archetype name, strengths list, or full narrative. This ambiguity makes it hard for agents to distinguish from similar tools like business_founder_personality.
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. The group label '[Group: Business Astrology]' is present but does not help an agent decide between this and other business astrology tools. No exclusions or alternative tool mentions 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is safe. The description adds no behavioral context beyond these annotations, but does not contradict them. With annotations covering safety, a score of 3 is appropriate.
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 brief (two sentences plus example), but the example is lengthy and not explained. It could be structured better, e.g., with parameter descriptions or usage notes. Every sentence earns its place but lacks 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?
No output schema is provided, and the description does not mention return values (e.g., a numeric score, interpretation). Given the complexity of astrological compatibility and the large number of sibling tools, the description is insufficient for an agent to fully understand the tool's purpose and output.
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 description coverage is 0%, yet the description does not explain any of the 11 parameters. The example shows some fields but provides no semantic meaning (e.g., what 'houseSystem' represents). This is a significant gap given the high parameter count.
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 a 'Founder × partner compatibility score' and groups it under 'Business Astrology', indicating a business-focused compatibility assessment. However, it does not differentiate from other compatibility tools like horoscope_compatibility or synastry that might also be used for business pairs.
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 lacks context such as prerequisites (e.g., needing birth data of two individuals) or when not to use it (e.g., if detailed synastry analysis is needed). An example is provided but does not serve as 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral traits beyond the example request. The description does not disclose any side effects, limitations, or requirements, so it adds minimal value over annotations.
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 clear structure: purpose, group, cost, and example. However, the group and cost info could be separated into metadata. The example is helpful but adds length. Overall, it is 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?
Given the tool's complexity (11 parameters, no output schema), the description is insufficient. It does not explain the output structure, interpretation of dignities, or how parameters affect results. The example provides some context but leaves many questions unanswered, limiting an agent's ability to invoke the tool correctly.
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?
Schema description coverage is 0%, meaning none of the 11 parameters are documented in the schema. The description does not explain any parameter meanings, only shows an example body. Critical fields like 'houseSystem', 'zodiacType', 'ayanamsaId', and 'cosmogram' are left unexplained, making it very difficult for an agent to know what values to 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 clearly states the verb 'Calculate' and the resource 'five Ptolemaic essential dignities (rulership, exaltation, triplicity, term, face) and debilities for each planet.' It also lists the specific dignities, making the tool's purpose highly specific and distinct from 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?
The description includes a group tag '[Group: Dignities & Receptions]' implying a category, but no explicit guidance on when to use this tool versus alternatives like 'almuten', 'receptions', or 'disposition_chains'. No when-not-to-use or exclusion criteria 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?
Annotations already declare readOnlyHint=true (safe read) and idempotentHint=true. The description adds no behavioral context, such as what 'deep' entails (e.g., comprehensive aspects, house overlays), potential computational intensity, or output characteristics. With annotations present, the description does not compensate for missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one clause plus group tag), which is concise but sacrifices informativeness. It is front-loaded with the main purpose but lacks sufficient detail to be truly helpful. It does not waste words, but it does not earn its place either.
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?
For a tool with nested parameters and likely complex output ('deep analysis'), the description is incomplete. It does not explain what 'deep' means, what specific aspects are analyzed, or what the return structure looks like (no output schema). The annotations provide safety but not depth. The description needs to be expanded 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% with detailed descriptions for both parent and child objects (required fields, defaults, formatting). The tool description itself adds no parameter-level information, but the schema already provides sufficient semantics. 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 is a 'Deep parent-child synastry analysis', specifying the tool's function and relationship domain. The group tag further contextualizes it within Family Astrology. However, it does not explicitly differentiate from other parent-child or synastry tools among the extensive sibling list.
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 like synastry, family_sibling_dynamics, or other family tools. The description lacks any recommendation or exclusion criteria, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no further behavioral details (e.g., output format, side effects). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus example. The structure is front-loaded with the key concept. However, the first sentence is somewhat cryptic ('Long-cycle archetype') and could be clearer. Still, no wasted words.
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 minimal description. The tool does not explain what it returns (e.g., a chart, text, or numerical values) or how to interpret 'wealth cycle'. Given the large set of financial tools, more context is needed for an agent to select appropriately.
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 all parameters are described in the input schema. The description adds no additional meaning or context beyond the example request, which only shows typical values. 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?
Description states 'Long-cycle archetype tied to Jupiter and Saturn returns' which indicates a financial wealth cycle analysis, but it lacks a clear verb (e.g., 'calculates' or 'generates') and does not explicitly differentiate from other financial tools like financial_wealth_house. The purpose is hinted but not fully 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?
No guidance on when to use this tool vs alternatives. The example request body shows input format but does not explain context or exclusions. No mention of other financial astrology tools that might be more appropriate for specific queries.
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?
Annotations already declare it as read-only, non-destructive, idempotent. Description adds the source method ('per Brennan §11') as behavioral context. However, no details about output structure or side effects are provided.
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 very short, but the example is incomplete and not informative. The grouping notation is helpful but overall structure could be more detailed without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description is severely lacking. It does not explain what the lots represent, how to use the output, or any interpretation context. The agent is left with minimal understanding.
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?
Schema description coverage is 0%. The description provides no explanation of any parameter; only a vague example with a placeholder. It fails to compensate for the low 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?
Description clearly states it computes 'All 15 Hermetic Lots per Brennan §11', which is a specific and distinct purpose. The title reinforces this. Sibling tools like hellenistic_brennan_bonifications_maltreatments are different, so it is well 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 versus alternatives such as 'arabic_parts' or other Hellenistic lot calculators. There is no when-to-use/when-not-to-use or context about prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description does not contradict these and adds group context but no new behavioral details (e.g., what kind of constellations, data source).
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?
Extremely brief but front-loaded with purpose. However, the example is incomplete and misleading. Conciseness is achieved at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 2 required, and no output schema, the description fails to explain inputs, outputs, or use context. The agent cannot determine how to invoke this tool correctly.
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?
Schema has 0% coverage in description; no parameter meanings are explained. The example request body uses {'...chart':'...'} which does not match any schema parameter and adds confusion rather than clarity.
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 'Constellations beyond the zodiac' within the 'Hellenistic — Greenbaum tradition'. This is a specific verb+resource combination that distinguishes it from siblings like decans or other Hellenistic 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 guidance on when to use this tool versus alternatives. The description merely states what it does without indicating scenarios, 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?
Annotations already indicate it's read-only and idempotent. The description adds that it includes specific astrological elements and costs 50 credits, but doesn't disclose any significant behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but contains a misleading example that does not align with the schema, reducing its effectiveness. The structure could be improved by clearly mapping parameters.
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 partially mentions output contents but omits details on return format. The parameter mismatch and lack of explanations make it incomplete for a tool with 4 parameters and no output schema.
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?
Schema description coverage is 0%, and the description does not explain any parameters. Furthermore, the example request body uses fields (natal, month) that do not match the input schema (sign, date), causing confusion instead of clarity.
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 a monthly horoscope, specifying included elements (major transits, Moon phases, personal-year themes, profections-aware). This distinguishes it from siblings like horoscope_daily or horoscope_weekly.
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 other horoscope tools. Only a group tag and cost info are provided, but no when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about the 9-year cycle but does not discuss behavioral traits like error handling, output format, or the role of location parameters.
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 (two lines) but includes a confusing example request body that does not match the schema. The group tag is helpful, but the example wastes space and creates ambiguity.
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 4 parameters and no output schema, with many siblings. The description lacks explanation of the output, the meaning of personal year number, and why location parameters are included. More context is needed for an agent to use it correctly.
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 coverage is 100% but the description adds no meaning beyond schema. The example includes 'year' and 'name' parameters not present in the schema, which is misleading and contradicts the actual parameters.
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 calculates the Personal Year number for a given calendar year, specifying the 9-year cycle and Chaldean system. However, the example includes parameters (name, year) not in the schema, causing some confusion.
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 numerology personal_year tools (e.g., pythagorean, vedic), the description only implies 'Chaldean system', but does not clarify scenarios 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat those. It adds that the date is 'reduced,' but lacks other behavioral details (e.g., output format, error conditions). The description provides marginal extra context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two sentences and a group label. However, the group label ('[Group: Numerology — Kabbalistic (phonetic)]') is redundant given the title, and the example adds noise without clear benefit. The structure is adequate but not optimal.
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 large set of sibling numerology tools, the description does not help an agent distinguish between this and similar tools (e.g., 'numerology_kabbalistic_strict_life_path'). There is no output schema, and the description does not describe the return value, leaving the agent uncertain about what the tool outputs.
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 already describes all parameters (100% coverage). The description adds no additional meaning and, in fact, includes an example with a 'name' field that is not in the schema, which could mislead the agent. This reduces clarity.
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 'Calculate the Life Path number from birth date' and specifies the system as 'Kabbalistic (phonetic).' The verb 'calculate' and resource 'Life Path number' are specific. However, it does not explicitly differentiate from sibling tools like 'numerology_kabbalistic_strict_life_path,' so it loses a point.
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 other numerology life path tools (e.g., Chaldean, Pythagorean) or when not to use it. The description merely provides an example, offering no 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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and non-destructive. The description adds no additional behavioral context beyond the calculation method. No contradictions with annotations are present.
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 brief and includes a group tag and example. However, it lacks explanations for parameters and does not resolve the schema mismatch. It is concise but incomplete in conveying necessary 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 complexity of the numerology tool family and the discrepancy between description and schema, the description fails to provide a complete picture. No output schema exists, and the required input for calculation (name) is missing from the schema. The tool cannot be invoked correctly as described.
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 coverage is 100% but the description's example includes a 'name' field not in the schema, causing confusion. The description does not explain why location parameters (latitude, longitude, timezoneOffset) are relevant for a name-based calculation. This misalignment reduces clarity on parameter usage.
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 calculates the Expression/Destiny number from the full birth name using the Pythagorean system. However, the input schema does not include a 'name' parameter, contradicting the description and example. Among many similar numerology siblings, the description does not differentiate beyond the system name.
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 other expression number tools (Chaldean, Kabbalistic, Vedic). The example is present but does not clarify the context or prerequisites. The description lacks instructions on handling the missing 'name' parameter in the schema.
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?
Adds useful behavioral context by mentioning the number activates around age 35, but does not contradict annotations (readOnlyHint=true). The description adds moderate extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise with front-loaded action verb, but the inclusion of an irrelevant 'name' parameter in the example and lack of structured formatting reduce 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?
Missing essential information: no output schema to describe return value, no explanation of optional parameters, and the example introduces an extraneous parameter. This leaves the agent with significant uncertainty about the tool's behavior.
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 example request body includes "name" which is not in the input schema, potentially misleading the agent. Schema parameters have 100% coverage, but the description does not clarify the purpose of latitude, longitude, or timezoneOffset for this calculation.
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?
Clearly states the tool calculates the Maturity number (sum of Life Path and Expression) and specifies the Pythagorean system, distinguishing it from other numerological maturity tools. However, it could more explicitly differentiate from other Pythagorean numerological numbers.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., other Pythagorean numbers or maturity numbers from other systems). Lacks context for agent decision-making among numerous 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?
Annotations already indicate read-only, idempotent behavior. The description adds that it performs a calculation and mentions activation at age 35, which provides some context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with two sentences plus group label. However, the example includes an irrelevant 'name' field, causing potential confusion. It is mostly concise but slightly flawed.
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 4 parameters (3 optional) and no output schema. The description does not explain how the Maturity number is derived beyond summing two components, nor what the response contains. It fails to justify the need for location/timezone parameters, leaving gaps for an agent.
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 100% description coverage, so schema already documents parameters. The description does not add value beyond schema and includes an example with an extra field ('name') not present in schema, which could mislead. It also fails to explain optional location parameters' purpose.
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 calculates the Maturity number using Vedic numerology, specifying it is the sum of Life Path and Expression and activates around age 35. It distinguishes from other numerology systems but does not explicitly differentiate from sibling Vedic tools like life_path or expression.
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. It does not explain scenarios where maturity is relevant or provide any contextual advice. The example request body is provided, but it does not help with selection criteria.
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 annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description does not need to repeat that. However, it adds no extra behavioral context such as rate limits or output characteristics, but given annotations, score is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a useful example. However, it could be front-loaded with more actionable information rather than just 'Full personality breakdown'.
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 lacks detail on what the output contains (e.g., personality traits, scores, text), and given the large number of pet-related siblings, it does not distinguish itself. No output schema exists to compensate.
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 100% of parameters with descriptions, so the description adds no additional semantics beyond an example request body. Baseline 3 is appropriate since schema does the work.
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 'Full personality breakdown' plus the group 'Pet Astrology' gives a general idea of an astrological personality profile for pets, but it lacks specificity about what aspects of personality are included or how it differs from other pet astrology 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 guidance is provided on when to use this tool versus related sibling tools like pet_temperament or pet_sun_sign_meaning. The description does not indicate prerequisites or alternative 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?
Annotations already mark the tool as readOnly, non-destructive, and idempotent. The description adds specifics about finding stations and mentions cost, but does not disclose any behavioral traits beyond what annotations provide. Adequate but not enhanced.
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 concise but includes extraneous formatting like [Group: Calendar & Cycles] and [Cost:...]. While not verbose, it could be streamlined to focus on core functionality.
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 0% schema description coverage, the description lacks details about return format, possible planet IDs, ordering, pagination, or error conditions. Incomplete for an agent to fully understand the tool's behavior.
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 description coverage is 0%, so the description must compensate. It provides an example but does not explain that 'planetIds' is an array or what planet IDs represent (e.g., numbering scheme). The mismatch between 'planetId' in example and 'planetIds' in schema further reduces clarity.
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 finds retrograde stations (direct, retrograde, stationary) for a planet within a date range. However, there is inconsistency: the description and example use singular 'planetId' while the schema defines 'planetIds' as an array, which may confuse an agent.
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., stream_retrograde_alerts, webhooks_retrograde_start/end). The description only states what it does without any 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?
Annotations indicate readOnlyHint=false, suggesting side effects, but the description implies a read operation without clarifying. The description adds minimal behavioral context beyond annotations, such as the 'Real-time Streaming' group, but fails to explain streaming behavior or potential 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 description is concise with two short lines plus an example. It is front-loaded with the main action, but the group line adds minimal value and could be integrated. Overall, it is efficient but lacks structured parameter documentation.
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 one-parameter tool without an output schema, the description is adequate but incomplete. It does not explain what a 'sign-ingress' is, describe the output format, or differentiate from similar tools. The example helps but leaves gaps.
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?
With 0% schema description coverage, the description must compensate. It only provides an example ('days':30), which implies the parameter's purpose but does not explicitly describe it, its format, range, or default 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 returns 'next planet sign-ingresses for N days,' providing a specific verb and resource. However, it does not differentiate from the sibling tool 'ingresses' or other streaming tools, limiting 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 given on when to use this tool versus alternatives like 'ingresses' or other stream tools. An example request body is provided, but it lacks context on appropriate usage scenarios.
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?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, but the description adds minimal behavioral insight. It does not clarify whether the tool provides a one-time snapshot or a continuous stream, nor does it explain any side effects or authentication needs. The example body '{}' contradicts the schema's required 'body' field, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences plus a group label and example. Every element serves a purpose without redundancy.
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, the description should elaborate on the return format, update frequency, or other behavioral details for a real-time streaming tool. It only mentions 'Current 8-phase + countdown to next major phase', which is insufficient for an agent to fully understand the tool's output.
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 schema defines a single required 'body' parameter as a freeform JSON object, with a vague description referencing the tool description. The tool description only provides an empty example body, which conflicts with the required constraint. No parameter details (e.g., allowed fields, format) are given, leaving the agent to guess.
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 provides 'Current 8-phase + countdown to next major phase' which clearly indicates lunar phase information. The '[Group: Real-time Streaming]' label adds context, but it does not distinguish from sibling tools like moon_phase or lunar_calendar, which may serve similar purposes.
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 lacks any context about prerequisites, intended use cases, or exclusions, leaving the agent to infer from the 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read-only behavior. The description adds computational details (direction logic, duration formula) but is cut off and does not fully disclose computation limits or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is moderately concise but incomplete due to truncation ('lord-in-own-…'). It front-loads the system name and key rules, but the cut-off reduces clarity. Each sentence adds value, but the overall structure could be improved by a brief summary of what the tool returns.
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 (many sibling dashas) and lack of output schema, the description should state what the tool returns (e.g., list of periods with lords, dates). It does not. It also omits mention of the optional target parameters, leaving agents uninformed about progressive computation. The example only shows birth data, reinforcing this gap.
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 description coverage is 100%, so baseline is 3, but the description does not add any parameter meanings. Critically, it fails to mention that the tool accepts an optional targetDate/targetTime/targetTzOffset for projecting dashes to a specific date, which is a key capability. The description only discusses the dasha system, ignoring the input structure.
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 identifies the tool as computing Chara Mahadasha, a Jaimini rasi-dasha. It explains the key characteristics (12 signs, variable duration, direction rules), distinguishing it from planet-based dashas. However, it could be more action-oriented by explicitly stating 'calculates periods' rather than describing the system.
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 state when to use this tool versus other dasha tools among many siblings. It only mentions it's a Jaimini rasi-dasha, implying a specific system, but lacks direct comparisons or exclusions (e.g., 'use this for Chara Dasha; for Vimshottari use vedic_dashas_vimshottari_maha'). No guidance on prerequisites or context.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the agent knows it is a safe computation. The description adds '4-level cascade' implying nesting, but nothing about output format, side effects, or other behavioral traits. Given the annotations, the description contributes minimally.
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 very short, with a clear title line and an example. It is front-loaded and avoids unnecessary words. However, it is almost too terse, leaving out important context.
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?
For a complex tool (4-level cascade dasha with many siblings), the description is incomplete. It does not explain what Sookshmadasha means, what the output looks like, or how it differs from other levels. No output schema exists, so the description should provide more 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 the schema already describes all parameters (birth data, target date). The description provides an example request body but does not add meaning beyond the schema's built-in description. Baseline score of 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 states it is a 'Shodashottari Sookshmadasha — 4-level cascade' and places it in the Vedic group. This indicates it is a deep-level sub-dasha, but the purpose is vague: it does not explicitly say it computes dasha periods for a given birth and target date. The example request body provides some clarity, but the purpose could be more 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 provides no guidance on when to use this tool versus the many sibling dasha tools (e.g., antar, prana, pratyantar). There is no mention of when it is appropriate or alternatives, leaving the agent to infer from the 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?
Annotations already indicate readOnly and idempotent. The description adds behavioral details like seed calculation, duration rules, and sub-period splitting, but does not disclose potential errors, edge cases, or output format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the tool name and type but then dives into technical details (PyJHora functions, year basis). It is dense and cut off, which reduces clarity. More concise structuring would help.
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 the return format. It mentions sub-periods but does not describe the response structure, fields, or how results are presented. This is a significant gap for agent 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 description coverage is 100% and already explains the birth data parameters. The tool description adds no new parameter information beyond the example request body (which is not in the description proper). It does not clarify the targetDate/targetTime fields from the second object.
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 identifies the tool as 'Sthira Dasha — Jaimini fixed rasi-dasha' and explains the seed calculation. The purpose is specific and distinguishable from other dasha types, though it could more explicitly differentiate from siblings like vimshottari or chara dasha.
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 dasha (e.g., jaimini system vs other systems) or when not to use it. No alternatives are mentioned, leaving the agent without context for selection among many dasha 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description adds minimal behavioral context (single moment calculation, returns nakshatra name, pada, percent) but does not disclose any additional traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a group/cost line and an example. However, for 11 parameters, the example is somewhat bulky and the description could be more structured without losing 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 11 parameters, 0% schema coverage, no output schema, and a complex domain, the description is inadequate. It omits explanations for most parameters and does not clarify return values or usage 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?
Schema description coverage is 0%, so the description must compensate. It provides an example with 5 of 11 parameters but explains none. Most parameters (e.g., houseSystem, zodiacType, ayanamsaId) are unexplained.
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 calculates the Moon's Nakshatra at a given moment, including pada and percent-complete. It is specific and actionable, but does not explicitly differentiate from sibling tools like 'nakshatras' or other panchang 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 guidance is provided on when to use this tool versus alternatives. Among many sibling panchang and nakshatra tools, the description lacks any indication of preferred use cases 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?
Annotations already declare readOnlyHint, destructiveHint false, idempotentHint true, and openWorldHint false. The description adds the topics 'strengths, weaknesses, stamina,' which hints at output content but does not disclose any behavioral traits beyond annotations. No contradiction detected.
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 clear chart name and topics. It includes practical metadata (group, cost) and an example request body. However, the structure could be improved by front-loading the main purpose and adding a brief sentence on when to use.
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 return value or output format. Without an output schema, the agent has no idea what the tool returns (e.g., a chart text, JSON, interpretation). Compared to siblings like vedic_varga_D1, there is no differentiation. The description is incomplete for a tool with 7 parameters and many siblings.
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 all 7 parameters described in the input schema. The description does not add parameter-level meaning beyond what the schema provides. The example request body is helpful but does not clarify parameters like houseSystem or city. Baseline score 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 identifies the chart as Saptavimsamsa/Bhamsa chart and mentions strengths, weaknesses, stamina, giving a general sense of purpose. However, it lacks specificity about what the tool actually computes (e.g., a divisional chart for stamina/physical strength) and does not clarify how it differs from other varga 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 guidance on when to use this tool versus alternatives. It does not mention when D27 is appropriate, nor does it exclude contexts (e.g., male vs female charts, daytime vs nighttime). The sibling list includes many other vargas, but no differentiation 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?
Annotations set openWorldHint=true, but the description adds no behavioral context beyond the event trigger. It fails to disclose registration side effects, authentication requirements, or what happens on success/failure. With annotations present, the bar is lowered, but the description still lacks sufficient behavioral detail.
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 includes a group tag and example, which is efficient. However, the example could be more integrated, and some redundant phrasing ('Fires on') 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 description lacks critical context: no output schema, no mention of response structure, error handling, or prerequisites. For a webhook registration tool, this is incomplete and may lead to incorrect usage.
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 sole parameter 'url' has 0% schema description coverage, and the description only shows an example request body without explaining the parameter's purpose or constraints. The schema already defines format and maxLength, so the description adds negligible 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?
The description clearly states the tool fires on Vedic Vimshottari dasha period transitions, which distinguishes it from other webhook tools (e.g., webhooks_eclipse_alert, webhooks_mahadasha_end). 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 is provided on when to use this tool versus alternative webhook registration tools. The description does not explain scenarios or exclusions, leaving the agent to guess based on the tool name 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?
Annotations indicate readOnlyHint=false, consistent with subscription as a mutation, but description provides no additional behavioral details like idempotency, rate limits, or how to manage/unsubscribe. Minimal beyond the action itself.
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 lines of text, a group label, and an example. Every element is functional with no redundancy. Ideal length for simple tool.
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 (one parameter, no output schema), the description should still cover what happens on success, how to confirm subscription, and how to unsubscribe. These are missing, leaving the agent underinformed.
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 coverage is 0%, so description must explain the 'url' parameter. It offers an example but no semantic explanation of what the URL should be, any validation constraints, or how the webhook will be called. Insufficient compensation for missing schema 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 states 'Subscribe to natal-transit aspect threshold-crossings', which clearly identifies the specific event type. It distinguishes from sibling webhook tools (e.g., eclipse alerts, dasha changes) by naming the exact event, but could be more explicit about the uniqueness.
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 like webhooks_subscribe or other event-specific webhooks. The example request body helps with usage but does not replace context selection criteria.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds cost (20 credits) but no other behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus group/cost/example. It could include more detail without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return value and parameter semantics. With 11 parameters and no output schema, the description is incomplete for correct tool invocation.
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?
Schema coverage is 0% and description does not explain any of the 11 parameters. Only an example request body is given, which is insufficient for proper invocation.
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 planetary disposition chains, explaining the concept as a recursive sequence leading to the final dispositor. This is specific and distinct from siblings, though it could mention the layout variant.
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 vs alternatives like essential_dignities or receptions. Group label and cost are provided but 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe and deterministic. The description adds minimal behavioral context beyond stating it is element-based and gives allocations. It does not explain what 'allocation buckets' entail, the output format, or any limitations.
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 very brief: a single line describing purpose, a group tag, and an example. It is front-loaded but could be more informative about output without being overly verbose. The conciseness earns a 4, as every part earns its place.
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 7 parameters and no output schema, the description is incomplete. It lacks details on what the output looks like (e.g., a risk level, percentages, recommendations). The agent has to guess the return format. Additionally, no guidance on when to use this among many sibling financial tools is provided.
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 all 7 parameters with descriptions, achieving 100% coverage. The tool description adds no parameter-specific meaning beyond the schema; it only shows an example request with typical values. With high schema coverage, baseline is 3, and no extra 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 states it computes 'element-based risk tolerance' and suggests 'allocation buckets', which is a specific verb-resource pairing. It distinguishes itself from sibling financial tools like financial_market_timing or financial_investor_archetype by focusing on risk tolerance using astrological elements. The title matches the 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 explicit guidance is provided on when to use this tool versus alternatives. The description only includes a group tag 'Financial Astrology' and an example request, but no when-to-use, prerequisites, or exclusions.
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?
Annotations already indicate read-only and idempotent. Description adds no extra behavioral context (e.g., side effects, permissions, 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?
Concise with main purpose front-loaded. Group/cost line adds non-essential metadata but does not bloat.
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 description of return format. With 11 parameters and no parameter docs, the description is significantly incomplete.
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?
11 parameters with 0% schema coverage; description only provides an example request, not explaining any parameters like zodiacType, houseSystem, or ayanamsaId.
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 verb 'Calculate', resource 'Gauquelin sector positions', and output 'indicating power zone'. Unambiguous and distinct from 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 vs. alternatives like acg or acg_zones. No context about prerequisites or typical use cases.
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?
Annotations already provide readOnlyHint=true and idempotentHint=true, indicating safe read behavior. The description adds cost (50 credits) and an example request but does not disclose other behavioral traits like dependencies on prior chart calculations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (3 sentences) and front-loaded with purpose. Group and cost info are useful. The example is helpful but could be integrated more cleanly. Overall 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?
With 11 parameters, 2 required, and no output schema, the description is insufficient. It does not explain the output format beyond listing sequences, nor how the input parameters relate to 'HD gate activations'. Missing details on validation or prerequisites.
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 coverage is 0%, placing full burden on description. Only an example request is provided for 5 of 11 parameters; the remaining 6 (name, city, houseSystem, zodiacType, ayanamsaId, cosmogram) are unexplained. The description fails to compensate for missing schema 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 clearly states the verb 'Calculate' and the resource 'Gene Keys hologenetic profile' with specific sequences. It differentiates from generic Human Design tools by focusing on Gene Keys, but does not explicitly distinguish from sibling HD tools like hd_circuitry.
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 human_design or hd_circuitry. The description implies input of HD gate activations but does not clarify how the provided date/location inputs relate to that, leaving usage ambiguity.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is read-only and idempotent. The description adds nothing beyond that; it does not mention error handling, input validation, or what happens with missing/invalid chart data. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single line plus a group tag and example. It is front-loaded with the key purpose. However, it could include a brief usage note without sacrificing conciseness. Overall well-structured for its brevity.
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 zodiacal releasing and the absence of an output schema, the description is incomplete. It does not describe the output format, interpretation of periods, or how the 'years' parameter affects results. The siblings list is large but no cross-referencing is provided.
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 already includes a description for the birth data parameter, including defaults and requirements. The tool description does not add any additional meaning about parameters beyond what the schema provides, so it meets the 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 states 'Zodiacal Releasing from Lot of Fortune — body/livelihood periods', which clearly indicates the tool computes ZR for the Lot of Fortune focusing on body/livelihood. This distinguishes it from the sibling 'hellenistic_brennan_zodiacal_releasing_spirit' (spirit periods). However, it does not explain what zodiacal releasing is, leaving some ambiguity for unfamiliar agents.
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 its siblings (e.g., spirit version, loosing of bond, peak periods). It only mentions 'body/livelihood periods' without explaining the context or prerequisites for choosing this variant.
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?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds 'calculation with conditions analysis' but does not detail behavioral specifics like output format or data dependencies.
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 short and includes a group label and example request, but the example is minimal and does not add significant value. It is concise but lacks substantive structure.
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 11 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not provide enough context for correct invocation, such as required inputs or output behavior.
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?
With 0% schema description coverage, the description fails to explain any of the 11 parameters. Only a vague example request body is given, leaving the agent without necessary 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 tool name and description clearly indicate it calculates the Lot of Eros with conditions analysis, distinguishing it from sibling Hellenistic lot tools like hellenistic_brennan_lots_15 or hellenistic_hand_lots_of_seven.
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 (e.g., other lot calculations or different traditions). The description lacks prerequisites or usage context.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description aligns with these but adds no new behavioral context beyond mentioning the output includes radicality assessment and significator analysis.
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 one sentence plus group and cost lines, and an example. It is front-loaded and avoids fluff, though could include a brief parameter explanation without adding much length.
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 11 parameters, no output schema, and many sibling tools, the description is incomplete. It lacks details on optional parameters and return structure. The tool's complexity demands more than a single sentence and example.
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 description coverage is 0%. The description provides only an example request body with sample values but does not explain the meaning or constraints of any parameters beyond what the schema provides. For 11 parameters, more explanation is needed.
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 calculates a horary chart and returns chart data with radicality assessment and significator analysis. However, it does not differentiate from sibling horary tools like horary_diagnostics or horary_moon_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 alternative horary tools. No when-to-use or when-not-to-use information is 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the definition of VOC and date range scope, but does not detail output format or behavior for missing data, making it adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes an example with extraneous fields ('time', 'rangeDays') not in the schema, reducing clarity. The group and cost information is useful but could be integrated better.
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 present, and the description does not explain the return format (e.g., list of periods, timestamps). The example is misleading as it includes non-schema fields. More detail about output is needed for complete contextual 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 description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond that; the example includes 'time' and 'rangeDays' which are not in the schema, potentially causing confusion.
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 'Find Moon void-of-course periods within a date range' and explains what VOC means. However, it does not differentiate from sibling tools like 'horary_moon_voc' or 'stream_void_of_course', which could cause confusion.
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 explicit context for selection, such as comparing to other Moon VOC tools or specifying prerequisites.
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?
Annotations already declare readOnly, destructive false, and idempotent. The description adds minimal behavioral context beyond stating it 'calculates', which is consistent. It does not describe side effects, auth needs, or limitations, and the interpretive phrase 'life chapters of opportunity' adds no operational 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 short and includes a group tag and example, but the example contains an extraneous field that may confuse. It is front-loaded but not perfectly 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 gives a high-level idea of the output (four cycles with age boundaries) but lacks details on return format. With no output schema, more explanation would be beneficial. It is adequate for a simple tool among many similar ones.
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?
Although schema coverage is 100%, the description includes an example with an undocumented parameter 'name' (not in schema), which is misleading. It does not clarify the purpose or format of parameters beyond what the schema offers.
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 calculates four Pinnacle cycles with age boundaries, specifying the Chaldean system. The verb 'Calculate' and resource 'Pinnacle cycles' are specific, and the system is indicated in the title and group, distinguishing it from other pinnacles 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?
The description does not provide any guidance on when to use this tool versus alternatives, such as other system-specific pinnacles tools. No prerequisites, exclusions, or context for selection 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?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description adds minimal behavioral context beyond stating it calculates from the day-of-birth digit. It does not explain processing of timezone or location parameters, nor what happens with invalid dates.
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, with only two sentences and an example request. It is quickly scannable but could be slightly more structured (e.g., bullet points) without adding length.
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 complexity introduced by optional location parameters and many siblings, the description is incomplete. It does not explain what the birthday number represents, the role of extra fields, or how output is formatted.
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%, but the description only mentions the 'date' parameter in an example. It does not clarify the purpose or impact of latitude, longitude, or timezoneOffset beyond the minimal schema descriptions. Thus it adds no extra meaning.
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 calculates a birthday number from the day-of-birth digit, specifying the Kabbalistic (phonetic) system. However, it does not differentiate from many sibling tools with similar names (e.g., 'numerology_kabbalistic_strict_birthday', 'numerology_pythagorean_birthday'), leaving ambiguity for the agent.
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 mention when not to use it. The extensive sibling list includes many birthday-number tools, but the description offers no 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's mention of 'calculate' adds little. It specifies 'full birth name letters' and 'all letters, reduced', providing minimal extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a group label, but the example with a non-existent 'name' parameter is confusing and undermines conciseness. It could be restructured to avoid misleading examples.
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 explain what the tool returns, which is problematic since there is no output schema. It also fails to clarify the purpose of optional parameters like latitude, longitude, and timezoneOffset. The required 'date' parameter is mentioned, but the overall context is incomplete.
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 description implies a 'name' parameter with the example, but the input schema does not include any name field. This is misleading and contradicts the schema. The description adds confusion rather than clarity about 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 the verb 'calculate' and the specific resource 'Expression/Destiny number' with the Kabbalistic phonetic system, distinguishing it from numerous sibling numerology tools for different systems and numbers.
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 like Chaldean or Pythagorean Expression numbers. There is no mention of prerequisites, exclusions, or contexts where this tool is preferable.
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?
Annotations already declare readOnlyHint true and idempotentHint true, indicating safe read behavior. The description adds minimal behavioral context: it mentions calculating from the day-of-birth digit, but does not explain the role of optional parameters (latitude, longitude, timezoneOffset) or clarify that the tool only uses the day part of the date, not the full date.
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 and includes a group tag and example request body. It is efficient but could be improved by front-loading the most critical information (e.g., that only the date is needed) and removing the generic example.
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 hint at the return format (e.g., a single number). It does not. Additionally, the purpose of optional location/time parameters is not explained, leaving the tool's behavior under-specified for a calculation that might depend on timezone.
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 baseline 3 is appropriate. The description does not add meaning beyond the schema; it only provides an example request body with a date. Optional parameters remain unexplained, but the schema already describes them.
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 calculates the Birthday number from the day-of-birth digit and specifies the Pythagorean system. The verb 'Calculate' and resource 'Birthday number' provide a clear action and object, though it does not differentiate from many sibling numerology tools with similar names.
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 other Pythagorean numerology tools (e.g., life path, expression). The description lacks any context, exclusions, or when-to-use instructions.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds minimal behavioral context beyond what annotations provide, but does not contradict them.
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 an example, but the misleading example reduces efficiency. The group annotation is helpful but the example should match the schema.
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 omits what the output contains (the Personal Year number itself) and how to interpret it. The unexplained location parameters and lack of return value description leave the tool's behavior partially unclear.
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 schema includes latitude, longitude, and timezoneOffset, but the description does not explain their relevance to calculating a personal year. The example further confuses by introducing 'name' and 'year' parameters that are not in 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 calculates the Personal Year number, a 9-year cycle in the Pythagorean system. However, the example includes 'year' and 'name' fields not present in the input schema, causing confusion about the actual required parameters.
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 other personal year calculators (Chaldean, Kabbalistic, Vedic). The description lacks criteria for selecting this specific system.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is set. The description adds no further behavioral context (e.g., that it returns astrological communication advice, that it requires birth data, or how results are formatted). Since annotations are present, the bar is lower, but the description still fails to add meaningful behavioral detail beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences plus an example, which efficiently communicates the core purpose. However, it could be improved by front-loading the key information more clearly and perhaps removing the group tag if it adds little value. Still, brevity is a strength here.
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 moderate complexity (7 parameters) and no output schema, the description should explain what the tool returns and how it differs from dozens of sibling pet tools. It does not specify output format, content, or scope, leaving a significant gap in completeness for an AI agent to use it correctly.
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 each of the 7 parameters having a clear description (e.g., 'Birth date YYYY-MM-DD'). The tool description does not add any additional meaning beyond what the schema already provides, so it appropriately remains at the baseline of 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 states 'How best to communicate with this pet,' which clearly indicates the tool provides communication advice for a pet. However, among many pet-related siblings (e.g., pet_training_style, pet_play_style, pet_personality), it does not differentiate this tool from similar ones, missing a chance to clarify its unique focus.
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 like pet_personality or pet_training_style. The description lacks prerequisites, context for invocation, or exclusions, leaving the AI 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, indicating safe, non-mutating operation. The description adds that it returns exercise minutes and activities, but fails to explain that it uses astrological birth data or how results are derived. The example request body includes birth chart parameters, which may confuse agents expecting simple pet data.
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 very concise, consisting of one sentence plus a group tag and example. It is front-loaded and efficient, but the structure could be improved with clearer separation of purpose and 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?
The description is very brief for a tool with 7 parameters and no output schema. It does not explain what 'element-based' means, how exercise minutes are computed, or what the output format is. More context is needed for agents to use this tool 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%, so all parameters are described in the input schema. The description does not add any additional meaning beyond what the schema already provides. Baseline score of 3 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 states it provides 'element-based daily exercise minutes + recommended activities', which clearly indicates the tool's output. However, it does not explicitly state that it uses birth chart parameters, though the example implies it. The group label 'Pet Astrology' helps contextualize it among 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 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. No mention of prerequisites or when not to use. The description is too brief to provide usage context.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety. The description adds the definition of mutual receptions but does not disclose any additional behavioral traits (e.g., what happens if no receptions found, output format). With annotations covering core traits, a '3' is appropriate.
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 clear first sentence defining the tool, followed by group and cost metadata and an example. Every sentence contributes, though the group/cost lines could potentially be in annotations.
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 11 parameters, no output schema, and a specialized astrological concept, the description is too brief. It lacks details on output interpretation, edge cases, and parameter usage, making it incomplete for an agent to use effectively.
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 description coverage is 0%, meaning the description provides no explanations for the 11 parameters. The example shows some parameters but does not clarify their meanings or constraints. The description fails to compensate for the missing schema documentation.
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 finds mutual receptions between planets and defines the concept. However, it does not differentiate from sibling tools in the 'Dignities & Receptions' group, such as essential_dignities or disposition_chains.
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 group label implies context, but no explicit when-to-use or when-not-to-use instructions 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds only a cost warning and the fact it generates a narrative, but does not disclose behavioral traits such as rate limits, permissions, or what happens to existing data. Given the annotations already cover some aspects, the description adds minimal value.
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 very short and to the point, but it lacks structure such as separating purpose from usage or providing bullet points. It is concise but could be better organized without adding length.
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 tool (two nested chart objects, multiple parameters, no output schema), the description is incomplete. It does not explain the output format (what the narrative contains), the relationship between chart1 and chart2 (e.g., which person is which), or any prerequisites. The cost warning is the only additional 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?
Schema coverage is low (40%), and the description merely lists input names ('chart1, chart2, language, tone, length') without adding any meaning beyond what the schema already provides (e.g., schema descriptions for chart objects include format details). No explanation of enums or how parameters affect the output.
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 a 'long-form relationship narrative grounded in cross-chart aspects,' which precisely identifies the tool's function and distinguishes it from single-chart narratives (e.g., reports_ai_natal_narrative) and non-narrative synastry tools (e.g., synastry).
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 includes a cost warning ('⚠️ Heavy — confirm with user before invoking') advising caution, but it does not explicitly state when to use this tool versus alternatives like reports_synastry or other AI reports. No differentiation or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly a safe, read-only operation. The description adds little beyond the example body, but it does not contradict the annotations. Given the annotations, the burden is lower, and the description is adequate but not enriched.
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 very concise—two sentences plus a group label and example. Every element earns its place, and the critical info (all runes) is front-loaded. It could be slightly expanded without becoming 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?
Given that there is no output schema, the description should explain what the tool returns (e.g., format, structure). It only states 'All 24 runes,' without indicating whether the output is an array, object, or includes additional metadata. For a complete description, more detail on the response format is needed.
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 100% description coverage with a single 'body' parameter, whose schema description defers to the tool description. However, the tool description only provides an empty example ({}) and does not clarify what fields the body should contain. The schema says 'see the example in the tool description,' but the example is insufficient for understanding complex inputs.
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 'All 24 runes,' clearly indicating that the tool returns the complete list of Elder Futhark runes. This distinguishes it from sibling tools like runes_single or runes_three, which return a subset. However, it lacks an explicit verb like 'list' or 'get,' slightly 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?
The description provides no guidance on when to use this tool versus alternatives. While the sibling list includes more specific rune tools, the description itself does not help an agent choose between them. No context is given about suitable use cases or prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows this is a safe read operation. The description adds the layout name (Pennick) but no further behavioral context like randomness, output format, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence plus a group label and example. While brief, it is front-loaded and wastes no words, but could benefit from structured breakdown of parameters.
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 (3 undocumented parameters, no output schema, multiple sibling tools), the description is insufficient. It fails to explain the Pennick layout, how seed affects results, what question does, or what the output looks like. The example hints at seed usage but leaves major gaps.
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 description coverage is 0%, placing full burden on the description. The description only shows an example with the 'seed' parameter, leaving 'question' and 'allowReversed' unexplained. Their purposes (e.g., seed for reproducibility, question for focus, allowReversed for reversed runes) are not clarified.
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 specifies 'Pennick layout 9-rune cast' and groups as Elder Futhark Runes, indicating a specific rune cast with 9 runes. This differentiates it from siblings like runes_single or runes_three, but does not explicitly state the verb (e.g., 'performs' or 'generates').
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 runes_single or runes_three. The description does not mention use cases, prerequisites, or scenarios where this layout is preferred.
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?
Description says 'snapshot' which implies read-only access, but annotations set readOnlyHint=false, creating a contradiction. No explanation of behavioral traits such as whether it establishes a persistent stream or returns a one-time result.
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 with two lines, no wasted text, and front-loads the key purpose: 'Current planetary positions snapshot, tickSeconds=30.'
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?
Despite minimal parameters and a contradictory annotation, the description lacks essential context such as output format, whether it starts a stream or returns a single snapshot, and how to interact with it. More detail is needed for a real-time 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?
There are zero parameters, so the description does not need to add any. Schema coverage is 100%, and the description correctly provides an example request body {}.
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 provides a 'Current planetary positions snapshot' with a tick interval of 30 seconds, which is specific and actionable. However, it does not differentiate from sibling streaming tools like stream_eclipse_incoming or stream_ingress, but the purpose is still 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?
No guidance on when to use this tool versus other streaming tools. The grouping '[Group: Real-time Streaming]' implies real-time use, but no explicit alternatives or conditions 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?
Annotations indicate non-readonly, non-destructive, non-idempotent, and open-world, which are not contradicted by the description. The description adds that this is a streaming tool providing retrograde state and next stations, but does not detail behavior like update frequency, authentication needs, or error states. It provides moderate additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two lines covering purpose, group, and an example. It is well-structured with a clear header and formatted group label. However, it may be too brief, missing necessary details, but within its length it is 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?
Given the complexity (streaming tool, open-ended schema, many siblings, no output schema), the description is insufficient. It does not explain the output format, how to handle streaming data, or what fields the input body may contain. The empty example confuses rather than clarifies. Important context is missing.
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 sole parameter 'body' is described as 'Raw JSON body — see the example in the tool description for required fields'. However, the example is an empty object {} and no required fields are specified. The description fails to add meaningful semantics; the agent cannot determine what fields to include in the body.
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 'All planets retro state + next stations' which clearly indicates the tool provides retrograde state and next station dates for all planets. The title 'Stream Retrograde Alerts' reinforces the streaming nature. It distinguishes from non-streaming sibling 'retrograde_periods' by the streaming aspect.
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 includes '[Group: Real-time Streaming]' which hints at real-time usage, but no explicit guidance is given on when to use this tool versus alternatives like 'retrograde_periods' or other streaming tools such as 'stream_transit_alerts'. The agent receives no criteria 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds no behavioral context beyond that, e.g., no mention of auth requirements, rate limits, or how the advice card is generated. The example request body is present but does not disclose 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 very concise: one line, a group label, and an example. Every element serves a purpose, though it could be better structured with separate sections for example and parameters.
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 and the description does not explain what the response contains. The parameter description is minimal despite a complex nested object. Given the large sibling list of similar tools, more context on when to use this specific tool is needed.
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 but is vague (only describes 'body' as a JSON object). The description provides an example with fields like 'seed', 'question', 'allowReversed', adding essential meaning beyond the schema. However, it does not explicitly list all allowed parameters or their constraints.
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 name and title clearly indicate a single advice card from Rider-Waite-Smith tarot. The description 'Single advice card' specifies the resource and action, but lacks a verb like 'draw' or 'get'. It distinguishes from siblings by mentioning the group, though no explicit differentiation from similar 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 guidance on when to use this tool versus other tarot drawing tools (e.g., tarot_rider_waite_draw_single). No context on prerequisites or alternatives, leaving the agent to guess.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering basic safety. The description adds minimal behavioral context beyond 'Birth-card meditation pair', not explaining what gets computed or returned. With annotations present, a 3 is appropriate—it adds some value but is not rich.
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, with only two lines and an example. Every element (purpose, group, example) earns its place. No unnecessary words.
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 and lack of output schema, the description should explain what the tool returns. It only says 'Birth-card meditation pair', which is insufficient. It does not help differentiate from similar sibling tools like tarot_rider_waite_birth_card, leading to contextual 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 descriptions cover 100% of parameters, so baseline is 3. The description provides an example request body but does not add meaning beyond the schema. The vague schema description for location parameters is not clarified in the description.
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 'Birth-card meditation pair for court-card practice' which hints at the purpose but is vague. The title 'Court Card Cross-Sum' adds some clarity, but it does not clearly distinguish from sibling tools like tarot_rider_waite_birth_card. A specific verb+resource is missing, making it less clear for an AI agent.
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. No mention of context, exclusions, or when not to use it. The description lacks any usage guidance, relying solely on the name and group tag.
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?
Annotations already signal readOnlyHint=true and idempotentHint=true, so the tool is safe and deterministic. However, the description adds no behavioral context beyond '7-card relationship dynamics'. It doesn't disclose what happens with missing fields, how reversed cards are handled (though the example shows allowReversed), or the response format.
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 very concise: two lines stating the purpose and an example. It's front-loaded and efficient, though it could include a bit more detail without becoming 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?
Given the tool's complexity (7-card reading with seed, question, reversed flag) and no output schema, the description is incomplete. It doesn't describe the output format or card meanings, leaving agents uncertain about the response structure. Annotations cover safety but not functional 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 schema defines only one parameter 'body' with minimal description, but the tool description provides an example with seed, question, and allowReversed, giving agents a concrete usage pattern. Schema coverage is 100% but the schema itself is very permissive (any JSON), so the description partially compensates by showing expected fields.
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 '7-card relationship dynamics' and the title 'RWS — Relationship' indicates it's a Rider-Waite tarot reading focused on relationships. This is clear enough, but it doesn't elaborate on the specific relationship context (e.g., romantic, general) compared to sibling tools like 'tarot_rider_waite_draw_love_triangle' which are more 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 provides no guidance on when to use this tool versus alternatives, such as other Rider-Waite draws (e.g., three-card, celtic cross) or similar relationship draws from other decks (e.g., Lenormand). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide (readOnly, idempotent). It does not explain what happens with seed or allowReversed parameters, or what the response looks like. Annotations ensure safety, but description fails to elaborate on 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus a group label and an example. It front-loads the purpose. However, it lacks structure and could integrate the example more clearly. It is efficient but slightly under-specified.
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 simple tool (single card), the description partially covers functionality via the example. However, it omits: what the timing card indicates, expected output format, and prerequisites. With no output schema and sparse parameter documentation, the description is incomplete for an agent to fully understand 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?
Only one parameter 'body' is defined in the schema with minimal description. The tool description includes an example showing 'seed', 'question', 'allowReversed' fields, which provides semantic hints. However, the description does not formally explain these fields, relying on the example. Schema coverage is 100% but the description is weak.
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 'Single timing card to indicate when', which clearly identifies the tool's purpose as a tarot card draw for timing questions. It distinguishes itself from other tarot tools by being specifically for timing. However, it lacks detail on what 'timing' entails.
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. With siblings like 'tarot_marseille_timing', the user receives no explicit instructions on choosing this tool over others. The example shows request fields but not 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds only '5-level cascade (finest grain)', which hints at the output granularity but does not disclose behavioral traits such as required input fields, computation logic, or what 'cascade' means. The example shows some parameters but lacks explanation.
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 extremely concise: one line and an example. No redundant information. However, it could benefit from a short sentence explaining the tool's function. The example is well-placed for immediate understanding, but overall structure is minimal.
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 (5-level cascade) and absence of output schema, the description leaves many gaps. It does not explain what the tool returns, how the cascade is structured, or how input parameters affect results. With many similar sibling tools, it fails to differentiate beyond the name. The example is helpful but insufficient for 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?
Input schema coverage is 100%, and schema includes descriptions for some fields. The description provides a concrete example request body, which helps with parameter format and values. However, it does not explain the meaning of each parameter (e.g., targetDate, antardasaSeedOption) or how defaults affect output. The example is useful but incomplete.
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 title and description clearly indicate it's the Shoola Pranadasha, the finest grain (5-level cascade) in the Shoola dasha system. It distinguishes from sibling tools like vedic_dashas_shoola_maha by specifying 'prana' and 'finest grain'. However, it lacks an explicit action verb (e.g., calculates, computes).
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 other dasha tools or other levels (e.g., maha, antar). The description does not mention when the prana level is appropriate or indicate 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?
Annotations already declare readOnlyHint, idempotentHint, and no destructive behavior. The description adds only the grain level ('finest grain') and cascade depth, which is useful but insufficient to disclose behavior like output structure or data scope. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the tool's key feature. Including an example request is helpful, though it adds length. Overall, it is efficient and to the point.
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 (5-level cascade), but the description does not explain what the output contains, how cascading works, or how to interpret results. No output schema exists, so the description should compensate, which 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 description coverage is 100%, so the burden on the description is lower. The description provides an example request body but no additional parameter semantics beyond what the schema already documents. 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 identifies the tool as computing Sthira Pranadasha periods, with a distinctive feature '5-level cascade (finest grain)' that differentiates it from other dasha tools. However, it lacks an explicit verb like 'computes' or 'calculates', which slightly reduces 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 other dasha tools (e.g., Vimshottari, Ashtottari). The description only mentions the group 'Vedic', which is too vague to aid selection among dozens of sibling dashas.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds no new behavioral context (e.g., side effects, auth needs, rate limits). It does not contradict annotations, but it adds minimal value beyond them.
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 very concise—one sentence plus a group label and example. While it is efficient, it could be better structured with bullet points or sections for readability. Still, it is not 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?
Given the complexity of Vedic dashas and the many sibling tools, the description lacks important context: what makes Tribhagi unique, how the 9 PDs are defined, and what the return value looks like (no output schema). It is incomplete for a knowledgeable selection.
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 schema already documents all parameters with descriptions. The tool description only provides an example request, adding no additional meaning beyond what is in the schema. 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 identifies the tool as 'Tribhagi Pratyantardasha' and explains it as a 3-level cascade (MD → AD → 9 PDs), which clearly states what it computes. However, it does not distinguish this specific system from sibling pratyantar tools (e.g., vimshottari_pratyantar), so differentiation is weak.
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?
There is no guidance on when to use this tool versus alternatives like other dasha systems or levels. No prerequisites or exclusions are mentioned, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds minimal behavioral disclosure. It does introduce the 'KP Sun sub-lord chain' technical detail, which provides some insight into the calculation, but overall it does not go beyond what annotations imply.
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: two sentences plus an example. The most important information (what it calculates) is front-loaded in the first line. The example request body is helpful but could be more integrated. Overall, minimal waste.
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., a report, a score, or a list of aspects). Given the complexity of dosha calculations, the description is incomplete for an agent to understand the full behavior or outcome. It lacks details on return format or interpretation.
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 0% coverage in descriptions, meaning parameters are not explained. The description only gives an example request body without explaining the purpose or format of each parameter (e.g., date, time, latitude). It fails to compensate for the lack of schema documentation, leaving the agent to infer meaning from the example.
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 calculates 'Pitra dosha (Sun affliction)' using the KP system with 'KP Sun sub-lord chain'. It identifies the specific dosha and methodology, distinguishing it from other dosha tools like vedic_doshas_kp_manglik or vedic_doshas_kp_kalasarpa. However, it does not explicitly differentiate from all sibling tools nor mention the exact scope.
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?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, appropriate contexts, or when other tools (e.g., vedic_doshas_kp_full) would be more suitable. The description is purely functional without contextual advice.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, establishing safety. The description adds that specific remedies are provided, which is a behavioral output beyond mere calculation. However, it does not detail potential side effects or limitations of the remedies.
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 (two sentences plus example) and front-loaded with key purpose. The example request is useful. However, the brevity comes at the cost of missing parameter details, making it arguably too concise for a complex tool.
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 11 parameters and 0% schema description coverage, the description does not provide sufficient information for correct invocation. It omits parameter meaning, output format, and usage context. The example request partially compensates, but overall completeness is low.
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?
With schema description coverage at 0%, the description does not explain any of the 11 parameters beyond a generic example request. It fails to clarify the meaning or purpose of parameters like houseSystem, zodiacType, or ayanamsaId, leaving the agent to infer from names alone.
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 identifies the tool as computing Shrapit dosha (ancestral curse) per Lal Kitab, specifying the condition (Saturn conjunct Rahu/Ketu) and that it provides remedies. This distinguishes it from sibling dosha tools by name and specific condition, though a brief note on when to choose this over other dosha tools would strengthen differentiation.
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 other dosha tools (e.g., vedic_doshas_lal_kitab_kalsarpa or vedic_doshas_parashara_shrapit). The description lacks context on prerequisites or typical use cases.
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?
Annotations already indicate safe, idempotent, read-only behavior. The description adds algorithmic context (source texts, ranking method), which is useful but does not reveal potential side effects or limitations beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is efficient, front-loading purpose and grouping concepts. Includes source references and a group tag, which add context without significant bloat. Could be slightly trimmed but remains 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 output schema, so description should describe return values. It mentions chara and naisargika karakas but not their structure or format. With 11 parameters and no output details, the agent may not know how to use the result or configure additional parameters beyond the example.
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 description coverage is 0%, so the description must compensate. It only provides an example with 5 of the 11 parameters, omitting details for houseSystem, zodiacType, ayanamsaId, cosmogram, etc. The example is helpful but insufficient for full parameter understanding.
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 both chara karakas (8-planet ranking) and naisargika karakas (fixed planet-house mapping), distinguishing it from the sibling tool 'vedic_jaimini_chara_karakas' which likely only does chara karakas. However, it does not explicitly compare with all Jaimini 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 vs. alternatives like vedic_jaimini_chara_karakas or other Jaimini tools. The example request body shows some parameters but does not explain selection criteria. Lacks explicit context 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, establishing safe read-only behavior. The description adds the specific sub-lord chain method and reference to Krishnamurti, which is useful for understanding the calculation but does not contradict annotations. No additional behavioral traits are disclosed.
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 the key output stated upfront. The group label '[Group: Vedic]' and example are useful. However, the example could be integrated more seamlessly, and some text like 'KP-canonical' might be slightly redundant with the title. Overall, it's well-structured for its length.
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 11 parameters, no output schema, and a complex domain, the description is incomplete. It does not explain the output format beyond '12 cusps with sub-lord chain', nor does it specify the return structure (e.g., degrees, zodiac positions, sub-lord details). Agents may struggle to interpret results without additional documentation.
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?
With 0% schema description coverage, the description should explain parameters individually. It only provides an example request body with some parameters filled (date, time, timezoneOffset, latitude, longitude) but does not clarify the purpose or constraints of optional parameters like houseSystem, name, city, zodiacType, ayanamsaId, or cosmogram. The example helps but is insufficient for 11 parameters.
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 12 Placidus cusps with a full sub-lord chain, specifying the methodology (K.S. Krishnamurti 1971). The title reinforces this. However, it does not explicitly differentiate from sibling tools like vedic_kp_asc_sub or vedic_kp_horary, though the focus on cusps is distinctive.
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 only provides an example request, which hints at required parameters but offers no context about prerequisites, scenarios, or exclusions. Agents lack direction 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?
Annotations indicate read-only, non-destructive, idempotent behavior. The description adds context about the cycle length and tradition, which goes beyond annotations. However, it does not disclose expected output format, handling of missing optional parameters, or potential effects (like whether it returns detailed sub-periods). With annotations covering the safety profile, a 3 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 concise, with front-loaded key information (cycle length, tradition) and a helpful example. It avoids unnecessary words and uses a clear structure (definition, tradition note, group label, example). A slight improvement would be grouping parameters more systematically.
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 11 parameters and no output schema, the description should clarify what the tool returns (e.g., list of dasha periods with dates, lords, sub-periods). It provides no return value description, no mention of prerequisites (e.g., valid chart), and no hints about how the many optional parameters affect results. This leaves significant ambiguity for an AI agent.
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 description coverage is 0%, so the description must compensate. It provides an example request body that implicitly explains 5 of 11 parameters (date, time, timezoneOffset, latitude, longitude). However, it fails to explain the remaining 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram), leaving the agent uninformed about their semantics and impact on the calculation.
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 identifies this as a Lal Kitab dasha with a 35-year cycle, providing specific numerical detail (1 house per ~2.917 years). It distinguishes from other dasha systems by naming the tradition (K. Ashant) and noting an alternate 38-year method. However, it does not explicitly state the tool's action (e.g., 'calculates' or 'computes'), relying on the title and context to imply 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?
The description offers no guidance on when to use this tool over the many sibling dasha and Lal Kitab tools. It mentions an alternate implementation but does not contrast this with other dasha systems (e.g., Vimshottari, Ashtottari) or specify scenarios where this tool is appropriate or inappropriate.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the cost tier and Vedic group but no additional behavioral traits like rate limits or authentication needs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes essential elements: definition, group, cost, and a concrete example. No redundant information, but could be slightly more structured with a clear purpose statement.
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 11 parameters, no output schema, and 0% schema coverage, the description is inadequate. It does not explain the return format, the meaning of optional parameters, or how the tool behaves. The example only covers a subset.
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 coverage is 0%, so description must compensate. It only provides an example with 5 of 11 parameters and no explanation of their meaning (e.g., houseSystem, zodiacType, ayanamsaId). The example helps but does not define parameter semantics.
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 defines karana as 'half-tithi' and lists movable and fixed types, clearly indicating the tool's focus. The title 'Panchang — Karana' adds context. However, it does not explicitly state 'retrieves the current karana' or position it relative to siblings like vedic_panchang_tithi.
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 the many sibling panchang tools (e.g., tithi, yoga, nakshatra_of_day). The example shows required parameters but lacks any when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds value by specifying the exact output (paksha, tithi name, % complete), which aligns with the annotations. No contradictions or hidden side effects are implied.
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, front-loading the core purpose in one sentence. The example request body is helpful, though the cost and group metadata could be considered extraneous. Overall, it is efficient and well-structured for quick scanning.
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 has 11 parameters and no output schema, the description is too terse. It does not explain the purpose of optional parameters, which calculation details might require latitude/longitude/timezone, or what the output looks like beyond a brief mention. The example partially compensates but leaves significant gaps.
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?
With 0% schema description coverage, the description fails to explain any parameters beyond what is shown in the example. The example only includes date, time, timezoneOffset, latitude, longitude, leaving many other parameters (city, houseSystem, zodiacType, etc.) unexplained. This is insufficient for an agent to understand how to fill all parameters correctly.
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 returns the lunar day (tithi) along with paksha, tithi name, and percentage complete. The title 'Panchang — Tithi' effectively distinguishes it from other panchang tools like vedic_panchang_full. However, it could be more explicit about the action (e.g., 'Retrieves the tithi for a given date/time').
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 includes an example request body but provides no explicit guidance on when to use this tool versus alternatives like vedic_panchang_full or other vedic_panchang tools. There is no mention of use cases, prerequisites, or situations where this tool is preferable.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds only group and cost info, which are not behavioral. It does not disclose output format, pagination, or any side effects beyond what annotations state.
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 with three lines: purpose, metadata, and example. The example is somewhat lengthy but overall concise. Could be slightly tighter by omitting the example or moving it to a note.
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 and 7 parameters, the description lacks details about what the tool returns (e.g., chart data structure) and how it integrates with other Vedic tools. The agent is left uninformed about expected output.
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 all parameters described. The description provides an example request body but does not add new meaning beyond the schema. 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 identifies the tool as the Shodasamsa chart (D16) and associates it with vehicles, comforts, and conveyances, which differentiates it from other varga charts. However, it does not explicitly state that the tool calculates or returns the chart, relying on inference from the title and name.
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 vedic_varga tools (e.g., D1, D9) or the general vedic_divisional tool. The agent receives no selection criteria beyond the tool's theme.
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?
Annotations are minimal, and the description adds only that it 'fires' on an event. No details on registration behavior, overwrite policy, authentication, or side effects. The example is helpful but insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence, a group label, and an example. It avoids redundancy but could benefit from a bit more structure.
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 simplicity (one parameter, no output schema), the description is minimal. It lacks information on response format, error scenarios, or how the webhook will be delivered.
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 coverage is 0%, and the description provides no parameter details beyond a single example URL. No explanation of the url parameter's purpose, format constraints, or validation rules.
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 'Fires when any tracked planet ingresses a new sign,' which precisely defines the tool's function. It includes a group label and example, distinguishing it from sibling webhook 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 guidance on when to use this tool versus other webhook-related siblings (e.g., webhooks_dasha_change). The description only states what it does, not context for selection or prerequisites.
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?
Annotations already indicate readOnly and idempotent properties. The description adds minimal behavioral context beyond the purpose and example, but does not elaborate on rate limits, data sources, or behavior for invalid inputs.
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 very concise and front-loaded with the purpose. However, it omits important details such as output structure or usage context, making it somewhat under-informative.
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 7 parameters, no output schema, and no description of the return format, the description is incomplete. It fails to explain what the tool returns or how it processes birth data to determine zodiac sign.
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 includes an example request body but does not add explanatory detail beyond what the schema already provides for each 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 what the tool does: provides primary and supportive crystals with intentions per zodiac sign. However, it does not explicitly mention that it derives the zodiac sign from birth data, which is implied by the example but not stated. Among siblings, it is distinct as the only crystal-related tool.
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 esoteric_crystals_recommend or other wellness tools. There is no when-not 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds no additional behavioral context (e.g., prerequisites, return format, side effects beyond what annotations imply). It fails to add value beyond the structured annotations.
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 very short (three sentences) and front-loaded with the key topics. Every sentence serves a purpose: naming the domain, grouping, and providing an example. It is appropriately sized for a simple tool, though it could be more structured with headings.
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, so the description should at least hint at the return type (e.g., 'returns an interpretation of the travel palace'). It does not mention required prerequisites like having a Zi Wei chart computed. The example only shows a date input, omitting that latitude/longitude might be needed for location-based analysis. Given the esoteric topic and sibling complexity, the description is insufficiently 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%, so the input schema already documents all parameters (date, latitude, longitude, timezoneOffset). The description only provides an example request body, adding no new semantic insight into the parameters themselves. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Travel Palace (Qianyi)' and description 'Travel, relocation, foreign opportunities' clearly indicate the tool focuses on travel-related astrology. It distinguishes itself from siblings like ziwei_palace_career by narrowing to a specific palace topic. However, it lacks an explicit verb (e.g., 'analyze' or 'interpret'), relying on the agent to infer the action.
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 ziwei_palace_career or when not to use it. It only lists topics, leaving the agent without decision support for tool selection among the extensive 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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that only a single nearest minimum is returned, and it can be before or after the date. However, it does not clarify behavior when no minimum exists or the role of the optional longitude parameter.
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 and includes a clear purpose, group, cost, and example. The extra meta lines (group, cost) are somewhat redundant but do not harm conciseness. The core description is 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 no output schema, so the description should explain return values. It does not. Additionally, the optional longitude parameter is never mentioned. The description is incomplete for a tool with two parameters and no output schema.
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?
Schema description coverage is 0%, so the description must explain parameters. The description only shows an example with 'date' but does not describe the pattern or the optional 'longitude' parameter at all. This fails to add 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 'Find the single nearest Algol brightness minimum before or after a given date.' It specifies a verb (Find), a resource (Algol brightness minimum), and a scope (single nearest, before/after). This distinguishes it from the sibling 'algol_minimum' which likely returns all minima.
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 like 'algol_minimum'. It includes a group label but no comparison or exclusion criteria, leaving an agent to guess.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds no additional behavioral context such as output format, constraints, or side effects. With such minimal description, the agent gains little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus group tag and example). It is concise but could benefit from better structuring (e.g., purpose, parameters, example). The key info is front-loaded, but the lack of structure reduces 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?
No output schema is provided, yet the description does not explain what the tool returns. The tool is part of a large family of BaZi tools, and the minimal description leaves the agent unsure of the output structure, reducing 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% with four parameters clearly defined. The description does not add meaning beyond the schema; it only provides an example request body. Baseline 3 is appropriate as the schema does the heavy lifting.
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 computes the year pillar (stem, branch, animal, element, yin/yang) for a given date. It is a specific verb+resource and distinct from sibling BaZi tools like bazi_day_master or bazi_hour_pillar.
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 group tag [BaZi (Four Pillars)] only implies context but does not differentiate usage. No when-not-to or alternative recommendations 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds the mechanism detail and credit cost, but does not disclose output format or side effects beyond what annotations imply.
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 at two sentences plus a group/cost line and example. It is front-loaded with the core function. However, the example is helpful but not essential; overall structure is 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?
Despite annotations covering safety, the description lacks output details and parameter explanations for an 11-parameter tool. Agents would need additional context to use it effectively, making it incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter documentation. Only an example request is given, which does not explain the purpose of optional parameters like houseSystem, zodiacType, or ayanamsaId. Agents would lack understanding of how to set parameters beyond date/time.
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 verb 'Calculate' and the resource 'draconic chart', and explains the mechanism (shifting longitudes relative to True Node). It distinguishes this tool from other chart tools by specifying the unique transformation, making it easy for an agent to identify its 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 vs. alternatives like composite, davison, or other specialized charts. The group label 'Specialized Charts' is too vague to direct agent decision-making.
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?
Annotations already indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the description's behavioral burden is low. It adds cost information (100 credits) but no additional behavioral traits, which is adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a clear example, efficiently conveying the tool's purpose and showing usage. It is well-structured and front-loaded with the action, though it could be slightly more detailed without losing 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 description states the output is a combined BodyGraph showing group dynamics, which is helpful. However, without an output schema, agents cannot know the exact structure of results. The cost and example add context, but deeper explanation of the Penta concept is missing.
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 schema has 0% description coverage, so the description must compensate. It provides an example request body showing required fields (date, time) and optional defaults, but many parameters (e.g., houseSystem, zodiacType, cosmogram) are unexplained, leaving agents unclear about their meaning or necessity.
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 calculates a Penta (group) chart for 3-5 people, producing a combined BodyGraph for group dynamics. It is specific and differentiates from generic chart tools, though it does not explicitly contrast with sibling group tools like hd_group_overlay.
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 an example and cost but no guidance on when to use this tool versus alternatives such as group_synastry or hd_group_overlay. The only usage constraint is the group size (3-5 people), leaving the agent to infer the rest.
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?
Annotations already declare this as read-only and idempotent. The description adds that it calculates from initials, which is consistent but does not provide significant additional behavioral context beyond the input 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 short and front-loaded with the purpose. However, the example contains an extraneous parameter not in the schema, which is inaccurate and misleading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain how the name is provided (missing from schema), nor does it describe the return value. For a tool with 4 parameters and no output schema, this is critically incomplete.
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 description states the tool uses initials from the full name, yet the input schema does not include any 'name' parameter. The example includes 'name' which is not in the schema, creating confusion. Schema coverage is 100% but the description contradicts 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 calculates the Balance number using initials from the full name, specifying the Numerology Chaldean system. This distinguishes it from other Chaldean numerology tools like life_path or expression.
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?
An example request body with name and date is provided, implying use when these are available. However, no explicit guidance on when to use this versus sibling tools (e.g., other Chaldean numerology calculators) is 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?
Annotations already mark as read-only and idempotent. The description adds the derivation formula and activation age, aligning with annotations. No contradiction. However, it does not disclose potential effects of optional parameters or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a group label and example. No redundant information; every part adds value. Well-structured and front-loaded with key 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?
With no output schema and optional parameters (latitude, longitude, timezoneOffset) unexplained, the description does not fully specify input expectations or return structure. The example omits optional fields, leaving their use unclear for this calculation.
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 descriptions cover all parameters (100% coverage), but the description adds no extra parameter details. The example request includes 'name' which is not in the schema, potentially misleading an agent about required inputs.
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 calculates the Kabbalistic Maturity number, derived from Life Path and Expression, with activation at age 35. It specifies the system (Kabbalistic phonetic) and provides a formula, but does not differentiate between this and the strict Kabbalistic version 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus other maturity calculators (like strict or Pythagorean versions). It mentions activation age but does not address context or prerequisites, nor does it advise against use in any scenario.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, providing sufficient behavioral transparency. The description adds no additional behavioral context beyond these 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?
The description is concise but includes an example request body that introduces a parameter not in the schema, causing confusion. Conciseness is present but flawed by misleading content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 fails to explain what the tool returns. Additionally, the parameter mismatch leaves the tool's required inputs unclear, making the description incomplete.
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 description's example includes a 'name' parameter not present in the input schema, while the schema includes parameters like latitude, longitude, etc., which seem irrelevant to the calculation. Despite 100% schema coverage, the mismatch between description and schema undermines 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 calculates the Personality number from consonants of the full birth name using the Kabbalistic Mathers strict system. It differentiates itself from sibling tools like life_path or soul_urge by specifying the exact calculation.
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 through the group 'Numerology — Kabbalistic (Mathers strict)' and the title, but lacks explicit guidance on when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds group and cost information but does not elaborate on behavioral traits beyond the annotations. No contradiction detected.
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 with only three lines of text plus group/cost and an example. It is front-loaded and contains 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?
With 11 parameters, no output schema, and many optional fields, the description is incomplete. It lacks explanation of optional parameters and expected output format, making it insufficient for an agent to fully understand usage.
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 description coverage is 0%, so the description must compensate. It provides an example covering 5 of 11 parameters but omits explanation for houseSystem, name, city, zodiacType, ayanamsaId, and cosmogram, leaving significant gaps.
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 verb 'Calculate' and the resource 'synodic phase of each planet relative to the Sun', and lists the eight phases. However, it does not explicitly distinguish this tool from siblings such as 'moon_phase' or 'planetary_cycles', though the planetary focus is implied.
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 mentions a group and cost but lacks explicit context for selection or exclusion 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe reads. The description adds no behavioral context such as output format, what happens with invalid input, or any constraints beyond the example. It does not contradict annotations but fails to add meaningful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short: three sentences including the group label and example. It is concise and front-loaded with purpose, but could benefit from slightly more detail without becoming 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?
Given there is no output schema, the description should explain what the tool returns (e.g., card positions, interpretation). It only provides an input example, leaving the agent without knowledge of the output structure. Annotations cover safety but not 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 input schema is minimal with only a 'body' object having no defined properties. The description provides an example showing required fields (seed, question, allowReversed), which adds essential semantics beyond the schema. However, it does not formally document all possible parameters or their types.
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 'Adapted Celtic Cross with Lenormand cards' which clearly identifies the tool as a Celtic Cross spread using Lenormand cards. The title and group label help differentiate from other tarot tools, but it does not explicitly distinguish from the similar 'tarot_marseille_draw_celtic_cross' sibling, lacking explicit differentiation.
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 an example request body but gives no guidance on when to use this tool versus alternatives (e.g., other Lenormand draws or Marseille Celtic Cross). There are no usage scenarios, when-not-to-use, or alternative tool mentions.
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?
Annotations indicate read-only, idempotent behavior. The description adds no additional behavioral context such as output format, number of cards interpreted, or any side effects. Without annotations, this would be a 1, but annotations partially fulfill 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 extremely concise (3 lines) and front-loads the essential purpose and group. The example is included without unnecessary text. However, it could be slightly more structured for 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?
Despite the simplicity of the tool (single parameter), the absence of output schema or description of return values (e.g., card interpretations or positions) leaves the agent uncertain about what to expect. The example only covers input.
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 defines only a generic 'body' object with additional properties. The description compensates by providing a concrete example request with fields (seed, question, allowReversed), clarifying required structure 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 states '7-card pyramid spread' and groups it under Tarot — Marseille, making the purpose clear. It differentiates from sibling tools through the specific card count and spread type, though 'pyramid' could be more explicitly defined.
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 spread versus alternatives like Celtic Cross or three-card draws. The context signals show many sibling tarot tools, but the description offers no selection criteria.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat these. However, it adds no extra behavioral context beyond the purpose. The description does not contradict annotations, but provides minimal additional 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 concise at two sentences plus an example, with front-loaded main purpose. The example is somewhat lengthy but useful. Minor improvement could be integrating the example more smoothly or removing the group tag line.
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?
Despite annotations and schema providing some structure, the description lacks details on output format, which is crucial since there is no output schema. The tool has 11 parameters, many optional, but no guidance on how they influence results. The description is insufficient for an agent to fully understand tool behavior.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters. It only provides an example request without clarifying what each parameter represents or how they affect the calculation. This is a significant gap, as the description should compensate for low 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 what the tool computes: 'Karakamsa — sign occupied by the Atmakaraka in the Navamsa (D9).' It provides astrological significance by referencing Jaimini Sutras and indicating soul-level destiny. This is distinct from numerous sibling tools like vedic_jaimini_karakas or vedic_varga_D9, making its 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 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 only provides a group tag '[Group: Vedic]' and an example request, but does not explain scenarios where this tool is appropriate or when other Jaimini tools (e.g., vedic_jaimini_chara_karakas) should be used instead.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) cover safety. The description adds the computational rule and source (Jaimini Sutras 1.1), but does not disclose return format, pagination, or error behavior. It provides modest added context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three lines plus an example, with a clear structure: rule, reference, group, sample. It front-loads the core purpose. However, it could be improved by including parameter explanations without becoming overly long.
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?
Despite annotations covering safety, the description lacks essential context: no output format, no parameter explanations, and no usage notes. For a tool with 11 parameters and no schema descriptions, this is insufficient to fully specify its behavior.
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?
Schema description coverage is 0%. The description does not explain any of the 11 parameters (e.g., houseSystem, zodiacType, ayanamsaId, cosmogram) beyond a sample request. Agents cannot learn parameter meaning from the description, relying entirely on parameter names and schema, which is insufficient.
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 this tool computes a 'Jaimini rasi drishti table' for sign aspects, specifying the exact rule for movable, fixed, and dual signs. It is distinct from sibling tools like vedic_jaimini_drishti_graha (planetary aspects) and vedic_jaimini_argala_analysis, making its 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 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. With many vedic_jaimini_* siblings, agents are left to infer usage context without direction on when sign aspects are needed over other Jaimini calculations.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that the tool returns a table of sub-lord chains, which is consistent with read-only behavior, but does not disclose additional behavioral traits such as performance impacts or limitations.
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 includes an example request, making it easy to parse. However, it could be more structured by listing key parameters or output format, though the conciseness is not overly detrimental.
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 (11 parameters, no output schema), the description is insufficient. It omits output structure, parameter descriptions, and behavioral constraints, making it hard for an agent to use correctly without external knowledge.
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?
With 0% schema description coverage, the description fails to explain any of the 11 parameters. It only provides an example request body, leaving agents to infer parameter meanings from context or trial-and-error.
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 provides a full KP 'horoscope at a glance' table with sub-lord chain for every cusp and planet, distinguishing it from sibling tools like vedic_kp_cusps which may only cover cusps or specific details.
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 does not mention prerequisites, when not to use, or differentiate from similar KP tools, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. The description adds no behavioral traits beyond the calculation details, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and includes detailed sub-strength information. It is concise for the technical content, though slightly lengthy.
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 return values or structure. For a complex Vedic 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 11 parameters with 0% description coverage. The tool description only provides an example body without explaining any parameter meaning, usage, or constraints.
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 computes Sthana Bala, a component of Shadbala, listing the five sub-strengths with specific references. This distinguishes it from sibling tools like vedic_shadbala_cheshta and vedic_shadbala_dig.
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 other Shadbala tools or alternatives. The description lacks any context about specific use cases 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it scans for house-based yogas and returns strength scores and manifestation hints. It does not contradict annotations but also does not disclose additional behaviors like rate limits or error handling. With annotations present, the description adds marginal value.
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 reasonably concise with two main sentences plus group, cost, and an example. It front-loads the core functionality. The example request body aids understanding without excessive text.
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 (8 karakas, house-based yogas, strength scoring) and no output schema, the description provides only a high-level output description. It does not explain what the strength score means, how houses are determined, or the structure of the returned data. More detail is needed for complete understanding.
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?
Schema description coverage is 0%, so the description should explain parameters. However, it only provides an example request body without describing any parameter meaning. Parameters like ayanamsaId, zodiacType, or houseSystem are critical for Vedic astrology but are not explained. The description fails to compensate for the lack of schema documentation.
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 scans every chara karaka for house-based yogas and returns 8 yogas with karaka role, house, and strength score 0-100. It is specific about the verb 'scans' and the resource 'chara karaka', and it distinguishes from sibling tools like vedic_yogas_jaimini_daridra and vedic_yogas_jaimini_dhana by focusing on all 8 karakas.
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 explicit guidance on when to use this tool versus other Vedic yoga tools (e.g., vedic_yogas_jaimini_full). It mentions group and cost but lacks context for selection. No exclusion or alternative references.
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?
Annotations already indicate read-only, non-destructive, idempotent. Description adds group (Vedic), cost (50 credits), and example request, but no further behavioral traits like side effects or limitations beyond what annotations cover. Adequate but not additive.
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?
Two sentences defining the yoga plus group/cost info and an example. Concise and front-loaded with key concept. The example is somewhat lengthy but not excessive. No wasted sentences.
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?
Missing return format, output schema, prerequisite conditions (e.g., need accurate birth data), and how to interpret results. With 11 params and no output schema, agents lack sufficient context for correct invocation and result handling.
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?
With 0% schema description coverage and 11 parameters (2 required), the description provides no parameter explanations. The example request body shows typical values but does not explain the meaning or usage of any parameter. Fails to add value beyond the input 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 defines Dhana Yoga as the connection between lords of wealth houses (1,2,5,9,11) via conjunction, mutual drishti, or strict parivartana. This is specific and differentiates from other yoga tools like raja yogas or jaimini dhana yogas, as it specifies Parashara method.
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 such as vedic_yogas_jaimini_dhana or other yogas. Lacks context for selection, no when-not-to-use or prerequisites 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds cost (50 credits) and group (Vedic), but no behavioral traits beyond what annotations provide. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and mostly relevant, but includes redundant listing of yogas with planets (already covered in the list). Front-loads purpose well. Group and cost info are useful extras.
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 description of return values or behavior for this complex astrological calculation. Many parameters remain unexplained. Incomplete for an agent to use correctly without external knowledge.
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?
Input schema has 11 parameters with 0% description coverage. The description only shows an example request body for date/time/location. Other parameters like houseSystem, zodiacType, ayanamsaId, cosmogram are not explained, leaving the agent without necessary context.
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 the 5 Mahapurusha yogas, listing each by name and associated planet (Ruchaka-Mars, etc.) and defines the formation condition (planet in own/exalted sign AND in kendra). This is specific and distinguishes it from generic yoga 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 guidance on when to use this tool vs alternatives like vedic_yogas_parashara_dhana or vedic_yogas_jaimini_full. The description does not provide usage context 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?
The description adds the behavioral detail that alerts are sent 'default 7 days before' an eclipse, which is not in annotations. However, it doesn't disclose other important behaviors like idempotency, authentication requirements, or how to manage subscriptions. Annotations are minimal (readOnlyHint=false, etc.) and are not contradicted, but the description only partially fills the transparency gap.
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 very short and front-loaded with the main purpose. The example is helpful and the group label provides context. It is appropriately concise for a simple tool with one parameter, though it could include a bit more detail without losing efficiency.
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 webhook registration tool, the description covers the essential action and gives an example. However, it omits details like how to unsubscribe, confirmation behavior, or error handling. Given the tool has no output schema, some additional context would improve completeness.
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 0% description coverage, so the description must compensate. It provides an example request body showing the expected URL format, but does not explain the parameter's purpose (e.g., 'the endpoint URL that will receive eclipse alert notifications') or any constraints like HTTPS requirement. The example helps but is insufficient for full understanding.
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?
Description clearly states 'Subscribe to upcoming eclipse alerts' with a default timing, and the title says 'Register Eclipse-Alert Webhook'. It identifies the specific resource (eclipse alerts) and action (subscribe/register). However, it does not explicitly differentiate from sibling webhook tools like webhooks_subscribe or webhooks_dasha_change, which slightly reduces 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 alternatives. There is no mention of prerequisites, when not to use it, or comparisons with other webhook subscription tools. The description lacks any usage context beyond stating what it does.
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?
The description discloses that the tool persists results and checks CNAME, adding value beyond annotations. However, it contradicts the readOnlyHint=true annotation by stating it modifies state, creating confusion. The description is accurate but the annotation conflict lowers the score.
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 explaining functionality and a hint about A records, plus cost info. It is front-loaded and efficient, but missing the promised example for the body parameter.
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, and the description does not detail the return format beyond mentioning A records as hints. The parameter is also insufficiently documented. With one parameter and no output schema, the description should provide more context to be complete.
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 describes the body parameter as 'Raw JSON body — see the example in the tool description for required fields,' but the tool description does not include any example or list of fields. The agent has no guidance on what to include in the body, making parameter semantics extremely poor.
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 if the custom_domain has a CNAME pointing to api.astroway.info, persists the result, and provides hints for A records. It is distinct from siblings like whitelabel_logo and whitelabel_preview, which handle other whitelabel settings.
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 verifying custom domain DNS, but it does not explicitly state when to use it or contrast it with alternatives. The context of whitelabel tools makes it obvious, but no explicit guidance is 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so safety profile is clear. The description adds the default 700-mile orb and cost info, but does not disclose other behavioral traits like output format or limits beyond radiusDeg. With annotations present, the description provides minor added 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 concise: two sentences plus an example. It includes metadata like group and cost efficiently. No unnecessary words, though the example could be integrated more succinctly. Overall well-structured for its content.
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 explain what the tool returns (output format), which is critical since there is no output schema. It also fails to differentiate from sibling tools like 'acg' or 'local_space_influence_zone'. Given the complexity and lack of output schema, the description is incomplete for a standalone 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?
Input schema has 100% coverage with detailed descriptions for the body parameter and its nested properties. The description provides an example request body which aids understanding, but the schema already conveys parameter meaning. No additional semantic value is added 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 calculates radius zones around A*C*G lines with a default orb, specifying the action and resource. However, it does not differentiate from sibling tools like 'acg' or 'local_space_influence_zone' that may compute similar zones, so purpose is clear but lacks sibling distinction.
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 (e.g., 'acg' or 'local_space_influence_zone'). The example request body hints at usage but does not explain prerequisites or context. Explicit when/when-not instructions are absent.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, providing basic safety and idempotency info. The description adds minimal behavioral context beyond 'find within a date range,' but does not contradict annotations. Since annotations cover the behavioral burden, a score of 3 is appropriate.
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, including only essential information: purpose, group, cost, and an example. It is well-structured and front-loaded. The only minor drawback is the lack of parameter explanations, but overall it is efficient.
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 adequately explains the primary functionality and gives an example request. However, it does not clarify the output format, timezone handling, or the role of the optional longitude parameter. Given the tool's moderate complexity, this is a moderate gap.
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?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description only provides an example with startDate and endDate but does not explain their meaning, format (though schema has a pattern), or the purpose of the optional 'longitude' parameter, failing to compensate for the schema gap.
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 finds the nearest minimum brightness moment of Algol within a date range, using a specific verb ('Find') and resource ('minimum brightness moment of Algol'). It also provides context about Algol being an eclipsing variable star, which distinguishes it from other 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?
The description includes a group label and cost but no explicit guidance on when to use this tool versus alternatives. The sibling 'algol_minimum_nearest' exists but is not mentioned, and there are no when-not-to-use scenarios described.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe and idempotent. The description adds that it uses solar-term boundaries, which is relevant but not essential beyond annotations. No discussion of output format or potential limitations.
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?
Extremely concise: one sentence, a group label, and an example. No wasted words. Could be considered under-specified but still efficient for a simple tool.
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 does not explain what the tool returns (e.g., the format of stem and branch). Given the sibling list's complexity and the lack of output details, the description is incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters are described in the input schema. The description provides an example request but adds no new semantic meaning beyond what the schema already contains.
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?
Description clearly states the tool computes the month pillar stem and branch from solar-term boundaries. It specifies the resource (month pillar) and the input (date). However, it does not explicitly distinguish itself from sibling BaZi pillar tools like bazi_year_pillar or bazi_hour_pillar.
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 other BaZi pillar tools. No mention of prerequisites, alternative tools, or when not to use it. This is a significant gap given the large set 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly safe and idempotent. The description adds no behavioral details beyond the annotations, which is acceptable but not enhanced. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a group tag and example. The first sentence could be more precise, but overall it is concise and front-loaded with the group label. Every element serves a 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?
With 7 parameters and no output schema, the description fails to explain what the tool returns (e.g., a persona description, traits). The example only shows input. This gap leaves the agent uncertain about the tool's output and how to use 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%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the example request body, which just illustrates the schema. 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 states it generates a 'Native customer persona' aligned with the founder's sun-sign brand voice, which gives a clear verb+resource. However, it is ambiguous about using full birth chart data instead of just sun sign, and it doesn't fully distinguish from other business astrology tools like 'business_founder_personality'.
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 group label 'Business Astrology' provides context, but there is no mention of prerequisites, when not to use, or comparison to sibling tools like 'business_founder_personality' or 'business_ideal_partner_sign'.
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?
Annotations (readOnlyHint: true, idempotentHint: true) already cover the safety profile, and the description does not add any behavioral context beyond a group label. It neither contradicts nor enriches the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a group label and example. It is front-loaded with purpose and contains no fluff, but could be slightly expanded for better guidance.
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 fails to describe the tool's return value (e.g., is it a score, text, or boolean?). The 7 parameters and 2 required fields suggest complexity, and the description does not help the agent understand what to expect from the tool's response.
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. The example request illustrates usage but does not explain parameter semantics 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 indicates the tool evaluates suitability of a proposed launch date for a venture type, distinguishing it from other business astrology tools in the sibling list. However, it does not specify what 'suitability' means (e.g., a score or analysis), leaving some ambiguity.
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 like business_expansion_timing or business_founding_chart. The description lacks context for when the tool is appropriate, forcing the agent to infer from the 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety and idempotency. The description adds that it is 'element-based' but does not disclose any additional behavioral traits like what happens with invalid input or the nature of the output. With annotations present, the bar is lower, and the description adds marginal value beyond them.
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 and to the point, with a clear purpose and an example to illustrate usage. The group label is a helpful structural element. The example could be more concise, but overall it is 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 description lacks detail about the return value or output format, and there is no output schema to compensate. It mentions 'marketing voice and campaign style' but does not describe what the agent should expect. Given 7 parameters and complex astrology, the description is incomplete for an agent to fully understand the tool's behavior without additional inference.
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 each parameter is already documented with descriptions in the schema. The tool description does not add any new meaning or context for the parameters beyond the example request body. 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 states 'Element-based marketing voice and campaign style,' which clearly indicates the tool's purpose: to analyze or generate marketing style based on astrological elements. The group label 'Business Astrology' and example input further clarify. However, it lacks an explicit verb (e.g., 'calculate' or 'analyze') and could more distinctly differentiate from siblings like business_founder_personality.
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. It only gives an implicit context via the group label and example. There is no mention of conditions or exclusions, leaving the agent to infer usage without clear direction.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to add safety information. The description adds the concept of 'element-based' and 'safeguards', which provides some behavioral context, but it does not elaborate on what exactly is computed or the nature of the safeguards.
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 very concise (one line + example), but the example is lengthy and not structured. It is front-loaded with the core purpose but the example could be integrated better. Still, it is efficient with no wasted words.
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 lacks details about the output format, the nature of 'recommended safeguards', or how the risk tolerance is presented. With no output schema, the agent has insufficient context to interpret the result. The example only shows input, not output.
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 schema already documents all parameters. The description adds a concrete example request body, which helps illustrate parameter usage but does not add new semantics 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Element-based risk tolerance + recommended safeguards' clearly states the tool's output and methodology, distinguishing it from siblings like financial_risk_tolerance. However, it does not explicitly differentiate itself within the business tool group, leaving some ambiguity.
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 over alternatives, such as financial_risk_tolerance or other business-related tools. No context for selection is 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Multi-generational family pattern map' which is consistent but does not disclose behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise, consisting of a single phrase and a group tag. It avoids verbosity but could benefit from being slightly more structured with front-loaded 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?
Given the complexity of 3 required nested parameters and no output schema, the description lacks explanations of what a genogram is, how birth data is used, and what output format to expect. Significant gaps remain.
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 each parameter object having a description explaining required fields and defaults. The tool description itself adds no parameter 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?
Description clearly states 'Multi-generational family pattern map' indicating a genogram creation tool for three generations. It distinguishes from siblings like 'family_system_pattern' by naming and scope, but does not explicitly differentiate.
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 'family_system_pattern' or 'family_parent_child_deep'. No prerequisites or exclusions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds that the tool uses astrological signs (implied by 'by sign' and the group), which is consistent with annotations. No contradictions, but the description does not add significant behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—two lines plus an example—which is efficient and front-loaded with the purpose. It wastes no words, but could be slightly improved by adding a verb (e.g., 'Provides investor archetype...') 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?
Despite having annotations and a complete schema, the description lacks details about output format, interpretation of 'investor type', 'bias', 'strength', 'pitfall', and how the sign is derived (e.g., sun sign or rising). For an AI agent with no output schema, this incomplete context may lead to incorrect invocation or interpretation.
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% description coverage for all 7 parameters. The description provides an example request body, which gives concrete guidance on expected values and format. However, it does not explain parameter interaction or special constraints beyond the schema 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 states the tool outputs 'Investor type + bias + strength + pitfall by sign', which clearly identifies the resource. It is not a tautology and distinguishes it from siblings like financial_risk_tolerance or financial_spending_style by focusing on archetype determination from astrological sign. However, it lacks a verb (e.g., 'calculate') and the exact output structure is implied rather than explicit.
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 financial_wealth_archetype or financial_career_money_style. The group label 'Financial Astrology' provides context but no comparative or exclusionary advice. The description does not mention 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds the example request body showing it uses birth data, which is useful. However, it does not describe what the output looks like or how recommendations are generated.
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 and to the point, with only two sentences and an example. It is well-structured and front-loaded with the key phrase. However, it could be slightly more informative without losing 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?
Given that this is an astrological savings tool with 7 parameters and no output schema, the description does not explain what the tool returns, how it uses the elements, or what 'saving recommendations' means. It is incomplete for an agent to understand if it should be called.
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 all parameters are documented in the schema. The description does not add additional meaning beyond the schema, only provides an example. 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 'Element-based saving recommendations' combined with the title 'Savings Tips' and the example request body indicates it provides savings advice based on astrological elements. It distinguishes from sibling financial tools by specifying 'element-based', but could be more explicit about its astrological nature.
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 other financial tools like financial_lucky_day or financial_wealth_house. The description lacks any 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds 'full classical condition' but does not elaborate on what that implies behaviorally (e.g., whether it returns a planet, sign, or detailed conditions). With annotations covering basic safety, this is adequate but not enriched.
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, including a group tag and an example request body. It avoids unnecessary detail, though the group tag could be considered metadata. It is well-structured for a quick read.
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 lacks information about the output structure, which is especially important since there is no output schema. The agent cannot anticipate what the result will contain (e.g., planet, sign, conditions). Given the complexity of profection calculations, 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 coverage is 100%, so the schema already describes parameters (birth data and targetAge). The description does not add any additional meaning beyond what the schema provides. It references 'age' in the example but offers no further semantic detail. 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 states 'Annual profection year-lord with full classical condition,' clearly indicating the tool computes the year-lord for annual profections. The example shows the required age input. However, it does not distinguish itself from siblings like 'profections' or 'hellenistic_hand_perfections', which might produce similar output.
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. No when-to-use, when-not-to-use, or prerequisite information is given. The agent must infer its applicability from the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds no behavioral traits beyond 'timing technique', which is already implied. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence plus group tag and example). Front-loads the key action. Could be more structured but 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?
Despite annotations covering safety, the description lacks details on what decennials compute, the output format, or any behavioral context. No output schema further reduces completeness for a complex timing technique.
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%: the 'body' parameter includes a detailed description of birth data fields. The tool description adds no further parameter meaning beyond an example, so it meets the 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 'Hand's decennial timing technique', which indicates a specific verb (timing) and resource (decennials). However, it does not differentiate from sibling tools like hellenistic_hand_bounds or hellenistic_hand_decanic_rulers, which also relate to timing techniques in the Hand tradition.
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 only provides a group label and an example request, leaving the agent without context to choose among many hellenistic 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is clearly a safe, idempotent lookup. The description adds domain context (Hellenistic Hand tradition) but no additional behavioral traits beyond what annotations provide. This is adequate given the 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 extremely concise (two short lines) and front-loaded with the core purpose. It avoids redundancy. However, it could be slightly more informative without becoming verbose, hence 4 rather than 5.
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 give some hint about what the tool returns. It does not. Additionally, the concept of 'seasonal quarter' is not explained, which might be unclear to agents unfamiliar with Hellenistic astrology. Given the specificity, more context is needed.
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 single parameter 'body' is documented in the schema with a detailed description covering required fields (date, time) and defaults. Schema description coverage is 100%, so the description does not need to add more, but it also doesn't provide any extra parameter insight.
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 identifies the tool's purpose: computing the lord of the chart's seasonal quarter. The title 'Quarter Lord' reinforces this. While it doesn't elaborate on what a seasonal quarter is, the purpose is distinct from sibling tools like hellenistic_hand_bounds or hellenistic_hand_critical_degrees.
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 other hellenistic_hand_* tools or alternatives. There is no mention of prerequisites, exclusions, or typical use cases, leaving the agent to infer usage context independently.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds value by specifying output content (strengths, friction, 30-day themes) and cost (50 credits), which annotations do not cover. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded, but the example is overly long and contains a nested JSON structure. The cost and group info are useful but the example is misleading and could be omitted or corrected.
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, yet description only vaguely mentions outputs (strengths, friction, themes). Lacks detail on return structure. Parameter example mismatch further undermines completeness. Agent would lack sufficient context to invoke correctly or interpret results.
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?
Schema coverage is 0% (parameters not described in schema). Description fails to explain 'sign1', 'sign2', 'language', or 'disclaimer_inline'. The provided example uses 'chart1'/'chart2' with date objects, which contradicts the actual schema expecting sign strings, making it misleading.
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 'Generate a relationship horoscope based on synastry between two charts' with specific outputs (strengths, friction points, themes) and a 30-day timeframe, distinguishing it from siblings like 'synastry' or 'human_design_compatibility'.
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 choose this tool over alternatives (e.g., 'synastry', 'chinese_zodiac_compatibility'). No exclusions or prerequisite conditions mentioned, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description is not required to restate safety. It adds the detail of including retrograde re-entries, a behavioral trait. But it does not describe response format, pagination, or other behavioral aspects beyond the 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 concise: one sentence for purpose, plus group/cost/example. It is front-loaded with the verb. However, the example request body could be part of the schema rather than the description, slightly reducing efficiency.
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 (3 required parameters, no output schema), the description is incomplete. It does not specify what the tool returns (e.g., list of dates, sign names), error cases, or how planetId maps to celestial bodies. More context is needed for an agent to confidently use the tool.
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?
With 0% schema description coverage, the description must add meaning for each parameter. It provides an example request body but does not explain what 'planetId' values represent (e.g., mapping to planets) or the exact format of dates. The example gives a concrete instance but lacks semantic context.
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 finds sign ingresses for a planet within a date range, including retrograde re-entries. The verb 'find' and resource 'sign ingresses' are specific. However, it does not differentiate from many sibling tools that also involve planetary movements or ingresses.
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 a group label 'Calendar & Cycles' and a cost, hinting at typical usage. It mentions including retrograde re-entries, which clarifies scope. However, there is no explicit guidance on when not to use this tool or alternatives (e.g., stream_ingress for real-time).
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?
Annotations (readOnlyHint, destructiveHint) are consistent with the read-only interpretation task. Description adds credit cost information. Missing detail about output format (AI-generated text) but overall adequate.
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 with front-loaded purpose statement. The example is lengthy and potentially misleading, but the overall structure is 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?
Inconsistencies between the example and schema leave gaps. No description of the return value (AI interpretation). For a complex nested-parameter tool, the description is insufficiently comprehensive.
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 descriptions cover 100% of parameters, but the example request body in the description uses keys 'windowStart' and 'windowEnd' that do not match the schema's required 'transitDate', causing confusion and reducing clarity.
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?
Description clearly states verb 'interpretation' and resource 'transits to a natal chart', distinguishing it from natal-only interpretations. However, the phrase 'current/upcoming' and 'major transit' lack precise scope definition.
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 'ai_explain_transit' or 'transits'. The group marker hints at category but does not specify selection criteria 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds an example request body showing required fields and hints at input format, but does not disclose additional behavioral traits like error handling, data validity conditions, or return value structure. Since annotations handle most transparency needs, the description's contribution 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus example) and front-loaded with the core action. However, the inclusion of an errant 'name' field in the example introduces noise. The group label is useful for categorization, but overall the structure is adequate for a simple tool, though imperfect.
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 (calculating four cycles with age boundaries) and the absence of an output schema, the description should explain what the result contains (e.g., cycle numbers, age ranges) and how the calculation works. It does not mention any output details, leaving the agent to guess. The input schema includes optional location parameters not explained in the description, further reducing completeness.
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 coverage is 100% (all parameters described), so baseline is 3. However, the description's example includes a field 'name' that is not in the schema, causing confusion. The description does not explain the optional parameters (latitude, longitude, timezoneOffset) or their purpose. This undermines clarity and adds potential misinterpretation, warranting a lower score.
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 four Pinnacle cycles with their age boundaries, specifying the Kabbalistic (phonetic) system. The verb 'Calculate' and resource 'Pinnacle cycles' are precise, and the mention of 'life chapters of opportunity' adds context. It differentiates from sibling tools like chaldean or strict variants by naming the system.
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 guidance is provided. The description does not state when to use this tool versus alternatives (e.g., numerology_kabbalistic_strict_pinnacles or other systems). It lacks prerequisites, when-to-use, or when-not-to-use hints. The only context is the system name, which implies usage for Kabbalistic numerology, but no explicit 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, which effectively communicate the tool's safety profile. The description adds that it calculates cycles with age boundaries but does not contradict annotations. It provides some context beyond annotations but does not elaborate on behavior like required permissions 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a group tag and example. The key purpose is front-loaded. Every sentence adds value, though the example could be better aligned with the schema.
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 simple with 4 parameters and no output schema, but the description includes an example with a 'name' field that is not in the input schema, creating a mismatch. It also does not explain the return format or the precise requirement of inputs (name vs. date). This omission reduces completeness 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 description coverage is 100%, so the input schema already documents all 4 parameters. The description does not add parameter-level details beyond the schema. The example includes a name field not present in the schema, which could be confusing, but the schema itself is clear.
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 calculates four Pinnacle cycles with age boundaries, using a verb ('Calculate') and resource ('Pinnacle cycles'). It specifies the Vedic system via the title and group tag, which helps distinguish from other numerology systems. However, it does not explicitly differentiate from other pinnacles tools (e.g., chaldean, pythagorean), relying on the system mention.
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. It includes an example but does not explain context, prerequisites, or when to prefer this over other vedic numerology tools or pinnacles from other systems.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no additional behavioral context beyond the annotations, such as what the 'body' parameter should contain or the nature of the response.
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 very short and to the point, but it lacks critical information. It is concise but under-specified, earning an average score for structure.
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 large set of palmistry sibling tools and the tool's 1-parameter schema, the description is incomplete. It omits details about the required body payload and does not explain what the output represents. The annotations cover safety but not usage 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's description for the 'body' parameter merely points to an example in the tool description, but the provided example is empty. The tool description does not explain what fields are required or what the body object should contain, leaving ambiguity.
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 'Intellect, mental approach,' which is a precise and conventional interpretation of the head line in palmistry. This distinguishes it from sibling tools like palmistry_heart_line (emotions) and palmistry_life_line (vitality).
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 the numerous other palmistry tools or other tools. There is no mention of prerequisites, alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) already indicate a safe read-only operation. The description adds minor context about the layout but does not significantly enhance transparency beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a group tag and an example. However, the example is somewhat redundant given the schema, and the description could be more concise by omitting it.
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 is minimal for a tool with many sibling tools and a complex schema. It lacks details about the output format (SVG), how to configure options, and what the tool returns, leaving the agent with insufficient context to use it properly.
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 parameter details beyond the schema. The example request body is present but adds no semantic value over the schema's description.
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 renders a South Indian Vedic wheel in a 4x4 grid with fixed signs, and mentions house number placement. However, it does not distinguish from sibling tools like render_wheel_vedic_east or render_wheel_vedic_north, which are similar in 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 on when to use this tool versus alternatives such as other Vedic wheel renderings or render_aspect_grid. The description simply describes the layout without providing usage context.
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?
Annotations indicate the tool is not read-only (readOnlyHint=false), not destructive, and not idempotent. The description adds a disclaimer and notes it's a premium report, but does not explain behavioral details like what happens after generation (e.g., storage, deletion). The cost note is helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences plus a formatted cost warning. It is front-loaded with purpose and key content highlights. The example and group tag are separate, keeping the core concise. A fifth sentence might be warranted for output format details, but current structure is 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?
No output schema exists, so the description should clarify the report format (PDF/HTML) and structure. The title hints at formats, but the description omits this. The cost warning and disclaimer are present, but missing details on what the generated report contains (e.g., page count, sections) 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 baseline is 3. The description does not add meaning beyond the schema; it simply references chart data. The example request body provides a concrete usage pattern, but this is not part of the description itself.
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 founding-chart analysis for business, highlighting specific planetary points (Sun, MC, Jupiter, Saturn). The title adds that it generates PDF or HTML output. This distinguishes it from other report tools (e.g., reports_natal, reports_synastry) by focusing on business astrology.
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 explicit guidance on when to use this tool vs. alternatives. A cost warning is present but not usage context. Given many sibling report tools, the description should indicate what scenarios call for a business report vs. a natal or synastry report.
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?
Annotations already declare readOnlyHint, idempotentHint, and not destructive. The description adds only a group label and an example body, with no additional behavioral context such as whether the seed is required for reproducibility or how reversed cards affect output. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus an example. The purpose is front-loaded ('Full 36-card layout'), and the example is directly useful. No unnecessary words.
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?
Despite the tool's complexity (36-card layout), the description does not explain what the output contains (e.g., card interpretations, positions, houses). There is no output schema, so the description should clarify the return format. It is incomplete for an agent to understand the tool's full behavior.
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 is a generic 'body' object with no defined properties. The description compensates by providing an example request body with fields like seed, question, and allowReversed, clarifying what the agent should include. This adds 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 it's a 'Full 36-card layout — every card and house used,' which is a unique Lenormand spread. The name 'grand_tableau' reinforces this. However, the description lacks a strong verb like 'draw' or 'generate,' though the tool name implies the action.
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 sibling tools (e.g., tarot_lenormand_daily or tarot_lenormand_draw_9_card_square). The group annotation only indicates it's a Lenormand tool, but no contextual cues 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so description doesn't need to restate. No additional behavioral context (e.g., rate limits) provided. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise one-sentence description plus group tag and example. However, the example contains an extra parameter not in schema, which is a structural flaw.
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 provided; description does not mention return format or content. For a simple tool, minimal context, but the mismatching example reduces completeness.
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 covers all 4 parameters but description's example includes a 'year' field not defined in schema, creating confusion. No param description beyond schema's own 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?
Description clearly states 'Year card per Greer method' and includes group tag 'Tarot — Marseille', distinguishing it from sibling tools like tarot_marseille_birth_card or other draws.
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 other tarot tools for different spreads or card types. The example provides usage hint but no explicit selection criteria.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. However, the description adds no behavioral context beyond '6-card three-person love dynamics,' such as whether it returns card interpretations or positions. Given the presence of annotations, the score is adequate but not enhanced.
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 very short, containing only a one-line summary and an example. While concise, it lacks structured information about what the tool does beyond the minimal statement. The group tag and example add some value, but the description could benefit from a brief explanation of the spread's purpose or output.
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 lacks an output schema, and the description does not specify what the response contains (e.g., card names, positions, interpretations). For a complex spread like a love triangle, this omission leaves the agent uncertain about the return structure. Annotations provide some safety context but not 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 input schema defines a single 'body' parameter as a JSON object with no internal schema, but the tool description provides an example with fields 'seed,' 'question,' and 'allowReversed.' This example compensates for the lack of explicit schema details, giving meaning to the parameter's structure. However, explicit documentation of these fields would improve clarity.
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 title 'RWS — Love Triangle' and description '6-card three-person love dynamics' clearly indicate the tool is for a specific tarot spread about love triangles. It distinguishes itself from sibling tools like tarot_rider_waite_draw_relationship by specifying the number of cards and dynamics, making the purpose 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?
No explicit guidance is provided on when to use this tool versus alternatives such as tarot_rider_waite_draw_relationship or tarot_lenormand_draw_relationship. The description lacks context about suitable questions or scenarios, leaving the agent without direction for tool 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?
Annotations already declare readOnlyHint=true and idempotent. The description adds the spread positions and an example, but does not disclose important behavioral traits such as whether interpretation is included, if the seed makes it deterministic, or what the output format is. Minimal beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the spread name and group. The example is helpful. Efficient, though slightly more detail on expected parameters would not harm 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, the description should explain what the tool returns. It does not mention the response format, positions interpretation, or whether multiple cards are displayed. Annotations cover readOnly and idempotent, but the tarot context requires more completeness for an agent to use it correctly.
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 only defines a generic 'body' object. The description provides an example with seed, question, and allowReversed, giving meaning to the parameters. However, it does not explain field types, ranges, or whether they are required (example shows them as optional). Adds value but could be more explicit.
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 'Past / Present / Future three-card spread,' specifying the verb (draw) and the resource (three-card spread with positions). It distinguishes from single-card draws or other spreads by naming the spread type, but lacks elaboration on what the tool returns.
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 other tarot tools (e.g., single card, Celtic cross). The example implies it can answer a question, but there is no comparison with siblings to help the agent choose this spread over 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no new behavioral context beyond the example, which hints at reproducibility via seed and reversed cards. It does not explicitly state that the tool is read-only or idempotent, nor does it discuss potential 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 is very short (three lines) but includes necessary group context and a helpful example. It could be slightly more structured or include a brief note about output, but it avoids verbosity. It is concise but borders on too minimal.
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 that there is no output schema, the description should explain what the tool returns (e.g., a card name, image, interpretation). It does not specify the response format, leaving the agent to guess. The example only covers the request side. The tool is part of a complex tarot suite, and the description lacks completeness for an agent to confidently use it without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal, with only a 'body' object and no property definitions. However, the description provides an example request body showing the fields 'seed', 'question', and 'allowReversed', which fully compensates for the sparse schema. This example is essential for understanding the required parameters and their types.
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 provides a 'Single outcome card' from the Rider-Waite-Smith tarot deck. The title 'RWS — Outcome Card' helps differentiate it from other tarot tools like advice or daily draws. However, it doesn't explicitly distinguish itself from siblings beyond the phrase 'outcome card'.
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 gives no guidance on when to use this tool versus alternatives. It does not specify scenarios for outcome card draws compared to other tarot functions (e.g., advice, daily, cross sum). The group hint is present but not helpful for usage decisions.
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?
Annotations indicate read-only, idempotent, and non-destructive behavior. The description adds no behavioral details beyond the purpose. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of two lines and an example. It is concise and front-loaded, but could be slightly more structured with a clearer explanation of the output.
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 explain what the tool returns (e.g., a pair of cards). It only vaguely says 'shadow card pair' without clarifying the output format. Context is incomplete for a tool with no output schema.
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 schema already documents parameters. The description only provides an example with the required 'date' parameter, adding no extra meaning to optional parameters like latitude, longitude, or timezoneOffset.
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 a shadow card pair that mirrors the personality card in the major arcana, using the Rider-Waite-Smith deck. The tool name and group reinforce this. It distinguishes itself from other tarot tools by specifying the 'shadow' concept.
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 other tarot tools like the birth card or year card. The example only shows input format, not when the tool is appropriate.
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?
Annotations already declare readOnlyHint and idempotentHint, ensuring safe operation. The description adds the specific calculation method, but does not disclose return format, error handling, or side effects. With annotations covering the safety profile, a 3 is appropriate.
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 extremely short, but the example is inconsistent with the schema, reducing clarity. It lacks structure such as bullet points or clear sections, though it is free of unnecessary content.
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?
For a simple tool, the description omits what the output represents (a card name/number) and does not explain the return value. The inconsistent example further undermines completeness, especially given the absence of an output schema.
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 coverage is 100% with descriptions for all four parameters, but the description adds no new semantics. The example request body includes a 'year' field not present in the schema, creating confusion and potential misuse.
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 specifies it calculates a year card using the Greer method (m+d+year reduced), which clearly distinguishes it from other year card tools like tarot_marseille_year_card. The title 'RWS — Year Card' reinforces the resource and method.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, contexts, or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description's addition of 'day-for-a-lunar-month' and 'converse' adds some behavioral context. However, no details on error handling, edge cases, or computational cost beyond the credit label.
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 concise with two main sentences, group/cost metadata, and a helpful example. No unnecessary information, though the example is lengthy but valuable.
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 tertiary progressions and the large sibling tool set, the description lacks context about what the output contains, how it differs from similar tools, and any prerequisites (e.g., valid birth data). Annotations cover safety but not 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 includes an example that maps to the schema, but does not explain parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool calculates tertiary progressions using a day-for-a-lunar-month mapping and supports converse direction. The verb 'Calculate' and the specific resource 'tertiary progressions' make the purpose clear, though it does not differentiate from sibling tools like 'progressions' or 'minor_progressions'.
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., primary or minor progressions). The description only mentions converse direction support but lacks context on prerequisites, scenarios, 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?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds group and cost info but no further behavioral traits like output format or limitations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a single sentence stating purpose, plus group/cost and an example. Front-loaded and no superfluous content.
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 the return structure (e.g., list of months, aspect details). Also lacks guidance on when to use among many related siblings, 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?
Input schema has 100% description coverage, so baseline is 3. The description provides an example request but adds no additional semantic meaning beyond what is in 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 builds a month-by-month transit calendar showing exact dates of aspect ingresses and partile hits. This is a specific verb and resource, though it lacks explicit differentiation from sibling tools like transits or aspect_timeline.
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 does not mention prerequisites, when not to use, or contrast with related tools among the many siblings.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds '5-level cascade' and 'minute-scale duration' but does not clarify computational depth, limits, or what the cascade levels represent. Adequate but not rich.
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: one line of core info, group label, and example. No wasted words. However, it lacks structural elements like a summary sentence or explicit return description.
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 explain what the tool returns (e.g., list of dasha periods, timings). Given the complexity of a 5-level cascade, the description is insufficient for a complete understanding of the tool's capabilities.
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%, fully defining all parameters. The description provides an example that reinforces the schema fields but adds no new semantic meaning. Baseline score of 3 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 'Chara Pranadasha — 5-level cascade (finest grain). Minute-scale duration at full depth.' clearly identifies the tool's purpose as computing a specific Vedic dasha system at the finest granularity. The example reinforces the input requirements. However, it could be more explicit about the output nature.
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 implies it is for fine-grained timing analysis but provides no explicit guidance on when to use this tool over sibling dasha tools (e.g., vedic_dashas_chara_maha, vedic_dashas_chara_pratyantar). No when-not-to-use or alternative suggestions.
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?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds that it uses the same chakra-row at every depth and provides the formula. This adds some behavioral context, but does not disclose potential side effects or dependencies on accuracy of input parameters.
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, contains the formula, group, and cost indication. It is front-loaded with the tool's purpose. However, the technical formula might be improved with a brief plain-language explanation.
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 the tool and absence of output schema, the description does not describe the return structure (e.g., list of periods with signs, years, dates). It mentions '9 sub-periods' but not their format or how to interpret the results. 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 input schema covers 100% of parameters with descriptions, including birth data and target date. The description does not add new meaning beyond the schema; it only restates the targetDate concept. With full schema coverage, the baseline is 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 clearly states that the tool computes the 9 sub-periods (antardasha) of a running Mahadasha at a target date, and provides the calculation formula. It distinguishes itself from sibling tools like the maha and prana levels by specifying the antardasha level. However, it could be more explicit about the output being a list of sub-periods.
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 (e.g., maha, prana, sookshma). It only names the level and gives a formula, but no context for selection 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds that it is a 3-level cascade, which is a behavioral detail beyond annotations. No contradictions noted. However, it does not mention any input validation, error conditions, or output characteristics.
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 very concise: one line for the cascade, one line for group, and an example. No unnecessary words. It could benefit from a more structured format (e.g., bullet points for key features), but it efficiently communicates the core idea.
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?
For a complex tool with no output schema, the description is incomplete. It does not hint at what the output contains (e.g., period dates, planets, sub-periods). The agent cannot determine if this tool meets the user's need without additional knowledge. The example only shows input, leaving output behavior unspecified.
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 input schema itself provides detailed parameter explanations (e.g., required fields, defaults). The tool description adds an example request body but does not further explain the parameters' meaning or usage beyond the schema. This meets the baseline but does not elevate understanding.
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 identifies the tool as 'Shatabdika Pratyantardasha — 3-level cascade (MD → AD → 7 PDs)'. It names the dasha system and level, distinguishing it from other vedic dasha tools in the sibling list. However, it lacks an explicit action verb like 'calculate' or 'compute', slightly reducing clarity. The example request body reinforces the 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 versus alternatives. Among many similar dasha tools (e.g., antar, maha, sookshma, or other systems like vimshottari), the description does not explain the specific use case for shatabdika pratyantar. An agent would need external knowledge to decide.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds only '4-level cascade', hinting at hierarchical computation, but does not explain what the tool returns, how it processes the input, or any side effects. It adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line plus an example. It front-loads the key information (name and level) without waste. However, it could be slightly more informative without sacrificing conciseness, e.g., briefly stating the output.
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 (4-level cascade, target-date computation), but the description lacks any mention of return value or output format. No output schema exists, so the description should compensate by stating what the result contains (e.g., period dates, planetary lords). The example only shows input, not output.
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 provides an example request body, which helps illustrate the required structure and format (e.g., date, time, timezoneOffset). However, it does not explain the purpose of targetDate or other parameters explicitly; the schema already includes 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 explicitly states 'Shatabdika Sookshmadasha — 4-level cascade', clearly identifying the tool as the sookshma (sub-sub-sub) level of the Shatabdika dasha system. The title and group ('Vedic') further distinguish it from numerous sibling dasha tools for other systems and levels.
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 other dasha tools or levels. The description does not mention prerequisites, for example, that birth data is needed or that targetDate is required for computing sookshma periods. Alternatives (e.g., other dasha systems like Vimshottari) are not referenced.
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?
Annotations indicate readOnlyHint=true and idempotentHint=true, so safety is clear. The description adds that sub-periods are 'equal-split', providing computational context. However, it does not disclose behavior for invalid target dates or missing birth data, nor describe the output format or data structure.
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 very concise—two lines and an example—which is efficient. Front-loads purpose and method. However, it could be improved by adding a brief sentence about the output, but overall packs relevant info without 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 (many sibling dashas, nested input schema) and no output schema, the description is too minimal. It lacks details on the return value (e.g., a list of antardasha periods with start/end dates), which is essential for an agent to decide if this tool meets the user's need.
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 describes all parameters. The description adds value with an example request body and a note on lat/lon defaults, but does not explain the targetDate parameter's role or how targetTime/targetTzOffset relate to the computation.
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 'equal-split sub-periods of running MD at targetDate' for Sthira Antardasha, identifying the dasha system and sub-period level. It distinguishes itself from other vedic dasha tools by name and brief method, but could more explicitly state the output (e.g., list of sub-periods with dates).
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 like vedic_dashas_sthira_prana or vedic_dashas_vimshottari_antar. The 'Group: Vedic' hint is present but not actionable for selection. A sentence explaining that this is for equal-split sub-periods within the Sthira system would help.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) indicate safe, readable operation. The description adds behavioral detail: the specific condition checked (planetary positions relative to Moon) and the involvement of KP Moon sub-lord chain. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with essential definition. Includes an example request body. The '[Group: Vedic]' tag is extraneous but not harmful. Could be slightly more structured, but overall 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 11 parameters, 0% schema coverage, and no output schema, the description is incomplete. It mentions the yoga condition and sub-lord chain but lacks details on what exactly the tool returns (e.g., flag structure, sub-lord information). For a complex Vedic tool, more context is needed for proper usage.
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 coverage is 0%—no parameters are described. The description does not explain the 11 parameters (date, time, timezone, coordinates, house system, zodiac type, etc.). An example request body is provided but does not clarify semantics. This is a significant gap for proper parameter usage.
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 defines Kemadruma yoga as a check for no planets (excluding Sun, Rahu, Ketu) in 2nd or 12th from Moon, and identifies it as a moon-isolation flag for emotional/financial volatility. This is specific and distinct from sibling doshas tools, though it could be more explicit about the output being a boolean or flag.
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 dosha or vedic analysis tools. No alternative tools or when-not use cases are mentioned. The agent must infer usage from the generic name and context.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which imply a safe, idempotent calculation. The description does not add behavioral context beyond what annotations provide, nor does it contradict them.
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 short but includes a group tag and an example. However, it lacks structure (no sections) and omits critical parameter details. It is concise but at the expense of completeness.
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 11 parameters, 2 required, and no output schema, the description is inadequate. It does not explain the output format, how cancellations affect the result, or how to interpret the return value. The example shows inputs but not outputs.
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?
Input schema has 0% description coverage, and the description does not explain any parameter. The only parameter info is in the example request body, which shows values but not meaning. This leaves agents unable to understand parameters like zodiacType, houseSystem, or ayanamsaId.
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 determines Manglik dosha per Lal Kitab, specifying the houses (1/4/7/8/12) and cancellation condition (Mars in Aries/Scorpio/Gemini). It is distinct from siblings like vedic_doshas_lal_kitab_full or vedic_doshas_parashara_mangal.
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 vs alternative dosha tools. The name and group hint at Lal Kitab Manglik, but no comparison or selection criteria 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safe, non-mutating nature is clear. The description adds no extra behavioral context (e.g., permissions, rate limits, response structure). This is adequate but not enhanced.
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 short and includes a group label, cost, and example request. However, for a tool with 11 parameters, it is too brief and lacks structure (no parameter summaries or output hints). It is not efficiently front-loaded with key details.
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 (11 parameters, no output schema), the description fails to cover output format, interpretation of sub-patterns, or conditions for dosha presence. The example request omits many optional parameters, leaving the agent uninformed about their relevance.
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?
With 0% schema description coverage, the description must compensate but only provides an example request body for 5 of 11 parameters. It does not explain critical parameters like zodiacType, ayanamsaId, houseSystem, or cosmogram, leaving their meaning and usage ambiguous.
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 defines Grahan Dosha as conjunctions mimicking eclipses and lists the four sub-patterns (Surya-Rahu, Surya-Ketu, Chandra-Rahu, Chandra-Ketu). It uses specific verb+resource (identifies Grahan Dosha) and distinguishes from sibling dosha tools by naming the exact condition.
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 when-to-use or when-not-to-use guidance is provided. The description does not differentiate when to choose this tool over other vedic_doshas_parashara_* tools, leaving the agent without selection criteria.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, indicating safe, read-only behavior. The description adds value by detailing the calculation logic (star-lord, planet, sign-lord) and citing the source (K.S. Krishnamurti Reader IV). This goes beyond annotations by explaining how results are derived.
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 with the core definition. It includes a structured example and a group tag. However, the technical jargon (star-lord, sign-lord) may reduce clarity for non-experts. Still, it is concise and each sentence adds 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?
Despite many parameters and no output schema, the description fails to cover return format, error handling, or how the output should be interpreted. It only explains the significator hierarchy. The tool's complexity (11 parameters, no parameter descriptions) demands more context for an agent to use it effectively.
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 0% description coverage, leaving all 11 parameters undocumented. The description provides a single example request but does not explain individual parameters like houseSystem, zodiacType, or ayanamsaId. The agent lacks semantic understanding of optional parameters, making it prone to misuse.
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 'KP significator hierarchy per planet' and explains the three levels (primary, secondary, tertiary). This gives a specific verb and resource. However, it does not differentiate from other vedic_kp_* tools, such as vedic_kp_asc_sub or vedic_kp_cusps, so it lacks sibling distinction.
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?
There is no guidance on when to use this tool versus alternatives. The description only explains what it computes and provides an example request, but does not indicate scenarios, prerequisites, or when to avoid it. No alternative tools are mentioned, leaving the agent without usage context.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds that it uses 'Chaldean order' and includes 'sunrise/sunset and day ruler', which provides behavioral context beyond annotations. The cost mention (50 credits) is also helpful. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences plus example, front-loading the core purpose. However, it lacks structural elements like sections or a clear summary of required parameters. Still, every sentence adds value with no redundancy.
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 11 parameters, many optional and non-obvious (e.g., 'houseSystem', 'cosmogram'), the description fails to provide sufficient context. There is no output schema, and the description does not explain what the returned data looks like or how to interpret the horas. A more complete description would benefit the agent.
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?
With 0% schema description coverage, the description must compensate but fails to do so. It only provides an example request body without explaining any parameter meaning or constraints. Fields like 'houseSystem', 'zodiacType', 'ayanamsaId', and 'cosmogram' are left undefined, which is problematic for correct invocation.
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 returns '24 planetary hours per Chaldean order, with sunrise/sunset and day ruler'. This verb+resource combination is specific and distinguishes it from sibling panchang tools like 'vedic_panchang_full'. However, it does not explicitly mention that the tool requires a date/time and location, though that is implied by the required parameters.
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 vs alternatives such as 'vedic_panchang_choghadia', 'vedic_panchang_karana', etc. The description lacks explicit context for selection, leaving the agent to infer based on the name 'Hora' 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?
Annotations already declare readOnly, non-destructive, idempotent, and closed-world behavior. The description adds cost (20 credits) and group (Vedic), which are minor. It does not elaborate on output format, data sources, or any side effects. With annotations covering the core transparency needs, the description adds marginal value.
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 substantive sentences plus meta tags. It front-loads the core purpose and includes a helpful example. While brevity is good, it could be more informative without becoming verbose. No extraneous content.
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?
This is a complex topic (Vedic divisional chart) with 7 parameters and many sibling tools. The description does not explain the concept of vargas, the significance of D3, or how it relates to other divisional charts. Without an output schema, more context is needed for the agent to understand the tool's role and output.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description includes an example request body but does not provide additional semantics or constraints beyond the schema. Parameters like houseSystem and city are self-explanatory in 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 identifies the tool as a Drekkana chart (Varga D3) and mentions its associations with siblings, courage, and trinal third-of-sign division. However, it does not differentiate from many similar vedic_varga sibling tools such as D1, D4, D9, etc., leaving ambiguity about when to choose this specific chart over others.
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 does not state typical use cases, prerequisites, or contrasting scenarios. Given the abundance of similar sibling tools, explicit usage instructions are crucial but absent.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only cost information ('20 credits') and a group label, not behavioral details like data limits or caching. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description with an example request body is concise. The purpose is front-loaded, and the example is helpful. However, the example could be structured more clearly (e.g., bulleted list). Still 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?
With 7 parameters, no output schema, and a complex chart type, the description is too minimal. It explains what the chart represents but not what the output contains (e.g., planet positions, house cusps), how to interpret results, or any limitations. An example request is present 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%, so the schema already documents all parameters. The description does not add meaning beyond the schema (e.g., no clarifications on optional fields like houseSystem or city). 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 'Akshavedamsa chart (general life patterns, paternal lineage)' which specifies the exact chart type (Varga D45) and its domain. Combined with the title, it effectively distinguishes this from other varga charts among many 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use D45 over other varga charts (e.g., D1, D9, D60). The description does not mention scenarios, prerequisites, or alternatives, leaving the agent to infer without help.
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?
Annotations already indicate read-only and idempotent behavior. The description adds the specific astrological condition for the yoga, which is useful but does not elaborate further on behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example. No redundant or filler content.
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 output schema and details about what the returned data contains. For a specialized vedic yoga calculation, the description is too sparse to fully inform an agent about the tool's capabilities.
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?
With 0% schema coverage and 11 parameters, the description provides no parameter explanations. The example request body is insufficient for understanding parameter meaning or required 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 the tool computes Jaimini Dhana yoga, specifying the condition (AK or AmK in 2nd/11th from lagna) and the outcome (wealth indicator). It is distinct from sibling tools like vedic_yogas_jaimini_daridra or vedic_yogas_jaimini_raja.
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 other yoga tools (e.g., raja, daridra). The description only provides a generic example request body, failing to clarify context or 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds the source (Culpeper) and scope (all classical planets), but does not disclose how the planetary ruler is determined or any edge cases. Not contradictory.
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 plus a group label and example. It is front-loaded with key information, though the example, while helpful, could be omitted without losing core meaning.
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 7 parameters and no output schema, the description omits output details (e.g., list of herb names, descriptions). It also does not clarify how the sign is determined from the birth data, which is essential for agent 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% with all parameters described. The description only shows an example request body, adding no new meaning beyond the schema. Baseline 3 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 returns herbs ruled by the sign's traditional planetary lord, referencing Culpeper and covering all 7 classical planets. It distinguishes from sibling wellness tools like wellness_crystals or wellness_diet, though it could be more explicit about which sign (ascendant or sun) is used.
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. Among many sibling wellness and astrological tools, no usage context or exclusionary advice is 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe and repeatable behavior. The description adds that the output includes 'yoga focus + asanas + pranayama', which is helpful but not behavioral. It does not disclose any other traits such as data source, accuracy disclaimers, or limitations. Given the annotations cover the main behavioral aspects, the description provides minimal additional transparency, earning a 3.
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 very concise: one line for the core functionality plus a group tag and an example request. It is front-loaded with the most important information. However, it could include a slightly more detailed explanation of what the tool returns without becoming verbose. The example request is a helpful addition.
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 has 7 parameters, no output schema, and many sibling wellness tools, the description is incomplete. It does not describe the output format (e.g., text, structured data), nor does it guide the agent on how the parameters influence the result (e.g., how date/time determine the sign). It also fails to differentiate from wellness_exercise, which could be seen as overlapping. The agent lacks enough context to fully understand the tool's behavior and output.
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%, meaning all 7 parameters have descriptions (e.g., 'Birth date YYYY-MM-DD', 'House system: P=Placidus...'). The tool description adds no semantic value beyond the schema; it only provides an example request body. According to guidelines, when schema coverage is high (>80%), baseline is 3. No extra parameter info is given, so score 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 clearly states 'Sign-specific yoga focus + asanas + pranayama', which indicates the tool provides yoga recommendations personalized to the user's zodiac sign. The title 'Yoga Practice by Sign' reinforces this. However, it does not explicitly connect that the sign is derived from the birth data provided in the input, leaving slight ambiguity. Compared to sibling wellness tools like wellness_exercise or wellness_crystals, the 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.
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 like wellness_exercise or wellness_diet. There is no mention of typical use cases, prerequisites, or exclusions. An AI agent would have to infer from the title 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?
Annotations already indicate read-only, safe behavior. The description adds no additional behavioral context (e.g., what data is returned, any prerequisites). It is too brief to improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line of description, one line group, one line example. Front-loads the key purpose, but lacks structured formatting. Efficient but minimal.
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 only 4 params, so description should compensate. It fails to explain return format, scope, or any limitations. Incomplete for effective tool 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%, so baseline is 3. The description does not add parameter meaning beyond what the schema already provides; it only shows an example with date.
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 'Marriage partner, romantic union' which directly identifies what the tool provides. It is a specific palace in Zi Wei Dou Shu, distinct from sibling palace tools like ziwei_palace_career.
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 other palace tools or full chart interpretation. The description only provides a group label and example, but no contextual differentiation.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, etc., so the agent knows this is a safe query. The description does not contradict annotations and adds the example request, but doesn't elaborate on behavior like error cases or output format. With annotations covering safety, a 3 is appropriate.
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 includes only necessary information: the classification purpose, list of ten gods, group, and an example. It is front-loaded with the key action. A minor improvement would be to remove the list of gods if redundant, but it does not waste space.
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 4 parameters with only 1 required, and no output schema. The description lists the ten gods classifications, hinting at the output content, but does not specify the output structure or how the optional parameters (latitude, longitude, timezoneOffset) affect the result. For a simple classification tool, it is adequate 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%, so all parameters are described in the input schema. The description provides an example with 'date' but adds minimal extra meaning beyond the schema definitions. Baseline 3 is correct when the schema already documents parameters well.
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 does 'Ten Gods classification per day master', which is a specific verb and resource. It lists the ten gods categories and provides an example request. While it doesn't explicitly differentiate from siblings like 'bazi_day_master' or 'bazi_four_pillars', the purpose is well-defined 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 explicit guidance on when to use this tool versus alternatives. The description only mentions the group 'BaZi (Four Pillars)' and provides an example, but does not indicate when this classification is appropriate or what the prerequisites are. With many sibling BaZi tools, clearer usage cues would help.
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?
Annotations already indicate read-only, idempotent behavior. Description adds no further behavioral details beyond the basic output. No contradictions, but doesn't enhance 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?
Very concise, front-loads key purpose. Group label and example are useful. Could be slightly more detailed without losing brevity.
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, description explains return values briefly. Schema covers all parameters. Example aids understanding. 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?
Schema coverage is 100%, so parameters are well-defined. Description includes an example request, which adds some context but does not explain parameter meaning beyond 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?
Description clearly states output: founder type, strengths/weaknesses, ideal industry. However, it does not explicitly distinguish this tool from siblings like business_ideal_industry or business_leadership_style, leaving ambiguity.
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. Only an example request is provided, but no context for comparing with similar business 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. Description adds minimal behavioral context beyond the group and example. No mention of output or side effects, but annotations cover safety.
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?
Extremely concise: one line purpose, group in brackets, and a helpful example. No unnecessary text.
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, yet the description does not describe the return format (e.g., list of industry names). Sibling differentiation is absent. The tool is one of many business-related tools but no relationship is explained.
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 all parameters described. The description provides an example request body but does not add 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 it returns industries best suited to a founder profile. The verb is implied (return/list). However, it does not distinguish from sibling tools like business_founder_personality or business_marketing_style.
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. No exclusions or context provided beyond being part of 'Business Astrology' group. Example request is given but no usage scenario.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate safe, idempotent read. The description adds that it analyzes progressed lines, aspects, and latitude crossings, and includes an example request. No contradiction, but no further behavioral details (e.g., return format, 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 front-loaded with the core purpose, followed by group and cost metadata, and an example. It is efficient and includes useful information without excessive verbosity. The structure is 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?
Given the complexity (nested schema, many parameters) and no output schema, the description covers the main purpose and provides an example, but lacks details on output format and advanced features. Differentiation from many sibling tools is minimal, reducing 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 description coverage is 100%, so baseline is 3. The description includes an example request showing the structure, which provides some context beyond the schema's property descriptions. However, it does not explain individual parameters beyond what schema says.
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 analyses CCG lines, specifically progressed A*C*G lines with aspects and latitude crossings. It distinguishes from sibling tools like 'acg' by mentioning 'progressed' and 'CCG' (Cyclo-Carto-Graphy), though not explicitly differentiating. The verb 'analyse' and resource 'CCG lines' 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. The group tag '[Group: Astro-Geography]' hints at context but does not provide explicit usage conditions or exclusions. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and description adds 'upcoming eclipses' and 'Saros series context' for extra context. But no further behavioral details like cost implications or error handling. The description adds some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise at two sentences plus metadata lines and an example. The core purpose is front-loaded, though the example JSON adds length but is helpful.
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, description covers what the tool returns (aspects, house activations, Saros series). Annotations cover safety. Schema covers inputs thoroughly. The description is adequate for the tool's complexity.
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% description coverage, so the schema already explains parameters. The description provides an example but does not add additional semantic meaning beyond what the schema 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?
Description clearly states the tool analyzes eclipse impact on a natal chart, listing aspects, house activations, and Saros series context. However, it does not differentiate from the sibling 'eclipses' tool, which may have similar 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?
Description lacks guidance on when to use this tool versus alternatives. No explicit when-to-use or when-not-to-use context provided, only an example request.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool is safe and read-only. The description adds minimal behavioral context (it gives an archetype), but does not contradict annotations. With annotations covering safety, a 3 is appropriate.
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 very short (two lines plus example) with no unnecessary words. It is front-loaded with the key purpose. The example helps clarify usage. Could be slightly more informative but remains efficient.
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 astrological interpretation, the description is minimal. It does not specify the output format or content beyond 'archetype by sign'. Since there is no output schema, the description should ideally indicate what the tool returns. However, among a family of similar tools, the brevity is understandable. A 3 reflects adequacy with 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?
All 7 parameters have descriptions in the input schema (100% coverage). The description only provides an example request body and does not add any additional meaning to the parameters beyond what the schema already provides. 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 states 'Income / earning archetype by sign', clearly indicating the tool calculates a career money style archetype based on zodiac sign. However, it does not distinguish this from sibling tools like financial_wealth_house or financial_risk_tolerance, so it's not a 5.
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 information on when to use this tool versus alternatives among the many financial astrology tools. It only gives an example request body, which is not sufficient guidance 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool calculates conjunctions and returns star details and aspect type, but does not disclose behavior beyond what annotations imply (e.g., no mention of rate limits, cost details beyond example, or what happens with missing parameters). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one clear sentence explaining the function, followed by group/cost info and a JSON example. It is front-loaded with the key purpose. The example is helpful but could be more targeted. Overall, no wasted words.
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 (11 parameters, astrology domain), the description is incomplete. It does not explain the output format (no output schema), list all parameters, or describe which fixed stars are used. The example shows a request but not the response, leaving the agent uncertain about return values. Essential context like default values for houseSystem, zodiacType, etc., is missing.
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 11 parameters with 0% description coverage. The description only provides an example request body showing some parameters (date, time, timezoneOffset, latitude, longitude, orb) but does not explain their meaning or how they affect results. Parameters like orb are mentioned in the description text but not explicitly mapped. No parameter descriptions are added, so the description does little to clarify 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's purpose: 'Calculate conjunctions between natal planets and fixed stars within a specified orb. Returns star details and aspect type.' It uses a specific verb (calculate) and resource (conjunctions between natal planets and fixed stars), making the function distinct from sibling tools like 'aspects' which are broader.
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. While it includes a group label '[Group: Aspects & Points]', it does not differentiate from siblings like 'aspects' or 'moon_aspects'. There is no mention of when not to use or which tool to choose for similar tasks.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description's 'Calculate' aligns with these. It adds the cost (100 credits) but otherwise provides no additional behavioral context beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus metadata (Group, Cost) and an example. It is concise and well-structured, but the lack of an output schema or further details slightly detracts.
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., format of centers and channels). For a complex tool like HD group overlay, this omission leaves the agent uncertain about the output structure.
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 description coverage is 0% per context signals. The description does not explain parameter semantics; it only provides a JSON example. The schema itself has some descriptions inside the items property, but the tool description adds no value beyond that.
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 verb 'Calculate' and resource 'HD group overlay chart' for 2+ people, specifying 'collectively defined centers and channels'. This distinctively separates it from sibling tools like 'group_synastry' and 'human_design_compatibility'.
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 an example request but gives no guidance on when to use this tool versus alternatives like 'group_synastry' or 'human_design_compatibility'. No explicit 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal context ('career/action periods') but does not disclose additional behavioral traits such as impact on data or authentication needs. Annotations do the heavy lifting.
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 very brief (two lines plus group and example). It is front-loaded with purpose but lacks structure. The example is incomplete and not fully informative. Could be more organized.
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 specialized nature of Zodiacal Releasing, the description is insufficient. It does not explain the concept, output format, or limitations. No output schema exists, so the description should provide more context about what the result contains.
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 property descriptions for 'body' (chart data and years). The tool description adds no extra meaning beyond the schema, only a generic example. Baseline 3 is appropriate since the schema already documents 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 states it computes Zodiacal Releasing from the Lot of Spirit for career/action periods. The title and tool name reinforce this. It distinguishes from sibling tools like hellenistic_brennan_zodiacal_releasing_fortune (Lot of Fortune) and hellenistic_brennan_zr_loosing_of_bond.
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 does not compare with other ZR tools or time-lord methods, nor does it specify prerequisites or context of use.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by listing what checks are performed (early/late ASC, Via Combusta, Saturn in 7th, considerations before judgement). This clarifies what to expect beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It includes useful metadata (group, cost, example). The example is helpful but lacks parameter explanations. Overall, it is efficient but could be more complete.
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 (11 parameters, no output schema, no schema descriptions), the description is incomplete. It does not describe what the output looks like (e.g., text, JSON, report). The optional parameters (8 of 11) are left undocumented, making it hard to know their values or meaning. The description covers only the required fields in the example.
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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only gives an example request body with date, time, timezoneOffset, latitude, longitude, but does not explain any parameter beyond that. There is no description of houseSystem, name, city, zodiacType, ayanamsaId, cosmogram, or their defaults. This is a major gap.
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 runs a 'full horary radicality diagnostic' listing specific checks (early/late ASC, Via Combusta, Saturn in 7th, considerations before judgement). Verb 'Run' and resource 'full horary radicality diagnostic' are specific, and it distinguishes from sibling horary tools that focus on single aspects (e.g., horary_via_combusta).
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 calls it a 'full' diagnostic, implying it covers many checks, but does not state when one should prefer it over more specific horary tools (e.g., horary_moon_aspects) or what the prerequisites are. The cost is mentioned but not as a selection criterion.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating a safe read operation. The description aligns with this, stating it 'checks' and 'returns' data, but adds no new behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example request. Key information is front-loaded. However, the group and cost information could be considered extra detail not strictly necessary for understanding the tool's 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 11 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not specify the return format, explain what 'last aspect' means, or provide guidance on interpreting results. The tool's usage in horary astrology requires additional context not provided.
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 description coverage is 0%, so the description must add meaning to parameters. It only provides an example request covering required parameters (date, time, timezoneOffset, latitude, longitude) but does not explain the purpose or constraints of other fields like houseSystem, zodiacType, ayanamsaId, or cosmogram. This is insufficient for a tool with 11 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 the tool's purpose: 'Check if the Moon is void-of-course in this horary chart and return the last aspect it made and when it enters the next sign.' It uses a specific verb ('Check'), identifies the resource ('Moon is void-of-course'), and distinguishes from the sibling 'moon_voc' by explicitly mentioning 'horary chart'.
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 such as 'moon_voc' or 'horary_moon_aspects'. No explicit when-not-to-use or alternative suggestions are given, making it unclear for an AI agent to choose appropriately.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only that the tool shows 'each planet's altitude and azimuth', which is marginal behavioral context. No permission or limitation details are given beyond what annotations convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus metadata and an example. The main purpose is front-loaded. The metadata block (group, cost) is useful but could be integrated. The example is helpful but adds length. Overall, efficient for the information provided.
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 11 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain the return format beyond 'altitude and azimuth', nor does it clarify the role of optional parameters like 'houseSystem' or 'zodiacType'. An agent would lack essential context for effective use.
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?
With 0% schema description coverage, the description must explain parameters but only provides an example request body. It does not describe the meaning or purpose of any parameter (e.g., houseSystem, zodiacType). The example helps infer usage but does not add semantic value beyond the raw 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 function: 'Calculate the horizon chart showing each planet's altitude and azimuth relative to the observer's local horizon at birth.' It uses a specific verb ('calculate') and identifies the resource ('horizon chart') with explicit output details. This distinguishes it from sibling tools like 'local_space' or 'chart'.
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 any mention of preferred use cases, restrictions, or comparisons with related tools such as 'acg' or 'local_space'. The only additional context is the group label 'Astro-Geography', which hints at domain but is insufficient.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds minimal value by confirming it's a calculation, but does not disclose any additional behavioral traits like prerequisites or output format.
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 and front-loaded with the action. The example request is helpful, though the metadata (group, cost) adds structure. It is efficient with no wasted words.
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 and 11 parameters at 0% explanation, the description is incomplete. It does not describe the return value or the function of optional parameters, leaving significant gaps for the agent.
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 coverage is 0% and the description does not explain any parameters beyond providing a single example. Many parameters like houseSystem, zodiacType, ayanamsaId are left undocumented, forcing the agent to guess their 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 the tool calculates Hyleg and Alcocoden using a traditional Hellenistic method, with a specific verb ('Calculate') and resource ('Hyleg and Alcocoden'), distinguishing it from other Hellenistic tools like hellenistic_hand_longevity_hyleg.
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 hellenistic_hand_longevity_hyleg. The description lacks when-to-use or when-not-to-use context, forcing the agent to infer from the 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it uses birth data and returns hexagrams, but does not disclose any additional behavioral traits (e.g., pagination, error conditions). With reasonable annotation coverage, the description provides only minor additive value.
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: one sentence plus metadata (group, cost). It is front-loaded and to the point. However, it lacks structure like headings or bullet points, which could improve scannability.
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 annotations and schema coverage, the description covers the basic purpose. However, it lacks output format details and does not explain what 'gate' means or how the response is structured, which could be problematic without an output schema.
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 input schema already documents each parameter. The description does not add meaning beyond the schema; it only provides an example request. 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 returns I Ching hexagrams based on Human Design wheel gates, which is specific. However, it does not differentiate from related sibling tools like iching_daily or iching_throw_coins, leaving ambiguity about which tool to use for typical I Ching queries.
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. There is no mention of use cases, prerequisites, or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. Description adds cost of 100 credits and an example request, which is helpful. However, it does not explain the response format (e.g., plain text or structured data), especially since no output schema is provided. The description builds on annotations but leaves gaps.
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?
Description is very concise: a single sentence defining purpose, followed by group/cost metadata and an example. No fluff, front-loaded. Ideal for quick parsing.
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?
Despite 100% schema coverage, the description fails to connect that the tool requires both birth data (date/time) and a placement selection. The example shows only placement parameters, omitting required birth data. Given the complex nested input and no output schema, the description is insufficient 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 baseline is 3. The example request body clarifies that planet, sign, house, and language are expected, but the description does not explain the meaning of other parameters like birth data fields. The example omits required date/time, which could mislead. Slight value added but not substantial.
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?
Description clearly states 'AI interpretation of a specific planet+sign+house combination — concise, focused on the placement only.' This indicates the tool's specific scope but does not explicitly differentiate from sibling interpretation tools like interpret_natal or interpret_element.
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 only implies specialization for single placements, but lacks explicit when-not or sibling references. Among a long list of sibling interpretation tools, this omission reduces clarity.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds minimal behavioral context beyond stating the output (azimuth and altitude). It does not disclose potential side effects, authentication needs, rate limits, 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 concise, comprising two sentences plus example and metadata. The purpose is front-loaded, and the example is helpful. However, the group and cost lines could be integrated or omitted without losing core meaning.
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 11 parameters and no output schema, the description is insufficient. It fails to explain what 'each planet' means, the output format (list, object?), or how optional parameters like cosmogram affect results. The agent cannot reliably invoke this tool for non-trivial use cases.
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 coverage is 0%, so the description must compensate, but it only explains a few parameters via the example (date, time, timezoneOffset, latitude, longitude). Parameters like houseSystem, zodiacType, ayanamsaId, and cosmogram are not described, leaving the agent uncertain about their purpose.
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 calculates a local space chart, specifically azimuth and altitude of planets from a geographic location at the birth moment. The verb 'calculate' and resource 'local space chart' are specific, distinguishing it from siblings like local_space_influence_zone.
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 explicit guidance on when to use this tool versus alternatives. It includes a group label 'Astro-Geography' and a cost hint, but no when-to-use, when-not-to-use, or references to sibling tools like horizon, zenith, or relocation.
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?
Annotations already indicate readOnly and idempotent. Description adds the epoch and notation format, which is useful but doesn't reveal additional behavioral traits like optional parameter effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and includes a group tag and example. It is front-loaded with the notation explanation. Could be slightly clearer in stating the purpose, but overall 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?
No output schema exists, so description should explain the return value. It mentions 'Five-place positional notation' but doesn't explicitly state that the output is the Long Count string. Optional parameters (latitude, etc.) are not clarified for their impact on the conversion.
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 in the schema. Description adds an example and group tag 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?
Description states 'Five-place positional notation' and provides example, making it clear this converts a Gregorian date to Mayan Long Count. However, it doesn't explicitly state the conversion action, leaving slight ambiguity.
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 like mayan_tzolkin or mayan_calendar_round. The group tag 'Mayan Calendars' implies category but not differentiation.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to confirm read-only behavior. The description adds the specific output fields (number, name, element, direction, keyword), which provides some transparency beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with three sentences, front-loading key output information. It includes a practical example. There is no wasted text, though it could be slightly more structured with a list. Efficient overall.
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 lists return fields, which is helpful. However, it lacks usage guidelines and does not explain the optional location parameters. For a simple tool, it is moderately complete but could better aid agent decision-making among siblings.
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% description coverage for all parameters. The description only mentions an example date and does not add any additional semantics for latitude, longitude, or timezoneOffset. Baseline 3 is appropriate as the schema already documents parameters adequately.
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 returns a 260-day sacred calendar with specific fields (number, day-name, element, direction, keyword). This differentiates it from many other Mayan calendar tools in the sibling list, but it does not explicitly distinguish from similar tools like mayan_calendar_round or mayan_dreamspell.
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 does not mention any prerequisites, context for when it is appropriate, or when not to use it. The example only demonstrates a request body.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, read-like operation. The description adds that it uses Server-Sent Events and optional chart context, which is useful. However, it does not detail output format, error behavior, or rate limits, so it contributes some but not extensive transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example, and the group tag is helpful. It is front-loaded with the key purpose. However, the example could be more structured or separated for 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 complexity (3 parameters, nested chart object, streaming output), the description is incomplete. It lacks details on how to handle the SSE stream, expected events, or any output schema. Important operational context is missing 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description should compensate, but it only provides a brief example and does not explain the 'message' or 'language' parameters beyond the schema. The optional chart parameter is hinted but not fully detailed. The description adds marginal value over 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 'Server-Sent Events streaming chat completion with optional chart context', specifying the verb (streaming chat) and resource (completion). It distinguishes this tool from siblings like 'ai_chat' by emphasizing streaming via SSE.
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 such as 'ai_chat' or other streaming tools. It lacks when-to-use or when-not-to-use conditions, leaving the agent to infer based on the 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?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds that it calculates midpoints and optionally includes aspects, consistent with annotations. However, no additional behavioral details (e.g., output format, pagination, or rate limits) are provided beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the key purpose. However, it includes non-essential formatting like group and cost labels. The example is useful but could be integrated more clearly.
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 has 11 parameters, no output schema, and 0% parameter documentation, the description is severely incomplete. It only states what is calculated but not how to use the parameters or what the output structure is. The example provides minimal context.
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?
Schema description coverage is 0%, meaning no parameter descriptions exist in the input schema. The description does not explain any of the 11 parameters (date, time, timezoneOffset, etc.). The example request body shows values but lacks explanation of purpose or constraints.
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 calculates all planetary midpoints and zodiac positions, with an optional inclusion of midpoint aspects to natal points. This is specific and distinguishes it from sibling tools like 'aspects' or 'midpoint_trees'.
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?
Usage is implied by the tool's name and description (if you need midpoints, use this), but there is no explicit guidance on when to use it versus alternatives, or when not to use it. No mention of excluded cases or references to 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds the calculation source (Meeus Ch.48) and cost, but no additional behavioral traits like rate limits or data freshness. With high annotation coverage, a 3 is appropriate as description reinforces but does not significantly extend 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?
Description is mostly concise with line breaks and group/cost notes. The example request body is useful but slightly lengthy. Could be more streamlined without losing clarity, but overall it efficiently communicates the tool's purpose and usage.
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?
No output schema, but description lists key output fields (illumination %, age, elongation, waxing/waning, zodiac signs) and mentions calculation method. Input parameters are fully covered by schema and example. Fairly complete for a data retrieval tool, though missing details like timezone handling or 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 description coverage is 100%, so baseline is 3. Description provides an example request body that shows parameter usage, but adds no extra semantic meaning beyond the schema's descriptions. The example is helpful but does not elevate the score.
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?
Description clearly states 'current moon phase at a given moment' with specific outputs like illumination %, age, elongation, zodiac signs. Includes example request body. Slightly reduced from 5 because it does not explicitly differentiate from sibling tools like moon_aspects or lunar_calendar, though the name and output specificity help.
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 moon_aspects or lunar_return. The group label 'Calendar & Cycles' provides some implicit context, but no when-not-to-use or sibling 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?
While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds minimal behavioral context (reduction method). However, the example request body includes a 'name' parameter not present in the input schema, which is misleading and contradictory. The description does not clarify the role of optional location parameters or whether they affect the calculation.
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 concise (two sentences plus an example) and front-loaded with the action verb. The group tag is useful for categorizing. Every element serves a purpose without redundancy.
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, the description should describe the return value format or range, but it only says 'Calculate the Life Path number.' It also fails to explain the optional location parameters and whether they influence the result. The contradictory 'name' parameter in the example further 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 baseline is 3. The description adds meaning for the 'date' parameter by confirming it should be the birth date and that reduction is applied. However, it provides no explanation for the optional parameters (latitude, longitude, timezoneOffset), leaving their purpose ambiguous.
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 action ('Calculate the Life Path number'), the resource (birth date), and the system (Chaldean). It distinguishes from siblings like Pythagorean and Kabbalistic life path tools by explicitly stating 'Chaldean system' and using a group tag. The verb 'Calculate' 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?
The description provides no guidance on when to use this tool vs. alternatives. Among numerous numerology life path siblings (Pythagorean, Kabbalistic, Vedic), no criteria are given for selection. The group tag is implicit, but explicit when-to-use or when-not-to-use instructions are absent.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description is consistent, stating a calculation derived from birth date. No additional behavioral traits (e.g., validity handling, rate limits) are disclosed, but the annotations cover the safety profile adequately. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a group label and example, efficiently conveying the core action. It is front-loaded but could remove the redundant group mention. Still, it is appropriately sized.
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 input and general output (four Challenge cycles) but lacks details on output format or what the cycles represent. Without an output schema, the agent may need additional context to interpret results. The example is only for input.
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. The description adds the overall purpose but does not elaborate on parameter semantics beyond the schema. Baseline of 3 is appropriate as schema does the heavy lifting.
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 calculates four Challenge cycles using birth date components in the Kabbalistic (Mathers strict) system. The verb 'Calculate' and specific resource 'Challenge cycles' are well-defined. However, it does not explicitly differentiate from sibling tools like the non-strict kabbalistic challenge tool, relying on the title to convey the variant.
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 does not mention prerequisites, exclusions, or compare to similar tools (e.g., numerology_kabbalistic_challenge). The example only shows input, not 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, establishing this as a safe, non-destructive calculation. The description only adds that it calculates 'four Challenge cycles' and mentions the group, which is more about purpose than behavioral traits. No additional context about error handling, performance, or return characteristics is provided beyond what annotations give.
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 three sentences: purpose, group, an example request. It is front-loaded with the key action. However, the example includes an extraneous 'name' field, which slightly detracts from clarity. Overall, it is efficient and avoids unnecessary detail.
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 mentions 'four Challenge cycles' but does not explain what these cycles are, how they are derived (beyond 'birth date components'), or what the output format looks like. There is no output schema, so the agent must guess the structure of the result. Given the large number of sibling tools, the description lacks specific details that would help the agent understand the tool's unique value or output.
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 coverage is 100% (all 4 parameters are described in the schema). However, the description's example includes 'name' which is not a parameter in the schema, potentially confusing the agent about required inputs. The description does not clarify the optional parameters (latitude, longitude, timezoneOffset) or their purpose, adding no 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?
The description clearly states 'Calculate four Challenge cycles — life-area difficulties to master, derived from birth date components' with the specific system 'Numerology — Pythagorean system'. This distinguishes it from sibling tools like other numerology challenges (Chaldean, Kabbalistic) and other Pythagorean aspects (life path, expression). The action verb 'Calculate' and resource 'four Challenge cycles' are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a group tag '[Group: Numerology — Pythagorean]' which hints at context, but does not explicitly state when to use this tool versus alternatives (e.g., Chaldean Challenge or other Pythagorean tools). No when-not-to-use or alternative recommendations are provided, leaving the agent to infer usage from the name and group.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no further behavioral context (e.g., what happens with optional parameters, no side effects). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and efficient, with a single sentence, group tag, and example. It is well-structured and front-loaded, but very brief.
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 calculation tool with good annotations and full schema coverage, the description is adequate but lacks explanation of the Birthday number's significance or how it integrates with other Vedic numerology 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?
Schema coverage is 100%, so the schema already describes all parameters. The description adds an example but no additional meaning beyond what the schema provides. The optional location parameters are not explained further.
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 calculates the Birthday number from the day-of-birth digit, which is a specific verb and resource. It identifies the Vedic system, but does not explicitly differentiate from other numerology birthday tools among siblings, though the title and grouping help.
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 (e.g., other numerology birthday tools). There is no mention of context, exclusions, or prerequisites.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that the tool 'calculates' and 'derives' results, which is consistent but does not reveal additional behaviors such as output structure or edge cases. With annotations present, the description meets a baseline but adds minimal extra value.
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 three sentences: purpose, system tag, and example. It is front-loaded with the key action and quickly provides a concrete request example. No extraneous text. Slightly higher score because it is efficient and 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?
Without an output schema, the description does not explain what the tool returns (e.g., numeric cycles, interpretations). For a moderate-complexity calculation tool, this omission leaves the agent unsure of how to use results. Annotations and schema cover inputs well, but output context is missing.
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 fully documents parameters. The description only mentions 'birth date components', which maps to the required 'date' parameter but does not address the optional location parameters. Given full schema coverage, the description adds no significant 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 calculates 'four Challenge cycles — life-area difficulties to master' from birth date components. It specifies the Vedic system, distinguishing it from other numerological types, though it could more explicitly differentiate among the many sibling numerology 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 guidance is provided on when to use this tool versus alternatives like other challenge or cycle tools. It does not mention prerequisites, exclusions, or typical use cases, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context (e.g., required permissions, rate limits, or output behavior), but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear purpose and example, though the example introduces a parameter not in the schema, which detracts. The group tag adds organizational context.
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 value. For a tool with many siblings, more context (such as expected output or typical use cases) is needed. The missing 'name' parameter from the schema further reduces completeness.
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 description mentions 'full birth name letters' and the example includes a 'name' field, but the input schema has no 'name' property—only date and location fields. This mismatch confuses parameter semantics, and the description fails to clarify how name is supplied. Schema coverage is 100% but the description adds contradictory 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 clearly states the tool calculates the Expression (Destiny) number using the Vedic system from the full birth name, distinguishing it from other numerology tools like life path or soul urge.
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. With many sibling numerology tools, the description fails to specify context or exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the tool's safety profile is clear. The description adds no additional behavioral context (e.g., what the tool returns, required inputs beyond the body). With annotations covering the core safety, a score of 3 is appropriate.
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 extremely concise with two short sentences plus group and example. No fluff, but it is under-specified. Efficiency scored high, but substance lacks.
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 has a nested object parameter, no output schema, and many sibling tools, the description is incomplete. It fails to explain what data the body requires, what the tool returns, or how to use it effectively.
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 100% coverage for the single parameter 'body', but its description is vague ('Raw JSON body — see the example in the tool description for required fields'). The tool description only provides an empty example '{}', offering no meaning beyond the schema. The description fails to clarify what fields the body should contain, making it less than 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 tool name 'palmistry_heart_line' and title 'Heart Line' clearly indicate the subject. The description 'Emotional life, romance' matches the common interpretation of the heart line in palmistry, and it is distinct from other palmistry tools (fate, head, life, marriage lines) listed 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 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 other palmistry lines or alternatives. The group label 'Palmistry (Cheiro)' provides minimal context but no exclusion criteria or situational advice.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint, covering safety and idempotency. The description adds that the tool returns days of the week, but does not elaborate on format, edge cases, or other behavioral details. This is baseline adequacy.
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 very short—one sentence, a group label, and an example—with no filler. The group and example are placed after the main statement, which is acceptable. Every element earns its place.
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 there is no output schema, the description should clarify the format of the returned 'Days of week'. It only says 'Days of week traditionally aligned with the sign' without specifying whether output is a list, textual names, or numeric. The parameters are well-documented in the schema, so that is not a gap. Overall, the description is adequate but leaves some ambiguity about the output.
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 schema already documents all parameters. The description adds an example request body that illustrates typical values (e.g., timezoneOffset, lat/long), which provides practical context beyond the schema. This meets the baseline expectation but does not significantly enhance understanding.
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 'Days of week traditionally aligned with the sign' combined with the group '[Group: Pet Astrology]' clearly indicates it returns lucky days of the week for a pet based on astrological sign. It distinguishes itself from sibling tools like 'financial_lucky_day' through the group context, but could be more explicit about the pet scope.
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 or when not to use it. The group and title imply pet astrology usage, but there is no explicit instruction about preferred 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. The description adds that it returns 'training style + 3 tips' but provides no further behavioral details (e.g., output format, pagination, or astrological basis). Minimal additional value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The group label aids categorization. However, it is slightly terse and could benefit from a one-sentence elaboration. Example is appropriate but separate.
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 7 parameters, full schema coverage, and annotations, the description is adequate. The group and example clarify that astrology data is used. However, the output format is vaguely described ('3 tips'), and without an output schema, more detail would help. Score 3 for meeting minimum needs.
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 fully documented. The example request body illustrates usage but does not add meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Preferred training style + 3 tips' clearly states the tool's output. The group label '[Group: Pet Astrology]' and sibling tool names (e.g., pet_personality, pet_communication_style) disambiguate that this is for pets. Purpose is specific and distinct.
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 pet_personality or pet_communication_style. The description does not mention exclusions, prerequisites, or context. The agent must infer usage solely from the tool name and group.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds only the method names and output type. It does not disclose prerequisites or side effects beyond what annotations cover, but adds moderate 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 concise with two core sentences plus a metadata block and example. It avoids fluff, but the metadata could be integrated better. The example is helpful for understanding typical input.
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 11 parameters, no output schema, and decent annotations, the description is incomplete. It lacks parameter explanations, usage guidance, and output details, leaving significant gaps for an agent to proceed confidently.
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 description coverage is 0% for 11 parameters. The description only provides an example request body without explaining any parameter purpose, format, or constraints. This fails to compensate for the missing 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 calculates primary directions (Ptolemaic or Regiomontanus) up to a maximum age and returns a timeline of directed aspect hits. This distinguishes it from other prognostics tools like symbolic_directions and firdaria 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 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 includes a group label and cost but no when-to-use or when-not-to-use conditions, leaving the agent without selection criteria.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating no destructive effects. The description adds that the output is an SVG plot (from title) and includes an example request, but does not detail edge cases or further behavioral traits. It complements annotations well without contradicting them.
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 an example, front-loading the key purpose. The group marker adds minimal value. Could be slightly more efficient, but overall well-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?
Despite having 4 parameters (including a nested options object), the description does not explain output format, parameter meanings, or return value. The example partially compensates, but the tool requires richer context for correct invocation, especially given the complexity of options.
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?
Schema description coverage is 0%, and the description provides no explanations for parameters like birthDate, rangeStart, rangeEnd, or the options object. The example request body hints at usage but does not define semantics, leaving the agent to infer meaning solely from 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 renders a 'Three-curve sine plot of physical, emotional, and intellectual cycles since birth,' providing a specific verb and resource. Among many sibling render tools, this uniquely identifies biorhythm generation.
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., other render tools). It does not specify prerequisites, limitations, or scenarios where it is or isn't appropriate.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds only 'standard bi-wheel layout,' which does not disclose additional behavioral traits beyond annotations. It fails to mention any side effects, permissions, or output characteristics.
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 an example request body. It is front-loaded with the key purpose and layout summary. Every element serves a purpose with no filler.
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 bi-wheel chart with nested parameters and no output schema, the description is insufficient. It does not explain what the output contains (e.g., SVG vs JSON, aspect lines, house cusps) or how to interpret the result. The example only partially compensates.
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 67% description coverage for parameters. The description provides an example request body that illustrates usage but does not add significant meaning beyond the schema. For a tool with nested objects, the example helps contextualize parameter usage, but value 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 clearly states the tool renders a bi-wheel with inner natal and outer transit/progression rings, using the phrase 'Standard bi-wheel layout.' This distinguishes it from siblings like render_tri_wheel and other chart rendering 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?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit context such as choosing between transit or progression for the outer ring, or comparing with other render tools. The example is present but does not explain selection 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no additional behavioral context beyond the example, such as output format or performance considerations.
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 sentences and an example – extremely concise with zero wasted words. Front-loaded with the core 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?
The description provides an example but does not explain return values, error cases, or detailed behavior. For a tool with nested objects and no output schema, it is minimally adequate but could be more 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?
With 0% schema description coverage, the description compensates by providing a complete example request body that illustrates the structure of events and options parameters. This adds significant meaning beyond the schema alone.
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?
Description clearly states it renders a Gantt-style timeline of events using a supplied events array. However, it does not differentiate from similar sibling tools like 'aspect_timeline' or 'render_aspect_grid'.
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 implies it is for custom event timelines but does not provide when-not-to-use or exclusion criteria.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat safety. The description adds an example but does not disclose additional behavioral traits like output format or error handling. With strong annotation coverage, a score of 3 is appropriate.
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 an example. It is front-loaded with the layout and group, and every element serves a purpose. No wasted words.
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 lacks information about the output (e.g., SVG format), behavior on invalid inputs, and how to interpret the result. Given the complexity of the tool and no output schema, more context is needed 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 description coverage is 100%, so the input schema already documents all parameters thoroughly. The description's example request adds usage context but no new parameter semantics beyond the schema. Baseline 3 is justified.
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 specifies the East Indian (Bengali) layout with geometric details, making the purpose clear. However, it does not explicitly differentiate from sibling tools like render_wheel_vedic_north or render_wheel_vedic_south, relying on the title for distinction.
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 [Group: Visualization] badge and example request imply usage context, but no explicit when-to-use or when-not-to-use information 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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds no behavioral context beyond the purpose. It does not describe output format, error handling, or any side effects, which is acceptable for a simple lookup but still 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 very concise with the key purpose front-loaded. It includes a group tag and example request. However, it could be slightly more structured (e.g., explicitly listing input/output).
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 (single enum parameter, no output schema), the description provides the essential information. However, the lack of output format details (e.g., what is returned) leaves 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?
The input schema has no descriptions (0% coverage), so the description must compensate. It clarifies that 'sign' uses tropical zodiac and provides an example request. The term 'affinity rune' adds slight semantic nuance. This is adequate but not exceptional.
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 purpose: mapping a tropical zodiac sign to its Elder Futhark affinity rune. It is specific and distinct from sibling tools like 'runes' or 'runes_single', which do not involve zodiac signs.
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 does not mention exclusions or compare with sibling rune tools. The group tag 'Elder Futhark Runes' is present but insufficient for decision-making.
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?
Annotations include readOnlyHint=false, but streaming is inherently read-only, creating a contradiction. The description adds no behavioral context beyond the group label (e.g., connection management, rate limits, or that this is an SSE stream).
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?
Very short and front-loaded: the core purpose is in the first sentence. The group label and example are useful but not redundant. Could be slightly more efficient, but overall appropriate length.
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, so the description should indicate the stream's data format (e.g., timestamps, planetary hour identifiers). It only mentions 'planetary hour + next 24' without return structure. The streaming nature (SSE?) is implied but not specified. Incomplete for a 3-parameter tool with no output schema.
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 description coverage is 0%, so the description should explain parameters. The example shows values but does not clarify that latitude/longitude specify the location or that timezoneOffset adjusts time. The schema already provides basic types, but the description adds little 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 'Current planetary hour + next 24' clearly specifies the resource (planetary hour changes) and time scope (current and next 24 hours), distinguishing it from non-streaming siblings like 'planetary_hours'.
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 vs alternatives. The group label 'Real-time Streaming' implies use for live updates, but the description does not directly contrast with sibling 'planetary_hours' or state exclusions.
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?
Annotations include openWorldHint=true but do not clarify the streaming behavior. The description uses 'stream' and gives an example but does not explain whether this is a one-time fetch or a persistent connection, nor does it mention side effects, authentication, or rate limits beyond the minimal annotation hints.
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 very concise (around 30 words) and front-loaded with the purpose. It includes a group label and example, making it efficient. However, it omits important details, so it is not maximally concise while still informative.
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, low schema coverage, and a streaming context, the description is insufficient. It does not explain the output format, streaming mechanism, or how to interpret the data. The agent would struggle to use this tool correctly without additional knowledge.
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 coverage is 0%, so the description must compensate. It only provides an example with values but does not explain the meaning, constraints, or format of latitude, longitude, or timezoneOffset. The agent lacks essential 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 clearly states 'Today + tomorrow sun events' with a verb 'stream' and specific resource 'sunrise/sunset'. It includes a group label 'Real-time Streaming' and an example, making the purpose unambiguous and distinguishing it from sibling tools like 'sun_times'.
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 an example and group label but does not explicitly state when to use this tool over alternatives like 'stream_lunar_phase' or 'stream_positions'. Usage is implied through the example and group, but no when-not guidance is 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds no extra behavioral context (e.g., emotional impact of shadow work, or use of seed for reproducibility is only hinted via example).
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: two sentences plus an example. It front-loads the purpose and group, with no unnecessary words.
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 should explain what the tool returns (e.g., spread interpretation, card positions). It does not. The minimal description leaves the agent guessing about output format and 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?
The input schema has a single generic object parameter 'body' with no defined properties, so the description's example (seed, question, allowReversed) provides necessary clues. However, it does not formally document these fields, their types, or constraints, leaving ambiguity.
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 '6-card shadow integration spread', clearly indicating the tool draws a specific tarot spread. However, it does not differentiate this spread from the many other tarot draw tools among siblings, leaving the agent to infer its unique 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 vs. other tarot spread tools (e.g., celtic cross, decision). The description gives no context about appropriate use cases or 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's phrase 'single card to surface hidden information' adds mild behavioral context without contradicting annotations. But it does not elaborate on what 'surface hidden information' means operationally.
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 an example and a group tag. It is front-loaded with the main purpose and wastes no words.
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?
For a tool with a free-form JSON body parameter and no output schema, the description is incomplete. It lacks specification of required fields, field meanings, return format, and any constraints. The example helps but does not provide full 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 100% description coverage, but the body parameter description only says to see the example. The description provides an example with fields (seed, question, allowReversed) but does not explain their semantics or whether they are all required.
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 draws a single card to surface hidden information, with a specific verb and resource. However, it does not explicitly differentiate from other single-card tarot tools like tarot_rider_waite_draw_single, which could overlap in 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?
The description provides no guidance on when to use this tool versus the many sibling tarot tools (e.g., advice, clarify, shadow_card). It lacks any situational context 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?
The description adds behavioral details beyond annotations: it explains the equal-share subdivision (parent_years/12) and the ordering rule (next sign first, parent sign last). This is useful. However, it does not discuss potential limitations, error conditions, or data sensitivity. Annotations already indicate read-only and idempotent, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences plus an example. Every sentence adds value (purpose, algorithm, ordering, and example). No wasted words.
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?
For a complex Vedic dasha tool, the description is incomplete. It does not explain that birth chart data (date, time, location) is required to compute the running mahadasha, nor does it describe the output format (list of antardashas with start/end dates). The example includes birth data but the description assumes prior knowledge of dasha mechanics.
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 all parameters. The description adds an example body but does not provide additional meaning for parameters like latitude, longitude, or ayanamsaId. The description's mention of targetDate default is helpful but minimal.
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 12 sub-periods (antardashas) of a running mahadasha at a given date. It specifies the subdivision is equal-share. However, it does not explicitly differentiate this from sibling tools like vedic_dashas_chara_prana or vedic_dashas_chara_sookshma, which also calculate sub-periods at different levels.
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 maha, prana, pratyantar, or sookshma. The description mentions the calculation method and order but does not help the agent decide which dasha level to query. An example request is given but without usage context.
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?
Annotations already indicate read-only, idempotent behavior. The description adds that it is a '5-level cascade' with 'minutes-scale' precision, but does not explain what the output contains (e.g., list of periods, timestamps) or behavior when targetDate is omitted. Minimal added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line specifying the dasha type and depth, one line for group/cost, and an illustrative example. No redundant text; key information is 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?
For a complex tool with nested input schema (allOf) and no output schema, the description lacks critical context: it does not explain the 5-level cascade, how the objects in allOf combine, or what the output looks like. Sibling tools are numerous, but no differentiation is provided beyond grain size.
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 includes descriptions for the input fields (e.g., date/time required, defaults for lat/lon/tz). The tool description only provides an example, adding no new semantic information about parameters like targetDate, targetTime, or their meanings.
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 'Kalachakra Pranadasha — 5-level cascade (finest grain — minutes-scale at full depth)', which clearly identifies the specific dasha type and its granularity. The verb is implied (calculates) and it is differentiated from sibling dashas like maha or antar by mentioning 'prana' and depth level.
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 other Kalachakra dasha tools (e.g., maha, antar) or other dashas. The example includes a targetDate, hinting at usage for a specific date, but no when-not or alternative comparisons 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds '5-level cascade (finest grain)' which clarifies the computational granularity, but does not disclose other behavioral details such as data dependencies 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus an example. Every element serves a purpose—identifying the dasha system, level, group, and providing a concrete example. No 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?
The description lacks output context. With no output schema, agents are left guessing the response structure (e.g., list of periods with dates). The example only covers input. For a fine-grained computation 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?
Schema coverage is 100% with embedded descriptions. The description contributes an example request body, which demonstrates parameter usage but does not add new semantic information 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a Shatabdika Pranadasha (5-level cascade, finest grain), distinguishing it from coarser dasha levels (maha, antar) and other dasha systems among siblings. The verb 'compute' is implied via description and title.
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 when or when-not to use. The description does not differentiate this tool from other prana dashas (e.g., vimshottari prana) or explain context for selection beyond the group 'Vedic'. No alternatives 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?
Annotations already declare readOnlyHint and idempotentHint. The description adds the '3-level cascade' detail, but does not disclose what data is returned (periods, lords, dates). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the dasha level and group, then provides a complete example. Structure is minimal but effective.
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 mention what the tool returns (e.g., period timings, lords). It only states '3-level cascade' without specifying the output structure, leaving a significant gap for an agent.
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 provides a detailed description for the body parameter, covering all required and optional fields. The tool description includes an example request, reinforcing correct parameter usage.
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 names the specific dasha level (Pratyantardasha) and mentions '3-level cascade', clearly identifying the tool's function among sibling tools at different levels. However, it could be more explicit about what it computes (e.g., period timings and lords).
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 vs its siblings (e.g., antar, sookshma). The description only states its level, 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds minor behavioral context (e.g., sub-lord chain for transit-trigger analysis) but does not disclose further behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose, followed by a key feature and an example. It is efficient with no wasted words, though the example could be integrated more seamlessly.
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 11 parameters, no output schema, and many sibling tools, the description lacks details on output format, interpretation of results, and handling of optional parameters. It does not provide enough context for an AI agent to fully understand the tool's capabilities.
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 description coverage is 0%, so the description needs to compensate. It provides an example request body showing parameter usage but does not explain individual parameters' semantics, defaults, or constraints beyond the schema. For 11 parameters, this is insufficient.
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 Manglik dosha with KP sub-lord precision and includes a sub-lord chain of Mars for transit-trigger analysis. This distinguishes it from sibling tools like vedic_doshas_parashara_mangal by specifying the KP system.
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 Manglik dosha analysis within the KP framework but does not explicitly state when to use this tool versus alternatives or when not to use it. No comparison with siblings 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds context that the tool computes a single value based on a birth chart and references a specific astrological system. However, no details on error handling or what happens with invalid inputs are given.
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 with the key purpose. The example request body is helpful, though the group label '[Group: Vedic]' adds marginal value. Overall, it is concise but not overly terse.
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 11 parameters, 2 required, and no output schema, the description is insufficient. It does not describe the return value format, parameter constraints, or how to handle optional parameters. The example shows basic parameters but omits others like 'houseSystem' or 'zodiacType', leaving the agent without complete guidance.
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 11 parameters with 0% description coverage. The description does not explain any parameter beyond the example request body. For example, the meaning of 'houseSystem', 'zodiacType', or 'ayanamsaId' is not clarified, requiring the agent to infer from 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 clearly states the tool computes the KP ascendant sub-lord, the 'ruling indicator' for primary motivation and life direction. It references K.S. Krishnamurti's work and distinguishes itself from sibling tools like vedic_kp_sub_lords by focusing specifically on the ascendant.
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 determining the ascendant sub-lord but does not explicitly state when to use it versus alternatives like vedic_kp_cusps or vedic_kp_sub_lords. No when-to-use or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint false, idempotentHint true. The description adds value by detailing the output content (ASC longitude + sub-lord chain) and clarifying that the horary moment is the call moment passed in the body. It also provides an example request. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example and group tag. The first sentence front-loads the main purpose. The example is helpful. Minor redundancy: 'given a number 1..249' is clear but could be integrated. Overall efficient for the amount of information conveyed.
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 only gives a high-level output description ('ASC longitude + sub-lord chain'). It does not specify the structure of the response, what format the data is in, or how to interpret the sub-lord chain. The tool has 6 required parameters but no explanation of their significance for the horary calculation. Incomplete for an agent to reliably use without additional knowledge.
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?
Schema description coverage is 0%. The description does not explain any of the 7 parameters beyond showing them in an example. Required parameters like date, time, timezoneOffset, latitude, longitude are not described semantically. For a horary number lookup, location and time are crucial but their roles are unexplained. The description fails to compensate for the lack of 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?
Description clearly states 'KP horary number lookup' with specific verb and resource. It specifies input range (1-249) and output (canonical KP-table ASC longitude + sub-lord chain). This distinguishes it from sibling tools like vedic_kp_asc_sub which returns only ASC sub-lord, and vedic_kp_cusps which returns cusps. The purpose is highly 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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use, or differentiate from other KP tools in the sibling list. The agent is left to infer usage context from the tool 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. Description adds no new behavioral traits beyond detecting debts and returning remedies. It does not reveal potential side effects or limitations, but annotations cover the safety profile adequately.
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?
Three concise sentences plus an example. No wasted words, but the example could be better formatted as a parameter table. Still, it is well front-loaded and 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?
For a complex tool with 11 parameters, no output schema, and esoteric subject, the description should provide more context about what trigger conditions are, how output is structured, or the methodology behind detecting debts. It mentions sources but lacks completeness.
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 coverage is 0%, so the description carries full burden. It only illustrates an example with 5 of 11 parameters (date, time, timezoneOffset, latitude, longitude), leaving others like houseSystem, name, city, zodiacType, etc. unexplained. The example is helpful but insufficient for complete 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?
Clearly states the tool detects six specific ancestral debts (Pitri, Stree, etc.) using Lal Kitab patterns, and mentions output includes trigger conditions and remedies. This is a specific verb+resource with distinction from sibling tools like 'vedic_doshas_lal_kitab_rin'.
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 (e.g., vedic_doshas_lal_kitab_rin or other Vedic debt tools). The description provides an example request body but does not clarify context for use or exclusion criteria.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it's a 'scanner' of windows, which is consistent. No additional behavioral quirks (e.g., rate limits, response format) are disclosed, but the safety profile is covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (4 lines), includes an example, and front-loads the purpose. Every sentence adds value, though it could be more structured (e.g., bullet list for parameters).
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 7 parameters, no output schema, and annotations present, the description covers domain context (Vedic muhurat), preferred timings, and provides an example. However, it lacks full parameter descriptions and output expectations, leaving gaps for a complete understanding.
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 description coverage is 0%. The description only gives an example request body covering 5 of 7 parameters (search_window_start, search_window_end, latitude, longitude, timezoneOffset). It does not explain ayanamsaId or topN (which controls max results). Parameter meaning is poorly compensated.
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 title and description clearly state the tool finds auspicious windows for starting formal education (Vidyarambha). It lists preferred nakshatras and days to avoid, distinguishing it from other muhurat tools by name, but does not explicitly differentiate from 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 gives criteria (preferred nakshatras, avoid Sun/Tue/Sat) for when the scanner is applicable, implying use for education start ceremonies. However, it does not provide explicit when-not-to-use cases or compare with other vedic_muhurat_ 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?
Annotations already indicate read-only, non-destructive, idempotent, and non-open-world behavior. The description adds 'with karaka details' but does not contradict annotations or provide significant additional behavioral context beyond what the annotations already convey.
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 succinct, consisting of two lines with a clear purpose and an example request. The example is helpful but the overall structure is minimal, though it does not waste words. A sentence about parameters would improve conciseness further.
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 (11 parameters, no output schema), the description is insufficient. It does not explain what the composite output contains, how karaka details are presented, or how parameters like houseSystem, zodiacType, or ayanamsaId affect the result. The annotations cover safety but completeness is lacking.
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?
With 0% schema description coverage and 11 parameters, the description adds no semantic meaning to any parameter. It neither lists nor explains parameters, leaving the agent without guidance on what each parameter does or how to use them effectively.
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 composite summary of multiple Jaimini yogas (Raja, Dhana, Daridra, Viparita) with karaka details. This directly differentiates it from sibling tools that focus on individual yoga types.
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 combined overview of several yogas, but does not explicitly state when to use this tool versus the individual sibling tools (e.g., vedic_yogas_jaimini_raja). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (openWorldHint=true). Description does not clarify what 'N' is (not a parameter), whether registration updates existing webhooks, or side effects. Adds only the trigger event context.
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?
Extremely concise, front-loaded with key info. Group label helps categorization. Every sentence adds value without waste.
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?
Tool is simple with one parameter and no output schema. Missing details: what is N? Is it configurable? No info on response or errors. Adequate but has gaps.
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?
Only parameter 'url' has no schema description. Description only gives an example URL, not explaining its purpose or constraints beyond what the schema already indicates (type, format). Does not compensate for low schema coverage (0%).
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 fires N days before a Vimshottari mahadasha ends. Differentiates from sibling webhook tools by specifying the trigger event (mahadasha end). Verb 'fires' and resource 'webhook' are explicit.
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?
Provides an example request body but no guidance on when to use this vs other webhook tools (e.g., webhooks_dasha_change, webhooks_transit_trigger). No when-not or alternative conditions 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?
The description provides the trigger but no details about the webhook's behavior: what data is sent in the payload, how often it fires, whether it requires authentication, or any side effects. Annotations are minimal (destructiveHint=false, idempotentHint=false) and do not cover behavioral aspects. The example request body is for registration, not the event itself. This leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus an example), which is concise. It front-loads the trigger condition. However, it sacrifices necessary detail for brevity. The example is helpful but not fully explained.
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 (one parameter), the description is incomplete. It omits details about the webhook event payload, how to unsubscribe, rate limits, or any behavioral aspects beyond the trigger. This lack of completeness could lead to misusage.
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?
With 0% schema description coverage, the description must explain the url parameter. It only shows an example request body without stating that the parameter is the webhook callback URL. The meaning is inferable but not explicitly described, providing minimal additional value over 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 that the webhook fires when any planet from Mercury to Pluto stations direct (ends retrograde). This straightforwarrow explanation, combined with the tool name and title, leaves no ambiguity about the tool's purpose. It also implicitly distinguishes from sibling webhooks_retrograde_start.
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 does not explicitly state when to use this webhook versus alternatives like webhooks_retrograde_start. The usage is implied by the trigger condition, but there is no guidance on context or exclusions. A score of 3 reflects the implicit clarity without 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?
The description lacks critical behavioral details: the meaning of 'N days' is undefined, it does not specify whether the webhook replaces or overlaps with others, and the payload format or authentication needs are omitted. Annotations do not clarify these gaps.
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: one sentence for purpose, a group label, and an example. Every element is necessary and front-loaded, making it efficient for quick scanning.
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 misses essential context: the value of 'N' is not defined, and there is no mention of what the webhook payload contains or if authentication is required. Given the simple schema, these omissions hinder full 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?
With 0% schema coverage, the description provides an example request body showing a URL, which adds context beyond the schema. However, it does not explicitly explain that 'url' is the callback endpoint, leaving some reliance on inference.
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 title 'Register Return-Due Webhook' clearly states the action and resource. The description 'Fires N days before a solar/lunar/planetary return is exact' specifies the event type, differentiating it from sibling webhook tools like webhooks_dasha_change or webhooks_eclipse_alert.
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. There is no mention of prerequisites, when not to use it, or comparisons with similar webhook 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?
Annotations indicate this is a write operation (readOnlyHint: false) but not destructive. The description adds value by mentioning the returned signing_secret for HMAC verification. However, it lacks details on idempotency or side effects (e.g., whether duplicate subscriptions are prevented).
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, uses two sentences plus a group/cost line and an example. It avoids unnecessary repetition. Could be slightly more structured (e.g., separate param list), but overall efficient.
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 only mentions the signing_secret return value, missing other potential response fields (e.g., subscription ID, status). The cost and group info add context, but the tool's output remains 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?
With 0% schema description coverage, the description partially compensates by listing events and showing an example with both 'event' and 'url'. However, it does not fully describe each parameter (e.g., url constraints like maxLength 2048).
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's purpose: 'Subscribe to outbound webhook deliveries.' It lists events and includes a cost/group note. While it distinguishes itself from sibling webhook tools focused on specific events (e.g., webhooks_dasha_change) by being the subscription creator, it does not explicitly mention this differentiation.
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. There are many webhook-related sibling tools; the description doesn't explain when to use this generic subscription over those specific event tools or vice versa.
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?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already declare safety. The description adds 'Body, illness, weak points' but no behavioral details beyond that. Since annotations cover the key traits, the description adds minimal extra value.
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?
Three lines with a clear purpose, group label, and example. Every sentence is necessary and front-loaded. No waste.
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 hint at what the tool returns (e.g., text analysis, structured data). For a tool focused on health in an esoteric system, missing output expectations 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% with parameter descriptions. The description adds an example request body showing date format, which is helpful but doesn't add meaning 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Body, illness, weak points' clearly indicates the tool covers health topics within Zi Wei Dou Shu. It distinguishes from sibling palace tools (e.g., career, wealth) by its health focus. However, it could explicitly state it returns an analysis of the health palace.
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. With many sibling palace tools and generic ziwei tools, the absence of usage context or exclusion criteria makes it hard for an agent to select it appropriately.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe reads. The description adds no behavioral context (e.g., authentication needs, rate limits, or result format). It neither contradicts annotations nor adds meaningful value beyond them.
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 very short and includes a group tag and example. It is front-loaded with key terms. However, it lacks structured sections or formatting that could aid readability for an AI agent.
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 part of a complex system (Zi Wei Dou Shu) and has four parameters, but the description does not explain return values, required inputs beyond date, or how to interpret results. No output schema exists, so the description should compensate but does not.
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 coverage is 100% but parameter descriptions are minimal (e.g., 'Date YYYY-MM-DD'). The description does not explain how latitude, longitude, or timezoneOffset influence output, nor what the date represents (e.g., birth date). The example shows only date, leaving ambiguity.
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 'Real estate, family home, ancestry' clearly specifies the domain of this palace tool. The title 'Property Palace (Tianzhai)' aligns with the description, and it is distinct from sibling palace tools (e.g., health, career, wealth) by focusing on property and ancestry.
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 other palace tools or alternatives. The context of sibling names implies its purpose, but the description does not state conditions or exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, destructiveHint, idempotentHint) already declare non-modifying behavior. The description adds that it calculates a timeline with enter/exact/leave dates and mentions cost (100 credits). This supplements the annotations without contradiction.
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: one sentence for purpose, plus group, cost, and example. No wasted words, and the key information is 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 7 parameters, no output schema, and 0% schema coverage, the description lacks detail on parameter formats and return structure. It mentions enter/exact/leave dates but not output fields. Users would struggle to use the tool correctly.
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?
Schema coverage is 0% and description does not explain individual parameters. The example uses singular planet1Id, planet2Id, aspectAngle, orb, but the schema expects arrays (planet1Ids, planet2Ids, aspectAngles) and maxOrb. This mismatch is not clarified, causing 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 calculates a timeline of exact aspects between two planets within a date range, including enter/exact/leave dates. The verb 'calculate' and resource 'timeline' are specific, and it distinguishes from similar tools like 'aspects' or 'aspect_bar'.
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. It does not mention prerequisites, when to prefer other tools, or exclusions. The example request body is provided but without usage context.
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?
Annotations already indicate readOnlyHint, destructiveHint, and idempotentHint. The description adds context about the computation method (solar-year digit sum and gender) and the mapping to groups, which goes beyond annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the purpose. However, the inclusion of a nonexistent 'gender' parameter and lack of explanation for other schema parameters (latitude, longitude, timezoneOffset) detracts from conciseness and efficiency.
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 4 parameters (date required, plus optional location fields) and no output schema, the description should explain the role of all parameters and the return value. It only addresses date and an erroneous gender, ignoring latitude, longitude, and timezoneOffset. The output (Kua number and group) is mentioned but not detailed sufficiently.
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 description mentions a 'gender' parameter, but the input schema does not include a gender property. This is a critical error that misleads the agent. Although schema coverage is 100%, the description introduces an undocumented parameter, severely harming parameter clarity.
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 computes a personal Kua number from solar-year digit sum and gender, and maps it to East/West group for direction work. This is specific and distinguishes it from related tools like chinese_feng_shui_bagua and chinese_feng_shui_lucky_directions.
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 a group label ('Chinese — Zodiac & Feng Shui') and an example request body, implying its use for Feng Shui direction work. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage is implied but not clearly delineated.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not need to repeat that. It adds cost info, but no behavioral traits beyond what annotations provide, so it's adequate but not enhanced.
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: one sentence defining the tool, followed by group and cost in a structured manner, then an example. No unnecessary words, front-loaded with key action.
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 an example and states the tool is for two charts, but fails to describe the output format or behavior on errors. Given no output schema, this is a notable gap, but not severe.
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 schema already documents parameters. The description adds an example but no additional parameter-level details, meeting the 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 calculates a coalescent chart, a harmonic chart between two charts. It uses a specific verb and resource, but does not explicitly differentiate from sibling comparison tools like 'composite' or 'davison', making it less than perfect.
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 alternative comparison tools. With many sibling tools, explicit usage conditions are necessary but absent.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the group label 'Hellenistic — Brennan tradition' for context but does not elaborate on the output format, computational impact, or any quirks of combining the three techniques. With annotations covering core safety, a score of 3 is appropriate.
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 one sentence, a group label, and an example. However, the example omits the required 'targetAge' parameter, reducing clarity. The structure is front-loaded with the purpose, but the inconsistency with the schema harms its effectiveness. Earns a 4 for brevity but loses a point for the misleading example.
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 complex input schema (multiple required fields including targetAge) and the lack of an output schema, the description does not explain what the 'combined stack' output looks like, how the three techniques interact, or what the targetAge represents. This leaves significant gaps for an agent attempting to invoke the tool correctly.
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 detailed descriptions for all parameters (date, time, targetAge, etc.). The description does not add any additional parameter semantics beyond what the schema already provides; the example is incomplete and adds confusion rather than clarity. Therefore, no extra value is contributed.
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 'Combined stack of profection + ZR + decennials for a date,' specifying the verb 'stack' and the three resources. This distinguishes it from sibling tools that focus on individual techniques (e.g., hellenistic_brennan_profections_detail, hellenistic_brennan_zodiacal_releasing_fortune, hellenistic_hand_decennials). The purpose is 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?
The description offers no explicit guidance on when to use this tool versus alternatives. The example request body is incomplete (missing the required 'targetAge') and may mislead an AI agent about required parameters. No context for when not to use or prerequisites are provided, leaving the agent to infer usage from the 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?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds 'Deterministic per-date', which confirms idempotency and specifies that the output depends only on the date. No behavioral contradictions, but no additional disclosure of what the output contains 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 extremely concise—two sentences plus a group label. Every word is necessary: 'Deterministic per-date hexagram' is packed with meaning. No fluff or irrelevant details.
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 (one parameter, no output schema), the description should at least hint at the return value (e.g., hexagram number, trigrams, interpretation). It doesn't, leaving the agent to guess the output format. Annotations provide safety profile but not completeness about what the tool returns.
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 0% description coverage for the 'date' parameter (just a type string). The description provides an example body '{"date":"..."}' but does not specify format (e.g., YYYY-MM-DD) or constraints. With low schema coverage, the description should compensate more but only gives a minimal example.
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 'Deterministic per-date hexagram' clearly states that this tool returns a hexagram based on a date, distinguishing it from sibling tools like 'iching_by_question' (question-based) and 'iching_throw_coins' (coin-throwing). The verb 'hexagram' and qualifier 'per-date' make 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 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 'iching_by_question' or 'iching_throw_coins'. The only context is '[Group: I Ching (Standalone)]', which implies it's a standalone daily tool but doesn't help an agent choose among similar I Ching 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it calculates and supports converse direction, but does not disclose any additional behavioral traits such as rate limits, prerequisites, or return value nature. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus group/cost tags and example) and front-loaded with the core purpose. The example is helpful but could be considered extraneous. No wasted words.
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 (e.g., a list of progressed positions or aspects). It only describes the calculation input, not the output. This is a significant gap for a complex 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 description coverage is 100%, so the schema already documents each parameter. The description provides an example request body that illustrates usage, adding minimal extra meaning. Baseline 3 is appropriate as the schema carries the burden.
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 calculates minor progressions (lunar month-for-a-year) to a target date and supports converse direction. This is specific and distinct from the sibling tool 'progressions', though it does not explicitly differentiate. The verb 'calculate' and resource 'minor progressions' are clear.
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 it supports converse direction and provides an example, but does not explain when to use this tool compared to siblings like 'progressions' or 'tertiary_progressions'. The group tag 'Prognostics' provides some context, but explicit when/why guidance is missing.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already convey safety. Description adds value by detailing the output (nakshatra name, pada, deity, quality) and providing an example request. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (two sentences plus example and metadata) and front-loaded. The example is helpful but could be better integrated. No unnecessary 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 11 parameters and no output schema, the description lacks completeness. It does not specify how optional parameters affect the calculation or the output format beyond listing fields. Usage context is thin for a complex Vedic astrology tool.
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?
With 0% schema parameter coverage, the description heavily relies on the example to hint at required params (date, time, timezoneOffset, latitude, longitude) but fails to explain most of the 11 parameters (e.g., houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). No explicit parameter 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 clearly states the tool calculates Nakshatra for each planet using sidereal zodiac and lists return fields (name, pada, deity, quality). While it distinguishes from similar Vedic tools like 'vedic_panchang_nakshatra_of_day' by focusing on planets, it could be more explicit about being for planetary positions.
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 (e.g., other nakshatra-related tools). The description implies it's for planetary Nakshatra calculation but lacks when-not-to-use scenarios or prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds no further behavioral details (e.g., error handling, calculation method, or response structure). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, an example, and a group tag. It is front-loaded with the main action. Only essential information is included.
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 explain the return format. It does not mention what the Birthday number is or that it derives from the day-of-birth digit. The presence of location parameters is unexplained. Completeness is lacking for a simple calculation.
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 all parameters described. The description adds minor context for 'date' but does not explain why location parameters (latitude, longitude, timezoneOffset) are relevant to a birthday number calculation. The description 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?
The description clearly states the verb 'Calculate', the resource 'Birthday number', and the system 'Chaldean'. It provides an example and a group tag, making it distinct from siblings like life_path or expression. The title reinforces the specific system.
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 gives an example but no explicit guidance on when to use this tool versus other numerology tools. It does not state prerequisites or common use cases. The context is implied but not explicit.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description states 'Calculate', which is consistent, but adds no additional behavioral context such as what the output contains or any limitations beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a clear example request body. Every sentence adds value without redundancy.
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 calculation tool with full schema coverage and annotations, the description is adequate but lacks context about the output format or what the Birthday number represents, which an agent might need for downstream 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%, so the schema already describes all parameters (date required; latitude, longitude, timezoneOffset optional). The description does not explain the optional parameters' relevance to the birthday number calculation, leaving the agent to infer from the schema alone.
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 calculates the Birthday number from the day-of-birth digit using the Kabbalistic (Mathers strict) system. However, it does not differentiate from the similar sibling tool 'numerology_kabbalistic_birthday', which likely computes the same number but without the 'strict' variant.
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 like 'numerology_kabbalistic_birthday' or other numerology birthday tools. Missing 'use this when' or 'prefer X for' statements.
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?
Annotations already indicate read-only, idempotent, non-destructive. Description adds activation age (~35) as behavioral context. No contradictions. Short but adequate for a calculation 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?
Very concise: two sentences plus group label and example. Purpose stated upfront. Could be improved by removing the extraneous 'name' from example or adding structure.
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?
Adequate for a simple calculation with one required parameter. However, no output schema or hint about response format. Misleading example with 'name' that is not a parameter. Could benefit from usage guidance among many sibling numerology tools.
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 covers 4 parameters with descriptions. Example request includes 'name' which is not in schema, potentially misleading. Description adds no additional meaning beyond schema for 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?
Describes calculating Maturity number as sum of Life Path and Expression, activates around age 35, and specifies Kabbalistic (Mathers strict) system. Clearly distinguishes from other systems via name and group label.
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 sibling tools like other maturity calculators (e.g., Chaldean, Pythagorean). Only implicit through system name. No when-not or alternative suggestions.
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?
Annotations already indicate readOnly and idempotent. Description adds trivial context (calculation method) but no behavioral limits or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively concise but includes a misleading example that wastes space and could confuse. Group tag is useful but not 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?
No description of output format or behavior. Agent cannot know what the tool returns. Example only shows input, not output. Incomplete for a simple calculator.
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 describes all 4 parameters clearly, but the description includes an example with 'name', which is not a parameter, causing confusion. No added value for 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?
Clearly states it calculates the Personality number from consonants of full birth name in the Vedic system. Distinguishes from siblings like numerology_vedic_life_path or numerology_vedic_soul_urge.
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 group tag and name imply scope, but the agent must infer usage from sibling tool names.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds that it covers health vulnerabilities based on birth data, and it includes an example request. It does not explain internal behavior (e.g., how it computes vulnerabilities), but it does not contradict annotations. It adds some context but not rich behavioral detail.
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 very brief: two short sentences plus a group label and an example. It is front-loaded with purpose and disclaimer. The example adds length but is helpful. No superfluous text. Score 4 for being efficient while including essential cues.
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 explain what the output looks like (no output schema). Given the complexity of the tool (7 parameters, many sibling tools), a brief statement of purpose and an example are insufficient. The tool appears to return text about health vulnerabilities, but the user agent has no clue about the format or content of the response.
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 all parameters are documented in the schema. The description does not elaborate on parameter meaning beyond the schema; it only provides an example request body. Baseline 3 is appropriate as the description adds no 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 states 'Sign-specific health vulnerabilities' and groups it under '[Group: Pet Astrology]', clearly indicating it returns health risks based on zodiac sign. The verb is implied (retrieve). It does not explicitly distinguish from the many sibling pet tools, but the unique focus on health 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'NOT veterinary advice' as a usage disclaimer but provides no explicit guidance on when to use this tool versus the many other pet astrology tools (e.g., pet_birth_chart, pet_diet_by_sign). Usage is implied by the title and group, but 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?
Annotations are light (not read-only, not destructive). Description adds credit cost and output format, but does not discuss side effects (e.g., data storage, rate limits). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs plus example. Front-loads key astrological content and cost. Every sentence adds value; no 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?
Covers core purpose, content, and cost. Lacks output format detail (no output schema) and explicit guidance for selecting among sibling tools. Example helps but is not comprehensive.
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 description coverage is only 33% (only chart has description). The tool description adds an example but does not explain the language enum or the whitelabel object, leaving many parameters underspecified.
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 Vedic Kundli (PDF or HTML) with specific content (Lagna, Moon nakshatra/pada, planet positions, Vimshottari Dasha). It distinguishes from Western chart tools but does not explicitly differentiate among the many sibling report 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?
Includes cost warning and instruction to confirm with user, plus an example request. However, no guidance on when to use this tool versus alternative reports or vedic tools, and no prerequisites 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the term 'Deterministic', which aligns with idempotency but doesn't go beyond. It does not describe what happens if no seed is provided (random?), the effect of 'allowReversed', or the return format. With annotations covering safety, this is adequate but lacks detail.
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: a single sentence plus a group label and example. It is front-loaded with the core purpose ('Deterministic 1-rune draw') and contains no superfluous information. Every element earns its place.
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 3 parameters at 0% schema coverage and no output schema, the description is too minimal. It does not explain the output format (e.g., rune name, reversed status, interpretation), how 'date' influences the draw, or the effect of 'allowReversed'. Given the tool's simplicity, more context could be added without verbosity.
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 coverage is 0%, yet the description only mentions the 'seed' parameter via an example. The 'date' and 'allowReversed' parameters are completely undocumented. The description does not compensate for the lack of schema descriptions, leaving the agent to infer their purpose from names 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?
Title 'Single Rune Draw' and description 'Deterministic 1-rune draw' clearly state the tool's purpose. Among sibling tools like 'runes', 'runes_three', 'runes_nine', etc., this one is distinct as a single rune draw. The group label 'Elder Futhark Runes' further specifies the rune set.
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 alternative rune tools (e.g., 'runes_three', 'runes_nine'). It does not specify if the seed is required, how the date parameter affects the draw, or when deterministic behavior is important. No explicit when-to-use or when-not-to-use information is 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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds cost and group context but does not detail behavioral traits like orbs, aspect types, or output format. It is consistent and adds minimal value.
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 a single sentence followed by metadata and an example. No fluff, every element earns its place.
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 (two nested objects, no output schema), the description is minimal. It does not explain what the output contains or mention important details like orbs or aspect types, leaving the agent uncertain about the result.
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%, so baseline is 3. The description adds an example request body that clarifies real usage, which provides additional 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 it calculates cross-chart aspects for relationship analysis with a specific verb and resource. However, it does not differentiate from sibling tools like synastry_aspect_grid or composite, which also handle relationship 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?
No guidance on when to use this tool vs alternatives. The description only includes group and cost metadata, not explicit context 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?
Annotations indicate idempotent and read-only behavior. Description adds the grid interpretation (rows/columns meanings) but does not disclose details like seed-based randomization or handling of reversed cards. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise lines: grid meaning, group label, and example. No unnecessary text; the most critical info is 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?
Without an output schema, the description does not explain return values or card significance. It omits details like card orientation interpretation or result structure, which are needed for an AI to fully understand the tool's usage.
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 for 'body' is generic (raw JSON), but the description provides a concrete example with required fields (seed, question, allowReversed), adding meaning beyond the schema's minimal definition. This compensates for the schema's lack of inner structure documentation.
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?
Description clearly states the tool produces a three-by-three grid with rows representing past/present/future and columns representing mind/heart/body, forming a 9-card square. It distinguishes from other Lenormand draws like line_of_five or three_card by specifying the unique layout, though it doesn't explicitly state the tool's name in verb form.
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 alternative Lenormand draws or other tarot tools. The example request body implies typical usage, but lacks context on selection criteria 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds the method (Greer) and deck (Marseille) but no additional behavioral details beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus an example. Front-loaded with key info. No redundant text, but could be slightly 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?
No output schema and description does not describe the return value (what a birth card consists of). Parameter details are only in schema. Missing explanation of output 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% (all parameters have descriptions). Description provides an example but adds no extra meaning beyond the schema's parameter 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?
Description clearly states it computes a birth card using the Greer method for the Marseille tarot deck. This distinguishes it from the similar Rider-Waite birth card tool and other tarot 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 guidance on when to use this tool versus alternatives like tarot_marseille_year_card or tarot_rider_waite_birth_card. 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no new behavioral traits beyond stating it is a single card, and it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only two lines plus an example. It includes a group label and example, but lacks structured sections (e.g., purpose, usage).
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 informative annotations, the description is minimally adequate. However, it omits any explanation of what a 'timing card' returns or how the result should be interpreted, which would be helpful.
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 only describes 'body' as raw JSON referencing the description. The description provides a concrete example with fields (seed, question, allowReversed), adding necessary meaning beyond the abstract 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 'Single timing card' plus the tool name clearly indicates a tarot draw focused on timing, distinguishing it from multi-card draws or general interpretations. However, it does not explicitly contrast with siblings like tarot_marseille_draw_single.
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 other tarot tools (e.g., when a timing question vs. general draw is appropriate). The example shows a question but no contextual cues.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already define safety traits. The description adds no behavioral context beyond stating it's a tarot spread, which is implicit. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a clear example. Every element is necessary and front-loaded. No redundancy.
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 mention what the tool returns (e.g., card positions, interpretations). Given the many sibling tools, this omission hinders correct selection and use.
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 one 'body' parameter. The example request body (`{"seed":12345,"question":"...","allowReversed":true}`) adds meaning by showing required fields, compensating for the loose schema. Could define more constraints.
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 '5-card career trajectory spread,' which is a specific verb-resource pair. It distinguishes from sibling tarot tools like love or spiritual path draws, though could elaborate on the spread's structure.
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 versus not use this tool or alternatives. With many sibling tarot draw tools (e.g., tarot_rider_waite_draw_relationship), the lack of usage cues is a gap.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety and idempotency. The description adds only the number of cards and an example request body, without explaining the layout meaning or any behavioral nuances beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two short sentences plus example), with the core purpose front-loaded. It could be slightly better structured, but it is efficient and clear.
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 has many siblings and a nested parameter with no output schema, the description is too minimal. It does not explain the horseshoe spread's significance, typical use cases, or expected output format, which leaves the agent underinformed.
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 'body' has a schema description pointing to the tool description for required fields. The description provides a concrete example with 'seed', 'question', and 'allowReversed', which adds meaningful context beyond the generic schema definition.
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 '7-card horseshoe progression' under the Tarot Rider-Waite-Smith group, which distinguishes it from other tarot spreads like Celtic Cross or three-card draws. The name and title align well with the 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 versus the many other tarot siblings (e.g., tarot_rider_waite_draw_celtic_cross). The description does not mention alternatives or specific contexts for the horseshoe spread.
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?
Annotations already indicate readOnly, not destructive, idempotent. The description adds little beyond noting the default targetDate, which is a parameter default. No additional behavioral traits or side effects are disclosed.
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 short and includes an example, but the inaccuracy regarding targetDate undermines its conciseness. It could be restructured to correctly map to schema parameters.
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 number of parameters and lack of output schema, the description is incomplete. It does not explain what a 'running Mahadasha' means, the return format, or how to interpret results. The example includes a nonexistent parameter, adding to incompleteness.
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 description references a 'targetDate' parameter that does not exist in the input schema, causing confusion. It does not explain any of the 11 actual parameters, and schema coverage is 0%, so the description fails to provide necessary parameter context.
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 the running Mahadasha for Chara, Sthira, and Shoola at a target date. It explicitly calls itself a 'convenience aggregate' and distinguishes from dedicated endpoints. 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by noting it aggregates three endpoints into one call, implying it should be used when all three dashas are needed. However, it does not explicitly state when to avoid it or mention alternatives like the dedicated endpoints for single dashas.
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?
Annotations indicate readOnlyHint=true, idempotentHint=true. Description adds that it counts benefics with fixed +2 each, consistent with idempotent read operation. However, it does not disclose additional behavioral traits beyond what annotations already cover, so only moderate value.
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 with only two sentences: one functional description and one example. All words are necessary and the example is immediately helpful. No 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 11 parameters and no output schema, the description lacks completeness. It does not describe the return format, error handling, or default values for parameters like houseSystem and ayanamsaId. The tool assumes knowledge of Lal Kitab without further explanation.
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 coverage is 0%, meaning no parameter descriptions in the schema. The description provides an example request body with typical birth data parameters but does not explain the meaning or constraints of each parameter. The example helps but is insufficient to convey complete 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 calculates a sum of benefic planets (Moon, Mercury, Venus, Jupiter) in specific houses (2,5,9,11) for Lal Kitab prosperity yoga. It uses specific terminology (LK dhana yoga sum) and distinguishes from siblings by specifying LK fixed houses.
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 implies it's for Lal Kitab prosperity yoga calculation but does not mention when not to use it or provide comparisons with sibling tools like vedic_lal_kitab_dasha or vedic_lal_kitab_debts.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already indicate read-only, idempotent behavior. The description adds that planets are considered 'dormant' and remedies can activate them, providing useful conceptual context. No contradictions with annotations, and no additional behavioral details (e.g., auth, rate limits) are needed given annotations.
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: two sentences plus an example and group tag. The first sentence defines the core concept, and the second adds significance. The example is helpful but could be more informative. Overall, it is front-loaded and efficient.
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 concept-specific tool, the description adequately explains the concept but lacks details on required parameters or output format. Given the tool's niche focus and standard birth chart parameters, the description is minimally sufficient but could be more complete for agents unfamiliar with Lal Kitab.
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?
With 0% schema description coverage, the description does not explain any of the 11 input parameters. It provides an example request body with typical parameters (date, time, etc.) but does not clarify their meaning or usage beyond what the schema already shows. The agent must infer standard astrological 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 defines the tool's purpose: identifying 'sleeping houses' where a planet is in its own sign (pakka ghar) without companions/aspects, and explains the Lal Kitab significance (dormant planets) and remedy context. This is specific and distinguishes it from other Lal Kitab tools like vedic_lal_kitab_blind_house.
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 mentions 'Lal Kitab' grouping but does not advise when to choose this over other Lal Kitab tools (e.g., vedic_lal_kitab_planet_house_effect). Usage context is only implied.
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?
The description aligns with annotations (readOnlyHint=true, destructiveHint=false) and adds behavioral context such as using Namkaran-derived rules, widened tithi set, and preferred nakshatras. The cost and group details are also helpful. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise at three sentences plus an example, but it lacks structured formatting. The example is useful but could be integrated more cleanly. There is some redundancy in mentioning preferred nakshatras twice.
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 7 parameters, no output schema, and a complex domain, the description is incomplete. It does not explain the return format, how auspicious windows are determined, or the significance of preferred nakshatras. The example helps but falls short of providing full 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?
With 0% schema coverage, the description provides an example request body but does not explain individual parameters like ayanamsaId or topN. While the example gives some context, it is insufficient for the agent to understand all parameter semantics, especially for optional fields.
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 as an 'auspicious-window scanner for legal or sacramental name change', specifying the verb (scanner) and resource (auspicious windows). It also mentions using Namkaran-derived rules with a widened tithi set, effectively distinguishing it from sibling muhurat tools like marriage or business start.
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 explicit guidance on when to use this tool versus alternatives. It mentions preferred nakshatras but lacks context on when this tool is appropriate. There is no differentiation from the sibling 'vedic_muhurat_naming_ceremony', which likely serves a similar 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral details beyond stating it's a Hora chart and providing an example request. It does not describe response format, error behavior, 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 description is concise (one line for chart type, one line for example, plus metadata). It is front-loaded with purpose. However, the inclusion of [Group: Vedic] and [Cost: 20 credits] adds minor noise and could be omitted or placed elsewhere.
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 tool returns (e.g., chart data, HTML, JSON). For a 7-parameter tool with no output schema, this is a significant gap. The example request is helpful but incomplete without response description.
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% description coverage, so baseline is 3. The description does not add any new meaning to parameters beyond what schema already provides; the example request illustrates usage but doesn't clarify 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 title 'Varga D2 — Hora' and description 'Hora chart (wealth analysis, half-sign Sun/Moon division)' clearly state the tool computes the D2 divisional chart for wealth analysis. This distinguishes it from other vedic_varga_* siblings by specifying chart type and purpose.
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 'wealth analysis' implying use for wealth-related queries, but gives no explicit guidance on when to use D2 versus other divisional charts (e.g., D1, D9). No exclusion criteria or alternative suggestions 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral traits beyond these; it simply states the chart type. It does not contradict annotations, but also does not provide additional context like what the chart contains or if any side effects exist.
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, front-loading the purpose in the first sentence. Bracketed meta-info (group, cost) and an example are provided efficiently. While very brief, every element serves a purpose, though a bit more context could be included without becoming 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?
Given the large number of sibling tools (especially other vedic_varga tools), the description lacks differentiation. It does not explain how D4 differs from other divisional charts like D1 or D10, nor what specific use cases call for this chart. The domain hints (fortune, assets) are helpful but insufficient for an agent to reliably select this tool over alternatives.
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 all parameters (e.g., date, time, timezoneOffset). The description does not add any extra meaning beyond the schema; it only repeats the example. With full schema coverage, a score of 3 is appropriate as the description adds no additional 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?
The description clearly states the tool computes a Chaturthamsa chart (Varga D4) and lists its domains: fortune, fixed assets, and real estate. The title and name further identify it as a specific Vedic divisional chart, distinguishing it from other varga tools like D1, D2, 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 provides no guidance on when to use this tool versus alternatives. It only states the group and cost, and gives an example request body. There is no comparison with other Vedic varga tools or indication of scenarios where D4 is appropriate.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds the chart's thematic focus but does not disclose additional behavioral traits like output format or limitations. With annotations present, the description provides adequate but not rich 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 concise: one sentence explaining the chart's focus, followed by metadata and an example. Information is front-loaded and each part earns its place. Slight room for improvement by structuring the example separately.
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?
Despite having 7 parameters and no output schema, the description does not explain what the chart output contains, how to interpret it, or the significance of D40. For a complex Vedic divisional chart, this is insufficient to fully understand the tool's context and 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 coverage is 100%, so each parameter is already documented in the input schema. The description includes an example request body showing typical values but adds no new semantics 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 clearly states the tool generates a Khavedamsa chart (Vedic D40) focusing on auspicious/inauspicious effects and maternal lineage. This distinguishes it from sibling varga tools like D1, D9, etc., which serve different purposes.
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 (e.g., other varga charts or lineage tools). No when-to-use or when-not-to-use context is given, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds the behavioral context of 'children, progeny' but does not explain other traits like input constraints or output format. With annotations present, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line plus cost/group metadata and an example). It is concise but lacks structure (e.g., sections for behavior, examples, return format). However, for a simple tool, it is efficient 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 the complexity of a varga chart and the absence of an output schema, the description is too sparse. It does not explain what the chart contains (e.g., planetary positions, houses aspects), how to interpret the output, or any caveats. For a general-purpose agent, this is insufficient.
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% (all 7 parameters have descriptions). The description does not add any parameter-level detail beyond what the schema already 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?
The description clearly states 'Saptamsa chart (children, progeny)' which identifies the tool's purpose and its specific focus. The title 'Varga D7 — Saptamsa' reinforces this. It distinguishes this varga from other varga tools like D1, D9, 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?
No guidance is provided on when to use this D7 chart versus other varga charts (e.g., D1, D9, D10, etc.). With over 40 sibling varga tools, the agent needs explicit cues to select the correct one for children/progeny analysis.
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?
Annotations already declare readOnlyHint, idempotent, non-destructive. Description adds that it returns a 'poverty/struggle flag' and suggests remedies, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and includes example request and group tag. However, the description could be more informative without being verbose; it lacks parameter details.
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 11 parameters, no output schema, and no parameter descriptions, the description is incomplete. It does not explain the response format beyond a vague flag and remedies, nor how parameters affect the calculation.
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?
Schema has 11 parameters with 0% description coverage. The description does not explain any parameter meaning, only shows an example request. Fails to compensate for low 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?
Clearly states the tool checks Jaimini Daridra yoga (AK+AmK in dusthanas) as a poverty/struggle flag with remedies. Distinguishes itself from many sibling Jaimini yoga tools by naming a specific yoga type.
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 usage for checking this specific yoga condition, but no explicit when-to-use or when-not vs siblings like dhana, raja, etc. Missing guidance on prerequisites or context.
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 adds the behavioral insight that the webhook fires 24 times per day, which is beyond the annotations. However, it does not disclose whether registration is reversible, if there are rate limits, or how authentication works. Annotations already indicate non-read-only and non-destructive, but the description misses opportunities to explain side effects or persistence.
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 very concise: a one-line event description, a group label, and an example. It front-loads the key behavior. However, the brevity sacrifices completeness, so it earns a 4 rather than a 5.
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 single parameter and no output schema, the description should explain the webhook's purpose more fully, such as what data is sent to the URL, whether the URL must be publicly accessible, or how to manage multiple registrations. The current description is insufficient for an agent to use this tool correctly among many similar webhook 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?
With 0% schema description coverage, the description provides an example request body ('{"url":"https://example.com/hook"}') that illustrates the required URL format. While helpful, it does not explain what type of URL is acceptable (e.g., callback endpoint), whether it must be HTTPS, or any additional constraints beyond the schema's format and maxLength.
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 webhook fires at every planetary hour boundary (24/day), which matches the title 'Register Planetary-Hour-Tick Webhook'. The specificity of the event distinguishes it from other webhook tools like webhooks_dasha_change or webhooks_sign_ingress, even without an explicit contrast.
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 does not mention prerequisites, context, or scenarios where other webhooks might be more appropriate. Given the large sibling list of webhook tools, this lack of direction hinders agent 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?
Annotations indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description states 'Fires when…' but does not disclose additional behavioral traits like persistence, idempotency, rate limits, or authentication requirements beyond what annotations already provide.
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 the trigger condition. The group label and example are useful and concise, though the group label consumes space without adding functional detail.
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 input (one required parameter) and no output schema, the description covers the basic trigger condition. However, it omits details about registration persistence, success/error responses, or limits, which could be helpful for an agent.
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?
With 0% schema description coverage, the description must compensate, but it only provides an example request body. It does not explain the purpose of the 'url' parameter beyond showing a URI format, leaving the agent to infer that it's the webhook endpoint.
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 fires when any planet from Mercury to Pluto stations retrograde, and the title indicates it registers a retrograde-start webhook. This distinguishes it from siblings like webhooks_retrograde_end.
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 includes a '[Group: Webhooks]' label which groups it with other webhook tools, but does not explicitly state when to use this one over alternatives. It specifies the trigger condition but lacks guidance on 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that the output includes nearby and full lists of milestones, which provides some behavioral context beyond annotations, but it does not disclose details like 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, a group label, and an example. It is front-loaded with the purpose. However, the example could be integrated more formally, and the description does not use structured formatting like bullet points.
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 that the tool has one parameter with a minimal schema and no output schema, the description provides the purpose and an example but lacks details on return format, date format expectations, and error handling. The output hint ('nearby + full list') is vague. This is adequate for a simple tool but not fully 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 is minimal with only a 'body' property described as 'Raw JSON body — see the example in the tool description for required fields'. The description compensates by providing an explicit example with birthDate and targetDate, which guides the agent on the required structure. Since schema coverage is 100% but schema itself is vague, the description adds crucial semantics.
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 specifies that the tool returns age-based wellness milestones, listing examples like Saturn return, Uranus opposition, and hormonal shifts. It distinguishes from other wellness tools (e.g., wellness_crystals, wellness_diet) by focusing on milestones. However, it does not explicitly state that the tool calculates milestones based on birthDate and targetDate, though the example helps.
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 wellness tools or siblings. The '[Group: Wellness]' label is present but no comparison or exclusion criteria are given. The agent must infer usage from the tool name and example.
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?
Annotations already indicate read-only, non-destructive, and idempotent behavior. The description does not add behavioral traits beyond what annotations provide, such as authentication needs or rate limits, but it does not contradict them either.
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 very short, with a clear one-line purpose statement and a concise example. It is front-loaded and free of any fluff, though it could be slightly more informative without becoming 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?
The tool has no output schema and multiple parameters, yet the description does not explain what the output looks like (e.g., a list of foods, a set of guidelines). An AI agent lacks context on how to 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?
With 100% schema description coverage, the schema already documents all parameter details. The description's example request body provides a concrete usage illustration but does not add meaningful semantics 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 an element-based dietary focus with specific actions: emphasize/avoid foods and cooking style. This verb+resource combination makes its purpose distinct from sibling tools like wellness_herbs (herbs) or wellness_exercise (exercise).
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 prerequisites, contexts where dietary suggestions are appropriate, or comparisons to other wellness tools.
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?
The description contradicts the annotations: annotations declare readOnlyHint=true and destructiveHint=false, but the description states the tool uploads, replaces, and deletes a logo—clearly a write and destructive operation. This is a serious inconsistency, making the behavioral transparency effectively misleading.
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 concise and well-structured: it opens with the core action, immediately provides format and size constraints, then notes side effects. The group, cost, and example are neatly appended. Every sentence serves a purpose with no redundancy.
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 explanation covers the main behavior and constraints, but it omits important details such as the return value (whether it returns success/URL/error) and error handling for invalid input or size exceedance. Given the tool's simplicity, it is reasonably complete but lacks clarity on what the agent can expect back.
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 0% description coverage, but the description compensates by explaining the parameter's format (base64 data URL), allowed image types (png, jpeg, svg+xml, webp), file size limit (512 KB), and includes an example. This adds significant meaning beyond the schema's pattern constraint.
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 upload a logo as a base64 data URL. It specifies the action ('Upload'), the resource ('logo'), and provides details on format, size limit, and side effects (replaces prior logo, deletes old file). This distinguishes it from sibling tools like whitelabel_preview or whitelabel_domain_verify.
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 lacks information about prerequisites, use cases, or when not to use it. There is no mention of related tools or when to choose this over other white-label 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds no behavioral traits beyond this, such as data volume or pagination. With strong annotation coverage, a score of 3 is appropriate.
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: one sentence, a group tag, and an example. No redundant information. Every element earns its place, fitting well within a larger API.
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?
For an overview tool with no output schema and many alternatives, the description lacks detail on what the output contains. It mentions 'overview' but does not specify fields or format. The example shows input only. More context on the return structure is needed.
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 parameters are fully documented. The description adds value with a concrete example request body, illustrating a valid invocation. Example usage aids understanding but no additional semantic depth for lat/long/timezoneOffset 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 identifies the tool as providing an overview of Year pillar, animal, and 12 palaces for Zi Wei Dou Shu. While it lacks a verb like 'computes' or 'generates,' the noun phrase 'overview' is sufficient to convey the output. It is distinguishable from siblings like ziwei_twelve_palaces, which focus on individual palaces.
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 dozens of Zi Wei siblings, explicit context for selection is missing. The example usage hints at input but does not address tool choice.
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?
Annotations already declare the tool as read-only, non-destructive, and idempotent. The description adds minimal behavioral context ('theme/archetype') but fails to describe the output format, pagination, or other traits. With no output schema, the description should carry more burden.
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 (one sentence plus group tag and example). The example request body is helpful. However, the grouping information could be better integrated, and the structure is minimal.
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 Zi Wei Dou Shu and the absence of an output schema, the description should detail the return structure (e.g., list of stars with names and themes). It only mentions 'theme/archetype' but is incomplete for agent 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%; all four parameters are documented in the schema. The description reinforces the required 'date' via example but adds no extra semantics beyond what the schema provides for latitude, longitude, or timezoneOffset.
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 '14 canonical Zi Wei main stars with theme/archetype', specifying the exact resource and scope. The title '14 Main Stars' further reinforces this, distinguishing it from sibling tools like ziwei_full_chart or ziwei_palace_*.
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 includes a group tag 'Zi Wei Dou Shu (Purple Star) — MVP' but provides no explicit guidance on when to use this tool versus alternatives. The example request body implies a use case, but lacks exclusions or comparisons to sibling 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds no new behavioral context beyond 'detailed explanation', and does not disclose any hidden behaviors or requirements like chart computation prerequisites.
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 very short (two sentences plus example) and front-loads the core purpose. It avoids wordiness, though the example could be more precise and the group label is not 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?
There is no output schema, and the description does not explain what the tool returns (e.g., text, format). It also omits guidance on the chart parameter structure beyond the minimal example, leaving the agent to infer from the input schema alone.
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?
With only 20% schema description coverage, the description should compensate but only provides an example request that uses 'aspect' instead of the actual parameter 'aspectType', which is slightly misleading. It does not clarify the nested 'chart' object or the purpose of other 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 uses a specific verb ('explain') and resource ('aspect between two planets'), clearly distinguishing it from similar tools like ai_explain_transit which focuses on transits. The example further reinforces the purpose.
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 when to use (for aspect explanations) but does not explicitly state when not to use or what alternatives exist. The sibling list is extensive, and the title/description alone makes the context clear, but no explicit 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. The description adds no behavioral details beyond this, but also does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two lines and an example. It front-loads the purpose and includes a group tag, but could be better structured with subheadings or more detail.
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 that it provides high-level guidance and should be paired with transits. Given the 7 parameters (all documented) and no output schema, it is adequate but lacks details on what the output contains or how the guidance is derived.
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 all parameters are described in the schema. The description provides an example request body, which is helpful but does not add new semantic meaning beyond the schema 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 states 'High-level expansion guidance' and the tool name includes 'timing', making it clear that this provides broad strategic advice rather than precise dates. It distinguishes from the sibling 'business_electional_day', which likely offers specific timing.
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 advises to 'pair with /transits for actual windows', giving limited guidance on when to use this tool and when to supplement with transits. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already disclose safety. The description adds that it operates on a 'solar year' and provides an example request, but does not elaborate on output format or potential side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence defining output, a group tag, and an example. No filler, front-loaded with essential 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?
For a computation tool with 7 parameters and no output schema, the description is minimal. It does not specify the output structure or behavior (e.g., list, string), leaving the agent uncertain about return value 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 all parameters documented. The description merely shows example values without adding semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 computes 'Fixed-branch element + cycling-stem element + yin/yang for given solar year.' This distinguishes it from siblings like chinese_zodiac_animal which return animal signs. The group tag reinforces its domain.
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. It does not compare to chinese_zodiac_animal or other zodiac tools, nor does it specify prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true, idempotentHint: true, destructiveHint: false) already convey safety. The description adds that it calculates periods based on sect and planet order, and provides an example request body. However, it does not describe the return format, pagination, or any behavioral traits that annotations don't already cover.
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: one sentence, example, and metadata (group, cost). It front-loads the essential purpose. However, it could be more structured by adding parameter explanations or a brief on expected output.
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 11 parameters, rich annotations, no output schema, and a complex domain, the description is incomplete. It does not explain what the calculated result contains, how to interpret firdaria periods, or differentiate from the many similar time-lord siblings. The example request does not compensate for missing contextual details.
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 description coverage is 0% – no parameter descriptions exist in the input schema. The description only includes an example request body without explaining the meaning or required format of parameters like 'cosmogram', 'ayanamsaId', etc. The example helps but does not compensate for the lack of semantic documentation for all 11 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 the specific function: 'Calculate Firdaria planetary periods — the traditional Persian time-lord system based on sect and planet order.' This distinguishes it from other time-lord tools among siblings (e.g., profections, dashas) by naming the specific tradition and basis.
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 calculated firdaria periods but provides no explicit guidance on when to use this tool versus alternative time-lord systems like profections or dashas. The group and cost info is present but does not help choose between siblings.
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?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds that it uses the Sepharial method and maps longitude to zodiac degrees, providing moderate context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a group label, cost, and example. It could be more concise by omitting the cost line, but overall it is fairly 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 description lacks explanation of what 'geodetic chart degrees' are, the output format, or how the optional parameters affect results. For a complex astro-geography tool without output schema, this is incomplete.
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?
With 0% schema description coverage for 5 parameters, the description only mentions latitude and longitude in the example, failing to explain method, year, or obliquity. This forces the agent to infer meaning, which is insufficient.
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 converts geographic coordinates to geodetic chart degrees using the Sepharial method, mapping longitude to zodiac degrees. This is a specific verb+resource with clear scope.
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 group 'Astro-Geography' and provides an example, but it does not explicitly differentiate this tool from sibling tools like acg or solar_acg. Usage context is implied but not directly 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety. The description adds context about the astronomical quantity but does not disclose any additional behavioral traits beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, an example, and metadata. It front-loads the purpose. However, it could be more structured with explicit parameter explanations, but overall is 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?
With 11 parameters and no output schema, the description lacks completeness. It does not describe the return format, response structure, or caveats. The complex parameter set is only partially addressed.
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 description coverage is 0%, yet the description only explains date, time, and timezoneOffset via an example. The other 8 parameters (latitude, longitude, houseSystem, etc.) are not explained. The description does not compensate adequately for the missing 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 the tool computes the Design date (88° solar arc before birth), a specific Human Design concept. It uses a specific verb 'Find' and identifies the resource. Among sibling tools with hd_ prefix, this one is 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 implies the tool is for Human Design calculations (Group: Human Design) but does not explicitly differentiate from other hd_ tools. No when-to-use or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context about outputs (sleep type, gates, themes), which is useful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence plus group and cost info. It is front-loaded and efficient, though could be better organized.
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 11 parameters and no output schema, the description lacks sufficient detail. It mentions outputs but does not explain input parameters or expected return format, leaving significant gaps.
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 coverage is 0% and description does not explain parameters. Only an example body is given, leaving meaning of all 11 parameters unclear to the agent.
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 calculates a Dream Rave chart and lists specific outputs: sleep type, active gates in lower centers, and dream themes. It uses a specific verb 'Calculate' and distinguishes the resource from other HD 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 guidance on when to use this tool versus alternatives. With many sibling HD tools, the agent lacks direction on selection criteria 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?
Annotations already declare readOnlyHint=true and destuctiveHint=false, so the agent knows this is a safe read operation. The description adds that it specifically checks the Moon and ASC in a defined degree range, but does not elaborate on other behavioral traits like error conditions or output format. With annotations covering safety, a score of 3 is appropriate.
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 main description is a single sentence that clearly states the tool's action. Group, cost, and an example are appended but do not clutter the core message. It is front-loaded and efficient, though the example could be shortened or moved to optional expansion.
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 essential purpose and provides an example for input formatting. However, it does not specify the return value or output structure (e.g., Boolean, object). Given the tool's simplicity and the lack of an output schema, this omission reduces completeness for an agent deciding to invoke it.
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 for all seven parameters, so the schema already documents their meaning. The description includes an example request body, which provides a concrete usage format but does not add semantic meaning beyond what the schema offers. Baseline 3 is correct.
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 if the Moon or ASC is in the Via Combusta (15° Libra – 15° Scorpio), specifying a verb (check) and a resource (Moon/ASC condition). It distinguishes from siblings like horary_moon_voc or horary_diagnostics by focusing on this specific classical prohibition.
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 such as horary, horary_moon_aspects, or horary_diagnostics. It only mentions it's a 'classical prohibition in horary,' which implies context but lacks explicit usage instructions or 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context beyond annotations, including the use of specific astrological techniques (major transit cycles, solar return, time-lord) and cost information (100 credits, Tier 4). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two clear sentences about purpose and context, plus a group label and cost line. The example request adds length but is useful. The information is front-loaded and easy to parse. Slightly longer due to example, but still appropriately sized.
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 and 0% parameter schema coverage, the description should provide a complete picture. It does mention the techniques used (transit cycles, solar return, time-lord) but fails to describe the output format, length, or how parameters relate to the computation. The example includes fields not in the schema, further reducing completeness.
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?
Schema description coverage is 0%, so the description must compensate. However, the description does not explain any of the four parameters (sign, date, language, disclaimer_inline). The example request body includes fields (natal, year) not present in the schema, creating confusion rather than clarity. This severely hampers effective 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 generates a year-ahead horoscope with a 12-month window, including major transit cycles, solar return chart context, and time-lord (profection). It distinguishes itself from sibling tools like horoscope_daily, horoscope_weekly, and horoscope_monthly by specifying the time range and included techniques.
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 does not provide explicit guidance on when to use this tool versus other horoscope tools (e.g., daily, monthly, compatibility). While the purpose is clear, there is no mention of scenarios where this tool is preferred or not recommended, leaving the agent to infer usage from the name and description 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about calculating lines and cost, but does not disclose behavioral traits beyond that. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a group tag, cost, and example. The example is somewhat lengthy but provides practical context. No unnecessary repetition.
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 lacks explanation of the output format and the meaning of parameters. Without an output schema, the agent is left guessing what the lines look like. Incomplete for a tool with 5 parameters and no output schema.
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 coverage is 0%, and the description fails to explain the meaning of parameters like azimuth, halfAngle, maxDistDeg. The example request body uses different field names (targetLat, targetLng) that do not match the schema, causing 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 calculates local space influence zone lines for a chart relocated to a specific city, and specifies it shows planet directions on a map. This distinguishes it from siblings like 'local_space' and 'acg_zones' which may compute different aspects of local space.
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 relocated charts) and an example request, but does not explicitly state when to use this tool versus alternatives like 'acg_zones' or 'local_space'. No exclusions or when-not-to-use guidance is 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the calculation reduces year+month+day and uses the Mathers strict system, but does not provide additional behavioral context (e.g., response format, error handling). With annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a group label and example, all front-loaded with the core action. Every sentence is necessary; no wasted words. Exceptionally 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?
Despite 4 optional parameters (latitude, longitude, timezoneOffset) and no output schema, the description does not explain why location/timezone are accepted, what the return value looks like, or how the reduction works. The tool's complexity demands more detail for an agent to use it fully.
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 input schema already describes each parameter. The description does not add semantic meaning beyond what is in the schema, though it provides an example usage. 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 verb ('Calculate'), the resource ('Life Path number'), and the method ('from birth date, reduced'). It also specifies the system ('Numerology — Kabbalistic (Mathers strict)'), which distinguishes it from siblings like the non-strict version and other numerological systems.
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., strict vs. non-strict, or other numerological systems). It lacks direction on prerequisites, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, idempotent, and closed-world. The description adds that it performs Vedic reduction on the birth date, which is useful but does not disclose nuanced behaviors like handling of master numbers or intermediate calculation steps. The description adds modest value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating the core function, a group tag, and an example request body. Every piece of information is purposeful and immediately accessible. No wasted words.
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?
The tool is simple and well-covered by annotations and schema. The description explains the essential function and provides an example. It does not detail the output format, but given the simplicity and the presence of an example, it is nearly complete. A brief note on the return value would push it to a 5.
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% parameter description coverage, so the baseline is 3. The description only mentions the 'date' parameter, aligning with the schema, but does not provide additional semantics for the optional location parameters (latitude, longitude, timezoneOffset). It does not detract but also does not enhance the schema's detail.
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 calculates the Life Path number from a birth date using the Vedic system. It is specific about the resource (life path number) and the method (Vedic reduction). However, it does not explicitly differentiate from other Vedic numerology siblings like expression or soul urge, making it slightly less than a 5.
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 alternative numerology tools. It does not mention prerequisites, exclusions, or relative contexts, leaving the agent to infer usage from the 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating a safe read operation. The description adds that it calculates based on a calendar year and mentions a 9-year cycle, but this does not go beyond what annotations imply. No additional behavioral traits (e.g., data usage, side effects) are disclosed.
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 short and front-loaded with the purpose. However, it includes an example with extraneous fields (name and year) not present in the schema, which is a structural flaw. The group label is useful but could be integrated more cleanly. The example adds clutter without 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?
Given the tool's simplicity (no output schema, few parameters), the description provides adequate high-level context. However, the example inconsistency undermines completeness. The tool's return value or interpretation of the Personal Year number is not described, but for a calculation tool, this is acceptable with good schema coverage.
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 schema covers all four parameters with descriptions (100% coverage). However, the tool description includes an example request body with 'name' and 'year' fields that are not in the schema. This inconsistency can mislead the agent about required parameters. The description does not add meaningful parameter semantics beyond the schema; it introduces 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 'Calculate the Personal Year number for a given calendar year — 9-year cycle of personal evolution.' It specifies the verb (calculate), the resource (Personal Year number), and the context (9-year cycle). The tool name and title include 'Vedic', and the description mentions 'Numerology — Vedic system', which effectively distinguishes it from sibling tools like numer_ chaldean_personal_year.
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 does not explicitly state when to use this tool versus alternatives. It implies usage through the 'Vedic system' label, but there is no direct guidance on when to choose Vedic over Chaldean, Kabbalistic, or Pythagorean personal year tools. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it calculates 'within orb' and provides an example with an 'orb' parameter, which clarifies the scope. No contradictions. However, it does not disclose details about how results are formatted 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 description is concise: one line for the core action, then group/cost metadata, then an example. It is front-loaded with the key information. The example adds value but is space-consuming. Overall, it is efficient and easy to skim.
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 11 parameters, no output schema, and 0% schema description coverage, the description should provide comprehensive guidance. It gives a high-level purpose and an example, but does not explain return values, how to interpret results, or the role of many parameters. The lack of output schema and parameter descriptions leaves significant gaps.
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 description coverage is 0%, so the description must compensate. Only an example request body is provided, which covers some parameters (date, time, timezoneOffset, latitude, longitude, orb) but ignores 5 others (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). No individual parameter explanations are given, leaving many parameters underdocumented.
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 calculates parallel (same declination) and contra-parallel (opposite declination) aspects between all planets within orb. This clearly differentiates it from sibling tools like 'aspects' which likely refer to ecliptic aspects. The verb 'Calculate' and resource 'aspects' 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 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 is provided. The description implies use for declination-based aspects via the title and example, but does not mention alternatives like 'aspects' for ecliptic aspects. Usage is inferred from the name rather than directly stated.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds no additional behavioral traits such as rate limits, authentication requirements, or side effects beyond what is already disclosed.
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, consisting of a single declarative sentence plus an example request body. It is front-loaded with the core purpose. The example is helpful but not explained in relation to the parameters or output.
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 input (via example) and purpose but lacks output description (no output schema) and does not cover edge cases or error conditions. For a tool with 7 parameters and no output schema, more detail on what the output contains 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?
Schema description coverage is 100%, so all 7 parameters are already documented in the input schema. The description does not add any extra meaning to the parameters, such as how they influence the derivation of element or grooming recommendations. Baseline of 3 is appropriate given full 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 clearly states the tool provides grooming focus and frequency based on element. It is distinguished from sibling pet astrology tools (e.g., pet_personality, pet_diet_by_sign) by specifying 'grooming'. However, it does not explicitly state that the element is derived from the birth chart data, which is implied by the example request.
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 group tag '[Group: Pet Astrology]' provides context that this tool belongs to a suite of pet-related astrology tools, but there is no explicit guidance on when to use this tool versus other pet tools (e.g., for grooming vs. health vs. personality). No when-not-to-use or alternative recommendations 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds that it returns 'full charts for each return,' which is useful but not exhaustive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a group/cost note and an example. It is front-loaded with the main purpose. The example is long but beneficial for understanding. Slightly verbose due to example inclusion, but overall efficient.
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 (requires birth data, planet, year), the description covers the main purpose and provides an example. It mentions 'full charts' for output but lacks details on response structure or multiple returns. Schema and annotations fill some gaps, but 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?
Schema description coverage is 100%, so the baseline is 3. The description includes an example request body that illustrates parameter usage, but the schema itself already provides detailed parameter descriptions (e.g., required fields, defaults). The example reinforces but does not add new 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 the tool finds all returns of any planet to its natal longitude within a given year. The verb 'Find' and specific resource 'returns of any planet to its natal longitude' precisely define the action, distinguishing it from sibling tools like 'lunar_return' or 'solar_return' which are planet-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 does not provide any guidance on when to use this tool versus alternatives. It does not mention that it covers any planet while siblings like 'lunar_return' are moon-only, nor does it specify when not to use it or any prerequisites. Users must infer usage from the description 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds group and cost info but does not disclose behavioral traits beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus metadata and an example. It is front-loaded with the purpose, and every sentence adds value. No unnecessary information.
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?
The tool has no output schema, but the description lists the computed values (profected Ascendant, lord of year, activated house, monthly sub-rulers), giving a good idea of the response content. It lacks details on the exact return format, but it is sufficient for a calculation 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?
Parameter schema coverage is 100%, and the schema includes descriptions for the body parameter and its nested properties. The tool description itself does not add additional parameter semantics beyond the schema, so 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 the verb 'Calculate' and specifies the resource 'annual profections' with a list of outputs (profected Ascendant, lord of year, activated house, monthly sub-rulers). It is specific, but there is a sibling tool 'hellenistic_brennan_profections_detail' that may overlap, and the description does not explicitly differentiate from it.
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 includes metadata like group and cost but provides no explicit guidance on when to use this tool versus alternatives. No when-to-use, when-not-to-use, or prerequisite conditions are stated.
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?
Annotations already indicate it's not read-only and not destructive. The description adds a disclaimer ('not investment advice') and cost warning but does not disclose behavioral traits like rate limits or response format. With annotations present, the description meets the minimum but adds little extra 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 mixes content overview, disclaimer, group tag, cost warning, and example in a somewhat cluttered manner. It could be more streamlined, but it's not excessively long. The cost warning is necessary but disrupts flow.
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 present, yet the description does not clarify what the tool returns (e.g., PDF link, HTML content). It mentions output format (PDF or HTML) only in the title. Without details on output structure or delivery, the description is incomplete for an agent to fully understand the tool's 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?
The input schema has 100% coverage, fully documenting all 7 parameters. The description includes an example request but does not add semantic meaning beyond the schema, so 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 title and description clearly indicate that the tool generates a financial report based on birth chart placements (2nd house, Jupiter, Saturn). However, it does not distinguish from sibling financial tools like financial_career_money_style, limiting clarity for selection.
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 warns about the high cost (5,000 credits) and instructs to confirm with the user before invoking, which is strong guidance on when to use. It lacks when-not-to-use or alternative options, but the cost warning is valuable.
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?
Annotations indicate non-read-only, non-destructive, non-idempotent, open-world hint. The description adds valuable behavioral context: PDF URLs expire after 24 hours via auto-cleanup cron, HTML mode is live, and cost is highlighted. This goes beyond annotations by explaining side effects and longevity, though auth needs are not mentioned.
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 concise: two sentences with key feature, plus an example and cost warning. It is front-loaded with the main purpose. The cost warning is separated but within the tool definition. No unnecessary words; all sentences add value.
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?
Explains report content and PDF expiry, but does not describe the return format (URL, file, binary?). No output schema exists, so description should specify output. Schema coverage for parameters is incomplete. Example request body is helpful but lacks response example. Additional context like permissions or rate limits is missing.
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 33% (only chart described in schema). The description adds meaning for whitelabel (branding overrides) and hints at language (uk, en) but does not list all 20+ language enum values. The chart object's sub-parameters are partially covered by schema description. Overall, description compensates for low schema coverage but not fully.
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 renders a Western tropical natal chart as PDF or HTML, specifying content (Big Three, planets, houses, aspects). The title reinforces 'Generate Natal Report'. However, it does not explicitly differentiate from sibling report tools like reports_business or reports_ai_natal_narrative, leaving ambiguity about when to use this specific tool.
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 lacks 'when-not' conditions or references to similar tools. Siblings include many report tools, but no rationale for choosing this one is provided. A cost warning is present but does not substitute for usage context.
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?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds minimal behavioral context (author, input example). No contradictions, but no significant added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus group/cost/example. Information is front-loaded and well-structured. Slight deduction for not using a more structured format (e.g., bullet points), but overall 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?
Given a simple tool with one parameter, annotations, and no output schema, the description covers the main purpose and input format. Lacks explanation of output structure or expected response, but sufficient for basic 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 description coverage is 0%, so the description carries full burden. It adds meaning by referring to 'ecliptic longitude' and providing an example array. However, it does not explicitly state units or allowed ranges beyond schema constraints.
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 verb 'Return' and the resource 'Sabian symbol (Dane Rudhyar)' for each given ecliptic longitude. It distinguishes from numerous sibling tools by specifying a unique, narrow function, avoiding tautology.
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 (e.g., 'modern_rudhyar_symbolic_degrees'). There is no mention of prerequisites, context, or exclusions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds no behavioral traits beyond these, missing opportunities to explain idempotency or other nuances.
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 paragraph and an example. No superfluous text, but the example is lengthy. Front-loading is good with the main purpose stated first.
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, and the description does not describe the return value or format. It adds group and cost context beyond schema but lacks output details. Adequate but incomplete for a tool with no output schema.
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 schema already documents parameters. The description provides an example request body but no additional semantic explanation of each parameter. Baseline score of 3 is appropriate as the example is helpful but not essential.
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 'Calculate solar (heliocentric) astrocartography lines — geographic loci where each planet was on an angle relative to the Sun at birth.' This is a specific verb+resource combination that distinguishes it from sibling tools like 'acg' and 'acg_zones'.
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 includes a group label '[Group: Astro-Geography]' and cost information, but does not explicitly state when to use this tool versus alternatives or when not to use it. The unique name and description imply the specific use case (heliocentric vs geocentric), 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?
Annotations already indicate readOnly=true and idempotent=true. The description adds that cells contain either an aspect object or null, and lists default bodies. However, it does not explain computational details like applied orbs, aspect types, or how missing data is handled, leaving some behavioral ambiguity.
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 at two sentences plus an example and metadata. It is front-loaded with the core purpose. Minor points: it includes non-descriptive metadata (group, cost) that may distract, but overall efficient.
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 the input schema (nested objects with many fields) and no output schema, the description explains the output format (matrix size, bodies) and includes an example. However, it does not clarify aspect-related semantics like orbs, exact aspects, or how null cells arise, leaving gaps in contextual 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 input schema already includes detailed descriptions for both chart1 and chart2. The description provides a concrete example request body but adds minimal semantic value beyond what the schema conveys. 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 returns an NxM matrix of cross-chart aspects between two charts, listing the default celestial bodies included (Sun..Pluto + nodes + Lilith + Chiron). It distinguishes from sibling synastry tools like 'synastry' and 'synastry_attraction_score' by specifying a grid format with specific default bodies.
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 such as 'synastry' or 'synastry_house_overlay'. The description lacks when-not-to-use scenarios or distinguishing context relative to the many sibling synastry 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe, idempotent read operation. The description adds minimal behavioral context beyond the card count and group. It does not describe potential side effects or constraints (e.g., whether the question is optional). With annotations present, the description's contribution is acceptable but not enriched.
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, with only three brief lines. No superfluous words. The group tag and example are efficiently included. Every sentence is necessary and contributes to understanding.
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, and the annotations cover safety. However, there is no output schema or description of the return value. A brief note on what the tool returns (e.g., a card object with name, meaning, etc.) would improve completeness. Currently, it relies on the agent's prior knowledge of tarot reading outputs.
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 only describes body as a raw JSON object, which is vague. However, the description compensates by providing an example with fields seed, question, and allowReversed, clarifying the required structure. This example adds significant meaning beyond the schema, earning a high score.
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 'Single clarifying card' clearly states the tool's function: drawing one tarot card for clarification. The title 'Marseille — Clarifier' reinforces this. However, it does not explicitly differentiate from sibling tools like tarot_marseille_draw_single or tarot_rider_waite_clarify, leaving the agent to infer the specific usage context.
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 guidance is provided. The description does not state when to use this tool versus others (e.g., after an initial spread, or when further insight is needed). Without explicit when/when-not advice, the agent may misuse 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds an example with 'question' and 'allowReversed', hinting at input behavior, but does not disclose the response format or any side effects. The example partially compensates, but overall behavioral details are sparse.
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 group note and an example. Every element is purposeful with no redundancy. The structure front-loads the purpose, groups it, and provides a helpful example, making it easy to scan.
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 is incomplete for an agent to fully understand the tool. It lacks any mention of the output format or return value, which is critical since there is no output schema. The example only covers input. For a tool that generates a card reading, the agent needs to know what the response contains to process it correctly.
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 a single 'body' parameter with a generic description deferring to the example. The example provides field names and sample values (seed, question, allowReversed), giving some meaning. However, the description does not explicitly list required fields, types, or constraints, making the parameter semantics less clear than they could be.
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 'Single-card draw from Marseille deck,' specifying the verb (draw), resource (Marseille deck), and scope (single card). This distinctively differentiates it from sibling tools like tarot_marseille_draw_three_card or tarot_marseille_draw_celtic_cross.
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 single-card draw versus other Marseille spreads. The sibling set includes many similar tools (e.g., tarot_marseille_daily, tarot_marseille_draw_love), but the description does not provide context or alternatives for appropriate usage.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the specific method (Mary Greer's m+d+y reduction) but does not disclose any additional behavioral traits beyond what annotations cover. This is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence describing the method plus a group tag and an example. It is front-loaded with the core purpose and contains no filler. Every element earns its place.
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 explain what the return value contains (e.g., card name, number, interpretation). It only says 'Birth card' without further details. Additionally, the role of optional location parameters is not clarified. This leaves the agent with gaps in understanding the tool's full behavior and output.
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 all parameters have descriptions in the schema. The description provides an example input for the required 'date' parameter but does not clarify the purpose of optional parameters like latitude, longitude, and timezoneOffset, which may appear irrelevant for a birth card calculation. Baseline 3 is appropriate as the description adds only marginal 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?
The description clearly states it computes a birth card from a date using Mary Greer's method (m+d+y reduced). The title and group tag 'RWS — Birth Card' and 'Tarot — Rider-Waite-Smith' distinguish it from sibling tools like tarot_marseille_birth_card. 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?
The description lacks explicit guidance on when to use this tool versus alternatives such as tarot_marseille_birth_card or other tarot birth card tools. The group tag provides implicit context, but no direct comparison or usage criteria are stated, leaving the agent to infer suitability from the 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?
Annotations already declare readOnly, destructive, idempotent, and openWorld hints. The description adds the spread structure but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only three short lines. It front-loads the key information (13-card spread) and includes a group tag and example. However, a more structured purpose statement could improve 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?
For a 13-card spread tool, the description omits important details such as the format of the output (e.g., does it return card names, positions, interpretations?) and the deterministic behavior implied by the seed. Without an output schema, this information is critical for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'body' object with no property definitions. The description compensates by providing an explicit example request body with seed, question, and allowReversed fields, which conveys the required and optional parameters effectively.
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 specifies a 13-card spread covering 12 months and a theme, which clearly indicates the tool's purpose for year-ahead readings. However, it lacks explicit differentiation from sibling tarot tools like daily or single-card draws.
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 other tarot drawing tools. The example shows required fields but no context about when this spread is appropriate (e.g., annual forecasting) or when to avoid 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds value by detailing the scoring algorithm (Mahendra and Vedha rules) and the cost (50 credits) and group (Vedic). This goes beyond annotations and provides operational context, though it does not mention rate limits or authentication.
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 explaining the scoring plus a one-line group/cost note. Every sentence serves a purpose—defining scope, giving calculation details, and stating cost. No fluff. 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?
Despite the detailed scoring rules, the description fails to mention the output format or structure. Since there is no output schema, the agent cannot predict what the return value will contain (e.g., total score, breakdown, individual points). This is a significant gap for a tool with no output schema.
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 coverage is 100%, so the schema sufficiently documents both parameters (chart1, chart2) with types and descriptions. The tool description does not add any parameter-specific meaning; it only describes the scoring. Per guidelines, baseline 3 is appropriate since schema already covers the parameters.
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 identifies the tool as extended matchmaking adding Mahendra and Vedha on top of Ashtakoot, with a specific max score of 39. It gives a concrete verb ('adds') and resource ('compatibility matchmaking'). However, it does not explicitly distinguish it from sibling tools like vedic_compatibility_ashtakoot or vedic_compatibility_full, relying on the reader to infer it is an extension.
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. It does not mention prerequisites, ideal scenarios, or cases where another tool (e.g., ashtakoot, full) would be more appropriate. The agent is left to infer usage context from the name and scoring description.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds no behavioral traits beyond stating it detects status. It does not contradict annotations but provides no additional transparency beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, a group tag, cost info, and an example request body. It is front-loaded and scannable, though the example could be better integrated.
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 11 parameters (2 required), no output schema, and complex Vedic context, the description fails to explain the output, how to interpret results, or how to use in a full compatibility flow. The school parameter mismatch also undermines completeness.
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 11 parameters with 0% coverage description. The description mentions a 'school' parameter not present in the schema and only provides an example with date, time, etc. It fails to explain the meaning or usage of most schema fields like houseSystem, zodiacType, ayanamsaId, etc.
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 detects Manglik status for a single chart, distinguishes it from sibling vedic_compatibility_mangal_match (which is for two-chart matching) by specifying 'single chart', and notes the school selection option.
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 use in 'compatibility context for matchmaking flows' and references the same canon as the doshas endpoint, giving context. However, it lacks explicit when-not-to-use or alternative tools for two-chart scenarios, though it 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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already disclose safe, non-destructive behavior. The description adds that this is a 5th-level sub-period with typical duration and cost (50 credits). Behavioral information beyond annotations is minimal but consistent.
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 and front-loaded: key function (Pranadasha, finest grain), cascade info, typical duration, then group and cost, ending with a realistic example. Every sentence adds value. No 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?
Given the complexity of dasha sub-periods and many sibling tools, the description covers the essence and provides a concrete example. However, there is no output schema, and the description does not explain what the response contains (e.g., planet periods, dates). The example hints at the input but not output. It's adequate but not fully 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?
Input schema coverage is 100%, so baseline is 3. The description includes an example request body that illustrates required (date, time, targetDate) and optional parameters (timezoneOffset, latitude, longitude). No explicit parameter descriptions, but the example adds practical value. The schema itself includes descriptive text for the body.
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 identifies this as Pranadasha, the finest 5th-level sub-period in the Vimshottari dasha system. It mentions 'finest grain' and typical duration (hours to days), distinguishing it from higher-level dashas like mahadasha or antardasha among siblings. However, it could be more explicit about the hierarchy of levels.
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 fine-grained timing by stating 'finest grain' and providing an example with a targetDate. It does not explicitly state when to use this vs. other levels (e.g., maha, antar) or when not to use it. No exclusion or alternative guidance is given.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about the output (active phase with sub-lord chain) and explains the Sade Sati period. This provides behavioral insight beyond annotations, though it doesn't detail side effects or further 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 concise (two sentences plus example) and front-loaded with purpose. It includes a group tag and example. However, it could be more structured by including parameter details. It is not verbose, earning a high score for efficiency.
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 11 parameters with no schema descriptions and no output schema, the description is incomplete. It minimally explains the return value (active phase with sub-lord chain) but lacks details on how to use parameters or interpret output. The example partially compensates, but overall the description is insufficient for correct tool invocation.
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?
Schema coverage is 0%, meaning no parameter descriptions exist. The description only gives an example with some parameters but does not explain the meaning or usage of any parameter. It fails to compensate for the lack of schema descriptions, leaving the agent to guess 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 defines the tool's purpose: computing Sade Sati state at a target date. It explains the concept of Sade Sati (Saturn transit through 12th/1st/2nd from natal Moon, 7.5 years) and specifies the output (active phase with KP Saturn sub-lord chain). This distinguishes it from sibling dosha tools like vedic_doshas_kp_full.
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 assessing Sade Sati on a specific date, but it does not provide explicit guidance on when to use this tool vs other dosha tools (e.g., vedic_doshas_kp_kalasarpa). No alternatives or exclusions are mentioned; usage is inferred from the example and context.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which align with the tool's read-only computation. The description adds a list of included doshas but no additional behavioral context like performance, error handling, or output structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus example), front-loaded with purpose. The example is helpful. However, it could be slightly more structured to include parameter guidance or output hints.
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?
For a complex tool with 11 parameters, 0% schema description coverage, and no output schema, the description is insufficient. It does not explain the meaning of each dosha, the kismat score, or the output format. The example is helpful but incomplete, leaving the agent uncertain about how to use all parameters or interpret results.
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 coverage is 0%, meaning no parameter descriptions in the schema. The description only provides an example with 5 of 11 parameters (date, time, timezoneOffset, latitude, longitude), leaving the remaining 6 parameters (e.g., houseSystem, zodiacType) entirely undocumented. This fails to compensate for the lack of schema documentation.
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 provides a composite summary of specific Lal Kitab doshas (manglik, kalsarpa, pitra, shrapit, 6 Rin, kismat score). The title 'Doshas — Lal Kitab full summary' further reinforces this, distinguishing it from individual dosha tools 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 use for a comprehensive dosha overview via 'full summary' and provides an example, but lacks explicit guidance on when to use vs alternatives (e.g., individual dosha tools). No exclusion criteria or when-not-to-use information.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the agent knows it is safe and non-modifying. The description adds that it includes remedies, which is useful context but does not elaborate on output or behavior further.
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: two sentences defining the tool and group, plus an example. It front-loads the key purpose and avoids redundancy, though it could integrate the example more seamlessly.
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 11 parameters, no output schema, and many sibling tools, the description is too sparse. It does not describe return values, remedy format, or how to interpret results, leaving significant gaps for an agent to use it correctly.
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?
With 0% schema description coverage, the description fails to explain most parameters. Only an example request body illustrates date, time, timezoneOffset, latitude, and longitude, leaving 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram) completely undocumented.
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 calculates Kalsarpa dosha (Rahu-Ketu encirclement) with Lal Kitab remedies, which is specific and distinguishes it from other dosha tools (e.g., Parashari kaal sarp, Lal Kitab full). The [Group: Vedic] tag further clarifies its domain.
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 Kalsarpa dosha analysis but does not explicitly state when to prefer this over alternatives like vedic_doshas_parashara_kaal_sarp or vedic_doshas_lal_kitab_full. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read operation. The description adds value by listing the exact components that go into the ruling planets and noting deduplication. An example request body is provided, giving practical insight into usage.
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 concise: two sentences plus an example. It includes a group label and is front-loaded with the key purpose. Every part serves a function without redundancy.
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 11 parameters, no output schema, and many siblings. The description does not explain the return format, how many ruling planets to expect, or how to interpret results. It also omits guidance on optional parameters like houseSystem or zodiacType, leaving the agent under-informed for correct 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?
With 0% schema description coverage, the description carries the full burden for parameter understanding. It only provides an example request body with some parameters but no explanations of their meanings, defaults, or valid values. This is insufficient for a tool with 11 parameters.
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 canonical KP ruling planets from a specific list of components (Day-lord, Hora-lord, etc.) and mentions horary timing analysis. However, it does not differentiate from sibling tools like vedic_kp_significators or vedic_kp_sub_lords, which may have overlapping functions.
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?
It states 'Used in horary timing analysis,' providing general context, but lacks explicit guidance on when to use this tool versus alternatives such as vedic_kp_horary or other KP tools. No when-not or exclusion criteria are given.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description implicitly supports by calling it a 'snapshot'. The description adds behavioral context: it covers ages 0-35, shows running house, ruler, and ruler's state, and is a 'rough timing index'. No contradictions. The description enriches beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus a group tag and example. It front-loads the main purpose. The example request body adds length, which may be useful but is not strictly necessary for understanding. Overall efficient, though could be tighter.
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 11 parameters, no output schema, and no parameter descriptions, the description is insufficient. It explains the output vaguely ('showing the running house, its ruler, and the ruler's current state') but omits format, pagination, or how the age range is calculated. The tool's complexity demands more detail to be fully usable.
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?
Schema description coverage is 0%, and the description contains zero explanation of the 11 parameters. The example request body shows values but does not describe what each parameter (like timezoneOffset, latitude, houseSystem) means or how they affect the output. This is a major gap for tool usability.
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 year-by-year Lal Kitab dasha snapshot for ages 0-35, showing the running house, its ruler, and the ruler's state. The verb 'snapshot' and resource 'Lal Kitab dasha' are specific, and the age range differentiates it from other dasha tools like vedic_lal_kitab_dasha.
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 as a rough timing index' but does not specify when to avoid this tool or provide alternatives. Given the large sibling list including many other dasha tools, explicit guidance would help. The group tag '[Group: Vedic]' provides some context but no exclusions or 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?
Annotations indicate readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds behavioral context by listing preferred nakshatras and avoidance days, but does not disclose what happens if no windows are found or how scoring works beyond an unclear 'same scoring shape.' It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is around 100 words and includes an example, list of nakshatras, and cost, making it fairly efficient. However, the phrase 'Same scoring shape' is unclear and could be expanded or removed. Front-loading is adequate with the main purpose stated first.
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 7 parameters and no output schema, yet the description does not explain what the tool returns (e.g., list of dates with scores). It mentions 'scoring shape' but never defines the output. Given the complexity, the description leaves significant gaps for an AI agent to understand the full 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?
Schema description coverage is 0%, so the description must compensate, but it only provides an example JSON body without explaining any parameters individually. Users are left to infer meaning from the example, which is insufficient for 7 parameters including optional fields like ayanamsaId and topN.
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 an 'auspicious-window scanner for starting a business / new venture,' providing a specific verb and resource. It further distinguishes itself from sibling muhurat tools by specifying nakshatras and days to avoid, 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 gives an example request body and mentions it's for business start, but does not explicitly state when to use or not use this tool versus alternatives like vedic_muhurat_investment or vedic_muhurat_general_auspicious. The phrase 'Same scoring shape' is ambiguous and provides no comparative 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds context about the scanning logic (preferred nakshatras, avoided days) and cost. However, it does not describe the output format or what the result contains, which is a gap beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with three sentences plus metadata and an example. It front-loads the purpose and includes key astrological details. The list of nakshatras is a bit long but necessary. It could be more structured, but overall 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?
Given the tool has 7 parameters with no schema descriptions and no output schema, the description is incomplete. It omits critical details like the output format, how latitude/longitude affect results, the significance of topN, and any constraints on the search window. The example helps but does not cover all parameters.
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 description coverage is 0%, so the description must compensate. It provides an example request body but does not explain the meaning of parameters like latitude, longitude, timezoneOffset, or topN. The listed nakshatras and days are not parameters. This leaves the agent guessing about 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 it is an 'auspicious-window scanner for short / daily travel', with a specific verb and resource. The title 'Travel (short Yatra)' and the mention of preferred nakshatras further clarify the domain. It implicitly distinguishes from the sibling 'vedic_muhurat_journey_long' by focusing on short travel.
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 preferred nakshatras and days to avoid, giving some guidance on what makes a window auspicious. However, it does not explicitly state when to use this tool versus other muhurat tools (e.g., for long journeys vs. short trips). The context is implied but not directly stated, leaving ambiguity for the agent.
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?
Annotations indicate read-only, idempotent, non-destructive. Description adds context about duration (~1.5h each), classification (good/bad/neutral), and that day-start is by weekday, which enriches understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loads key information (divisions, durations, cycle), and includes a helpful example. It is appropriately sized, though lacks structured parameter descriptions.
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 omits output details, interpretation of results, and full parameter context. Given the specialized Vedic nature and 11 parameters, this is insufficient for an agent to reliably invoke the tool.
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 description coverage is 0%, yet the description only provides one example request body covering a few parameters. The many optional parameters (houseSystem, zodiacType, etc.) are not explained, leaving the agent without guidance on their meaning or usage.
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 provides Choghadia divisions for day and night, with a cycle of 7 named periods marked good/bad/neutral. This differentiates it from sibling tools like vedic_panchang_full or vedic_panchang_hora.
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, no prerequisites or context for use. The description only explains what it calculates, not when or why an agent should choose it over other panchang 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?
Annotations already declare readOnly=true, etc. The description adds that position depends on weekday and sunrise/sunset, which is useful. No contradictions, but the description does not exceed what annotations provide significantly.
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 and to the point: 3 sentences plus example. It avoids redundancy, but could be slightly improved by briefly listing key optional parameters.
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 describe the return format. It only mentions the names of the windows but not what the output contains (e.g., times, dates). Also, many parameters are unexplained, leaving gaps for a complex tool with 11 parameters.
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 description coverage is 0%, so the description must explain parameters. It only provides an example with five parameters, but there are 11 total (e.g., houseSystem, zodiacType, ayanamsaId are unexplained). This is insufficient for an agent to understand all inputs.
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 calculates three inauspicious windows (Rahu Kaal, Yamaganda, Gulika) and the auspicious Abhijit Muhurat. This distinguishes it from other vedic_panchang sibling tools like full, choghadia, tithi, 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?
The purpose is clearly about inauspicious times, but no explicit guidance on when to use this versus other panchang tools. Alternatives not mentioned, so the agent must infer selection from context.
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?
Annotations already indicate read-only, no destruction, idempotent. Description adds behavioral details: simplified model, specific retrograde/speed formulas, Sun/Moon=0, divergence vs jhora ≤30v. This provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise and front-loaded with the purpose and key formula. The example request body is useful. However, the technical formula details could be moved to parameter description for better structure.
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 11 parameters and no output schema, the description should provide better guidance on parameters and expected output. The example helps but is insufficient for a complete understanding.
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?
Schema description coverage is 0%. Description does not explain any parameter semantics despite 11 parameters. Only shows an example request body without explaining what each parameter means or how to set them.
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 defines itself as Cheshta Bala (motional strength) and distinguishes from other shadbala components. Uses specific verb 'computes' implied, and states it's a simplified retrograde/speed model.
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. Mentions future 'Full BPHS Cheshta-Kendra method' but does not clarify when the current simplified version is appropriate vs other tools.
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?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details beyond these: it explains the calculation (linear gradient), the specific house-planet mappings, and provides an example request body. No contradictions. The cost and group are also specified.
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 concise (4 lines plus example body), front-loads the key purpose and algorithm, and avoids unnecessary detail. Every sentence serves a 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 the complexity of Vedic calculations and no output schema, the description covers the core algorithm and planet mappings but lacks parameter explanations, usage guidance, return format, and differentiation from many similar sibling tools. It is minimally adequate.
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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. However, the description only includes an example request body without defining any parameter meanings or constraints. It fails to add 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?
The description clearly defines Dig Bala as directional strength, explains the scoring mechanism (60v at preferred kendra cusp, 0v at opposite, linear gradient), and maps specific planets to preferred houses (Sun/Mars→10th, etc.). This distinguishes it from other shadbala tools like vedic_shadbala_cheshta or vedic_shadbala_drik.
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 other shadbala tools. It lacks explicit usage context or exclusions, leaving the agent to infer from the technical details 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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the formula and cost (50 credits), which goes beyond annotations but does not address additional behavioral traits like rate limits or specific prerequisites.
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, presenting the formula, rules, group, cost, and an example in a few lines. It is front-loaded with the core formula, though it could be better structured with bullet 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?
With 11 parameters, no output schema, and 0% schema coverage, the description is incomplete. It omits output format, parameter roles (e.g., name, city, cosmogram), and validation rules beyond the example. The formula provides technical depth but lacks broader 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?
Schema coverage is 0%; the description does not explain any individual parameters. It provides an example request but no details on optional fields like houseSystem, zodiacType, or ayanamsaId. The formula gives context but not parameter-level 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 explicitly states it calculates Drik Bala (net aspectual strength) per BPHS A.27.49, with a clear formula. The title and content distinguish it from sibling tools like vedic_shadbala_cheshta, vedic_shadbala_dig, etc., by focusing on 'aspectual' strength.
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 calculating net aspectual strength in Vedic astrology, but it does not explicitly state when to use this tool versus other shadbala components or provide alternatives. The context is clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context by stating that the strength is 'fixed' (not dependent on input beyond date/time) and lists the actual values. It does not contradict annotations and offers slight behavioral insight beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and includes key information (fixed strength values, example request) with group and cost metadata. It is front-loaded with the core purpose. There is no fluff, though the inclusion of group/cost tags adds structure. Could be slightly more organized but is 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 11 parameters, no output schema, and many sibling tools. The description only reveals the core output (planet strengths) without explaining the output structure or how parameters relate to the computation. It does not describe the role of this shadbala component within the larger system or how it differs from other shadbala tools (e.g., full, kala). Given the complexity, the description is insufficient for an agent to fully understand tool behavior and output.
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 description coverage is 0%, so the description must compensate. It includes an example request body but does not explain the meaning or derivation of any parameter (e.g., date, time, latitude, longitude). Many optional parameters (houseSystem, zodiacType, ayanamsaId, cosmogram) are not mentioned at all. The example does not clarify usage beyond showing a valid 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 states it computes 'Naisargika Bala — fixed natural strength per planet' and lists the exact values for each planet. This distinguishes it from sibling shadbala tools (e.g., vedic_shadbala_dig, vedic_shadbala_kala) by explicitly naming the naisargika (natural) component. The title and group also reinforce the 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?
The description provides no guidance on when to use this tool vs alternatives among the many shadbala and Vedic tools. It only includes group and cost metadata. No explicit when-to-use or when-not-to-use instructions, nor any reference to 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?
Annotations already provide readOnlyHint and idempotentHint. Description adds no behavioral details beyond source citation, meeting baseline expectations.
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 key info (condition and source). The example request body adds bulk but is useful. Minimal waste.
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?
For an 11-parameter tool without output schema, the description lacks guidance on many inputs and output expectations. It only covers the core condition.
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?
With 0% schema description coverage, the description fails to explain parameters. The example request body is present but does not clarify parameter semantics or provide context beyond a sample.
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 this computes a 'Reverse Raja yoga' specifically for AK in houses 6/8/12, differentiating it from sibling tools like vedic_yogas_jaimini_raja or vedic_yogas_jaimini_dhana.
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 specifies the exact condition (AK in 6/8/12) and source (Sanjay Rath modern commentary), implying usage context. However, it lacks explicit when-not or alternative guidance among siblings.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds behavioral context by explaining the yoga condition and including cost/group info, but does not specify what the tool returns (e.g., boolean or details) or how it handles inputs.
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 the core condition. It includes group and cost info in brackets and an example. However, the example could be more helpful if it explained parameters.
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 mention what the tool returns (e.g., a boolean, a list, or details). Given the 11 parameters and specific yoga, this is a significant gap.
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?
With 0% schema description coverage, the description fails to compensate. It only provides an example request body without explaining any parameter's meaning, leaving the 11 parameters largely cryptic.
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 defines the yoga condition precisely: 'Jupiter in a kendra (1, 4, 7, 10) from Moon.' It names the specific yoga and notes its classical significance, clearly distinguishing it from sibling yoga 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 when checking for Gajakesari Yoga but provides no explicit guidance on when to use versus alternatives, nor any 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds context about the tool's specific purpose (zenith) and cost (50 credits), but does not reveal any hidden behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus group/cost/example. However, the example includes 'planetId' which is not in the schema, confusing the structure. Every sentence earns its place, but the mismatch reduces 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?
With 11 parameters, no output schema, and a misleading example, the description is incomplete. It fails to explain key parameters like latitude, longitude, zodiacType, or the cosmogram flag, leaving the agent underinformed about how to properly invoke the tool.
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 description coverage is 0%, so the description must compensate. However, it only provides an example with a subset of parameters (date, time, timezoneOffset, planetId) and planetId is not even in the input schema. The other 8 parameters (latitude, longitude, houseSystem, etc.) are left unexplained, offering little semantic help.
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 'Find' and clearly states the resource 'geographic locations' and the exact condition 'a given planet is exactly at the zenith (MC) at the birth moment'. This distinguishes it from sibling tools like 'acg' which likely cover all astro-cartography lines.
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 when to use the tool (for zenith locations) but provides no explicit guidance on when not to use it or which alternative tool to use for other angles (e.g., AC, DSC, IC). No exclusions or comparisons 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description only needs to add extra behavioral context. It adds a cost note and group tag, but does not disclose traits like output format, pagination, or side effects beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus group/cost info and an example. Every sentence adds value. The first sentence immediately states the core purpose, making it front-loaded and efficient.
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 7 parameters and no output schema, the description lacks details about the return format or what lines are produced. For a mapping tool, more context (e.g., what the output contains) would be helpful. The example request body partially compensates but the overall 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?
The input schema covers 100% of parameters with descriptions. The description does not add any parameter meaning beyond the schema, but includes an example request body that implicitly illustrates parameter usage. Baseline 3 applies since schema does the heavy lifting.
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 'Calculate A*C*G lines for all planets' and explains what these lines are (geodetic map lines where each planet was on an angle at birth). The verb 'calculate' and resource 'A*C*G lines' are specific. However, it does not differentiate from sibling tools like 'solar_acg' or 'acg_zones', which may overlap in purpose.
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 a cost (50 credits) and a group tag [Astro-Geography], which implies usage context but offers no explicit guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use instructions are given.
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?
The description adds behavioral context beyond annotations: it is a chat (multi-turn via history) and persona-tunable. Annotations already indicate read-only, non-destructive, non-idempotent, and open-world behavior. The description aligns with these without contradiction.
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 very concise with two sentences and an example request. It front-loads the core purpose. However, structural improvements could include a list of key parameters.
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 hint at the response format (LLM string). It mentions 'LLM chat' implying natural language output, but doesn't state that explicitly. The example only shows request. No mention of the 'history' parameter's role in multi-turn conversations.
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 coverage is low (25%) and the description only provides a single example request body. It does not explain the 'chart' object fields, 'history' structure, or 'language' options. The schema itself contains rich nested properties, but the description fails to compensate for the low 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 title 'AI Chat (RAG over chart)' and description 'LLM chat grounded in a natal chart context. Persona-tunable.' clearly state the tool's purpose as a conversational LLM interface for natal charts. It distinguishes from siblings like 'interpret_natal' by specifying chat and RAG capabilities.
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 the many sibling interpretation tools. The description does not mention typical use cases, prerequisites, or when to prefer alternatives. The agent is left to infer usage from the title.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's added value is limited. It explains the output format (bars with duration and exact dates) and grouping by transit planet, but does not disclose additional behavioral traits like data limits or cosmic parameters.
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, with two sentences and an example. It front-loads the main transformation action and immediately provides a concrete use. No 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?
Given the tool has 8 parameters, no output schema, and many siblings, the description provides a solid overview but lacks detailed guidance on parameter usage and output structure. It feels incomplete for a tool with this complexity.
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 0% schema description coverage, the description must compensate. The example includes startDate, endDate, stepDays, visiblePlanetIds, which adds context. However, it omits explanations for planet1Ids, planet2Ids, aspectAngles, and maxOrb, leaving those parameters underspecified.
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 specifies transforming aspect timelines into Gantt-style bars grouped by transit planet, which is a clear and specific purpose. However, it does not explicitly differentiate from the sibling 'aspect_timeline', which may also produce timeline-based visualizations, lowering the score from 5.
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 'useful for visual transit calendars', giving a hint about when to use it. But it lacks explicit guidance on when not to use it, such as when a different tool like 'aspect_timeline' or 'transit_calendar' would be more appropriate.
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?
Description adds behavioral context beyond annotations: explains the calculation method (multiplying longitudes), valid harmonic range (H2–H36), and includes a group and cost. Annotations already indicate read-only, idempotent, non-destructive, so description reinforces safety while adding specifics.
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?
Three sentences: action, metadata, example. Efficiently structured with front-loaded purpose, no wasted words.
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 is returned (e.g., a chart object). The missing 'harmonic' parameter in the schema makes the tool incomplete as a callable function.
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?
Schema has 100% coverage but critically lacks the 'harmonic' parameter mentioned in the description and example. This creates a misleading expectation; the description implies a parameter that is not in the schema, making the tool effectively unusable as described.
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 'Calculate a harmonic chart by multiplying all planet longitudes by the given harmonic number (H2–H36)'. The verb 'calculate', resource 'harmonic chart', and method are all specified, distinguishing it from sibling chart 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?
Description implies usage when a harmonic chart is needed, and provides an example request body. However, no explicit when-not or alternative tools are mentioned among the many specialized chart siblings.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it returns stability/transition windows and includes cost and group info. However, it does not elaborate on what the output looks like or any behavioral quirks, so it's adequate but not enhanced beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the purpose, and includes the example and metadata efficiently. Every element earns its place with no 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 11 parameters with no schema descriptions, no output schema, and numerous sibling HD tools, the description is insufficient. It lacks details on parameter meanings, output format, and how this tool compares to similar HD tools like hd_design_date or hd_incarnation_cross.
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 description coverage is 0%, meaning the parameter properties have no descriptions. The description only provides an example request body but does not explain the meaning or purpose of most parameters (e.g., houseSystem, zodiacType, ayanamsaId). With 11 parameters and no schema descriptions, the description fails to compensate.
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 verb 'Analyze' and the specific resource 'HD chart type/authority', and explains that it returns windows of stability vs. transition. This distinguishes it from other HD tools like human_design or hd_circuitry which have different focuses.
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 does not explicitly state when to use this tool over alternatives or provide any when-not-to-use guidance. Usage is implied through the description of functionality, but given the many sibling HD tools, more explicit guidance would be beneficial.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context about the 9-deity cycle and provides an example, but does not disclose response format or any behavioral nuances beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus an example and group label. It front-loads the core purpose, making it efficient for agent comprehension.
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 required parameters and annotations, the description is moderately complete. However, the lack of an output schema and no description of the return value (e.g., deity name or number) leaves the agent without full context of what to expect.
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?
All parameters are described in the input schema with high coverage (100%). The description adds no additional meaning to the parameters beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the 9-day cycle of underworld deities (G1-G9) for a given night. It differentiates itself from sibling Mayan tools like 'mayan_tzolkin' or 'mayan_haab' by specifying the night lord cycle.
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 over alternatives. The group label '[Group: Mayan Calendars]' offers little discriminative advice, and no when-not-to-use or alternative references 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description does not need to repeat these. It adds the context of running personas and LLM synthesis, which is consistent with the annotations. No contradictions, but no additional behavioral disclosure beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (3 lines) with an example, which is efficient. However, the group label '[Group: MCP Advanced]' is not actionable context for an agent. The key purpose sentence is front-loaded, but the example could be integrated more succinctly.
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 what the tool returns (e.g., synthesized text, list of responses). It also does not explain the chart object parameters or language enum, which are optional but important. The tool has complex parameters (nested object) but the description covers barely any context beyond the minimal purpose.
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 only 25% (only chart object documented). The description provides an example request body showing 'question' and 'agents', adding some semantics, but it does not explain valid values for 'agents' or 'language' (despite enum). The chart object is documented in schema but not in description. Incomplete compensation for low 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 'Run N personas in parallel + LLM synthesis', which is a specific verb+resource combination. The example shows concrete usage with 'question' and 'agents' parameters. It is distinct from sibling tools like 'mcp_agent_debate' (debate vs synthesis) and other mcp_ 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 parallel multi-agent tasks followed by synthesis, but it does not explicitly state when to use this tool over alternatives like 'mcp_agent_debate' or 'mcp_multi_chart_context'. There is no guidance on prerequisites or situations to avoid.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds 'life-area difficulties to master' but does not fill gaps such as output structure, rate limits, or authentication needs. With annotations present, score is baseline adequate.
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 front-loaded with purpose in two sentences, plus a group label and example. Every element earns its place with no redundancy or 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 tool that calculates four Challenge cycles without an output schema, the description could explain what the four challenges are or hint at return values. It covers the basic purpose but lacks detail for full 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% with all four parameters described. The description offers an example request (date, name) but adds no semantic meaning beyond the schema. Baseline 3 applies as schema does the heavy lifting.
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 calculates four Challenge cycles derived from birth date components in the Chaldean system, distinguishing itself from sibling tools like numerology_chaldean_life_path or numerology_chaldean_pinnacles by specifying 'life-area difficulties to master'.
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 like numerology_chaldean_balance or numerology_chaldean_maturity. It lacks explicit when-to-use or when-not-to-use context, and the example request body only serves as parameter format illustration.
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?
Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds behavioral context: 'sum of Life Path and Expression, activates around age 35.' This clarifies the calculation method and timing, beyond what annotations offer. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear purpose, system group, and example. No superfluous text. However, structure is flat; brief bullet points or explicit sections could improve scannability.
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 description does not explain return format or optional parameters (latitude, longitude, timezoneOffset). The schema descriptions are minimal ('Latitude (some date-only endpoints accept location)'). For a 4-param tool, context is insufficient for an agent to decide when to include location params.
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% (all parameters described). Description adds no parameter-specific meaning beyond schema: it only shows an example with name and date. Baseline of 3 is appropriate; no extra value from description.
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 'Calculate the Maturity number — sum of Life Path and Expression, activates around age 35. Numerology — Chaldean system.' It specifies the verb (calculate), resource (Maturity number), and system (Chaldean), distinguishing it from siblings like numerology_kabbalistic_maturity and numerology_pythagorean_maturity.
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 mentions activation around age 35, implying it's for calculating maturity number for that age, but no comparison to other maturity tools or when-not-to-use. Among many numerology siblings, this lack of differentiation makes selection harder.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, covering safety and idempotency. The description adds that it calculates cycles with age boundaries, but does not elaborate on output format, possible side effects (none expected), or any other behavioral traits beyond what annotations convey.
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 concise: one sentence stating the purpose, a group label, and an example request body. It is front-loaded and contains no unnecessary words. The example adds value despite the parameter discrepancy.
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 omits key contextual details: there is no output schema, and the description does not explain the format or meaning of the results (e.g., what age boundaries look like, how to interpret pinnacle cycles). The example introduces an undocumented parameter, adding confusion. Given the complexity of calculating four cycles, the description is insufficiently complete.
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 schema covers all parameters with descriptions, but the description includes an example request body with an extra 'name' field not present in the schema. This contradicts the schema and may mislead users into thinking 'name' is required. The example also does not clarify that only 'date' is required, and no additional parameter semantics are added.
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 calculates 'four Pinnacle cycles with their age boundaries — life chapters of opportunity.' It uses a specific verb ('Calculate') and resource ('Pinnacle cycles'), and distinguishes from sibling tools like life_path or expression by specifying the Kabbalistic (Mathers strict) system.
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 purpose is clear, there is no explicit guidance on when to use this tool versus alternatives (e.g., other numerology pinnacles tools, other systems). It does not mention when not to use it or suggest alternatives. The group label and system name help but do not constitute usage guidelines.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) are consistent with 'Calculate' in description. The description adds significant context about the tool's purpose and example request, beyond what annotations alone provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear definition, group/cost metadata, and a practical example. Front-loaded and no unnecessary words.
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 11 parameters, 2 required, no output schema, the description only gives an example request and defines the concept. It lacks explanations for all parameters and output format, leaving the agent underinformed for correct 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 description coverage is 0%. The description provides an example with 5 of 11 parameters, but no individual parameter descriptions. With 0% coverage, the description should compensate more; it adds only partial semantics via example.
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 defines 'fixed star parans' and explains the concept of latitude circles where celestial bodies rise/set simultaneously. The tool name and title match, and the definition distinguishes it from siblings like 'fixed_stars'.
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 like 'fixed_stars' or 'chart'. The 'Astro-Geography' group hints at context but lacks direct 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, which fully describe the behavioral safety profile. The description adds only 'plus disclaimer', which hints at an additional output element but does not elaborate on behavioral traits such as rate limits, response size, or error conditions. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two lines plus an example), front-loaded with the core purpose. The group tag and example are concise. However, the example could be omitted or shortened without losing essential meaning, making it slightly less efficient than optimal.
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 moderate complexity (7 parameters) and lack of output schema, the description covers the essential return value (full natal chart with celestial bodies) and includes a disclaimer. It does not specify output format, pagination, or error handling, but for a birth chart tool, these are standard and may not be needed.
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 all 7 parameters described in the input schema. The description includes an example request body that illustrates the format for date/time/timezone/location, but this does not add meaning beyond the schema descriptions. Therefore, no substantial value is added beyond the schema 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 provides a 'full natal chart for the pet (sun, moon, ASC + planets) plus disclaimer'. It clearly identifies the tool's unique function among siblings like 'chart' (general chart) and other pet tools, 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 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. It does not specify prerequisites, exclusions, or mention sibling tools that perform related functions (e.g., pet_sun_sign_meaning, pet_personality). The agent is left to infer usage context from the tool name alone.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds the context that this tool finds conjunctions and interprets them as synodic cycle starts, which is consistent and adds value.
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?
Concise with one main sentence, group/cost metadata, and an example. Well-structured and front-loaded, but the example could be more informative.
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 what the tool does (find conjunctions) but does not describe the output format, such as whether it returns dates, degrees, or planet names. Given no output schema, this is a gap 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description only provides an example without explaining parameter semantics, such as what planet IDs correspond to or the date format details. Schema coverage is low, but description does not compensate.
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 verb 'Find' and resource 'conjunctions between two planets', and specifies 'defining the start of a new synodic cycle', which distinguishes it from sibling tools like 'aspects' that return all aspect types.
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 such as 'aspects', 'eclipses', or other cycle-related tools. The group and cost are provided but do not help the agent decide between similar 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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds the computational step (midpoint composite) and renders a Western wheel, but does not elaborate on behavior beyond what annotations provide. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two lines of purpose and a group tag, plus an example request. It is well-structured and front-loaded, but could be slightly more structured with explicit sections.
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 (e.g., SVG data or URL). It also omits mention of optional configuration options like size or theme, which are present in the input schema but not described in the tool description.
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 input schema already explains the parameters. The description provides a helpful example request body, but adds no additional 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 it creates a composite-chart wheel from two natal inputs, computing the midpoint composite and rendering as a Western wheel. It distinguishes itself from sibling tools like render_bi_wheel and composite by specifying the exact resource and action.
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 composite chart rendering, but does not explicitly state when to use this tool versus alternatives like render_bi_wheel or render_tri_wheel, nor does it provide exclusions or prerequisites.
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?
Annotations already provide readOnlyHint=true and idempotentHint=true, so the description adds only the purpose ('advanced forecasting visuals') without further behavioral details. It does not describe output format or computational aspects.
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 two sentences long, front-loads the core purpose, and contains 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 complexity (4 parameters, nested objects, no output schema) and many similar siblings, the description does not explain the wheel ordering, options usage, or output format, leaving significant gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 75% coverage (the three main objects have descriptions), but the description adds no additional parameter meaning. The 'options' parameter is undocumented in both schema and description, and the tool description does not compensate for the gap.
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 states the tool renders three concentric wheels (natal + progressed + transit) for advanced forecasting, clearly distinguishing it from siblings like render_bi_wheel (two wheels) and other render 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 'used for advanced forecasting visuals,' providing some context, but does not explicitly specify when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only, not destructive, not idempotent, and open-world. The description adds that it dispatches to 12 renderers and includes an example request. It does not elaborate on side effects, error behavior, or rate limits, but given the annotations, the description adds moderate 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 and front-loaded but contains a cut-off sentence ('see…') which reduces clarity. The example is helpful. Overall, it is moderately concise but the structural flaw of an incomplete sentence detracts from 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?
Given the tool complexity (11 parameters, nested objects, no output schema), the description lacks sufficient guidance. It provides an example and lists report types, but does not explain many parameters, expected output, or error handling. The incomplete sentence further reduces completeness.
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 description coverage is only 27%, so the description should compensate. It provides a partial example and lists report_type enum explicitly. It notes that required fields vary by type (chart for most, chart1+chart2 for synastry), but the sentence cuts off. Many parameters (spread, seed, etc.) are not explained, leaving gaps for the agent.
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 single endpoint over 12 type-specific renderers, listing all report types. It distinguishes from sibling tools (reports_natal, etc.) by positioning itself as a unified alternative: 'one method instead of 12.' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool is a single endpoint replacing 12 type-specific tools, providing SDK ergonomics. It mentions that required fields vary by report type. However, it does not explicitly state when to prefer this unified endpoint over the individual report generation tools, nor does it provide exclusion 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe read operation. The description adds no further behavioral context such as response format, pagination, or limitations. It only mentions output concepts (tallies, dominant/missing) without structure details.
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 succinct with two sentences for purpose, then group/cost metadata, and a well-formatted example. No extraneous text; every element serves a 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?
For a simple computation tool, the description adequately outlines inputs and outputs. However, it lacks details on whether results are counts or percentages, and does not mention prerequisites like chart calculation. With no output schema, more context on return structure 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?
Input schema has 100% description coverage with clear explanations for chart1 and chart2 parameters. The description provides an example request body but adds no new semantics beyond what the schema already provides. 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 computes element (fire/earth/air/water) and modality (cardinal/fixed/mutable) tallies for each chart and the combined pair, with dominant and missing elements. This is specific and distinct from sibling synastry 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 includes a group tag and example request, but does not explicitly state when to use this tool versus alternatives like synastry_aspect_grid or synastry_attraction_score. Usage context is implied but not directly contrasted with siblings.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description is not required to repeat those. The description adds that it uses a 'raw JSON body' with an example showing seed, question, and allowReversed parameters, which gives some behavioral context. However, it does not explain the meaning of the three positions or any additional constraints, so credit is limited to baseline for 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 very short (two sentences plus a group tag and example), which is efficient. The purpose is front-loaded. However, it could be slightly more structured by separating the example or adding a brief explanation of the spread meaning. It earns most points for being concise without losing 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?
Given the complexity of a three-card Lenormand spread and the absence of an output schema, the description is incomplete. It does not explain what the 'Subject / Situation / Outcome' positions represent or what the response will contain. The agent cannot infer the structure or meaning of the returned data. Compared to other tools with richer descriptions, this lacks necessary context.
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 coverage is 100% for the single 'body' parameter, but the schema only describes it as 'Raw JSON body' with no property definitions. The description compensates by providing a concrete example request body with fields like seed, question, and allowReversed, which adds semantic meaning beyond the schema. This helps the agent understand required and optional fields, though it does not document all possible 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 performs a 'Subject / Situation / Outcome three-card line' Lenormand draw. The title 'Lenormand — Three-Card' combined with the description specifies the verb (draw) and resource (three-card line). Among sibling tools like tarot_lenormand_draw_line_of_five and tarot_lenormand_draw_grand_tableau, this one is uniquely identified by its three-card spread format.
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 like other Lenormand spreads or tarot tools. It does not state prerequisites, limitations, or scenarios where this spread is appropriate. The agent receives no hints for tool selection among dozens of tarot/Lenormand siblings.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds limited behavioral context. It mentions it's a spread, implying a read operation, which is consistent with annotations. No additional behavioral details (e.g., response format) are provided, but the description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences and an example. It front-loads the purpose and includes a group marker for organizational context. Every element is necessary, and there is no redundancy.
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 does not explain what the tool returns beyond being a spread. The example hints at input structure but lacks details about the card interpretation or result format. For a tool with a single vague parameter and no output schema, the description is minimally complete but leaves gaps 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?
The input schema only defines a generic 'body' parameter with no internal structure. The description provides an example request body with fields like seed, question, and allowReversed, giving meaning beyond the schema. However, the schema does not enforce these fields, and the example is not exhaustive. The agent must rely on the example for correct invocation.
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 '5-card love and connection spread', which is a specific verb+resource combination. The title 'Marseille — Love' reinforces this. It distinguishes from sibling tools like tarot_marseille_draw_career and other love-focused spreads like tarot_rider_waite_draw_relationship.
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 like tarot_marseille_draw_relationship or tarot_rider_waite_draw_relationship. The agent must infer from the name and title, which may lead to confusion among many similar love-oriented spreads.
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?
Annotations already indicate readOnly=true. Description adds the recursive proportional split formula, providing useful behavioral context without contradiction.
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 concise, front-loads purpose, and includes an example. Slightly more structure could improve 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, and description does not specify what the response contains (e.g., list of sub-periods with dates). Lacks essential detail for a complex dasha 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. Description mentions targetDate and calculation but does not explain targetTime/targetTzOffset or 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?
Description clearly states it computes the 7 sub-periods (antardasha) of the running Mahadasha at a target date, differentiating it from sibling tools like maha, prana, 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?
No guidance on when to use this tool relative to alternatives such as vimshottari or other dasha systems; lacks 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, signaling safe behavior. The description adds specific algorithmic details (planets, sequence, distribution) and an example request, but doesn't mention prerequisites, output structure, or potential edge cases. It adds value beyond annotations but is not comprehensive.
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 concise (5 sentences) with no fluff. It is front-loaded with the core purpose and includes a helpful example request. The [Group: Vedic] tag aids categorization. Every sentence adds value.
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 a 100-year dasha cycle, the description covers algorithm and rules but omits output format (no output schema) and usage context. With many sibling dasha tools, more guidance on when to use this one 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?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description provides an example request body, which helps clarify the expected format, but does not add significant new semantics beyond what the schema already contains.
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 specific 100-year nakshatra dasha cycle (Shatabdika) with explicit source (BPHS Adhyaya 46), planet sequence, and distribution rules. It distinguishes itself from other dasha tools (vimshottari, ashtottari) by naming and detailing its unique parameters.
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 the many sibling dasha tools (e.g., Vimshottari, Ashtottari). The description does not provide context on what makes Shatabdika appropriate for a given query, such as specific nakshatra or planetary considerations.
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?
Annotations declare readOnlyHint=true, and the description adds algorithmic detail ('Recursive proportional split (parent_years × sub_planet_period / 116)'). However, it does not disclose return format, side effects, or other behaviors beyond the formula.
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 concise: two sentences and an example. It front-loads the purpose and formula without 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?
The description explains the algorithm and number of sub-periods, but lacks any description of the return value (no output schema). Given the complexity of dasha calculations and many sibling tools, more detail on output format 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?
Schema description coverage is 100%, and the description provides an example request body. This adds some value but does not explain each parameter beyond the schema's built-in 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 computes the Shodashottari Antardasha, which consists of 8 sub-periods of the running mahadasha at a target date. It includes the formula and distinguishes itself from other dasha tools by specifying the system and level (antardasha).
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 other vedic_dashas tools (e.g., vimshottari, ashtottari). The agent must infer based on the name and system 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds '5-level cascade' but does not elaborate on behavioral traits like rate limits, auth needs, or output structure. It relies heavily on annotations for 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 two sentences and an example, front-loading key info. The example is lengthy but valuable. Could be slightly more structured, but overall 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?
For a complex tool with nested parameters and no output schema, the description lacks details on return values or what the '5-level cascade' produces. It does not explain the output structure, making it incomplete for an agent to understand the result 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 description coverage is 100%, so the schema already documents all parameters. The description includes an example request body, which adds practical clarity but does not add meaning beyond what the schema provides. 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 'Shodashottari Pranadasha — 5-level cascade (finest grain)', specifying the exact dasha system and level (prana). It distinguishes from sibling tools like shodashottari_maha, antar, etc., which are coarser levels.
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 finest-grain timing via '5-level cascade (finest grain)' but provides no explicit guidance on when to use this vs. other dashas levels or alternatives. No 'when to use' or 'when not to use' statements.
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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's mention of a 'recursive proportional split' adds some behavioral context beyond the annotations. However, the description does not disclose potential side effects beyond read-only, nor does it describe the output structure or error conditions. The formula is helpful but not fully transparent.
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: three sentences plus an example. It front-loads the core purpose and formula, and the example is directly helpful. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (astrological dasha sub-periods) and the lack of an output schema, the description partially compensates by explaining the recursive formula and providing an example. However, it does not describe the output format (e.g., array of periods with dates and planets), which limits completeness. The tool is one of many similar dashas tools, so more detail 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?
The input schema has 100% coverage with descriptions for all properties, so the baseline is 3. The tool description provides an example request body, which adds a concrete illustration but does not explain the meaning of each parameter beyond what the schema already provides. Thus, no substantial 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?
The description clearly states that this tool provides '9 sub-periods of the running MD at targetDate' for the Tribhagi Antardasha system, which is a specific verb+resource combination. It distinguishes itself from sibling tools by including 'Tribhagi' and 'Antardasha' in the name and description, and by specifying the recursive proportional split formula.
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 explicit guidance on when to use this tool versus alternatives such as other antardasha tools (e.g., vedic_dashas_vimshottari_antar). There are no when-to-use or when-not-to-use instructions, and no mention of prerequisites or alternative tools, which is a significant gap given the large number of sibling dashas 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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the tool computes a ‘canonical Jaimini significator,’ which provides some context but does not disclose additional behavioral traits beyond the annotations. It does not describe output format 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three lines including a definition, group label, and example. It is front-loaded with the most important information and contains no extraneous text.
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 (11 parameters, no output schema, specialized Jaimini astrology context), the description is incomplete. It lacks explanation of output format, parameter semantics, and calculation specifics, relying heavily on user familiarity.
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 description coverage is 0%, and the description does not explain any of the 11 parameters beyond showing an example request. Required compensation for low coverage is missing, leaving the agent to infer meaning from parameter names 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 clearly defines the tool as computing the Upapada Lagna (UL), the pada of the 12th house, and explicitly states its role as a canonical Jaimini significator for spouse, marriage, and partnerships. It provides sufficient specificity to distinguish it from other Jaimini 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 Jaimini marriage analysis but does not provide explicit guidance on when to use this tool versus alternatives like vedic_jaimini_padas or other marriage-related tools. No 'when not to use' or alternative recommendations are given.
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?
Annotations (readOnlyHint=true, idempotentHint=true) already indicate safe read behavior. Description adds formula details and KP-style context. Does not contradict annotations; the sub-lord chain mention provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus group tag and example. Formula is front-loaded, essential info immediately clear. No redundant words.
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?
Despite annotations, lacks output schema description. Does not explain what the response contains (e.g., coordinates, sub-lord details, sign/degree). For 11 parameters, more context on inputs and expected output is needed.
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?
Schema has 11 parameters with 0% description coverage. Description does not explain any parameter meaning or usage. Only provides an example JSON body without field explanations, leaving the agent to infer from names and types.
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 computes the Part of Fortune (Lot of Fortune) with the exact formula for day/night birth and specifies KP-style sub-lord chain usage. Distinguishes from sibling vedic_kp_* tools by naming the specific astrological point.
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 KP Part of Fortune calculations but provides no explicit guidance on when to use this vs alternatives (e.g., arabic_parts, vedic_kp_cusps). No exclusions or prerequisites 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds no behavioral traits beyond these annotations, such as authentication needs or edge-case behavior. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example request, front-loaded with the key action and output. Every sentence adds value; no extraneous content.
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 parameter lookup with no output schema, the description covers purpose, input range, and usage context. However, it lacks detail on the output structure (e.g., format of the chain), which would help the agent understand the response.
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?
With 0% schema description coverage, the description carries full burden for parameter semantics. It provides the range (0..360) and an example, but does not explain what 'longitude' represents (e.g., planetary position, cusp). This leaves ambiguity for the agent.
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 returns the full sub-lord chain for a given longitude, specifying the verb and resource. However, it does not explicitly differentiate from similar sibling tools like vedic_kp_sub_lords, which may also return sub-lord data.
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: 'transit-trigger and dasha-bhukti exact-moment analysis.' This provides clear context for when to use the tool, though it does not list alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds that the output includes planet state and pakka-ghar match flag, and that it is single-school. No contradictions, but no further behavioral details like error handling or dependencies.
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 details. It includes a useful example request body. The structure is logical but could be more organized (e.g., separate parameter explanations).
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 adequately explains the tool's function and output features given the lack of output schema. However, it omits parameter semantics and does not cover potential errors or expected output structure, leaving some gaps for a complex 11-parameter tool.
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 coverage is 0%, and the description does not explain any parameters beyond providing an example JSON. It does not describe the meaning of fields like houseSystem, zodiacType, or ayanamsaId, leaving the agent to infer from the example.
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 generates a fixed-house Lal Kitab chart (teva) where house equals sign, with planet placement and states. It distinguishes itself from sibling tools by specifying 'teva' and the fixed-house nature.
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 Lal Kitab school and authorities but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the tool name and brief explanation, but no when-not-to or comparator with other Lal Kitab 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no behavioral context beyond that, such as auth needs, rate limits, or result details. It does not contradict annotations, making a score of 3 appropriate given the 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 concise: one sentence for purpose plus metadata (group, cost, example). It is front-loaded with the key domain. No redundant information. Loses one point for lacking any structural formatting beyond plain text.
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?
Despite the tool having 7 parameters (2 required) and no output schema, the description is minimal. It does not explain what the output looks like, how the chart is interpreted, or contextual details about the varga system. For a complex astrological tool, more context is needed to help the agent 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?
Schema description coverage is 100% (all 7 parameters have descriptions in the input schema). The tool description adds no additional parameter information beyond an example request body. Therefore, the description does not enhance meaning beyond the schema, resulting in a 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 'Dasamsa chart (career, profession, public reputation)'. This provides a specific verb (chart) and resource (Dasamsa), and distinguishes this D10 varga from siblings by its domain focus on career and reputation.
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 only says 'Dasamsa chart (career, profession, public reputation)' which implies usage for career-related queries, but it does not explicitly state when to use this tool versus alternatives like other varga tools (e.g., D1, D9). 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint false, idempotentHint true, and openWorldHint false. The description adds no behavioral context beyond that, such as permissions, side effects, or response behavior, but annotations are sufficient.
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 extremely concise (one sentence plus non-functional comments). It is front-loaded and clear, but could include a brief note on the chart's purpose or typical use cases without losing 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 simple nature of the tool (single calculation), high schema coverage, and comprehensive annotations, the description adequately states the output (Dwadasamsa chart for parents/ancestral karma). No output schema exists, but the return value is implied by the tool's domain.
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% for all 7 parameters, providing baseline value. The description does not add any parameter-specific semantics 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?
Description explicitly states 'Dwadasamsa chart (parents, ancestral karma)', clearly identifying the tool's purpose as computing the Vedic D12 divisional chart focused on parents and ancestral karma. This differentiates it among many sibling varga tools like vedic_varga_D1, D2, 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?
No guidance on when to use this tool versus alternatives. Among many divisional charts (D1, D9, D10, etc.), the description does not specify context, prerequisites, or exclusions. The implied usage from the title is minimal.
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?
Annotations already signal read-only, idempotent behavior. The description adds meaningful context (mechanics of Karakamsa projection, cost tier) without contradiction. However, it doesn't cover error handling or prerequisites, keeping from a 5.
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?
Concise with clear front-loading: opening sentence defines Karakamsa. Example and cost line are useful. Could drop the example or integrate parameter explanations, but overall efficient.
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?
Explains the concept and specific yogas, but given the complexity (Vedic Jaimini) and no output schema, the description omits what the tool returns (list, chart, interpretation). Adequate but not fully self-contained.
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?
With 0% schema coverage, the description must compensate but only provides an example showing a subset of parameters. Most parameters (houseSystem, zodiacType, ayanamsaId, etc.) are unexplained, leaving the agent without meaning beyond their names.
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 computes yogas from the Karakamsa chart (Atmakaraka's sign in D9 treated as lagna). It names specific outputs: 5th-house planet = Ishta Devata, 12th-house planet = Moksha Indicator. This clearly distinguishes it from sibling yoga 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 guidance on when to use this tool versus alternatives like vedic_yogas_jaimini_full or vedic_jaimini_karakas. The description lacks context for selection criteria.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context by detailing the output structure (7 grahas, fields, reasoning per BPHS rules) and mentions cost and group. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus metadata and an example. It is front-loaded with purpose and output details. Every part serves a purpose with no wasted words.
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 (11 parameters, specialized Vedic astrology), the description omits important context: it does not explain how parameters like houseSystem or ayanamsaId affect the result, or clarify what '7 visible grahas' are. The example helps but is insufficient for parameter-heavy use.
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?
Schema description coverage is 0%, so the description must explain parameters. It only provides an example request body without explaining any of the 11 parameters, their defaults, or their effects. The agent lacks guidance on how to fill parameters beyond the example.
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 specific verb 'identification' and resource 'functional benefic/malefic of grahas per Lagna-lord ownership', and lists the output fields (natural nature, functional nature, houses owned, reasoning). This distinguishes it from sibling tools like vedic_yogas_jaimini_dhana or vedic_yogas_jaimini_full.
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 for functional nature identification but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or comparisons to siblings 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the method (Five-Rats-Escape) and a timezone rule, which provides some additional context but does not significantly expand behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example and group label. The first sentence clearly defines the method and purpose, the second provides a critical time rule. The example is a quick illustration. No extraneous text, but the structure could be slightly improved by placing the example after the parameter explanations.
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 annotations, no output schema, and 4 parameters with full schema coverage, the description covers the core method and a key timezone nuance. However, it does not describe the output format (e.g., stem and branch) or explain the role of latitude/longitude parameters. Slight gaps in completeness for a tool with no output schema.
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 four parameters. The description does not add extra meaning to the parameters beyond the schema. The example request body provides a usage illustration, which is helpful but does not deepen parameter understanding. 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 states it computes the 'hour pillar' via the Five-Rats-Escape method, clearly specifying the verb ('compute') and resource ('hour pillar'). It distinguishes from sibling tools like bazi_month_pillar and bazi_year_pillar by focusing on the hour component, which is unique among the BaZi pillar 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 hour pillar calculation but does not explicitly state when to use this tool versus alternatives like bazi_month_pillar. It includes a specific timezone note (Zi-hour starts at 23:00 CST) and an example request, which helps context, but lacks when-not or exclusion 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns 10 consecutive pillars, which is consistent but does not disclose additional behavioral traits like response format or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences, a group tag, and an example. It is front-loaded and efficient, though a single additional sentence on usage alternatives would improve it.
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 mandatory parameter, no output schema), the description covers the input via example. However, it lacks any description of the output format or structure, which is incomplete for an agent to fully understand the tool's 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?
The input schema only defines a 'body' object with a generic description pointing to the tool description. The example '{"startYear":1990}' gives some meaning, but the schema coverage is 100% only because the schema refers to the description. The description provides a usage example but does not fully explain the expected fields or types beyond 'startYear'.
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 returns '10 consecutive year pillars from a given starting year,' clearly defining the action (returns) and resource (year pillars) and distinguishing it from the sibling tool 'bazi_year_pillar' which likely handles a single pillar.
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 obtaining a decade of year pillars but does not explicitly state when to use this versus alternatives like 'bazi_year_pillar'. No guidance on when-not-to-use or prerequisites is 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by specifying that output includes syllable structure, color palette, and semantic field hints.
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, front-loaded with the key purpose, and includes a concrete example. It is appropriately sized, though the group label adds minor structure.
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 explains the type of hints but not the exact output format or number of suggestions. Adequate but could be more complete for an agent to fully understand the 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%, so parameters are well-documented. The example request provides a usage context but does not add significant semantic details 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 provides naming hints (syllable structure, palette, semantic field) by sign. The title 'Name Suggestions' aligns. It is distinct from sibling business 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 includes an example request body implying the need for birth data, but no explicit guidance on when to use this tool vs. alternatives like business_founder_personality or business_ideal_industry.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description credibly adds context about the scoring range and the underlying canons used. It does not contradict annotations and provides additional behavioral detail.
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 to the point with two clear sentences plus a helpful example. The '[Group: ...]' tag adds minimal value but does not detract. No extraneous content.
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?
Despite clear annotations, the description lacks details on return value structure, prerequisites (e.g., valid dates), or how timezone/location affect scoring. The schema-input mismatch is not addressed, leaving the agent underinformed for a fairly complex compatibility calculation tool.
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?
While schema descriptions cover 100% of parameters individually, the actual input structure expected (two persons with date, lat, lon, tz) conflicts with the flat schema showing only one set of fields. The example in the description hints at the correct structure (person1, person2), but the description does not explain this mismatch or clarify the intended input format, leading to 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 it computes a 'Pair compatibility score (0-100)' using specific Chinese zodiac canons (San He trine, Liu Chong conflict-pair), making the tool's purpose precise and distinct from sibling tools like 'vedic_compatibility' or 'horoscope_compatibility'.
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 implicitly defines usage for Chinese zodiac compatibility scoring but does not explicitly contrast with alternative compatibility tools or specify when to use this over others. No exclusion criteria or usage context 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it calculates a midpoint chart and includes an example, but does not disclose any behavioral traits beyond what annotations provide, such as rate limits or error conditions.
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 a single clear sentence plus an example, which is efficient. However, it could be slightly more structured, e.g., separating purpose from example more explicitly.
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 tool with nested parameters and no output schema, the description is minimal. It explains what the tool does but omits output format, error handling, or further context needed 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 description coverage is 100% via the input schema's per-field descriptions. The tool description adds minimal additional meaning beyond 'birth moments' and 'midpoint', so 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 calculates a Davison relationship chart using the midpoint in time and space between two birth moments. The verb 'Calculate' and specific resource 'Davison relationship chart' uniquely identify the tool among siblings like composite or synastry.
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 does not provide explicit guidance on when to use this tool vs alternatives. It belongs to the 'Comparisons' group but no exclusions or sibling comparisons are mentioned, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that it returns 'type, date, and geographic visibility data', which is useful but does not elaborate on limits, authentication, or behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one sentence for purpose, plus group tag, cost, and an example. It is well-structured with each element in its own line, and the primary action 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?
For a simple tool with 2 parameters and no output schema, the description covers the essential: what it returns, required input, and an example. Minor gaps exist for default behavior and valid input ranges, but overall it is 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?
Schema coverage is 0%, so the description must compensate. It provides an example with year=2024 and yearsRange=2, illustrating the use of yearsRange as an offset. However, it does not explain valid values, default behavior, or meaning of null for yearsRange. The example adds some meaning but is not comprehensive.
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 finds solar and lunar eclipses within a year or multi-year range, with a specific verb ('Find') and resource. It is distinguished from siblings like 'eclipse_analysis' and 'stream_eclipse_incoming' by focusing on data retrieval rather than analysis or streaming.
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. While it mentions 'Calendar & Cycles' group, there is no mention of when not to use or which sibling to prefer. The large sibling list includes similar tools like 'eclipse_analysis' and 'stream_eclipse_incoming', but no comparative 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns pairwise matrices, which is useful, but does not disclose other traits like cost (though cost is in the group note) or potential limitations. With annotations covering safety, the description provides moderate added value.
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 concise (one sentence plus a group tag and example), front-loads key information, and avoids unnecessary details. Every element serves a purpose.
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 group synastry and the lack of output schema, the description provides the essential output format (pairwise matrices). It is reasonably complete for an AI agent familiar with astrology, though it could detail orbs or aspect types.
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 description includes an example request body, which aids understanding of the parameter structure. However, it does not explain each parameter's meaning or constraints beyond what is in the schema. With 0% schema description coverage, the description adds marginal 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 the tool calculates synastry aspects among 2-8 charts and returns pairwise cross-chart aspect matrices. However, it does not differentiate from sibling tools like 'synastry' or 'synastry_aspect_grid', which may lead to confusion about when to use this specific tool.
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 group synastry but does not explicitly state when to use this tool versus alternatives like the regular 'synastry' tool. There is no guidance on when not to use it or alternative tools.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that Earth replaces Sun and Moon is excluded, plus cost tier. This supplements annotations well, no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) with group and cost metadata and an example. It is front-loaded with purpose. Could omit the example if not adding value, but overall 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?
Given 11 parameters, no output schema, and complex astrological content, the description lacks details on return format, house system handling, or coordinate usage. Incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 11 parameters with 0% description coverage. The description does not explain any parameter meaning but provides an example request body. With such low coverage, the description should clarify key optional parameters like 'zodiacType' or 'houseSystem'.
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 calculates heliocentric (Sun-centered) planetary positions for a birth moment, specifying that Earth replaces Sun and Moon is excluded. This distinguishes it from other chart 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 it's a specialized chart and costs 20 credits, but provides no explicit guidance on when to use this tool versus alternatives like 'chart' or 'draconic'. The sibling list is large but not referenced.
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?
Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds cycle length context but no additional behavioral details like rate limits or auth needs. With annotations, the bar is lowered, and the description minimally supplements.
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?
Extremely concise: two sentences, an example, and a group tag. No fluff, front-loaded with key information. Every element 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, full annotations, and complete schema, the description is nearly complete. It explains the output concept and cycle, though it could mention output format or differentiation from other Mayan 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?
Schema coverage is 100%, so all parameters are already described in the schema. The description only provides an example request body without adding new semantic meaning beyond what the schema offers.
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 combines Tzolkin and Haab to produce a unique date label within the 52-year cycle, clearly distinguishing it from other Mayan calendar tools like mayan_tzolkin and mayan_haab.
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 other Mayan calendar tools. The description lacks exclusions or alternatives, leaving the agent to infer usage from the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that it calculates four challenge cycles from birth date components, which is consistent with readOnly behavior. However, it does not detail what the output looks like or potential 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a group label and example request body. Every part is useful: it names the output ('four Challenge cycles'), the system, and provides a concrete example. No redundant or vague statements.
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 calculates four specific cycles but the description does not explain what the output contains (e.g., numbers, descriptions, severity levels) or how to interpret results. Without an output schema, this omission leaves the agent guessing about the return 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% with all parameters described (date, latitude, longitude, timezoneOffset). The description mentions 'birth date components' and gives an example, but does not explain the role of optional location parameters. Baseline is 3 since schema does the heavy lifting.
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 'four Challenge cycles' derived from birth date components within the Kabbalistic (phonetic) system. The verb 'Calculate' and resource 'Challenge cycles' are specific, and the mention of 'four cycles' differentiates it from sibling tools like numerology_kabbalistic_balance or numerology_kabbalistic_pinnacles.
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 a user wants Kabbalistic challenge cycles and provides an example request body, but it does not explicitly state when to use this tool versus alternatives like numerology_chaldean_challenge or other systems. No exclusion criteria or alternative 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?
Annotations indicate readOnly, idempotent, and non-destructive behavior, which the description does not contradict. The description adds that it plots planets modulo 90 across quadrants, but does not elaborate on side effects, return format, or authentication needs. It provides some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a group tag and example. It is front-loaded with the core functionality. No wasted words, though the structure could be slightly improved by separating the example into a separate section.
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 a cosmogram rendering tool with many params and no output schema, the description is brief. It lacks explanation of the output format (though title mentions SVG), interpretation of quadrants, or prerequisites. Adequate but leaves gaps for deeper 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?
The input schema has 100% coverage with descriptions for nested objects. The tool description includes an example request body but does not add new meaning beyond what the schema already provides. 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 renders a Cosmobiology 90° dial, plotting planets modulo 90 across four quadrants (Cardinal/Fixed/Mutable). The title and name are specific, and it distinguishes from siblings like 'cosmobiology_cosmogram' and '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?
The description includes a '[Group: Visualization]' tag implying it is a visualization tool, but does not explicitly specify when to use this tool over alternatives like 'cosmobiology_dial_90' or other cosmobiology tools. No exclusions or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds detail about rendering centerline and band, consistent with read-only annotations. Discloses map type (Equirectangular). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus example, front-loaded with key information. Efficient but lacks comprehensiveness for parameter details.
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 has 5 parameters, nested options, no output schema. Description does not cover optional parameters, format options, or return structure. Incomplete for correct invocation without external knowledge.
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?
Zero schema description coverage for all parameters. Description provides an example using 'path', 'bandWidthDeg', and 'title' but does not explain 'centerlinePoints', 'options', or any nested fields. Very limited parameter meaning added.
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 renders an eclipse path on an equirectangular world graticule, with centerline and shaded band. Distinguishes from siblings via specific rendering function.
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?
Grouped under Visualization but no explicit when-to-use or when-not-to-use compared to other render tools. Example shows basic usage but no guidance on alternatives.
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?
The description adds useful behavioral context beyond annotations: it specifies the returned narrative is grounded in tight orbs (≤1°), and includes credit cost (250 credits) and a heavy usage warning. Annotations are sparse (readOnlyHint=false, etc.), so the description partially fills the gap, though it does not clarify if the tool creates persistent reports or only returns text.
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 clear sections: purpose, inputs, and group/cost. However, the input section inaccurately lists parameters, which undermines conciseness. The structure is otherwise logical.
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 (AI narrative, no output schema), the description omits crucial context: how to provide a natal chart (presumed from session), date format requirements, and what the narrative response structure includes. The parameter mismatch further reduces completeness.
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 4 parameters (date, time, timezoneOffset, ayanamsaId) with 0% schema description coverage. The description lists inputs including 'chart', 'transitDate', 'language', 'tone', and 'length', but these do not match the schema (chart, language, tone, length are absent). This is misleading and adds confusion rather than clarifying parameter usage.
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 'snapshot transit interpretation for a specific date' that 'returns narrative grounded in transit-to-natal aspects (orb ≤1°).' This distinctly identifies the tool's purpose and differentiates it from siblings like reports_ai_monthly_narrative or ai_explain_transit.
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 mentions it is for a 'specific date' and includes a heavy cost warning ('⚠️ Heavy — confirm with user before invoking.'). However, it does not explicitly state when to use this tool versus alternatives such as ai_explain_transit or transits, nor does it provide 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?
Annotations are minimal (readOnlyHint=false, openWorldHint=true). The description adds useful behavioral details: seed controls reproducibility, omitting seed uses a daily seed, and cost is indicated separately. However, it does not explain the output format (e.g., returns a file URL or base64) or any side effects beyond generation.
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 (5 sentences plus example), front-loads the core purpose, and uses a bullet-like list for spreads. The example request is helpful. Minor improvement would be grouping related info more clearly.
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 6 parameters, no output schema, and many siblings, the description covers key aspects (spreads, seed, allowReversed) but omits whitelabel and output format. The openWorldHint annotation is clarified by the seed behavior. Overall, it leaves the agent uncertain about the return value and advanced customization.
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 0%, so the description partially compensates by explaining spread, seed, and allowReversed. However, 'name', 'language', and especially the complex 'whitelabel' object are not described, leaving significant gaps in 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 renders a tarot reading PDF/HTML, specifies the default spread and deck (Rider-Waite-Smith), and lists available spreads. This distinguishes it from sibling tools that perform card draws or interpretations without generating a formatted report.
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 such as default spread, seed for reproducibility, and an example request, but it does not explicitly guide when to use this tool over the many other tarot tools (e.g., tarot_rider_waite_draw_three_card). An agent would need to infer that this is for generating a downloadable report rather than raw reading data.
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?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds that the draw is 'based on date seed', implying deterministic output for the same date, which is useful context. No contradictions with annotations. However, it does not explain the effect of optional location parameters on the seed.
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: one sentence, a group tag, and an example. No wasted words, front-loaded with core 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?
Despite the tool's simplicity, there is no output schema, and the description does not explain the response format (e.g., card names, positions, interpretations). The optional location parameters are mentioned but their impact on the seeded draw is not clarified. More completeness is needed for an agent to use this 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 description coverage is 100%, so the schema already documents each parameter. The description adds only an example request body, which provides marginal extra value. With high schema coverage, 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 'Daily three-card draw based on date seed', which specifies the action (draw), resource (Lenormand cards), and distinguishing feature (seeded by date). The title and group tag reinforce that it is Lenormand, differentiating it from other tarot daily tools and other lenormand spread 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 guidance is provided on when to use this tool versus alternatives like other lenormand draws or other daily tarot tools. The description does not mention exclusions, prerequisites, or preferred use cases.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds no further behavioral context beyond the basic 7-card relationship dynamics, which is acceptable but not elevated.
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 extremely concise—two short sentences plus an example—and front-loads the purpose. However, the lack of usage guidelines and the somewhat terse group tag reduce the efficiency; each element earns its place, but missing guidance space could have been better utilized.
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 low complexity (1 parameter, no output schema) and the presence of sibling tools for specific spreads, the description adequately identifies the tool's purpose and example input. However, it does not explain what the 7 cards represent or how the output should be interpreted, 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic (a JSON object with a single 'body' property of type object). The description compensates by providing a concrete example ('{"seed":12345,"question":"What should I focus on?","allowReversed":true}'), which clarifies the expected structure and required fields 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 '7-card relationship dynamics' uses a specific verb ('draw') and clearly specifies the resource ('relationship dynamics'). It distinguishes itself from sibling tools like tarot_lenormand_daily and tarot_lenormand_draw_three_card by indicating the scope and spread type.
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. The description does not state that it is best for relationship questions or contrast it with other Lenormand draw tools. The example request body shows what to send, but no selection criteria 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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context beyond the reading style ('Marseille pip-style'). It does not contradict annotations, but also does not elaborate on auth needs, rate limits, or side effects, which are already covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and an example. The first sentence immediately conveys purpose, and the example is front-loaded. Every element earns its place with no waste.
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, yet the description does not describe what the tool returns (e.g., card positions, interpretation). Given the tool's complexity (10-card spread) and the presence of sibling tools, this omission makes the description incomplete for an agent to understand the full behavior.
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 'body' parameter is vaguely described as 'Raw JSON body' in the schema, but the description provides an example request body showing fields (seed, question, allowReversed) that give practical meaning. This goes beyond the schema definition, earning a 4, though not all possible fields are documented.
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 performs an 'Adapted 10-card Celtic Cross' reading using 'Marseille pip-style'. This is a specific verb+resource+style, effectively distinguishing it from sibling tools like tarot_rider_waite_draw_celtic_cross and tarot_lenormand_draw_celtic_cross_lenormand.
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 many tarot draws (e.g., tarot_marseille_draw_career, tarot_marseille_draw_love) and other Celtic Cross variants, but the description lacks any when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds structural context (deck, positions) but no additional 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one sentence explaining the spread, a group label, and an example. No redundant information, front-loaded with key details.
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 explain return format or meaning of positions. Missing info on required body fields beyond the example. Significant gaps for a tarot reading 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 input schema only defines a wrapper body object with no internal schema. The description provides an example request with seed, question, and allowReversed, but does not fully document all possible or required fields, leaving ambiguity.
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's a 5-card cross spread from Jodorowsky/Costa, specifying positions (consultant, external, higher, result) and a synthesis card. This distinguishes it from other tarot spreads like Celtic cross or three-card draws.
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 spread vs alternatives. The description implies it's a general cross spread, but lacks differentiation from similar tools like draw_celtic_cross or draw_love.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the 10-card spread detail and an example request, but does not disclose additional behavioral traits such as determinism from seed or card interpretation style.
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 lines of text plus an example. It front-loads the essential purpose and groups the tool effectively, with no extraneous 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?
Despite the annotations covering safety, the description lacks information about the output format (e.g., card positions, interpretations). Without an output schema, this omission leaves the agent guessing about what the tool returns, which is critical for a tarot reading 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?
The input schema is minimal (a generic JSON object), but the description compensates by providing a concrete example with fields 'seed', 'question', and 'allowReversed'. This adds significant meaning beyond the schema, though it does not fully document all possible 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 'Classical 10-card Celtic Cross spread' and the title 'RWS — Celtic Cross' along with the group label 'Tarot — Rider-Waite-Smith' unambiguously identify the tool as a specific tarot spread for the Rider-Waite-Smith deck, distinguishing it from other tarot 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?
The description provides no guidance on when to use this Celtic Cross spread versus other tarot tools (e.g., three-card draws, career spreads). It lacks any contextual cues about appropriate use cases or 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds no behavioral context beyond the spread type, but it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences: one stating the spread type and one giving an example body. No unnecessary words, and critical info is 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 description lacks details about output format, card positions, and the meaning of parameters like seed. For a 7-card spread with no output schema, more context is needed to set user expectations.
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 only defines a 'body' object with a generic description, but the tool description provides an example with fields (seed, question, allowReversed) that explain required inputs. This adds meaningful context 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 performs a 7-card chakra spread from Root to Crown. It uses a specific verb (draw) and resource (chakra spread), distinguishing it from other tarot spreads like Celtic Cross or love triangle.
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 spread versus alternatives. The description only mentions the group 'Tarot — Rider-Waite-Smith' but does not explain ideal contexts 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the tool 'returns' data, which aligns with the read-only nature, but it does not disclose any additional behavioral traits such as whether optional parameters are used or ignored.
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 two sentences plus an example, all front-loaded with the core functionality. No unnecessary words or 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?
The tool has no output schema, and the description does not specify the format of the returned data (e.g., card names, numbers, suits). Additionally, the role of optional parameters (latitude, longitude, timezoneOffset) is unclear for a birth-date-based tool. The description should provide more context about the output structure and parameter 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 description coverage is 100%, so the input schema already provides descriptions for all parameters. The description includes an example for the required 'date' parameter but does not add meaning beyond what the schema offers. The optional parameters (latitude, longitude, timezoneOffset) are not explained in the description.
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 returns a soul card and personality card pair from a birth date. It specifies the verb ('Returns'), the resource ('soul card and personality card pair'), and the input ('birth date'), distinguishing it from similar tools like tarot_rider_waite_birth_card which likely returns a single card.
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 includes an example request showing how to use the tool, but it does not explicitly state when to use this tool versus alternatives (e.g., other tarot tools or zodiac-based tools). No guidance on prerequisites or exclusions is 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?
The description adds several behavioral details beyond the annotations: the specific planets and their periods, the block-based nakshatra mapping (4-3-4-3-3-3-4-3 anchored at Ardra), and the applicability flag per BPHS 46.23 (day Krishna OR night Shukla). It also notes the cost (50 credits) and group (Vedic). The annotations already indicate readOnly, non-destructive, idempotent, and not open-world; the description enriches the behavioral model without contradiction.
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, using three sentences to convey the core purpose, details, and applicability condition. It also includes group and cost info in separate lines. However, the cost and group lines could be moved to annotations or metadata. The structure is front-loaded with the main purpose, which aids quick comprehension.
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 clarify return values. It mentions an applicability flag but not the full output (e.g., list of dasha periods). The tool requires a birth chart input, but the description does not explicitly state that input is a birth date/time. The example helps, but reliance on example is weak. Additionally, with many sibling dasha tools, more context on selection criteria 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% description coverage for its single parameter 'body', which is a composed schema describing birth data with required fields (date, time) and optional fields. The description does not add meaning beyond the schema; it only provides an example request body. For a tool with full schema coverage, a baseline of 3 is appropriate, as the description does not further clarify parameter usage or constraints.
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 the 108-year Ashtottari Mahadasha (Ardradi tradition) and lists the 8 planets with their periods (6/15/8/17/10/19/12/21). It specifies that Ketu is excluded and mentions the block-based mapping anchored at Ardra. This distinguishes it from other dasha systems like Vimshottari or Chara, and from other Ashtottari sub-period tools (antar, prana, etc.). 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?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention scenarios where Ashtottari is preferred over Vimshottari, Chara, or other dashas. There is no comparison with sibling tools like vedic_dashas_vimshottari_maha or vedic_dashas_chara_maha. Without such context, an AI agent cannot decide when to invoke this tool.
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?
Annotations already provide readOnly, destructive, idempotent hints. Description adds cost and structure (3-level cascade) but no additional behavioral traits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with a clear front-loaded purpose. The example is lengthy but helpful. No superfluous text, but could be more 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?
No output schema; description mentions 3-level cascade but does not explain output format or interpretation. Adequate but could be more comprehensive given tool complexity.
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 detailed birth data parameters. The tool description adds no extra parameter meaning beyond an example, so 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 title and description clearly state it's for Ashtottari Pratyantardasha, a 3-level cascade (MD→AD→8 PDs). This distinguishes it from other dasha tools in 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?
No explicit when-to-use or when-not-to-use guidance. The name implies specificity, but 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?
Annotations already declare the tool as read-only, non-destructive, idempotent, and not open-world. The description adds that it computes sub-periods at a target date using a seed option, but does not disclose any behavioral traits beyond what annotations imply. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence covering the purpose and key parameters, plus a group label and example. No wasted words.
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 many sibling tools for different dasha levels, but no output schema. The description does not explain the return format (e.g., list of periods, dates, lords), leaving the agent without sufficient context to interpret results. More behavioral details are needed.
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 schema already documents the parameters in detail (e.g., body with birth data fields). The description only mentions targetDate and antardasaSeedOption, adding little meaning beyond the schema. 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 'Shoola Antardasha — sub-periods of running MD at targetDate per chosen antardasaSeedOption'. It specifies the verb (calculates sub-periods), the resource (Shoola antardasha), and distinguishes from many sibling dasha tools (e.g., vimshottari, ashtottari) by name and group.
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 computing sub-periods of a running Mahadasha, but does not explicitly state when to prefer this tool over other dasha levels (e.g., prana, pratyantar) or alternative dasha systems. No exclusions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which cover safety and idempotency. The description adds contextual info like cost and group but no additional behavioral traits (e.g., rate limits, auth needs). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus metadata, and it front-loads the core purpose. The example request body is useful but could be trimmed; still, no superfluous content.
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 annotations and full schema, the description is mostly adequate. However, it does not explain the return format of the 9 PDs, which could be helpful for an agent. It covers the cascade logic but lacks output 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?
The input schema has 100% coverage with descriptions for all properties. The description adds an example request body and notes about passing real lat/lon/tz for accuracy, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 Pratyantardasha, a sub-sub-period within the running Antardasha, and explains the 3-level cascade (MD->AD->9 PDs). This distinguishes it from sibling tools like vedic_dashas_vimshottari_antar and vedic_dashas_vimshottari_maha.
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 sub-sub-period details within the current Antardasha, but it does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use or prerequisite conditions.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, which cover behavioral traits. The description adds only '4-level cascade' and an example request, but no additional details about what happens during computation, response structure, or any side effects. It does not contradict annotations. Given the annotations carry the transparency burden, the description's contribution is modest.
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 very concise with two sentences plus group/cost tag and an example. Every element serves a purpose: defining the tool, indicating group and cost, and providing a concrete request example. No wasted words, though could include brief output note. Efficient for its role.
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 complexity (4th-level dasha calculator), the description is minimally adequate. Schema and annotations handle input and safety. However, no output schema exists, and the description does not explain what the tool returns (e.g., list of sookshma periods). For an agent, it may lack sufficient context to fully understand the output; but the domain-specific name partly compensates.
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 the body parameter fully described. The description does not list or explain parameters beyond the example. It adds no new semantic information; the schema already explains required fields and defaults. Baseline 3 is appropriate for high coverage with no extra explanation.
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 the 'Sookshma (4th-level Dasha) within the running Pratyantardasha'. The title specifies 'Vimshottari Sookshmadasha', distinguishing it from other dasha systems (e.g., ashtottari, chara) and levels (maha, antar, pratyantar, prana). This precisely identifies the tool's function and differentiates it from numerous sibling dasha 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 provides no explicit guidance on when to use this tool versus alternatives. It does not specify when not to use it or mention other tools like vedic_dashas_vimshottari_pratyantar. The context is implied by the name, but there is no direct usage instruction or differentiation strategy.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral details: the 3-level cascade structure (MD→AD→8 PDs) and cost/group metadata. No contradiction with annotations. This goes beyond annotations by clarifying the computational scope.
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?
Two short sentences plus an example. No waste. Front-loaded with the cascade structure. Could be slightly more structured (e.g., separate sections), but it is efficient and 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?
The description explains the cascade levels and includes an example, which helps. However, it does not mention return format (no output schema), and with many sibling dashas, an explanation of when Yogini is relevant would improve completeness. 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description provides an example request body with concrete values, which adds practical context, but does not explain parameter semantics beyond what is in the schema. At high coverage, 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 'Yogini Pratyantardasha — 3-level cascade (MD → AD → 8 PDs)', specifying the verb (computes), resource (Yogini Pratyantardasha), and scope (3-level cascade). This clearly distinguishes it from sibling dasha tools like 'vedic_dashas_yogini_maha' or 'vedic_dashas_vimshottari_pratyantar'.
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 Yogini versus other dasha systems (e.g., Vimshottari, Ashtottari). The description only states what it does, not the context or alternatives. The agent receives no help choosing this over many sibling dashas 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe and read-only. The description adds moderate functional context (aggregate of 6 Rin, active count) but does not disclose additional behavioral traits like rate limits, auth needs, or side effects beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with core info ('Aggregate of all 6 Rin...') and includes a group label and example. It is concise (two sentences plus example) without unnecessary fluff, though the example could be considered slightly lengthy for a description.
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 has 11 parameters, no output schema, and numerous sibling tools, the description is incomplete. It does not explain the output format beyond 'aggregate with active count', the meaning of 'dosha framing', or how it relates to other dosha tools. The example shows required parameters but fails to cover optional ones or the output structure.
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 11 parameters with 0% description coverage. The description includes an example request body showing 5 parameters (date, time, timezoneOffset, latitude, longitude) but does not explain their meaning or the purpose of the remaining 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). The example provides minimal semantic value, leaving significant gaps.
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 provides an aggregate of all 6 Rin (Pitri/Stree/Kanya/Atma/Rishi/Daiva) with an active count, and explicitly distinguishes itself from the sibling tool vedic_lal_kitab_debts by noting it uses the same engine but framed as dosha. This is specific and helps differentiate.
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 directly compares to sibling tool vedic_lal_kitab_debts ('same engine but framed as dosha'), giving clear when-to-use versus that alternative. However, it does not provide broader guidance on when to use this tool among the many dosha tools, nor does it mention prerequisites or 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the specific condition (Jupiter+Rahu/Ketu conjunction) and cost context. No contradictions. Could further mention output nature.
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 no fluff, delivering key information in four sentences. The example is useful. Could be more structured by grouping metadata (Group, Cost) separately.
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 has 11 parameters, no output schema, and complex context (vedic dosha), the description lacks important details: all parameter meanings, output format or examples, and guidance on when to use this specific tool over the full dosha analysis. The example covers only a subset of parameters.
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 description coverage is 0%, so the description must compensate. It provides an example with only 5 of 11 parameters (date, time, timezoneOffset, latitude, longitude) but does not explain the purpose of other parameters (houseSystem, zodiacType, ayanamsaId, etc.) or that they have defaults.
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 specific Vedic dosha (Guru-Chandal) involving Jupiter conjunct Rahu or Ketu, with a clear consequence (wisdom-confusion affliction). This distinguishes it from sibling tools that cover other doshas or full dosha 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 usage for checking Guru-Chandal Dosha but provides no explicit guidance on when to use this tool versus alternatives like 'vedic_doshas_parashara_full'. No when-not or context for selecting this specific dosha.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds beyond: cost (50 credits), example request body, and the scope limitation (detects only 3 of 14 patterns). This provides useful behavioral context that annotations alone do not convey.
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 three sentences plus metadata and an example. It front-loads the core purpose and limitation. The example is helpful but adds length; still, every sentence serves a purpose. Could be slightly tighter if example were moved to schema, but overall 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 11 parameters with no schema descriptions and no output schema. The description does not explain parameter meanings, valid values (except example), or the response format. For a complex Vedic astrology endpoint, this leaves significant gaps for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 11 parameters with 0% description coverage. The description provides an example request body showing 5 parameters (date, time, timezoneOffset, latitude, longitude) but does not explain the remaining 6 parameters like houseSystem, name, city, zodiacType, ayanamsaId, cosmogram. Without clarification, the agent cannot infer appropriate values for these 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 the tool detects Pitru Dosha via Sun+Rahu or Sun+Saturn conjunctions, with an auxiliary marker. It specifies it covers 3 of 14 patterns from BPHS, distinguishing it from the full canonical detection deferred to Phase Q. This is specific and differentiates from sibling dosha 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 Pitru Dosha detection and notes limitations (only 3 patterns, full detection deferred). However, it does not explicitly state when to use this tool versus other dosha tools like vedic_doshas_parashara_full or mention alternatives. Context is clear but lacks explicit exclusions or selection criteria.
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?
Annotations indicate readOnly, idempotent, non-destructive. The description adds group and cost info and an example, but no behavioral details beyond annotations. No contradictions. For a read-only tool, the description is adequate but not enhanced.
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: it defines the dosha, gives group and cost, and provides a clear example. Every sentence adds value without redundancy.
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 many sibling dosha tools, the description clearly identifies this tool's scope. However, it lacks detail on output format (e.g., returns boolean or score) and does not mention typical usage context (e.g., natal chart analysis). The absence of output schema makes it incomplete for an agent to anticipate results.
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 coverage is 0% so description must compensate; it only provides an example request with common parameters (date, time, timezoneOffset, latitude, longitude). It does not explain the purpose of parameters like houseSystem, zodiacType, ayanamsaId, or cosmogram, leaving ambiguity for agent use.
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 checks for Shrapit Dosha defined as Saturn + Rahu conjunction, signifying inherited curse/blockage. This specific condition distinguishes it from other dosha tools (e.g., mangal, pitru) and systems (KP, Lal Kitab). The verb 'conjunct' and resource 'any sign' precisely describe the tool's function.
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 guidelines on when to use this tool versus alternatives like other Parashara dosha tools (e.g., vedic_doshas_parashara_mangal) or brothers from other systems. The description implies use for Shrapit dosha inquiries but does not advise when not to use it or mention prerequisites.
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?
Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds that it computes aspects based on date/time/location, but does not elaborate on behavior, such as what happens if required parameters are missing, how errors are handled, or if any data is persisted. With annotations present, the description provides minimal additional 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 concise, front-loading the purpose and including a useful example. However, the example is placed at the end and the description lacks structured detail for many parameters, leaving gaps that could have been addressed without significant length increase.
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?
For a complex tool with 11 parameters, no output schema, and numerous sibling tools (including individual endpoints), the description is incomplete. It does not explain the output format, how to choose between tropical and sidereal zodiac, or clarify modality rules for rasi drishti. The grouping and example help, but many contextual aspects are missing.
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 description coverage is 0%, so the description must explain parameters. It provides an example request body covering date, time, timezoneOffset, latitude, and longitude, but fails to explain the other 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). Users are left to guess their meanings and permissible values.
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 combined Jaimini aspects (rasi and graha drishti) and explicitly identifies it as a convenience aggregate of two sibling endpoints `/drishti-rasi` and `/drishti-graha`. The title and group tag further reinforce its purpose.
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 mentions it is a convenience aggregate of two specific endpoints, implying this tool is for fetching both aspect types together. However, it does not explicitly state when NOT to use it (e.g., when only one aspect type is needed) or provide alternative tool names beyond the two endpoints.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the specific aspect rules for each planet, but this primarily describes output content rather than behavioral traits like side effects or prerequisites. The description does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and an example, placing critical information (rules, context) upfront. The example could be shortened, but overall it is well-structured and avoids unnecessary detail.
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 11 parameters, no output schema, and no parameter descriptions. The description only covers the core computation and an example, failing to explain the purpose of many parameters (e.g., city, name, cosmogram) or the structure of the response. This leaves significant gaps for effective agent usage.
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?
With 0% schema description coverage, the description must compensate by explaining parameters beyond the example request body. It only illustrates date/time/timezone/lat/lon via example, leaving 8 parameters (e.g., houseSystem, zodiacType, ayanamsaId) unexplained. This is insufficient for an agent to understand how to use all inputs.
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 per-planet graha drishti using specific Parashari rules (e.g., Mars 4/7/8, Jupiter 5/7/9), distinguishing it from the sibling tool vedic_jaimini_drishti_rasi (rasi drishti) by explicitly mentioning it is used alongside rasi drishti in Jaimini-context dashboards.
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 that the tool is 'used in Jaimini-context dashboards alongside rasi drishti,' indicating when it is appropriate to use. However, it does not explicitly state when not to use it or provide alternative tools for different contexts.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about the specific yoga checks performed but does not disclose additional behaviors like output format or error conditions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise, covering purpose, yoga types, future roadmap, and an example in a few sentences. The inclusion of '[Group: Vedic]' and the future roadmap adds slight overhead but 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?
Given 11 parameters with no schema descriptions and no output schema, the description is insufficient. It fails to explain optional parameters, response structure, or how to tailor the request for different yoga results. The agent lacks crucial details for correct 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 description coverage is 0%, and the description does not explain any of the 11 parameters beyond providing an example request that only covers 5 common ones. The example omits optional fields like houseSystem, name, etc., leaving agents without guidance on their meaning or usage.
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 'Basic Jaimini-yoga checks based on chara karakas' and lists specific yogas (Raja, marriage, success, challenge). It clearly defines the tool's function and distinguishes it from future dedicated endpoints mentioned in the roadmap.
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 this is for basic checks and notes that dedicated endpoints will be added in Phase 2, implying use this for a simpler set. However, it does not explicitly compare with sibling tools like vedic_jaimini_argala_analysis or vedic_jaimini_yogas_jaimini_*.
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?
Annotations already indicate readOnly, non-destructive, and idempotent. The description adds value by specifying output details (sidereal longitude, KP chain, Placidus house) and providing an example request, enhancing transparency without contradicting annotations.
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 (two sentences plus example JSON), front-loads key output details, and includes a practical example. It avoids verbosity but could be slightly more detailed without losing 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 11 parameters and no output schema, the description is minimal. It does not explain the structure of the KP chain output, what planets are included, or how parameters like houseSystem or ayanamsaId affect results. The example only covers basic positional parameters, leaving significant gaps for effective tool usage.
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 description coverage is 0%. The description partially compensates by showing an example with date, time, timezoneOffset, latitude, longitude, but leaves many parameters unexplained (houseSystem, zodiacType, ayanamsaId, cosmogram). Agents must infer meaning from names or enums.
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 provides for each planet: sidereal longitude, KP chain (sign/star/sub/sub-sub), and Placidus house occupied. This specific verb+resource distinguishes it from siblings like vedic_kp_cusps (house cusps) and vedic_kp_sub_lords (sub-lords only).
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 'Convenience layout for KP analyses' and provides an example, implying use when detailed planet positions for KP are needed. However, it lacks explicit when-to-use or when-not-to-use directives compared to alternatives (e.g., vedic_kp_cusps for house cusps only).
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?
Annotations already indicate the tool is read-only and idempotent. The description adds that it scans for auspicious windows and mentions cost (50 credits). However, it does not describe the output format or any other behavioral traits beyond the annotations, which is a gap given the absence of an output schema.
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 the purpose front-loaded in the first sentence. It includes relevant details (nakshatras, avoid days, group, cost) and an example. No redundant information, though the example could be separated but is not detrimental.
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 has 7 parameters, no output schema, and a specialized domain, the description is incomplete. It lacks parameter explanations, output expectations, and behavioral details. The agent would need additional context to use the tool effectively, especially for parameters not in the example.
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 0% description coverage, so the description must compensate but only provides an example request body with some parameters. It does not explain the meaning of parameters like ayanamsaId or topN, nor the allowed values or constraints. The example gives format hints but lacks semantic depth.
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 as an auspicious-window scanner for major investments and financial commitments, listing examples like deposits, share/bond purchase, and lending. It includes specific nakshatras and days to avoid, and the title 'Investment/Dhana Sthapana' further distinguishes it from sibling muhurat tools for other activities.
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 use case ('major investments and financial commitments') and provides celestial guidelines (preferred nakshatras, avoid days). However, it does not explicitly state when not to use this tool or name alternative tools for other muhurat purposes, though the domain is clear from context and sibling tool names.
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?
Annotations already declare readOnlyHint true and destructiveHint false, so the description does not contradict them. It adds context about being a 'scanner' (read-only) and mentions cost and group. However, beyond stating it returns a scoring shape, there is no additional behavioral detail (e.g., response format, pagination). The description adds modest value but does not fully exploit the transparency gap.
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 concise, with no redundant sentences. It front-loads the core purpose, lists key nakshatras, references scoring shape, and includes group/cost metadata and an example. Every sentence adds value, and the structure is logical and efficient.
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 complexity (7 parameters, no output schema, Vedic domain), the description covers the essential purpose, preferences, and reference to marriage tool's scoring shape. However, it omits explanations for parameters like ayanamsaId and topN, and does not describe the output format. While the example helps, the description could be more complete for an agent to use confidently.
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 coverage is 0%, so the description must compensate but falls short. It provides an example request body showing parameters like search_window_start and latitude but does not explain their meaning, units, or constraints. Preferred nakshatras are output criteria, not input parameters. The description adds no semantic value for parameters like ayanamsaId or topN, which remain undefined.
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 an 'auspicious-window scanner for buying a new vehicle,' which is precise and specific. It lists preferred nakshatras and avoids, distinguishing it from other muhurat tools like vedic_muhurat_marriage. There are no sibling tools for vehicle purchase, so purpose is unambiguous.
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 guidance on preferred nakshatras and to avoid Sun/Sat, which informs when to use the tool. However, it does not explicitly state when to use this tool over alternatives like vedic_muhurat_general_auspicious or vedic_muhurat_marriage. The reference to 'same scoring shape as /vedic/muhurat/marriage' hints at similarity but lacks clear usage boundaries.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds cost (50 credits) and group (Vedic) but does not contradict annotations. It adds minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with key outputs, and includes an example. The extra lines for group and cost are useful but somewhat meta. Could be slightly tighter but overall well-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?
With 11 parameters, no output schema, and complex Vedic context, the description should explain input parameters and return format. It fails to describe what the response contains (e.g., types, structure). Incomplete for an AI agent to know what to expect.
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 coverage is 0% with 11 parameters. Description provides only a single example body (date, time, timezoneOffset, latitude, longitude) without explaining any parameter semantics. Missing explanation for 9 parameters including houseSystem, zodiacType, ayanamsaId, etc. Insufficient for correct usage.
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 lists all components returned (Tithi, Vara, etc.) and positions itself as the comprehensive single-call alternative to individual panchang tools. This clearly differentiates it from sibling tools like vedic_panchang_choghadia or vedic_panchang_rahu_kaal.
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?
States this is a 'single call' for complete panchang and provides an example request. However, it does not explicitly state when to use this versus individual panchang tools, leaving it implicit that this is the full version.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to repeat these. It adds no further behavioral context (e.g., what the output contains), but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two lines front-load the essential identity. Every word is purposeful, with meta tags (group, cost) as supplements.
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 common for chart tools: no mention of output structure (planets, houses, aspects). Since no output schema exists, description should compensate, but it does not. Minimal for an agent to understand what data will be returned.
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. Description adds an example request body but no additional semantic explanation beyond what the schema provides. 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?
Clearly states it is the sidereal natal sign chart (Rashi) and calls it the foundation of Vedic analysis, distinguishing it from other varga charts like D2, D3, etc. The title and description unambiguously identify the resource.
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?
Does not explicitly state when to use this tool versus alternatives (e.g., other varga charts). The term 'foundation' implies it is the starting point, but no direct comparison or exclusion criteria 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds the formula used (Parashara unequal-segments) and the thematic domain, but does not elaborate on output format, auth requirements, or rate limits beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise—three lines including the example request body. Every part adds value, though the example could be shortened. Front-loaded with key purpose and formula.
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?
Gives purpose and formula but lacks any guidance on output format (no output schema exists). For a chart tool, describing typical return structure would improve completeness. Adequate but not fully self-contained.
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 all 7 parameters described. The description provides an example request body but no additional parameter semantics 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?
Clearly states it is the Trimsamsa chart (Varga D30) for misfortunes/evils, using Parashara unequal-segments formula. Differentiates from other Varga charts by naming the specific sub-type and its area of interpretation.
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 usage for negative events (misfortunes, evils) but does not explicitly state when to use this vs. other divisional charts (e.g., D1, D9). No when-not-to-use or alternative comparisons 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds cost and group info, and that it runs all detectors. However, no details on output structure or rate limits, so transparency is adequate but not enhanced.
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 brief and includes group, cost, and an example. No unnecessary words, but could benefit from structured parameter guidance.
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?
Despite having 11 parameters and no output schema, the description does not explain parameters or output structure. It leaves critical gaps for an AI agent to use correctly without external knowledge.
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?
Input schema has 0% coverage (no descriptions for 11 parameters). Description only gives an example request without explaining any parameter meanings. Fails to compensate for missing schema documentation.
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 combined Parashara yoga report that runs all 6 detectors (Raja, Dhana, etc.) and returns one structured response. This distinguishes it from sibling tools like individual yoga reports.
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 use when all yogas are needed, but does not explicitly state when to use the individual tools instead. Sibling tools exist, so context suggests alternatives, but 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?
Annotations already indicate readOnly, destructive, idempotent hints. Description adds valuable behavioral context: detection rules (aspect types: 7th universal, Mars 4/8, Jupiter 5/9, Saturn 3/10), strict parivartana definition, and cost/group labels. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with a clear structure: purpose, conditions, group/cost, example. The group and cost lines could be moved to metadata, but they don't overly bloat the text. The example is helpful.
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 11 parameters and no output schema, the description lacks completeness. It does not explain required vs optional, parameter meanings, or what the tool returns. The example shows input but no response structure. Contextual completeness is low.
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?
Schema coverage is 0% and description provides no parameter explanations. 11 parameters (date, time, timezoneOffset, latitude, longitude, houseSystem, name, city, zodiacType, ayanamsaId, cosmogram) are unexplained. Only an example request body is given, which doesn't describe meaning or defaults.
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 defines the tool as detecting Raja Yoga per BPHS A.36-37, specifying three conditions (conjunction, mutual graha drishti with detailed aspects, strict parivartana). It distinguishes from sibling tools like vedic_yogas_jaimini_raja by specifying the Parashari source and criteria.
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 when to use: for Parashari Raja Yoga detection. It doesn't explicitly exclude alternatives, but the specificity of BPHS and the three conditions contrasts with similar tools in the sibling list (e.g., vedic_yogas_jaimini_raja). Some guidance on selection criteria would improve clarity.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the tool is safe and idempotent. The description adds that it calculates specific data (planets, houses, etc.) and includes cost info, but no further behavioral traits like rate limits or error handling. With good annotations, a 3 is appropriate.
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 concise: two sentences plus a group/cost tag and example. It is well-structured with the main action first, then output components, then metadata. No unnecessary words, and the example is helpful.
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 11 parameters and no output schema. The description lists output components but does not describe the return format or structure. Many optional parameters (e.g., zodiacType, ayanamsaId) are left unexplained. Given the complexity, the description is incomplete for full agent understanding.
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 description coverage is 0%, meaning the input schema lacks parameter descriptions. The description only provides an example request body, which shows usage for some parameters but does not explain others like houseSystem, zodiacType, ayanamsaId, or cosmogram. This forces the agent to infer meaning from parameter names alone, which is insufficient.
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 'Calculate a full natal chart: planets, house cusps, aspects, sect, and angular data for a given birth moment'. The verb 'Calculate' is specific and the resource 'natal chart' is distinct from sibling tools like 'composite' or 'synastry', 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 title 'Natal Chart' and group tag '[Group: Core]' strongly imply this is the primary tool for complete birth charts. However, the description does not explicitly guide when to use this tool over alternatives like 'planets', 'houses', or 'aspects', nor does it mention when not to use it. The example request partially compensates.
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?
Annotations already declare readOnlyHint true, destructiveHint false, idempotentHint true, so the description does not need to repeat those. It adds meaningful context that the index is based on outer planet separations and used for crisis periods. However, it does not detail behavior for invalid inputs, edge cases, or output format.
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: three lines including the purpose and an example. The group and cost metadata could be better placed but do not detract. Front-loading is effective. Every sentence adds value.
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 specialized index calculation, the description lacks details on what the output contains (no output schema), how to interpret the results, and any limitations. The example only shows input. The annotations already cover safety, but the description could be more complete.
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 coverage is 0%, so the description must compensate. It explains startYear and endYear through an example, but does not define them explicitly, and the optional 'pairs' parameter is completely unexplained. This leaves ambiguity for the agent.
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 calculates the André Barbault Cyclic Index for a date range to indicate global crisis periods. The verb 'calculate' and specific resource 'Cyclic Index' make the purpose unambiguous. The sibling tools are numerous but none perform this exact calculation, so it is well-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?
The description implies the tool is used when a global crisis indicator over a date range is needed, but it does not explicitly state when to use this tool versus alternatives like planetary_cycles or other index tools. No when-not or alternative 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds some behavioral context: cost (10 credits), group (Esoteric), and return types (pattern classification, exact match, reduced meaning). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences plus metadata) and front-loaded with purpose. The example is placed after metadata, which is acceptable. Every sentence adds value, though the metadata line could be considered separate.
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 low complexity (1 parameter, no output schema), the description provides enough information for invocation: what goes in (sequence, optional context) and what comes out (pattern classification, exact match, reduced meaning). The example further clarifies usage.
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 only parameter ‘body’ is a raw JSON object with minimal schema. The description compensates by providing an example request body: {'sequence':'1234','context':'saw on receipt during career change'}, which clarifies required fields and usage. Without the example, the schema alone would be ambiguous.
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 verb 'Decode' and the resource 'a numeric sequence' (angel number), with optional 'life context'. It specifies outputs: pattern classification, exact match, and reduced single-digit meaning. This distinguishes it from sibling tools like esoteric_dreams_decode and various numerology 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?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., other decode tools or numerology tools). There is no mention of use cases, prerequisites, or when not to use it. The agent must infer from the title and description 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?
Annotations already indicate read-only, non-destructive, idempotent. The description adds cost (100 credits, Tier 4) and group (Prognostics), which are useful beyond annotations, but no details on result size, pagination, or computational 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?
Description is three sentences plus group/cost and an example. No wasted words, front-loaded with the core 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?
No output schema exists, and the description only vaguely mentions 'combined forecast calendar' without detailing the return structure, fields, or event ordering. Adequate but incomplete for full context.
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%. The description explains the 'natal' object with required fields and defaults, and provides an example request body. However, it does not elaborate on optional fields like 'zodiacType' or 'ayanamsaId'.
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 a combined forecast calendar including transits, lunar phases, ingresses, and retrograde stations. It distinguishes from sibling tools like transit_calendar or ingresses by being combined and covering multiple event types.
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 (e.g., transit_calendar, ingresses). The description only mentions 'for a given period' without specifying context or 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?
Annotations already indicate read-only, idempotent, and non-destructive behavior, providing safety guarantees. The description adds valuable context: it operates on a horary chart, lists aspects only until the Moon leaves its sign, and mentions a cost of 20 credits. This complements the annotations well without contradiction.
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, using just two sentences plus a group tag, cost line, and example. Every word adds value, and the key purpose is front-loaded. No redundant or unnecessary 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?
The description is incomplete given the tool's complexity: 11 parameters, no output schema, and horary-specific context. It lacks descriptions for most parameters, does not explain the return format or how 'aspects' are defined, and does not guide the agent on how to set up a horary chart. The example helps but is insufficient.
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 description includes an example request body with 5 parameters (date, time, timezoneOffset, latitude, longitude), which is helpful for understanding typical usage. However, with 11 total parameters and 0% schema description coverage, the description fails to explain the remaining 6 parameters (houseSystem, name, city, zodiacType, ayanamsaId, cosmogram). This is a significant gap.
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: listing all aspects the Moon makes in a horary chart before leaving its sign. It includes a specific verb (List), resource (aspects), and scope (horary chart, before sign change), and distinguishes it as the key timing tool in horary, differentiating it from siblings like 'moon_aspects' and 'horary_moon_voc'.
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 by calling it the key timing tool in horary, implying use for timing in horary charts. However, it does not explicitly state when not to use it or mention alternatives like 'moon_aspects' for general moon aspects or 'horary_moon_voc' for void of course moon. More explicit guidance would improve clarity.
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?
Annotations already indicate read-only, idempotent, non-destructive. The description adds context about the return value (planetary hour ruler and match check) and provides an example request, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with two sentences plus a group/cost note and example. It is front-loaded with the key action, though the example could be better integrated into parameter descriptions.
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 and parameter descriptions, the tool description leaves gaps in understanding the output structure and the exact matching logic. The annotations partially fill safety context, but completeness is adequate for a simple tool.
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 description coverage is 0%, and the description does not explain individual parameters. Only an example request body is provided, which gives format clues but lacks semantic meaning for each parameter (e.g., latitude, longitude, timezoneOffset).
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 returns the planetary hour ruler and checks if it matches the ASC ruler, specifically for a horary question. This distinguishes it from siblings like 'planetary_hours' and other horary 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 use for horary questions but does not explicitly guide when to use this tool over alternatives like 'planetary_hours' or 'horary'. No exclusion or alternative mentions.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the key behavioral trait 'Deterministic', which is not covered by annotations. However, it omits details about the output format (e.g., whether it returns a hexagram text, lines, or binary), which is a gap given no output schema exists.
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 with two sentences plus a group tag and example. The first sentence immediately states the core purpose. Every element is functional with no wasted words.
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 parameter, deterministic), the description is mostly adequate but lacks clarity on the return value. With no output schema, it should at least mention the structure of a hexagram or what the response contains. The group tag helps organizational context but does not compensate for missing behavioral details.
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 defines one required parameter 'question' with type and length constraints but no description (0% coverage). The description provides an example request body {"question":"..."} which clarifies the parameter name and JSON format, but adds no additional meaning about the question's purpose or constraints beyond the schema. This is adequate but not exceptional.
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 'Deterministic hexagram from question text', specifying the verb (generates), the resource (hexagram), and the input (question text). It distinguishes itself from siblings like iching_throw_coins (random) and iching_with_changing_lines by highlighting determinism, and the group tag 'I Ching (Standalone)' further clarifies scope.
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 deterministic readings via the term 'Deterministic', but does not explicitly state when to use this tool versus alternatives like iching_throw_coins (random) or iching_daily. No exclusions or context are provided, leaving the agent to infer intent from the tool name and description 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's characterization as an 'AI interpretation' is consistent but adds minimal behavioral insight beyond the cost and group. The description does not disclose additional traits like typical response time or data persistence.
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 concise and well-structured: begins with the core purpose, then groups meta-info (group and cost), and ends with an example. Every sentence adds value without redundancy.
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 lacks explanation of what the AI interpretation output contains or its format, especially since no output schema is provided. It also does not clarify differences from sibling interpretation tools like interpret_natal or interpret_transits, though the group label partially helps. The example input is helpful but the absence of output details limits 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing a concrete example request body that illustrates how to structure the required chart1 and chart2 parameters with realistic values, going beyond the schema's field-level 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 the tool provides an AI interpretation of synastry between two charts, covering relationship dynamics, attractions, friction points, and long-term outlook. It distinguishes from sibling tools like 'synastry' (raw data) by explicitly labeling it as 'AI interpretation' and grouping it under 'AI Interpretations'.
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 (e.g., synastry, composite, interpret_natal). The description lacks when-not-to-use conditions or mentions of other tools that might be better suited for specific needs.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds group and cost info (100 credits, Tier 4) which is helpful but not critical. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 lines plus example), front-loaded with purpose, and 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the calendar components but lacks details on output format or structure. Since there is no output schema, the description should at least hint at what the response contains (e.g., array of days, object with phases). This gap lowers completeness for a moderately complex 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?
With 0% schema description coverage, the description provides an example request body clarifying numeric format. However, it does not explain valid ranges (e.g., year limits, month 1-12) or handling of null values 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 calculates a lunar calendar for a given month and lists specific components (Moon sign per day, lunar phases, void-of-course windows, perigee/apogee). This is a specific verb+resource and distinguishes from siblings like moon_phase or moon_voc that focus on single 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 implies usage for monthly lunar calculations but does not explicitly state when to use this tool versus alternatives like eclipse_analysis or transit_calendar. No exclusions or when-not guidance 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds return structure but no further behavioral traits. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: 3 sentences plus group and example. Front-loaded with purpose. Every element serves a 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?
Adequate for a simple tool with good annotations, but lacks guidance on selecting this among many Mayan siblings and does not explain return format details beyond listing components.
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 description need not add much. It provides an example with date but no additional meaning for latitude, longitude, or timezoneOffset.
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 returns 'kin (1-260) + tone + seal' and distinguishes it as a reinterpretation by Argüelles, distinct from traditional Tzolkin.
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 notes it is distinct from traditional Tzolkin but does not explicitly guide when to use this tool over siblings like mayan_tzolkin or mayan_full. No alternatives are named.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the list of returned components and an example, but does not disclose additional behavioral traits such as prerequisites 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, a group tag, and an example. It is front-loaded but could include a bit more structure for completeness.
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 is a combined call returning multiple components, the description lists what is returned. Without an output schema, this is adequate. However, it could clarify when optional parameters (latitude, etc.) are needed.
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%, meaning all parameter descriptions exist in the schema. The description only provides an example with the 'date' parameter and does not add meaning for latitude, longitude, or timezoneOffset 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 that the tool returns 'all four classical components in one call: Long Count + Tzolkin + Haab + Calendar Round + Lord of the Night.' This clearly identifies the tool's purpose and distinguishes it from sibling tools that return individual components.
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 does not provide explicit when-to-use or when-not-to-use guidance. While the sibling tool names imply alternatives for individual components, no direct exclusions or contexts 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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining the Wayeb period detection. However, it does not clarify how optional parameters (latitude, longitude, timezoneOffset) affect 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 concise with two clear sentences, a group tag, and an example. It is well-structured and front-loaded with key information.
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?
The description explains the calendar structure and the key feature (Wayeb detection). It is mostly complete, though it could clarify what the tool returns (e.g., a date string or boolean).
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 all parameters. The description provides an example but no additional meaning beyond what the schema offers.
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 converts a date to the Haab civil day and identifies if it falls in the Wayeb period. It distinguishes from sibling Mayan tools like mayan_tzolkin and mayan_long_count by specifying the Haab calendar 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 does not explicitly state when to use this tool versus alternative Mayan tools. The group label 'Mayan Calendars' implies context, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds group and example but no additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus group label and example request body. Every element is relevant and efficiently presented.
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 exists, but description does not mention return format or values. For a 7-parameter tool with 2 required, it adequately covers purpose and required inputs but lacks output details.
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?
100% schema coverage; description mentions 'optional gender filter' and shows an example, but does not add meaning beyond what the schema already provides for each 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?
Description states specific verb+resource: 'Sign-aligned name suggestions' with optional gender filter. Differentiates from siblings like pet_birth_chart or pet_communication_style.
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?
Group hint '[Group: Pet Astrology]' and example request provide context for use, but no explicit when-to-use or when-not-to-use guidance or 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?
Annotations already mark the tool as read-only and idempotent. The description adds layout context but fails to disclose that the output can be SVG or JSON (despite the format option in schema). Behavioral traits beyond annotations are minimal; no mention of output format or limitations.
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 self-contained example. No filler tokens, front-loaded with the core purpose. The structure is clean and efficient.
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 complexity (single natal chart, many options, siblings), the description is incomplete. It lacks mention that the output format is configurable (SVG/JSON) and does not specify that it's for a single chart (not synastry). The vague 'standard textbook layout' may not be universally understood.
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% description coverage for parameters, explaining required fields and defaults. The description adds an example request body, which helps clarify usage. However, it does not elaborate 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 produces a 'triangular aspect matrix' with rows/columns for planets and aspect glyph+orb, using 'standard textbook layout'. It distinctly explains the visual output and distinguishes it from other aspect tools like 'aspects' or 'aspect_bar'.
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 over siblings such as 'aspect_bar' or 'synastry_aspect_grid'. It lacks explicit when-to-use or when-not-to-use instructions, leaving the agent guessing context.
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?
Annotations already state readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds 'Pure server-side, no browser needed' which is minor additional context. Does not contradict annotations. No discussion of performance or side effects beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly efficient: two sentences, one group label, one example. Every element adds value. Front-loaded with core 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 complex nested schema and no output schema, description could detail output format (SVG vs JSON) or visual characteristics. Example shows format option but doesn't explain what the SVG contains beyond the initial list. 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 coverage is 100%, and schema includes descriptions. Description provides a full example request body showing common parameters, which helps clarify usage. However, no additional semantic details 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?
Clear verb 'Render' and specific resource 'Western natal wheel as SVG'. Names components (signs ring, houses ring, planets, aspect lines). Distinguishes from sibling render tools like render_wheel_vedic_east by explicit 'Western' in name and title.
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 compared to alternatives. The name and group 'Visualization' imply use for Western charts, but no contrast with other wheel renderers. Missing guidance on choosing between this and other visualization tools.
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?
Annotations include readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds cost (250 credits) and a heavy-use warning with explicit instruction to confirm with user, which is valuable behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus cost note) and front-loaded with purpose. Minimal but effective; no redundant information. Slightly more structure could help readability, but overall it is 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 and many sibling AI reports, the description adequately explains the scope (single-month) and key differentiator (vs year-ahead), but doesn't detail return values, prerequisites, or compare to other monthly forecasts. It is minimally complete for a forecast tool.
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 description coverage is only 17% (chart has a description). The description merely lists parameter names (chart, year, month, language, tone, length) without adding meaning or constraints beyond what enums and schema already provide. It does not compensate for the low 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 'Single-month forecast' with explicit differentiation from 'year-ahead' (sibling reports_ai_year_ahead_narrative) and specifies it uses planet transits. The verb 'forecast' and resource 'monthly narrative' are precise, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It contrasts with year-ahead implicitly, but does not provide explicit when-to-use/when-not-to-use advice or compare to other monthly tools like horoscope_monthly. The cost warning and 'confirm with user' are usage prompts, but lack broader 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which are not contradicted by the description. The description adds useful context (group, cost) and states it returns a chart, but does not detail additional behaviors like data dependency on accurate birth time. It adds some value beyond annotations but not extensively.
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: two sentences of core purpose followed by meta-info (group, cost) and a helpful example. Every sentence adds value, and the structure is front-loaded with the main action. No unnecessary words.
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 relatively simple but lacks an output schema. The description says 'Returns full solar return chart' but does not specify the format or key fields of the output. The example shows input but not output. Given complexity and lack of output schema, the description could be more complete about what the chart contains.
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, so baseline is 3. The tool description provides an example request body that illustrates typical parameter values, which adds some practical guidance. However, it does not explain the meaning of 'year' or other fields beyond what the schema already includes.
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 specific function: finding the exact moment of the Sun's return to its natal longitude for a given year and returning the full solar return chart. The verb 'Find' and noun phrase 'solar return chart' are precise and distinguish it from sibling tools like lunar_return or planetary_return.
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 annual solar return calculations but does not explicitly state when to use this tool versus alternatives. The group 'Prognostics' and cost provide context, but no direct guidance on excluding other return tools or prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the card is 'based on date seed,' implying determinism and idempotency, which aligns with annotations. It provides context about the deterministic nature beyond the structured annotations.
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 very short—one sentence plus a group tag and an example. It is front-loaded with the core purpose. No extraneous information. However, it could be slightly more structured (e.g., separating the group tag into a separate line for clarity), but it is 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?
Despite low complexity, the description fails to explain what the tool returns (e.g., card name, image, meaning). No output schema exists. The agent must infer the return value from the tool name and group. This omission reduces completeness for an otherwise 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?
The input schema has 100% description coverage, so the schema itself clearly documents all four parameters. The description only mentions the 'date' parameter in the example, adding no new meaning beyond the schema. Baseline 3 is appropriate 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 provides a 'Daily Marseille card based on date seed,' specifying both the deck (Marseille) and the variant (daily card). The title reinforces this. This verb+resource combination is distinct from sibling tools like tarot_marseille_draw_celtic_cross or tarot_rider_waite_daily.
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 includes a '[Group: Tarot — Marseille]' tag and an example request, but it does not explicitly state when to use this tool over other tarot draws (e.g., when a simple daily draw is needed vs. a complex spread). Usage is implied by the tool name and group, but no alternatives or exclusions 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds the spread structure (three-card, past/present/future) and an example input, but does not explain behavior like reversals or seed determinism beyond the example. Some behavioral context is provided, but not comprehensive.
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: one line for spread purpose, one line for group, and one JSON example. Every sentence provides value without redundancy.
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 (three-card draw with no output schema), the description covers the spread type and input example. However, it does not describe the output format (e.g., three cards, interpretations) or the role of the seed parameter in randomness. Annotations cover safety, so overall completeness is adequate but not excellent.
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 (single body parameter described), and the description gives a concrete example showing expected fields (seed, question, allowReversed). This adds meaning beyond the schema's generic description, helping the agent understand the required structure.
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 'Past / Present / Future three-card spread' with the group 'Tarot — Marseille', which distinguishes it from sibling tools like tarot_rider_waite_draw_three_card or tarot_lenormand_draw_three_card. The verb 'draw' is implied by the spread name, and the resource is explicit.
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 an example question ('What should I focus on?') but does not explicitly state when to use this tool versus alternative tarot spreads (e.g., single card, Celtic cross). No guidance on exclusions or prerequisites 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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description only adds that it returns a single card, but does not explain the response format or additional behavioral traits such as how the card is selected or what parameters influence 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 very concise with no wasted words, immediately stating the function and providing an example. However, it could be slightly more informative without becoming verbose, such as hinting at the output.
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 and the description omits any mention of the response structure or how to interpret the returned card. Given the simplicity of the tool, this lack of return value information leaves the agent under-informed.
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 defines a generic 'body' object with no internal schema, but the description provides a concrete example with seed, question, and allowReversed, which compensates for the schema's lack of detail and guides the agent on required fields.
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 provides a 'single clarifying card after a primary draw', using a specific verb and resource. This distinguishes it from sibling tools that perform primary draws or other tarot operations.
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 phrase 'after a primary draw' implies sequential usage, providing clear context. However, it does not explicitly state when to use this tool over alternatives like tarot_marseille_clarify or give 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds an example request body but no further behavioral traits like auth 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line plus a group annotation and an example. Every element is necessary 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?
Adequate for a simple tool with one param and good annotations, but lacks explanation of the spread concept or result interpretation. More context could help disambiguate among many tarot siblings.
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 only describes 'body' as raw JSON, but the description provides a concrete example with seed, question, and allowReversed, adding meaningful structure beyond the schema. However, the exact required fields are inferred.
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's a '5-card spiritual development spread' for the Rider-Waite-Smith tarot. This specific verb and resource differentiate it from many sibling tools like tarot_rider_waite_draw_career or tarot_rider_waite_draw_love.
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 spread versus alternatives. The name implies spiritual development, but lacks a 'when to use' or 'when not to use' clause, nor does it mention alternative spreads.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe and read-only. The description adds 'Returns applying and separating aspects', which is useful but doesn't detail side effects, permissions, or data volume. With annotations covering safety, the description adds modest value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core function. The example and cost note are useful but could be considered extraneous. However, the example adds value for complex input, and the grouping helps context. No redundant sentences, but the description could be more streamlined.
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 (nested objects, many parameters) and the presence of a detailed input schema with descriptions, the description is sufficient for an agent to understand the tool's purpose and use. The absence of an output schema is mitigated by the statement of what is returned ('aspects'). However, more detail on the aspect structure (e.g., orb, type) 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?
Schema coverage is 100% and includes descriptions for each parameter (e.g., birth data defaults, required fields). The description adds the example request body, which helps illustrate structure but doesn't explain semantics beyond what the schema provides. Baseline of 3 is appropriate as schema does most of the work.
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 'Calculate transit planet aspects to natal planets for a given date' with a specific verb ('Calculate') and resource ('transit planet aspects to natal planets'). It also specifies outputs ('applying and separating aspects'), making the tool's function unambiguous and distinct from siblings like 'aspects' which is general, or 'transit_calendar' which likely lists transits over time.
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 calculating transit aspects for a given date but does not explicitly state when to use this versus alternatives like 'transit_calendar' or 'aspects'. No when-not or exclusion criteria are provided, though the example helps users understand required input format. Lack of guidance on when not to use it (e.g., if only applying aspects needed) reduces clarity.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context beyond annotations (cycle length, planet sequence, tradition) without contradiction. No disclosure of side effects or permissions is needed given readOnlyHint, so the description augments understanding of what the tool computes.
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 (two sentences plus an example). It includes technical details (sequence, distribution) that may be dense but are relevant. The example is helpful. Could be slightly more organized, but no wasted words.
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 tool returns (e.g., dasha periods, dates, sub-periods). Given the complex input schema and many sibling tools, the missing output explanation leaves the agent guessing about the result structure. The description focuses on the system's parameters but omits the output format.
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 100% coverage with descriptions for all properties. The description provides an example request body and notes that lat/lon/tz default to 0, urging real values for accuracy. This adds practical value beyond the schema alone, though the schema already documents required fields and defaults.
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 'Shodashottari Dasha — 116-year nakshatra dasha cycle' with specific details (BPHS Adhyaya 46, 8 planets, seed nakshatra Pushya, sequence, distribution, tradition). It distinguishes itself from the many sibling dasha tools (vimshottari, ashtottari, etc.) by naming the system and its unique parameters.
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 mentions 'Per AmatyaKaraka tradition: applicable when lagna in Chandra hora during Krishna paksha …' but this is a condition for the dasha system itself, not a directive for the AI agent to choose this over sibling dasha tools. Siblings like vedic_dashas_vimshottari_maha are not referenced, so the agent lacks context to differentiate.
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?
Annotations (readOnlyHint=true, idempotentHint=true) already indicate read-only behavior. The description adds value by detailing the seed calculation, period duration, and sub-period options, disclosing computational behavior beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and technical but ends abruptly with 'forward from…' which is incomplete. This lack of completeness harms conciseness and clarity. A more structured format (e.g., bullet points) would improve 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?
The tool is complex with multiple parameters and no output schema. The incomplete description fails to explain what the tool returns (e.g., list of mahadasha periods). The annotations are good, but the missing output info and truncated description leave gaps for an AI agent.
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 provides descriptions for all parameters (100% coverage), but the tool description adds significant meaning: it explains the default for 'houseIndex', how the seed is computed, and what each 'antardasaSeedOption' value does. This goes beyond the schema's enum constraints.
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 names the tool as 'Shoola Dasha — Jaimini Trident rasi-dasha' and specifies the seed selection, period length (12 signs forward, 9 years each), and sub-period options. This distinguishes it from sibling tools like 'vedic_dashas_shoola_antar' which handle sub-periods.
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 explains the mechanics but does not explicitly state when to choose this tool over alternatives (e.g., other dasha systems or other shoola levels). Usage context is implied by the name and technical details, but no direct guidance is given.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description adds value by specifying group '[Group: Vedic]', cost '50 credits (Tier 3)', and providing an example request body. These details help the agent understand resource usage and required input format beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 3 sentences plus an example. It front-loads the primary purpose and group/cost info, avoiding redundancy. However, the example is somewhat verbose and could be streamlined. Overall, it is well-structured but could be more compact.
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 11 parameters and no output schema, the description should clarify expected return values or result interpretation. It does not describe what the report contains beyond listing dosha names. The example only covers input. For a combined report, more completeness around output would benefit the agent.
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 coverage is 0%, meaning no parameter descriptions exist. The description only provides an example request with date, time, timezoneOffset, latitude, longitude, leaving the other 7 parameters (houseSystem, name, city, etc.) unexplained. This insufficiently compensates for the lack of schema descriptions, as parameters like ayanamsaId or zodiacType remain unclear.
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 runs a combined Parashara dosha report with all 6 detectors, distinguishing it from individual sibling tools like vedic_doshas_parashara_mangal or vedic_doshas_parashara_kaal_sarp. The verb 'runs' and resource '6 detectors' are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a comprehensive dosha report but provides no explicit guidance on when to prefer this over individual detectors or when not to use it. Without 'when to use vs. alternatives', the agent must infer from the 'combined' nature alone. This is adequate but leaves room for misuse if a single dosha is needed.
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?
Annotations indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing the output: subtypes by Rahu house and a partial flag when 6 of 7 grahas are on one side. This provides behavioral context beyond annotations, though it does not cover all possible 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the key definition and output details. It includes cost and an example, with no extraneous words. Minor improvement could be structuring the subtypes as a list, but overall efficient.
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 11 parameters and no output schema, the description covers the main output (subtypes and partial flag) but omits descriptions of optional parameters and their effects. The example helps but is incomplete for a full understanding.
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 description coverage is 0%, so the description is the only source of parameter meaning. It provides an example request body but does not explain individual parameters like houseSystem, name, city, etc. This is insufficient compensation for the lack of 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 defines the tool as computing Kaal Sarp Dosha, specifying the condition (all 7 grahas on one side of Rahu-Ketu axis) and listing the 12 sub-types. It differentiates from sibling tools by focusing on a specific dosha from Parashara tradition.
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 does not explicitly state when to use this tool versus alternatives, but the name and context imply it is for Kaal Sarp Dosha analysis. No comparative guidance is provided, which is adequate but not explicit for an agent.
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?
Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, confirming it's a safe query. The description adds behavioral details: it follows BPHS rules for dosha detection and applies sign-based cancellations. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key information but becomes truncated, listing cancellations without complete sentences. It is somewhat verbose with specific details but could be more concise and complete.
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 clarify the return format or what the detection result includes. It only mentions detection and cancellations, omitting details about the output structure, severity levels, or additional data. The truncation further reduces completeness.
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 coverage is 0%, so the description must compensate. It only explains the 'school' parameter in detail, leaving 10 other parameters (date, time, timezoneOffset, etc.) undocumented. These are standard chart inputs but the description fails to add meaning beyond the schema's basic type/default 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 clearly states the tool is for 'Mangal Dosha detection' with explicit school selection options (strict, north, south) and mentions canonical cancellations. It distinguishes itself from sibling dosha tools by focusing specifically on Mangal Dosha with Parashara 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 explains when to use this tool (for Mangal Dosha detection) and how to select the school via the 'school' parameter. It does not explicitly state when not to use or list alternatives, but the context of sibling tools like vedic_doshas_kp_manglik implies differentiation.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds that it uses the same algorithm as /karakas but focuses on AK/DK, which is minimal behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences followed by an example and a group tag. It is front-loaded and every sentence adds 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?
Given 11 parameters, no output schema, and 0% schema description coverage, the description is insufficient. It lacks explanation of what chara karakas are, what AK/DK means, and what the output looks like.
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 description coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain any of the 11 parameters; it only provides an example request body. This fails to add meaning for the 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 provides a 'Detailed chara karaka ranking with Atmakaraka/Darakaraka highlighted' and specifies it has the same algorithm as a sibling tool but with focused output. This distinguishes it effectively.
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 AK/DK-driven analyses and references the sibling tool vedic_jaimini_karakas for the full ranking. It provides clear context but does not explicitly state when not to use it or list alternatives.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds specific calculation details (1/7-trim rule per BPHS Adhyaya 26 verse 4), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example; no fluff. The example is useful but not essential. Could be slightly more concise without example, but still efficient.
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?
Adequate for a calculation tool: lists outputs and a rule reference. However, missing output structure description (no output schema) and parameter semantics leaves gaps for an agent unfamiliar with Vedic astrology.
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?
With 0% schema description coverage for 11 parameters, the description provides no parameter explanations beyond an example request. It fails to describe optional fields like houseSystem, zodiacType, ayanamsaId, or cosmogram.
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 lists all canonical Arudhas (A1..A12, S1..S12, M1..M12, Graha Arudhas) with specific naming, distinguishing it from sibling Jaimini tools like argala analysis or karakas.
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 direct comparison with alternatives or when-not-to-use. The [Group: Vedic] hints at context, but no exclusions or sibling differentiation 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?
Annotations already declare read-only and idempotent. The description adds the cost (20 credits) but no further behavioral traits. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, no fluff, includes group and cost info. Front-loads the core 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 the large number of sibling tools (many vedic_varga_D*), the description lacks details about output format or how this varga relates to others. Minimal context for selection.
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 all 7 parameters comprehensively (100% coverage). The description does not add any additional semantic value beyond what is 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?
Clearly states it's the Navamsa chart and identifies it as the most important divisional chart, with keywords 'spouse, dharma'. This distinguishes it from other vedic_varga 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?
Implies usage for marital and dharma analysis but provides no explicit guidance on when to use this varga over others among the many siblings.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is clear. The description adds the system (traditional Melothesia) and output components, but does not disclose any additional behavioral traits such as response format or limitations.
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 and an example. Every sentence adds value without redundancy.
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 exists, so the description partially compensates by stating what is returned (primary, secondary, vulnerabilities). However, it does not describe the structure or format of the output, leaving some ambiguity. Overall adequate for a simple list 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 description coverage is 100%, so the input schema already documents all parameters. The description provides an example request body but adds no extra meaning beyond the schema. 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 that the tool returns body parts ruled by sun-sign based on traditional Melothesia, from head to toe, and lists the output components (primary, secondary, vulnerabilities). This distinguishes it from other wellness tools like wellness_diet or wellness_exercise.
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 medical astrology body rulership but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: returns names (English/pinyin/Chinese), themes, and rules. Annotations already indicate read-only, non-destructive, idempotent behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (two sentences plus group label and example). It is front-loaded and efficient, though it could be slightly more 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?
No output schema exists, but description covers what is returned (names, themes, rules). Given the tool is a simple listing and annotations cover safety, it is fairly complete. Could clarify that response is a list of all 12 palaces.
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 fully documented. The description provides an example request body but adds no extra semantic meaning for parameters like latitude, longitude, or timezoneOffset.
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 provides all 12 palaces with names, themes, and rules. This is specific and distinguishes it from siblings that focus on individual palaces (e.g., ziwei_palace_career).
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 the many related siblings (e.g., ziwei_full_chart, ziwei_main_stars). No exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive nature. Description adds that it calculates bindus and a table, includes group and cost metadata, and provides an example request body. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one functional sentence, two lines of metadata, and an example. No redundant information. Well 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 complexity of Ashtakavarga and 11 parameters with no output schema, the description provides only basic function and an example. It lacks detail on output format and explanation of all parameters, leaving the agent with incomplete context for 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 description coverage is 0%, so description must compensate. It provides an example with date, time, timezoneOffset, latitude, longitude but does not explain other parameters like houseSystem, zodiacType, ayanamsaId, etc. Even the example lacks explanation for many optional 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?
Description clearly states the tool calculates the Ashtakavarga benefic point table with individual bindus and total Sarvashtakavarga for a Vedic chart. It uses specific verb 'calculate' and resource 'Ashtakavarga benefic point table', and no sibling tool has 'ashtakavarga' in name, distinguishing it effectively.
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 calculating Ashtakavarga in a Vedic chart but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned. Usage is implied by the tool's specificity.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety is clear. The description adds value by specifying the exact outputs (element, polarity, archetype) beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two clear sentences and an example. It is front-loaded with the most important information (output contents and purpose) and includes a group label. No unnecessary words.
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 tool with no output schema, the description adequately explains what the output contains (element, polarity, archetype) and its conceptual role. However, it could be more complete by detailing the exact structure of the response for this 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?
Schema coverage is 100%, so baseline is 3. The description provides an example request body with date, which adds some context, but does not elaborate on parameter meanings or formats beyond what the schema already states.
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 returns the day stem element, yin/yang polarity, and canonical archetype, identifying it as the 'self' character in BaZi. This is specific and distinguishes it from sibling BaZi tools that return other pillars or full charts.
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 other BaZi tools. The description implies its role as the core reference for interpreting other pillars but does not provide clear usage context or exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it works with only year and month pillars (4 of 8 characters), which is a behavioral constraint not in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, group context, example. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameters and basic output (dominant/missing elements) but lacks output format details. For a simple tool with good schema/annotations, this is adequate but could be more explicit about return 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% with descriptions for all 4 parameters. The description adds no further parameter meaning beyond the example. 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 counts elements from year and month pillars (4 of 8 characters) and identifies dominant plus missing elements. This is specific and distinct from siblings like bazi_four_pillars or bazi_day_master.
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 bazi_four_pillars or bazi_year_pillar. The description only notes it belongs to the BaZi group and provides an example, but no conditions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering behavioral traits. Description adds that it returns sun/moon/ASC + theme, which is useful but does not contradict or significantly expand beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example. Purpose is front-loaded, and every element adds value without redundancy.
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?
The description mentions return values (sun/moon/ASC + theme) and includes an example. With no output schema, this is fairly complete, though it could note house system parameter or coordinate accuracy.
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 well-described parameters. The description provides an example request but does not add meaning beyond the schema. Baseline 3 is appropriate since schema already explains 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?
Description clearly states the tool treats a founding date as a chart and returns sun/moon/ASC + theme. It is distinct from siblings like business_electional_day and business_founder_personality, providing a specific verb and resource.
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 business founding chart interpretation via the 'Business Astrology' group, but does not explicitly state when to use or when not to use, nor does it compare with alternative siblings.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about output format (computed layout coordinates), which is useful beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement, group and cost note, and an example. The structure is front-loaded and efficient, though the example could be integrated better.
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?
Despite 11 parameters and no output schema, the description only gives a brief purpose and an example. It lacks details on output format, what disposition chains are, and how layout coordinates are computed. This is insufficient for an agent to fully anticipate the tool's behavior.
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 coverage is 0%, and the description does not explain the parameters individually. The example request body provides an indirect hint but lacks systematic documentation. With 11 parameters, the description fails to compensate for the schema's lack of 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 the tool returns disposition chains with computed x/y layout coordinates for graph visualization. It uses specific verbs and resources, and distinguishes from similar tools like 'disposition_chains' by emphasizing layout computation.
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?
An example request is provided, showing typical usage. However, it does not explicitly state when to use this tool versus alternatives like 'disposition_chains', nor does it list exclusion criteria or prerequisites.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true; the description adds useful context about the output content (cross name, type, theme) and cost, which complements annotations without contradicting them.
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 sentences plus group/cost and a single example — concise, front-loaded with core purpose, no unnecessary words.
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?
Despite having 11 parameters, no output schema, and many sibling tools, the description only covers output content and one example. It lacks explanations for most parameters and does not differentiate from other HD tools, making it incomplete for an agent to fully understand 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?
With 0% schema coverage, the description provides an example request body that clarifies usage of required parameters (date, time) and some optional ones (timezoneOffset, lat, lon), but does not explain other parameters like houseSystem, zodiacType, or cosmogram, leaving gaps.
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 'Return the Incarnation Cross' from birth data or gate numbers, and specifies output includes cross name, type, and theme. This verb+resource combination is specific and distinct from sibling HD 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?
Mentions two input modes (birth data or gate numbers) but provides no guidance on when to use this tool versus other Human Design tools like hd_circuitry or human_design. No alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent behavior. The description adds value by disclosing the auto-fallback warning for extreme latitudes, a behavioral trait not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads key information (outputs, systems), and includes group/cost metadata. However, it could be more structured with bullet points 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?
Without an output schema, the description lists expected outputs (cusps, ascendant, etc.). It also covers supported systems and edge-case behavior, making it reasonably complete for a standalone calculation 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 descriptions for all 7 parameters. The description provides an example request body that illustrates how to use the parameters, adding practical 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?
Description clearly states it calculates house cusps and lists outputs. However, it does not explicitly differentiate from siblings like 'chart' which also includes house data, but the standalone nature is implied.
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 a usage hint about auto-fallback for high latitudes, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'chart' or 'vedic_kp_cusps'). The context is implied but could be clearer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by detailing what the tool calculates (centers, channels, gates), which is beyond the annotations and clarifies the non-destructive, read-only nature.
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 concise with two sentences plus a group/cost line and example. It front-loads the primary purpose and output components without unnecessary detail.
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?
While the description lists output components, it lacks explanation for the 11 input parameters and return format. Given the complexity and absence of output schema, more detail on parameter semantics and output structure would improve completeness.
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?
With schema description coverage at 0%, the description should compensate but only provides an example request body covering 5 of 11 parameters. It does not explain the purpose of parameters like houseSystem, zodiacType, ayanamsaId, or cosmogram, leaving gaps.
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 calculates a full Human Design BodyGraph chart and lists specific components (type, strategy, authority, etc.), distinguishing it from siblings like human_design_compatibility and human_design_transits.
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 does not explicitly state when to use this tool versus alternatives. It implies single chart calculation but provides no when-not or alternative guidance, leaving it to context inference.
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?
Annotations already declare readOnly, non-destructive, and idempotent. The description adds that it returns a 'full lunar return chart,' which is useful but not extensive. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The group and cost metadata are useful but add slight clutter. Overall efficient.
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?
Without an output schema, 'Returns full lunar return chart' is vague. The agent knows it returns a chart but not its structure or content. For a complex astrological computation, more detail would improve 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?
Schema description covers birth data well with defaults and completeness. The example request body demonstrates how to specify both natal and after parameters, adding practical 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?
The description clearly states it finds the next lunar return date and returns a full lunar return chart. The verb 'Find' and resource 'Moon returning to natal longitude' are specific and unambiguous, distinguishing it from solar or other planetary returns.
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 'solar_return' or 'planetary_return'. The description does not provide any context for selection 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds no further behavioral context beyond the expected calculation, which aligns 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences plus an example, front-loaded with key information, no wasted words.
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?
Description explains what the tool calculates and the system, includes an example. However, without an output schema, it does not describe the return value format, which is a minor 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 has 100% description coverage for its 4 parameters (date, latitude, longitude, timezoneOffset). Description does not add extra meaning beyond the schema and example usage.
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 verb 'Calculate' and resource 'Personal Year number', specifies system 'Kabbalistic (Mathers strict)', which distinguishes it from many sibling personal year tools for different numerology systems.
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 includes an example request body, which hints at usage, but does not explicitly state when to use this tool versus other personal year numerology tools or provide any when-not 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?
Annotations already indicate readOnly, idempotent, non-destructive behavior. The description adds that the calculation involves reduction, which is useful context. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example and group label. It is front-loaded with the main action, but the group line could be formatted separately. Still, it is efficient.
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 basic calculation but omits details like whether master numbers (11,22) are considered. No output schema is provided, so the agent cannot infer the return format. Some gaps remain 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 description coverage is 100% with detailed descriptions for all parameters. The tool description only mentions 'date', adding no extra semantic value over the schema. 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 verb 'Calculate' and the resource 'Life Path number' from a birth date, and it specifies the Pythagorean system. It effectively distinguishes from sibling tools like chaldean or kabbalistic life path 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 Pythagorean life path calculation but does not explicitly state when to use this tool versus alternatives. Given many sibling tools exist, some exclusion guidance would improve clarity.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, etc. The description adds that it calculates 'four Pinnacle cycles with their age boundaries', which is consistent. It does not contradict annotations and provides additional context about the output nature.
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 two sentences plus a group tag and an example. It is front-loaded with the core purpose, concise, and every element (purpose, group, example) adds value.
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 only states 'four Pinnacle cycles with their age boundaries' but does not specify the return format (e.g., numbers, age ranges). The misleading example reduces completeness. However, the tool is simple and annotations cover safety.
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 coverage is 100%, but the description adds no meaning to latitude, longitude, or timezoneOffset. Moreover, the example includes 'name' which is not in the schema, potentially misleading the agent about required 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 'Calculate four Pinnacle cycles with their age boundaries' and specifies 'Numerology — Pythagorean system', which distinguishes it from sibling pinnacles tools (Chaldean, Kabbalistic, Vedic). The verb and resource are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for Pythagorean pinnacles but does not explicitly guide the agent when to choose this over other numerology pinnacles tools (e.g., chaldean, kabbalistic). No when-not-to-use or alternative suggestions 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, which are consistent. The description adds value by specifying 'starting from sunrise' and the Chaldean system, providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a group label, cost, and an example request body. It is front-loaded and efficient with no unnecessary words.
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 moderate complexity (calculating schedule based on location and date), the description is minimal. It lacks details about output format, assumptions, or edge cases, and there is no output schema to compensate.
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 description coverage is 0%, and the description does not explain each parameter's meaning. The example shows the parameters but without clarifying their roles, leaving the agent to infer from the example 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 clearly states it calculates Chaldean planetary hours for a given date and location, starting from sunrise. This distinguishes it from siblings like 'horary_planetary_hours' and 'stream_planetary_hour_changes' by specifying the Chaldean system and calculation purpose.
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 does not explicitly guide when to use this tool versus alternatives such as 'horary_planetary_hours' or 'stream_planetary_hour_changes'. The purpose is clear but no exclusions or context for selection 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the output is raw longitudes without houses/aspects, which is consistent. However, it does not reveal any additional behavioral traits beyond what annotations convey, such as rate limits or auth needs.
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, containing only two sentences plus a group/cost line and an example. Every element serves a purpose: the first sentence states the core function, the second adds context, and the example shows usage. No wasted words.
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 11 parameters and no output schema, the description is somewhat incomplete. It explains the core output but does not describe the return format or the role of optional parameters like latitude, longitude, or houseSystem. However, it is adequate for the primary use case of getting raw longitudes.
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 description coverage is 0%, and the description only mentions date, time, and timezoneOffset in an example. It does not explain the other 8 parameters (e.g., latitude, longitude, zodiacType), leaving their purpose unclear. An example is helpful but insufficient for a tool with 11 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 calculates 'raw planet longitudes' and explicitly notes it is 'without full chart context (no houses, no aspects)', distinguishing it from full chart or aspect tools. The verb 'calculate' and resource 'planet longitudes' are 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when only raw longitude data is needed, and the exclusion of houses/aspects helps choose between this and full-chart tools. It provides an example request, but does not explicitly list alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds cost (250 credits) and confirmation requirement, which are useful behavioral traits beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact and well-structured: technique name, group, cost warning, and example. Every piece of information adds value, and it is appropriately sized.
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 11 parameters and no output schema, the description is adequate but incomplete. It lacks information about return format, behavior for invalid inputs, or edge cases. The example request body helps but does not fully compensate.
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 description coverage is 0% for 11 parameters. The description provides an example request body showing required and some optional parameters, but does not explain each parameter's meaning, format, or constraints. This is insufficient for the number of 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?
Description clearly states it applies the Trutine of Hermes technique to derive birth time from Moon's prenatal syzygy position. It uses specific verb 'derive' and identifies the resource (birth time). The tool is distinguished from the sibling 'rectification' which likely covers general rectification methods.
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 includes cost warning and asks to confirm with user before invoking, which provides usage context. However, it does not explicitly state when to use this tool versus alternatives or list exclusions. Sibling 'rectification' exists but no comparison is made.
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?
Annotations are minimal (readOnlyHint, destructiveHint, idempotentHint false). The description adds value by stating it's a self-knowledge (non-directive) tool, warning about premium cost (~50% of budget), and indicating it generates PDF/HTML. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences plus an example, efficiently covering core purpose, cost, and a usage hint. No fluff, but the example could be more concise. Slightly better than minimal viability.
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?
Lacks description of output format (PDF vs HTML), response structure, or how to specify format. No output schema exists. For a complex report tool, more detail on what the agent can expect 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?
Schema coverage is 100% with descriptions for all 7 parameters. The description does not add additional parameter meaning beyond the example and cost note. Baseline 3 is appropriate since the schema already fully documents 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 career-themed natal report focusing on MC, 10th-house cusp, Saturn, Mars, and Sun aspects. The title 'Generate Career Compass Report' and the phrase 'Self-knowledge tool, not directive' precisely define its purpose and distinguish it from sibling report 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 includes a cost warning and example, but lacks explicit guidance on when to use vs. alternatives like reports_natal or reports_love. The '[Group: Reports]' tag implies grouping, but no direct comparison or exclusion criteria 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?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds cost information but no further behavioral details (e.g., rate limits, side effects). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the tool's purpose. The cost warning is prominent. It could be better structured (e.g., separate sections), but overall it is efficient and easy to parse.
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; the description lists the report content but does not specify the exact return format (PDF vs HTML) or how it is delivered (file, URL). It is minimally complete for a complex tool with nested parameters.
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 low (33%) as only the chart parameter has a description. The description provides an example request body but does not explain the language or whitelabel parameters in detail. The example helps but does not fully compensate.
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 a Bodygraph PDF containing specific Human Design components (Type, Strategy, Authority, etc.), distinguishing it from siblings like human_design or human_design_compatibility.
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 includes a cost warning and instructs to confirm with user before invoking, providing clear usage guidance. However, it does not explicitly mention when not to use it or suggest alternative tools.
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?
Annotations already indicate it's not read-only nor destructive. The description adds valuable behavioral context: a disclaimer that it's not a prophecy, a significant cost of 5000 credits, and an instruction to confirm with the user before invoking. This surpasses what annotations alone provide.
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 purpose. It includes a group tag and cost info, which are useful but not verbose. No fluff, though the example body adds a bit of length.
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 report's contents and cost, but lacks details on how the output is delivered (PDF or HTML as suggested by title) and does not specify if the user can choose format. No output schema exacerbates this 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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the schema; it only provides an example body. Parameters are adequately described in the schema itself.
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's a romantic-relationship natal report, highlighting specific astrological points like Venus, Mars, Moon, and Descendant. This differentiates it from other report tools such as reports_natal or reports_synastry.
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 does not explicitly state when to use this tool versus alternatives. The cost warning is useful, but there is no guidance on when this is preferred over related reports like reports_natal or reports_synastry.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no extra behavioral context (e.g., error conditions, rate limits, or output format details). While annotations provide safety profile, description could still add value.
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 a single sentence front-loaded with core function, followed by group/cost metadata and an example. No filler, every word 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 no output schema, the description states output is a '0–100 attraction score', which is fairly clear. However, it lacks details like data type (float/integer) or how weightings work. For a simple numeric tool, it's nearly complete but could be slightly more precise.
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%: the input schema already explains 'chart1' and 'chart2' parameters in detail (required fields, defaults, accuracy note). The description adds no additional parameter-level information, so 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 what the tool does: compute a weighted 0–100 attraction score from specific astrological contacts (Sun-Moon, Mars-Venus, etc.) and 5th-house overlay. It distinguishes itself from sibling tools like 'synastry' or 'synastry_aspect_grid' by focusing on a single numerical output.
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 quick attraction score but provides no explicit guidance on when to use this tool versus alternatives (e.g., 'synastry' for full details, 'synastry_aspect_grid' for aspect breakdowns). With many synastry siblings, clearer differentiation would improve score.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds 'linear story spread' and an example, but does not disclose additional traits like shuffling or deck state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines plus example. Critical information (spread type, group) is front-loaded. No superfluous text.
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 mention what the tool returns (cards, interpretations, etc.). For a card draw, this is a significant gap. Sibling tools vary in completeness but this lacks essential info.
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 defines a single raw body object with 100% coverage via description. The tool description provides an example showing required fields (seed, question, allowReversed), adding 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?
The description 'Five-card linear story spread' clearly identifies the tool as a Lenormand card draw for a specific spread. Combined with the title and sibling tools list, it distinguishes this from other Lenormand draws (e.g., daily, three-card, celtic cross).
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 includes a group label but no explicit guidance on when to use this spread versus other Lenormand spreads. The example request body implies usage for narrative reading, but lacks when-not-to-use or 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?
Annotations already mark readOnlyHint=true, idempotentHint=true. The description adds the number of cards (4) but does not disclose any additional behavioral traits (e.g., whether it returns a full reading, stores data, or has rate limits). With annotations covering safety, the description provides minimal extra 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 concise (two lines plus example). The group tag is useful for categorization. The example is helpful but could be separated for clarity. No wasted words.
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 tarot draw with one parameter and good annotations, the description covers the basics. However, it does not explain the return format or what the tool outputs (e.g., card names, positions). Adding return context would improve 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 one 'body' parameter described as 'Raw JSON body — see the example in the tool description'. The description provides an explicit example showing required fields (seed, question, allowReversed), which adds meaning beyond the minimal schema description. This compensates for the generic 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 '4-card career spread' clearly states the verb (draw), resource (tarot cards), and scope (career). The group tag '[Group: Tarot — Marseille]' helps identify the deck. Among many sibling tarot draw tools, 'career' distinguishes it from love, spiritual, 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?
The description indicates use for career questions but does not specify when not to use it or mention alternatives (e.g., other career tools like reports_career). No explicit exclusion criteria or comparison to siblings.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it is a single-card verdict, which is consistent and provides context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus group indicator and example. Every part is useful, and the example provides clarity. Could be slightly expanded to describe the verdict output.
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 single-card yes/no tool with no output schema, the description adequately states purpose and gives an example. However, it does not specify what the response contains beyond 'verdict', nor does it clarify that the question is required. The group context is provided.
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 'body' parameter with a description pointing to the example. The example shows required fields (seed, question, allowReversed), adding meaning. Schema coverage is 100%, so baseline is 3. The description helps via example but doesn't enumerate fields explicitly.
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?
Title 'Marseille — Yes/No' and description 'Single-card yes/no with verdict' clearly state it's a binary decision tool using one card. It distinguishes from other tarot draws like love or career draws, and from other deck's decision 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 title clearly indicates yes/no decisions, but the description does not explicitly state when to use this versus other tarot draws (e.g., love, career). It implies usage for binary questions but lacks explicit guidance or mention of alternatives.
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?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds that results are deterministic per day based on date seed, providing useful behavioral context beyond annotations. However, it does not describe the output format.
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 an example and group tag). No unnecessary words, front-loaded with the core purpose.
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 required parameter and no output schema, the description covers determinism, date seed, and group. It could be improved by hinting at the output (e.g., 'returns a single tarot card'), but is 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%, so the schema already documents all parameters. The description provides a useful example request but adds minimal semantic nuance beyond what is 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 it provides a daily card based on a date seed, with group identification. This distinguishes it from other tarot draw tools by emphasizing determinism and daily use.
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 other tarot draw tools (e.g., single draw, Celtic cross). The description does not mention alternatives or specify context of use.
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?
Annotations already indicate read-only and idempotent behavior. The description adds valuable behavioral details: the specific cancellation rule (BPHS A.39), and the three possible verdicts (compatible, cancelled, incompatible). This goes beyond the annotations by clarifying the rule and output categories.
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 with three sentences. The first sentence states the core purpose and rule, the second lists the possible verdicts, and the third provides meta-info (group and cost). No unnecessary words, and key 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 the complexity of nested chart parameters, the schema descriptions cover the parameter details. The description defines the output clearly (three possible verdicts). No output schema exists, but the description suffices. A minor gap is lack of clarification on how the cancellation rule is applied in edge cases, but overall it is 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 each parameter described in the schema. The description does not add parameter-level meaning beyond stating that Manglik status is compared. Since the schema already documents the parameters well, the description adds marginal 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?
The description clearly states the tool compares Manglik status of both partners and applies the BPHS A.39 cancellation rule, returning one of three verdicts. This distinguishes it from sibling tools like vedic_compatibility_manglik_check (which likely only checks individual status) by specifying the mutual cancellation logic.
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 vedic_compatibility_manglik_check or vedic_compatibility_full. The description does not include context about prerequisites, when to avoid, or when to prefer another tool.
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?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already convey safety profile. Description adds non-behavioral context (group, cost) but does not disclose further behavioral traits like pagination, response format, or limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line for purpose, one for group/cost, and one example. Front-loads the key identity (name and grain level). No wasted words.
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 hint at what the response contains (e.g., dasha periods, timings). For a complex dasha tool, understanding the output structure is essential. The phrase '5-level cascade' is not explained, leaving interpretation open. Annotations exist but do not compensate for missing output context.
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 detailed field descriptions. The description adds value by providing a concrete example request body, aiding understanding of parameter usage and format 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 clearly states the tool computes 'Ashtottari Pranadasha — 5-level cascade (finest grain)'. The verb 'cascade' and phrase 'finest grain' precisely define its function and differentiation from other Ashtottari dasha levels (maha, antar, pratyantar, sookshma) seen in sibling tool names.
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 it is for very detailed timing assessments via 'finest grain', but lacks explicit guidance on when to use this vs other Ashtottari levels or alternative dasha systems. No when-not-to-use or prerequisite conditions are 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?
Annotations already declare readOnly, idempotent, non-destructive. The description adds that it uses recursive equal-share subdivision with same direction at every depth, which enriches the behavioral model beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with key info (name, cascade levels, and group tag). It earns its place but could be slightly more informative about output or sibling distinction without losing 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 many sibling dashas and no output schema, the description is minimally adequate for a specialized Vedic tool. It lacks explanation of 'chara' or how it differs from other systems, and does not describe the 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% (all properties described in schema). The description adds an example request body but no new semantic information about parameters 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 computes Chara Pratyantardasha, a 3-level cascade (MD → AD → 12 PDs). Among many sibling dashas, this specific level is unambiguously identified.
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 Chara Pratyantardasha computation but does not compare with other dasha levels (e.g., antar, prana) or other dasha systems, leaving an agent to guess when to choose this tool.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds value by noting it returns 9 mahadashas, with first truncated by elapsed pada, and explains the varying cycle lengths (100/85/83/86 years). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with key distinguishing features. However, it is truncated with an ellipsis, which may hinder complete understanding. Still efficient and to the point.
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 specialized tool with rich schema descriptions and annotations, the description provides basic context but lacks details on output format and the effect of optional targetDate parameters. Adequate for domain experts but not fully complete for general AI agents.
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% (body property has detailed descriptions). Description does not add additional parameter semantics beyond what schema provides, 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?
Description clearly states it computes Kalachakra Mahadasha (a rasi-dasha), distinguishes from planet-based dashas, and explains the chakra rows, nakshatra groups, and paramayu variation. Sibling tools include many other dasha types, so this tool is well-differentiated.
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 implies usage for Kalachakra system (rasi-dasha) but does not explicitly state when to use this vs other dasha tools. No exclusion criteria or alternatives are mentioned, leaving the agent to infer context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the tool returns a summary and that Sade-Sati is only a pointer, which provides some behavioral context but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences plus an example. Every sentence adds value—purpose, caveat, group tag. No unnecessary content.
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 11 parameters and no output schema. The description explains the composite nature and the Sade-Sati caveat, but lacks parameter documentation and output description, leaving some gaps for an agent to use it correctly.
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?
Description provides an example request body but does not describe the meaning of any of the 11 parameters. With 0% schema coverage, the description fails to compensate, leaving agents without guidance on fields like houseSystem, zodiecType, ayanamsaId, etc.
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 composite summary of multiple KP doshas (manglik, kalasarpa, pitra, kemadruma, and Sade-Sati pointer). It distinguishes from sibling tools like vedic_doshas_kp_manglik, etc., which focus on individual doshas.
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 notes that Sade Sati requires a separate call via /sade-sati, guiding the agent when to use this composite tool vs the dedicated one. It also groups the tool under Vedic, but does not explicitly list all alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by specifying the output metrics (net influence and dominant-over per house), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the core function in the first sentence, followed by house details, output metrics, and an example. Every sentence adds value with no wasted words.
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 main purpose and output metrics but fails to explain the input parameters, which is a significant gap given 11 parameters and 0% schema coverage. The example helps but does not fully compensate.
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?
Schema description coverage is 0%, and the description does not explain any of the 11 parameters beyond an example request body. It fails to compensate for the lack of schema descriptions, leaving parameter meanings unclear.
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 performs a full Argala and Virodhargala scan across all 12 houses, listing specific houses for each type. This clearly distinguishes it from sibling Jaimini tools like vedic_jaimini_aspects or vedic_jaimini_padas.
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 clear context about the tool's function and house involvement, allowing an agent to infer it is for argala analysis. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about the output (timeline with age-of-event, before/after planets, life-event hints) and constraints (default 84 years, cap 120), which is useful beyond the annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences plus group/cost info—and front-loaded with the core concept. Every sentence is informative, with no wasted words. The example further aids understanding without redundancy.
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 Vedic Jaimini and the lack of output schema, the description provides the core concept, output content, and defaults, but lacks explanation of the Naisargika progression, interpretation of life-event hints, and details of all parameters. It is adequate but not fully complete for an agent to use without prior domain knowledge.
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 description coverage is 0%, so the description must compensate for parameter meaning. However, it does not explain the 11 parameters (e.g., houseSystem, name, city) beyond showing an example. The description adds no value for parameter semantics, leaving agents to infer from the example.
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 performs a Naisargika 1°/year symbolic progression and scans for Atmakaraka changes, with a specific verb 'scans' and resource 'Atmakaraka rotation'. The title 'Jaimini — Atmakaraka rotation (timeline)' further clarifies its purpose and distinguishes it from siblings like vedic_jaimini_atmakaraka_navamsa.
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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. It implies usage for obtaining a timeline of soul-significator transitions but lacks guidance on when to choose it over other Vedic Jaimini 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds that the tool returns positions with KP sub-lord chain, which is useful beyond annotations, but no further behavioral traits (e.g., pagination, default values) are disclosed.
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 JSON example. It front-loads the core function. The group label '[Group: Vedic]' is slightly redundant but not harmful. The example adds value. Overall efficient.
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 4 parameters, no output schema, and moderate complexity (KP sub-lord chain), the description covers basic purpose and usage. However, it lacks details on what the sub-lord chain is, how ayanamsaId affects results, or the output structure. An agent might need to infer the 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 description coverage is 0%, so the description must explain parameters. It mentions `targetDate` (not a parameter name) and provides an example with date, time, timezoneOffset. However, it does not explain ayanamsaId or clarify that 'targetDate' is a concept, not a parameter. The example is helpful but incomplete.
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 sidereal positions of all 9 grahas with KP sub-lord chain for a target date. It distinguishes itself from siblings by specifying 'KP transit-timing' and mentioning the sub-lord chain, which is unique among the many vedic 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 explicit usage context: 'Use for KP transit-timing.' This helps the agent understand when to invoke this tool. However, it does not specify when not to use it or explicitly compare to sibling tools like transits or vedic_kp_cusps.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, indicating a safe read operation. The description adds behavioral context: it is a scanner (not mutating), excludes Fridays, and filters by preferred nakshatras. This enriches the agent's understanding beyond annotations without contradiction.
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 at two sentences plus a group/cost line and an example request. It front-loads the core purpose and key constraints. The example is helpful but adds slight length. No fluff, though parameter explanations would improve it.
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 7 parameters (1 required) and no output schema, the description should provide more context about expected results, pagination, or error handling. It mentions 'auspicious-window scanner' but not what the output contains (e.g., dates, ratings, nakshatra names). The example shows a request but not a response. The low schema coverage and lack of output schema worsen completeness.
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 0% description coverage, meaning none of the 7 parameters have descriptions. The description does not explain any parameter purpose, format, or constraints. The included example request body gives implicit hints for search_window_start/end, latitude, longitude, and timezoneOffset, but fails to describe ayanamsaId, topN, or required vs optional nature. This is a significant gap for tool invocation.
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 an 'auspicious-window scanner for multi-day journeys' and identifies specific use cases (pilgrimages, relocation travel). It differentiates from short travel by noting stricter criteria and excluded Fridays, and the sibling tool list includes vedic_muhurat_travel, confirming a distinct purpose.
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 clear guidance on when to use the tool (multi-day journeys) and hints at alternatives (stricter than short travel, implying vedic_muhurat_travel for short trips). It mentions excluded day (Friday) and preferred nakshatras, aiding selection. However, it does not explicitly state when NOT to use or list alternative tool names.
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?
Annotations already indicate readOnly, non-destructive, and idempotent. The description adds value by detailing the scoring methodology (Tithi, Vara, Nakshatra, Yoga, Karana), preferred nakshatras, avoided weekdays, and return format (top-N sorted by score). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It includes necessary detail (sources, preferred nakshatras, avoided days, output format) and an example. The truncation at 'Abh…' is minor. Overall efficient with 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?
Given the tool has 7 parameters and no output schema, the description covers the scoring, output format, and provides an example. However, it lacks explanation of the ayanamsaId parameter, what 'Abh…' abbreviates, and whether output includes timings. For a moderately complex tool, more detail 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?
With 0% schema coverage, the description compensates partially by mentioning 'date range' and providing an example request that clarifies search_window_start, search_window_end, latitude, longitude, timezoneOffset, and topN. However, it does not explain ayanamsaId or the meaning of 'topN' versus other parameters, leaving some ambiguity.
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 it as an 'Auspicious-window scanner for marriage (Vivah Muhurat)' and distinguishes from sibling tools by specifying the subject (marriage) and textual sources (Muhurta Chintamani, B.V.Raman). The verb 'scanner' and resource 'marriage muhurat' are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding marriage dates over a date range, but does not explicitly state when to use this tool versus other muhurat tools (e.g., business, education). No alternatives or exclusions are mentioned, leaving the decision to the agent based solely on the tool name.
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?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the description's behavioral burden is lower. It adds value by disclosing cost (50 credits, Tier 3) and efficiency ('Single call'), which are not in annotations.
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, uses bullet-style key facts (group, cost), and includes an example. It is front-loaded with purpose and actionable details. Every sentence adds value with no 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?
The description lacks details on the output format or return structure, which is significant given no output schema. It covers purpose and efficiency but is incomplete for an agent to fully understand the response. It provides enough context to call the tool but not to interpret results without further schema.
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 0% description coverage for 11 parameters. The description provides an example request body but does not explain any parameter semantics, meaning, or allowed values beyond what the schema already provides (e.g., patterns, enums).
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 combined Shadbala with all 6 types of strength plus totals per planet. It explicitly calls out that it is a single call for a summary, differentiating it from individual shadbala tools like vedic_shadbala_cheshta, 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?
The description says 'Useful for Vedic chart strength dashboards' which implies a dashboard context but does not explicitly state when to use this vs. individual shadbala tools or when not to use it. No exclusion criteria 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?
Annotations already declare the tool as read-only and idempotent. The description adds no additional behavioral traits beyond the educational context. It mentions cost but does not disclose any potential side effects or prerequisites.
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 explaining the chart's purpose, plus group label, cost, and a full example request. Every element earns its place with no redundancy or verbosity.
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 straightforward chart calculation tool with no output schema, the description adequately informs the agent of the chart's purpose and required inputs. It lacks details on return format but is sufficient given the nature of 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 all 7 parameters are fully documented in the input schema. The description provides an example request body but adds no new semantic meaning beyond what the schema already specifies.
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 'Chaturvimsamsa / Siddhamsa chart' focused on 'education, learning, academic achievement'. This is specific and distinct from other Varga charts in the sibling list (e.g., vedic_varga_D10 for career, vedic_varga_D9 for marriage).
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 educational analysis but does not explicitly state when to use this tool versus other Varga charts or alternative approaches. No when-not or alternative guidance is provided, so the agent must infer context from the title.
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?
Annotations already confirm read-only, safe operation. The description adds value by detailing the output dimensions (dominant element, strengths, vulnerabilities, coping) beyond what annotations convey, even though no output schema exists.
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 two concise sentences plus a group tag and example. It front-loads the core purpose with no redundant or verbose phrasing.
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 absence of an output schema, the description provides a reasonable overview of what the tool returns. However, it could be more explicit about the format or structure of the output, such as whether it includes textual descriptions or numeric scores.
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 does not add new semantic meaning to the parameters beyond the example request body, which is illustrative but not semantically additive.
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 purpose: creating an element profile focused on luminaries (Sun, Moon) and personal planets (Mercury, Venus, Mars), and identifying dominant element, strengths, vulnerabilities, and coping. This distinguishes it from other wellness tools like wellness_medical_astrology or wellness_diet.
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 such as wellness_cycle or wellness_herbs. The group label 'Wellness' is present but no explicit context for tool selection.
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?
Annotations already mark it as read-only, idempotent, and non-destructive. The description adds behavioral detail by explaining that it averages planetary positions and house cusps, and includes cost information (50 credits). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences conveying purpose, group, cost, and an illustrative example. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that returns a composite chart, the description does not specify the output format or what fields are included. While input details are clear (with example and schema), agents may lack guidance on interpreting the result. An output schema or brief description of return 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?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds an example request and notes defaults, but does not significantly enhance understanding 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses a specific verb ('Calculate') and resource ('midpoint composite chart'), and distinguishes this tool from siblings like synastry by describing the averaging approach. It is precise 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Group: Comparisons' which hints at context, but does not explicitly state when to use this tool over alternatives like synastry, davison, or coalescent. No when-not guidance 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which the description aligns with. The description adds context about symbol matching and cost but does not reveal additional behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: two sentences plus group/cost and an example. Every element adds value, and the core action is front-loaded with no unnecessary verbiage.
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?
While the description covers input and output at a high level, it lacks details on error handling, empty results, or exact response structure. An output schema is absent, so more explicit output description would help. Adequate but not fully comprehensive.
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 only defines 'body' as a raw JSON object with no inner properties, so the description's example ('text' and 'recurring') provides crucial semantics missing from the schema, significantly aiding 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 states it scans dream narrative text for known symbols and returns matched symbols with meanings, distinguishing it from siblings like 'esoteric_angel_numbers_decode' which handles angel numbers.
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 for decoding dream symbols but does not explicitly state when to use it versus alternatives like other esoteric tools, leaving comparative guidance unaddressed.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context beyond stating that the tool returns house cusps and signs, which is consistent with a read-only operation. No contradictions or additional traits disclosed.
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 concise, front-loading the purpose in a single sentence. The example request and group label add value without waste. Every element serves a clear function.
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?
Given the high schema coverage, clear annotations, and the tool's simple purpose (house cusps and signs), the description is complete. No output schema is needed for this type of tool, and the example clarifies the expected input 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 description coverage is 100%, so baseline is 3. The description does not add new meaning to parameters; it only provides an example request body. Parameters are already fully described in the input 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 house cusps and signs for the 2nd (personal money) and 8th (shared resources) houses. This specific verb+resource combination distinguishes it from siblings like financial_wealth_cycle or financial_career_money_style, which cover different aspects of financial astrology.
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 financial astrology via the group label and example request, but it lacks explicit guidance on when to choose this tool over alternatives (e.g., financial_wealth_cycle). No when-not-to-use or exclusion criteria 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?
Annotations indicate readOnlyHint, destructiveHint, idempotentHint. The description adds cost context (50 credits, Tier 3) which is useful for the agent. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a group and cost line. The example is lengthy but provides concrete guidance. No redundant 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?
The description covers the core purpose and gives an example, but lacks explanation of parameters and output. Given the tool has 11 parameters and no output schema, more detail is needed for complete understanding.
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 description coverage is 0%. The description only provides an example request with some parameters but does not explain individual parameters like latitude, longitude, zodiacType, etc. This is insufficient for an agent to understand all inputs.
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 calculates current Human Design transit activations and optionally overlays on a natal chart to show combined defined centers and channels. This is specific and distinct from sibling tools like human_design or human_design_compatibility.
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 an example request body that shows how to use the tool, including optional natal chart overlay. It implies when to use the natal option but does not explicitly state when not to use it or compare with 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?
Annotations include readOnlyHint=true, destructiveHint=false, which are consistent with the description. The description adds that it is 'Token-cached for repeats' but does not elaborate on caching behavior. Given the annotations, the description adds minimal extra context about the tool's 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 concise: one sentence for purpose, then key features (multi-language, token-cached), cost, and an example. No unnecessary information. The purpose is 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?
The tool lacks an output schema, and the description does not explain the output format (e.g., structured vs free text). It mentions contents like personality traits and archetypes but not how they are presented. For an AI generation tool, this is a notable gap.
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 coverage is 100%, and the schema already describes parameters. The description adds context beyond the schema by noting defaults for lat/lon/tz and emphasizing accuracy, plus an example request. This adds meaningful guidance for parameter usage.
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 'Generate AI interpretation of a natal chart — personality traits, life themes, strongest archetypes', which is specific and distinguishes it from sibling tools like interpret_synastry and interpret_transits. The title 'Natal Chart Interpretation' reinforces the purpose.
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 hints at usage with 'Multi-language' and 'Token-cached for repeats', and mentions cost and an example request body, but does not explicitly state when to use this tool versus alternatives like interpret_placement or report_ai_natal_narrative. No exclusions 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, etc., which match the description. The description adds that it handles magnitude scaling and labels, and provides an example. However, it does not describe output format (SVG or JSON) or any 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a group tag and example. Every sentence adds value, and it is front-loaded with the core function.
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 6 parameters, nested objects, no output schema, and 0% schema coverage, the description provides only a high-level overview. It lacks detailed parameter explanations and output description, but annotations cover safety.
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 0%. The description explains the 'points' parameter (RA/Dec, magnitude, labels) but does not describe observerLatDeg, zenithDecDeg, capAltitudeDeg, or the options object in detail. The example helps but leaves gaps.
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 performs a stereographic projection of user-supplied points with RA/Dec, handling brightness magnitude scaling and labels. This distinguishes it from sibling render tools like render_aspect_grid or render_bi_wheel.
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 vs alternatives. The description implies it is for custom star maps via caller-supplied points, but does not mention when not to use it or suggest alternative tools.
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?
Annotations indicate non-read-only, non-destructive, non-idempotent, open-world. The description adds credit cost (5000 credits, premium) and warns about budget impact, which are behavioral traits not covered by annotations. It also notes the interpretive nature and disclaimer.
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 each section providing value: purpose, cost warning, example. It could be more streamlined, but the structure is logical and front-loaded with key 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 no output schema, the description partially compensates by mentioning output format (PDF or HTML) and including full natal data. However, it does not specify how to choose output format, response structure, or error handling, leaving gaps for an agent to infer.
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?
Input schema has 100% description coverage, so baseline is 3. However, the description's example request body uses a nested 'chart' object that contradicts the flat schema structure, potentially misleading the agent. The description adds no new parameter 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 a parenting-oriented natal report, specifying key planetary focuses (Moon, Mercury, Venus, Mars) and output format (PDF or HTML). This distinguishes it from sibling report tools like reports_natal or reports_love.
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 child-related astrology through its parenting orientation. It includes a cost warning and instruction to confirm with user, providing context on when to invoke. However, it lacks explicit exclusions or comparison to alternative sibling reports.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and idempotent. The description adds value by specifying what is computed (sunrise, sunset, twilight, day length), which provides behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus an example and metadata. It is front-loaded with the core purpose, and the example aids understanding. The inclusion of group and cost information adds minor clutter but does not detract significantly.
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 fails to specify the output format or structure, which is important for a calculation tool without an output schema. While parameters are covered, the lack of return value documentation leaves the agent uncertain about what to expect.
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?
With 0% schema description coverage, the description is expected to clarify parameter meanings, but it only mentions 'date and geographic location' generically. It does not explain latitude, longitude, or timezoneOffset individually, and the example includes timezoneOffset without elaboration. This leaves parameter semantics ambiguous.
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 calculates sunrise, sunset, twilight times, and day length for a given date and geographic location. This is a specific verb+resource combination that makes the tool's purpose immediately apparent and distinguishes it from the many astrological 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage when date and geographic location are known, which is clear context. However, it does not explicitly state when not to use this tool or provide alternatives among siblings, but the astronomical nature of the tool contrasts with astrological siblings, making the usage fairly clear.
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?
Annotations (readOnlyHint=true, etc.) already cover safety. The description adds value by specifying the spread's origin, card count, and positions. No contradictions with annotations. Behavioral context beyond annotations is minimal but acceptable given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the most important information (spread type, source, card positions). The group tag and example are clearly separated. Every sentence adds value without redundancy.
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 omits any mention of the output format, which is important since no output schema is provided. It also does not clarify prerequisites or typical use cases beyond the spread itself. Adequate but not fully complete for an agent to understand the tool's full behavior.
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 defines a single 'body' object with no nested schema. The description compensates with an example request body showing required fields (seed, question, allowReversed). This is helpful but does not fully document all possible fields.
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 specific 6-card Hero's Journey spread from a well-known source (Jodorowsky/Costa). It lists the card positions (Hero, Objective, two Obstacles, Key, Resolution), making it highly distinct from sibling tarot 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?
The description does not provide any guidance on when to use this spread versus other tarot spreads (e.g., Celtic Cross, love, career). No when-to-use, when-not-to-use, or alternative suggestions 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, reproducible operation. The description adds context (4-card spread, example request) but does not disclose any behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for the spread type and one for the group and example. It is concise, front-loaded, and contains no unnecessary words.
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 spread count, group, and example request, but lacks details on output format, field semantics (e.g., seed for reproducibility), and guidelines for the question parameter. Given no output schema, this is a notable gap.
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 one parameter 'body' with no defined properties, but the description provides an example with three fields (seed, question, allowReversed). This example adds practical meaning beyond the bare schema, helping the agent structure the request.
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 states '4-card spiritual development spread' which is a specific verb-resource pair (draw/spread for spiritual development). It clearly distinguishes from sibling tools like tarot_marseille_draw_love, tarot_marseille_draw_career, 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?
The description implies use for spiritual development questions but provides no explicit guidance on when to use this spread versus alternatives like love or career spreads. With many tarot siblings, this omission reduces clarity.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe read-only behavior. The description adds that it resolves meanings, but does not elaborate on the return format, pagination, or potential limitations.
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 concise (two sentences plus example), with the purpose front-loaded. Every element earns its place, and the example clarifies input structure.
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 tool (one parameter, no output schema), the description covers input structure via example but omits any description of the output or behavior beyond 'meanings'. More completeness would improve agent 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?
The input schema's description of the 'body' parameter is minimal ('Raw JSON body — see the example...'). The tool description provides an explicit example with 'cards' and 'question' fields, adding significant 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's purpose: 'Resolve list of card slugs into meanings.' It specifies the Marseille deck via the group label and example, distinguishing it from sibling tools like tarot_rider_waite_interpret.
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. The group label and example imply Marseille tarot interpretation, but no direct comparison or exclusionary criteria 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?
Annotations (readOnlyHint, destructiveHint, idempotentHint) are consistent. Description adds behavioral context: calculates antardasha, uses formula (P.years × Q.years)/108, defaults targetDate to today UTC, and includes group/cost info. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences plus group/credit info and an example. No extraneous text; all content is purposeful and front-loaded for quick understanding.
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 schema richness and annotations, the description covers the essential aspects: what it does, formula, default date, and example. Lacks explanation of output structure, but no output schema is provided, so this is acceptable.
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 description adds meaning by explaining the formula, default targetDate behavior, and providing a full example request body. The input schema is well-documented, and the description complements it without redundancy.
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?
Description clearly identifies the tool as calculating Ashtottari Antardasha sub-periods. It specifies it returns 8 sub-periods for a running mahadasha at a target date. However, it does not explicitly distinguish from sibling dasha tools (e.g., _maha, _prana), which are closely related.
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 this tool is for sub-period analysis within the Ashtottari system but does not provide explicit guidance on when to use it versus other dasha levels or alternative dashas. No mention of prerequisites or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by noting that recursion preserves the natal chakra-row and paramayu. Annotations already indicate read-only, non-destructive, idempotent behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, front-loaded with purpose and key behavioral note. Every element earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While annotations and schema cover safety and parameters, the description omits output structure or further interpretation guidance. For a complex 3-level dasha tool, this is adequate but leaves gaps 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%, so baseline is 3. The example request body provides a concrete usage pattern but does not explain parameters beyond what the schema describes.
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 Kalachakra Pratyantardasha with a 3-level cascade (MD→AD→9 PDs), distinguishing it from sibling tools like vedic_dashas_kalachakra_maha and vedic_dashas_kalachakra_antar.
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 Kalachakra Pratyantardasha calculations but provides no explicit guidance on when to use this tool versus other dasha systems (e.g., Vimshottari, Ashtottari) or 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds the formula and default targetDate behavior (today UTC) but does not describe side effects or computational complexity. With annotations covering safety, the description adds some value.
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: two sentences of purpose, a formula, group/cost metadata, and an example. Every sentence provides essential information with no redundancy.
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 formula and example but does not describe the output format. Since there is no output schema, the agent might need to guess the response structure. The description is adequate for a simple computation but incomplete for an agent needing output details.
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 detailed properties. The description adds a clarifying note on defaults ('pass real values for accurate computation') and includes an example request body, which helps the agent understand parameter usage 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 computes the 8 sub-periods of the Yogini Antardasha at a target date, with a formula provided. It is specific to the Yogini dasha system, distinguishing it from many sibling dasha 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 tells what the tool does but does not explicitly state when to use this tool versus alternatives like Vimshottari or Ashtottari dashas. It implies Vedic astrology context but lacks explicit when/when-not 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?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that the tool returns a 'Short summary' and that data is placeholder for most planets. This provides useful behavioral context without contradicting annotations.
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 at three sentences plus an example. It front-loads the purpose and includes essential parameter info. The placeholder note inside parentheses slightly reduces readability but overall is efficient.
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 lacks details about the output format (e.g., plain text, JSON) and does not fully clarify parameter validation given the schema mismatch. For a simple lookup tool, it is adequate but could better prepare the agent for the actual response and constraints.
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?
With 0% schema coverage, the description explains the meaning and valid ranges for both parameters: planet (0..6, 11=Rahu, 100=Ketu) and house (1..12). This adds critical value beyond the schema, though the schema's overly broad integer range for planet is not addressed.
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 provides a 'Short summary of a (planet, house) placement per LK', using a specific verb and resource. It distinguishes itself from sibling Lal Kitab tools by focusing on individual planet-house placements, though it could be more explicit about the summary content.
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 tells the caller to pass `planet` and `house` and provides an example request body. It also notes the current limitation (Sun-only full data) which guides usage expectations. However, it does not suggest alternatives for other planets or when not to use this tool.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safety. The description adds value by disclosing the cost (20 credits Tier 2) and the tool group (Vedic), which are behavioral traits not covered by annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then group/cost/example. It is front-loaded with the key information and contains no unnecessary words. The structure is efficient.
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 tool like a Vedic divisional chart, the description is minimal. Although the schema covers parameters 100%, the lack of output schema and description of what the result contains (e.g., chart data) leaves some gaps. The cost and group are helpful, but more context about output 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?
Schema coverage is 100%, so the baseline is 3. The description does not add any parameter-specific information beyond the schema. The example request body shows example values but does not explain parameter meaning. No additional semantics 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 the tool computes/returns the Vimsamsa chart for spiritual progress, sadhana, and religious inclination. The verb is implied by the tool name and example, and the resource is specifically identified as Varga D20. This distinguishes it from other divisional charts like D9 or D10.
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 domain (spiritual progress, sadhana, religious inclination), which implies when to use it. However, it does not explicitly say when to use this tool versus alternatives (e.g., other varga tools), nor does it provide exclusions or alternative recommendations. The guidance is implicit, not explicit.
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?
Annotations already provide safety traits (readOnly, non-destructive). The description adds behavioral nuance: this chart is highly sensitive to birth time accuracy, which is a key operational trait beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose, group/cost, and example. Front-loaded with essential information. No filler.
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 exists, yet the description does not explain what the tool returns. While use case is hinted (past karma), more completeness (e.g., output format or interpretation guidance) would be valuable for such a subtle chart.
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 provides an example request but adds no additional semantics beyond the schema. Baseline 3 maintained.
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 Shashtiamsa (D60) chart, specifying it's the most subtle divisional chart for past karma. It distinguishes from sibling varga tools by emphasizing high birth time precision and subtlety.
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 implicitly suggests use for karmic analysis and notes high precision needs, but does not explicitly state when to choose this over other varga charts (e.g., D1, D9). No 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which convey safety. The description adds no behavioral context beyond stating the tool's purpose, such as authentication needs, rate limits, or error handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus group tag and example), with the core action front-loaded. Every element serves a purpose: clear purpose, grouping hint, and illustrative example. No superfluous content.
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 read-only tool with strong annotations, the description adequately covers the tool's purpose. It specifies input (date) and output (sleep recommendations per moon phase). No output schema exists, but the description implies natural language tips, which is sufficient for this 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 description coverage is 100% with clear parameter descriptions. The description does not add meaning beyond the schema; the example shows typical usage but does not explain optional parameters (latitude, longitude, timezoneOffset) further. 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 'Sleep recommendations per moon phase' uses a specific verb ('recommendations') and resource ('sleep per moon phase'), clearly distinguishing it from sibling wellness tools like wellness_diet or wellness_exercise. The title 'Moon-Phase Sleep Tips' reinforces the focus.
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 hints at a complementary tool by stating 'Pair with /sun-times to find current phase', providing cross-reference but no explicit guidance on when to use this tool versus alternatives (e.g., other wellness tools). It does not exclude misuse or clarify context.
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?
Annotations already mark the tool as read-only and idempotent. The description adds value by noting the Lichun/Feb 4 cutoff and the full pillar output, but does not disclose other behavioral traits like error handling or data limits. With annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example and a group label. It front-loads the key output (animal sign and pillar) immediately, with no wasted words. Every sentence provides essential information.
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 could elaborate on the format of the returned pillar or additional data. However, it covers the core outputs (animal sign, stem, branch, element) and includes an example request, making it reasonably complete for a calculator 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 description coverage is 100%, so all 7 parameters are fully described in the schema. The description adds no extra semantic detail beyond the schema, meeting the baseline expectation.
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 the 'animal sign of birth year' and 'full pillar (stem + branch + element)', clearly differentiating from siblings like chinese_zodiac_compatibility or chinese_zodiac_element. The purpose is specific and actionable.
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?
While no explicit 'when to use' vs alternatives is given, the description and example request body imply the tool is for computing the basic animal and pillar. Among many Chinese zodiac siblings, the purpose is unique enough that no further guidance is needed.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly a read operation. The description adds no additional behavioral context beyond the annotations; it only repeats the cost and group. It does not disclose any new traits like auth needs, rate limits, or response 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 group/cost line and an example. It is front-loaded with the purpose. Every element earns its place without waste.
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 moderate complexity (single element interpretation with nested input), the description includes the context, cost, and an example. It lacks output format details, but that is acceptable since no output schema is provided. It is fairly complete for 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?
The input schema has 100% description coverage, already documenting the required fields and defaults. The description adds value by providing a concrete example request body showing the structure and usage, which helps the agent construct valid input.
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 this tool provides 'AI interpretation of a single chart element (planet/house/aspect) in context,' which is a specific verb-resource pair. It is distinguished from siblings like interpret_natal (whole chart) and interpret_placement (specific placements) by focusing on a single element.
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 says 'Useful for chart-detail pages,' implying a specific context, but it does not explicitly state when not to use the tool or mention alternatives among the many interpretation tools. No exclusions or comparative guidance is 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it calculates both applying and separating aspects, which is consistent with annotations. No contradictory or missing 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose, followed by group and cost labels, and an example. Every part is front-loaded and serves a clear function without redundancy.
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, usage, and an example, but lacks details about the output format or any additional behavioral notes. For a simple tool with annotations, it is adequate but not fully comprehensive.
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 description coverage is 0%, and the description does not explain the 'year' and 'month' parameters beyond the example request body. The purpose implies a date range, but explicit parameter meaning is absent.
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 calculates all aspects the Moon makes within a date range, including both applying and separating aspects. It distinguishes from sibling tools like 'aspects' (general) and 'horary_moon_aspects' (specific to horary).
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 the tool is useful for electional and horary work, with a Group tag 'Calendar & Cycles'. While it doesn't explicitly exclude alternatives, the context is sufficient for an agent to determine appropriate use cases.
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?
The description adds value beyond annotations by explicitly stating the credit cost (100 credits, Tier 4) and providing an example request. The annotations already declare readOnlyHint=true, so the description aligns and adds cost context.
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 two sentences plus a group/cost line and an example. The purpose is front-loaded, and the example is directly useful. No extraneous text.
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 (one nested parameter), the schema and annotations provide 100% coverage. The description adds purpose, an example, and cost info. Considering the absence of an output schema, the description is sufficient for selection and 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 description coverage is 100%, so the baseline is 3. The description's example request shows parameter format, but does not add new semantic meaning beyond the schema's own 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 the tool finds dates when a planet returns to its same synodic phase relative to the Sun, with specific examples like Venus heliacal rising and Mars retrograde station. This verb+resource combination is precise and distinguishes it from sibling tools such as 'planetary_return' or 'transits'.
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 a group label and cost, and includes an example request, but does not explicitly state when to use this tool versus alternatives. The examples hint at usage contexts, but no direct guidance on exclusion or comparison with similar tools.
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?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful output context (SVG + metrics) and does not contradict annotations. No additional behavioral traits are needed beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example request. It front-loads the core purpose and avoids any redundant information.
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?
The description adequately explains the output (SVG + metrics) for a rendering tool. However, it does not address error handling or the structure of illumination metrics, which could be helpful for 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?
Schema coverage is 100% with descriptions for nested fields. The tool description adds an example request body that clarifies parameter usage, providing additional value 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 clearly states the verb 'Render', the resource 'moon disk', and the output 'SVG plus illumination metrics'. It specifies the moment via date/time, differentiating it from sibling tools like 'moon_phase' that likely return textual data.
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 such as 'moon_phase' or other render tools. There is no mention of prerequisites or exclusion criteria.
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?
Annotations indicate mutation (readOnlyHint=false) and side effects (openWorldHint=true). The description adds important behavioral context: cost (5000 credits), premium tier, need for user confirmation, use of sidereal Lahiri ayanamsa, and output format (PDF/HTML). This goes beyond annotations and helps the agent set user expectations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first line states purpose and components, second line covers cost and group, third line provides an example. Every sentence adds necessary information without redundancy. Information is front-loaded for quick scanning.
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 report contents and output format. It mentions the specific analyses included and that output is PDF or HTML. It does not cover error handling or performance, but for a report generation tool, the provided context is largely 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?
Only 33% of parameters have schema descriptions (chart). The tool description adds semantic value for the chart parameter by specifying the computation method (sidereal Lahiri ayanamsa, sign-from-Lagna house numbering) and provides an example request. However, language and whitelabel parameters receive no additional description, so the description does not fully compensate for low 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 name and title clearly indicate this generates a Lal Kitab report. The description lists specific analyses (Teva, Kismat, Prosperity, Rins, Upayas), which distinguishes it from sibling tools that cover individual components, making it clear this is a comprehensive report.
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 includes a cost warning and instruction to confirm with user before invoking, which is a clear usage guideline. However, it does not provide guidance on when to use this full report versus more specific sibling tools (e.g., vedic_lal_kitab_debts, vedic_lal_kitab_kismat), missing comparative context.
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?
Annotations already indicate it is not read-only or destructive, but the description adds the critical behavioral detail that this is a premium-cost tool consuming significant credits. It also specifies the output format (PDF) and contents, going beyond annotations. No contradiction found.
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 with the core purpose, plus a cost warning and an example. Every part is essential and front-loaded. No wasted words.
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 (nested chart object, no output schema), the description covers the main output (PDF), what aspects are included, default year, and cost. It provides a full example request. It could mention that language and whitelabel affect output, but for a typical agent the description is sufficiently 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?
With only 25% schema description coverage, the description provides some context (e.g., year defaults to next calendar year) and an example request body, but does not explain parameters like 'language' or 'whitelabel' in detail. The schema already defines them, so the description adds minimal 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 states the tool renders a year-ahead transit calendar PDF grouped by month, with specific aspects (conjunction, sextile, square, trine, opposition) of outer planets to natal positions at 0.5° max orb. This is a specific verb+resource that distinguishes it from siblings like 'reports_ai_year_ahead_narrative' or 'transit_calendar'.
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 includes a cost warning ('~50% of free monthly budget. Confirm with user before invoking.') and notes the default year behavior. However, it does not explicitly state when to use this tool versus alternatives like 'transit_calendar' or 'reports_ai_year_ahead_narrative', nor excludes scenarios.
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?
Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable context: optional seed for deterministic shuffling, acceptance of a question, and allowReversed parameter. This supplements the annotations further than the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, a group tag, and a JSON example. Every element is purposeful—the example is particularly efficient for conveying parameter structure. No redundancy or unnecessary detail.
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?
While annotations and the description cover input behavior well, the tool lacks an output schema and the description does not mention the return format. The agent does not know what the response contains (e.g., card name, interpretation, suit). Given the simplicity of a single card draw, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (single raw JSON body with no detailed properties). The description provides a concrete example with fields (seed, question, allowReversed), significantly compensating for the schema's lack of structure. This is crucial for the agent to understand required and optional inputs.
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 draws 1 card from the Rider-Waite-Smith deck, with a specific verb and resource. The name and title reinforce this, and it effectively distinguishes from sibling tools like 'draw_three_card' or 'draw_celtic_cross' due to the singular 'single' and explicit card count.
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 a single card draw versus other Tarot tools such as three-card spreads or Celtic cross. No differentiation criteria, use cases, or exclusions are mentioned, leaving the agent without context for appropriate selection.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context by specifying what the tool returns (per-Kuta scores, dosha flags, threshold verdict) and traditional threshold values. This goes beyond the annotations, providing useful operational details.
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 concise: one sentence establishing purpose and one sentence detailing outputs and thresholds, plus metadata (group, cost). No wasted words; front-loaded with essential information. It is efficiently structured for quick comprehension.
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 moderate complexity (8 Kutas, doshas, verdict), the description covers main outputs but lacks output schema or format details. It mentions per-Kuta scores, dosha flags, and threshold verdict, which is sufficient for an agent to understand expectations. Without output schema, the description carries the burden and does so adequately.
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 coverage is 100%, with descriptions for chart1 and chart2 explaining required fields and defaults. The tool description does not add additional parameter-specific meaning; it focuses on the computation and outputs. Baseline score of 3 is appropriate since schema already handles 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 performs 'Canonical 8-Kuta matchmaking out of 36 points' and lists the eight Kutas by name. It specifies outputs (per-Kuta scores, dosha flags, threshold verdict). This distinguishes it from sibling tools like vedic_compatibility_full or vedic_compatibility_bhrigu_match, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Ashtakoot Guna Milan but provides no explicit guidance on when to choose this tool over other Vedic compatibility tools (e.g., vedic_compatibility_dashakoota, vedic_compatibility_manglik_check). An agent receives no 'when-not' or alternative suggestions, leaving selection to inference.
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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds context that it counts benefic/malefic planets and labels status, and clarifies it is not a numerical score. No contradictions, and additional behavioral details (e.g., cost, group) are included.
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?
Description is very concise: two sentences plus metadata tags. No extraneous information; purpose, output type, and cost are clearly stated upfront.
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?
Despite no output schema, the description hints at return format (labels status). However, it could be more complete by detailing the output structure (e.g., per planet or overall). For a moderate-complexity tool, it is largely 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 description coverage is 100%, with both chart parameters having full descriptions in the schema. The tool description does not add significant semantic detail beyond referencing 'both partners'. 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?
Description clearly states it is a Bhrigu Sanhita-style 7th house planetary placement summary for both partners, counts benefic/malefic planets, and labels status. It distinguishes from other Vedic compatibility tools by focusing on 7H placement and explicitly notes it is not a numerical match score.
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 implies usage for 7th house compatibility analysis but does not explicitly state when to use this tool over siblings like vedic_compatibility_ashtakoot or vedic_compatibility_full. No when-not-to-use or alternative suggestions 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?
Annotations already cover safety (readOnlyHint, destructiveHint, idempotentHint). The description adds cost (50 credits) and grouping (Vedic), which are useful beyond annotations. No contradiction, but adds limited 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading key components in a single sentence, followed by metadata (group and cost). No extraneous words; every sentence is necessary.
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?
Despite no output schema, the description lists response contents (Ashtakoot total, threshold, Manglik check, per-Kuta sub-scores, recommendation), adequately informing the agent of return structure. Input schema covers required parameters, making the description sufficiently complete for a complex 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% with descriptions for chart objects providing required fields and defaults. The description adds no additional parameter meaning 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 combines multiple matchmaking components (Ashtakoot total, threshold, Manglik check, per-Kuta sub-scores, recommendation) into one call. This distinguishes it from siblings that handle individual aspects, providing a specific verb and resource.
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 comprehensive reports via 'combined ... in one call' but does not explicitly state when to use this versus individual siblings (e.g., vedic_compatibility_ashtakoot). No when-not or alternative guidance is 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?
Annotations indicate readOnly and idempotent, which the description does not contradict. The description adds behavioral detail: returns exactly 9 ADs, uses a formula, defaults to today UTC, and includes cost/group metadata. This provides value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: purpose, formula, group, cost, example. It front-loads the main function. Extra details (example) are useful but slightly lengthen it; still efficient.
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; description states 'returns the 9 ADs' and gives formula, but does not describe the structure or fields of each AD. The example request hints at input but not output. For a tool of this complexity, more detail on returned data would improve 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?
Schema description coverage is 100% (body described well). The description adds context beyond schema by explaining how targetDate is used (defaults to today) and providing the calculation formula and an example request. This enhances 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: computing antardashas (sub-periods) within a running mahadasha. It specifies the input (targetDate), output (9 ADs), formula, and distinguishes from other vimsottari dasha levels like maha, prana, etc., as seen in sibling tool names.
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 explains the tool's function but does not explicitly guide when to use this tool over alternatives (e.g., other dasha sub-period tools or other dasha systems). It implies usage when antardashas are needed, but lacks when-not or comparison cues.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. Description adds key behavior: starts from yogini-of-Moon-nakshatra at birth, first MD truncated. This clarifies the computation start point, going beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is mostly concise but includes extra metadata like '[Group: Vedic]' and '[Cost: 50 credits (Tier 3)]' which could clutter the core description. The example request body is useful but adds length. Front-loaded with the main purpose is good.
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 moderate complexity (36-year dasha, 8 yoginis, starting condition) and rich schema, the description covers essential computational logic. However, it lacks any mention of output structure (e.g., a list of periods), which would help agents understand the return format without an output schema.
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 has 100% coverage of parameters with descriptions in the schema itself. The tool description adds an example request body with format and defaults, clarifying how to set date/time and optional fields like latitude/longitude. This adds practical 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?
Description precisely names the tool as '36-year Yogini Dasha' and lists the 8 yoginis with their rulers and periods, clearly distinguishing it from many sibling dashas (e.g., vimshottari, ashtottari). The verb 'computes' is implied, but the resource and scope are explicit.
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 Yogini Dasha versus other dashas. Among many sibling dashas (vimshottari, ashtottari, etc.), an agent would benefit from selection criteria. The description only implies usage for Vedic calculations.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds value by specifying that the output includes 12 houses with planets and state. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two main sentences, a group tag, and an example. It is front-loaded with key information and has no unnecessary words.
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 provides a basic understanding of the output (12 houses with planets and state). However, it lacks details about the 'state' meaning, error handling, or parameter descriptions, which would improve completeness for a complex tool with 11 parameters.
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 description coverage is 0%, so the description must compensate. It provides an example request body with 5 parameters, but does not explain the meaning or format of the 11 total parameters. The example is helpful but insufficient for understanding the full parameter set.
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 Lal Kitab kundali grid layout with 12 houses listing planets and their states. It distinguishes itself from sibling tools by specifying 'Lal Kitab' and the grid format, and mentions it is a companion to /teva for chart visualization.
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 states it is a companion to /teva for chart visualization, providing context on when to use this tool vs the sibling teva tool. However, it does not explicitly state when not to use this tool or mention alternatives among the many sibling tools.
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?
Annotations declare readOnlyHint true, destructiveHint false, idempotentHint true. The description adds that it returns a dasha house and solar-return JD, which is consistent. No contradictions; the description provides additional output context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a group label and example. Every part adds value. No extraneous text.
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?
No output schema exists, but the description explicitly states the return values (dasha house and solar-return JD). This is sufficient for the tool's simple purpose. Minor gap: no mention of possible additional outputs, but the core is covered.
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 includes descriptions for body properties. The description provides an example request body but does not add semantic detail beyond what the schema already describes. 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 Lal Kitab annual progression at a given age and returns the running 35-year-cycle dasha house and approximate solar-return JD. The verb 'Returns' and the specific outputs distinguish it from other Lal Kitab 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 annual chart casting but does not explicitly state when to use this tool versus other vedic_lal_kitab tools or alternatives. 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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds value by mentioning 'wide nakshatra acceptance per classical text' and credit cost (50 credits), providing algorithmic and pricing context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured: first sentence states purpose, followed by a contextual note, group/cost info, and a clear example. No superfluous content.
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 concept and provides an example, but it omits details about output format, ranking criteria for 'top auspicious days', or error conditions. Since there is no output schema, the description should hint at return structure, which it does not. Adequate for a simple scanner but not fully complete.
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?
Input schema has 7 parameters with 0% schema description coverage. The description does not explain individual parameters except through the example request body (search_window_start, search_window_end, latitude, longitude, timezoneOffset). Parameters like ayanamsaId and topN are not described. Given the low coverage, the description should compensate but only partially does.
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 an 'auspicious-window scanner for Namkaran (naming ceremony)' with specific verb 'scan' and resource 'Namkaran'. It distinguishes from sibling muhurat tools by naming the ceremony type and referencing classical text acceptance.
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 usage context by noting orthodox practice schedules the ceremony on the 11th or 12th day after birth, and that the tool scans any caller-supplied window. It implies when to use (post-birth) but does not explicitly state exclusions or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds value by detailing preferred nakshatras, avoided days, cost (50 credits), and an example request. No contradictions with annotations; all traits are consistent and well-explained.
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 compact: two sentences for purpose and guidelines, plus a line for auspicious details, group/cost metadata, and an example. Every sentence adds value, and the most critical info (purpose) is 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?
The tool has 7 parameters and no output schema. The description provides an incomplete parameter guide (missing ayanamsaId, topN) and does not describe the return format (e.g., list of windows). For a scanner tool, output structure is important; this gap reduces completeness.
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 description includes an example request body that implies meaning for 5 of 7 parameters (search_window_start/end, lat/lon, timezoneOffset). However, ayanamsaId and topN are not mentioned, and schema coverage is 0%. With low coverage, the description should explain more; missing parameters reduce clarity.
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 'Auspicious-window scanner for purchasing or moving into property (Griha Pravesh)', with specific verb 'scanner' and resource 'property purchase/move'. It distinguishes from sibling muhurat tools by explicitly mentioning the activity, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides preferred nakshatras and avoided days (Sun/Tue/Sat), offering some guidance. However, it does not explicitly state when not to use this tool versus other muhurat tools, nor does it provide alternatives. Usage context is implied but not exhaustive.
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?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds important behavioral context: the specific day pillar algorithm, requirement for 'time' parameter, and the 23:00 CST day-shift handling with timezoneOffset. This significantly aids understanding beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise—two focused sentences plus a group label and example. Every sentence adds essential information without redundancy, and the structure front-loads the core 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 output schema, the description does not specify the return structure, and it omits explanation of latitude/longitude parameters, which are present in the schema. For a tool with four parameters, this leaves some contextual gaps for an AI agent.
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?
While input schema descriptions cover parameter formats, the description adds semantic value by explaining how 'time' and 'timezoneOffset' jointly compute the hour pillar and handle day-shift, and provides an example, enriching the schema-provided info.
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 four BaZi pillars (year, month, day, hour), specifies the day pillar calculation method (HKO-canonical 60-jiazi cycle), and distinguishes from sibling tools that return only individual pillars or other 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 implies usage when the full set of four pillars is needed, but does not provide explicit when-to-use, when-not-to-use, or alternatives, leaving the agent to infer context from the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds context about the method (Sheng-Ke, branch-clash, jieqi) but does not disclose additional behavioral traits like response format or limitations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with a clarifying example and group label. Every sentence earns its place, and the core functionality is front-loaded. No wasted words.
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 is missing information about return values, especially since there is no output schema. It explains what the tool does but not what it returns, which is a notable gap. The annotations and example mitigate some incompleteness, but the lack of output description lowers the score.
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 describes only a generic 'body' parameter, but the description provides a concrete example showing required fields (natalDate, targetYear, targetMonth). This adds significant meaning beyond the schema, compensating for its generic description. With 100% schema coverage, additional detail is minimal but the example is key.
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 performs the same Sheng-Ke and branch-clash analysis as the yearly tool but applied to a specific calendar month. It explicitly distinguishes from the sibling tool bazi_yearly, making its 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 implicitly tells when to use it (for monthly BaZi analysis) and contrasts it with the yearly version. It groups the tool under 'BaZi (Four Pillars)' and provides an example, but does not explicitly state when not to use it or mention alternatives beyond the yearly tool.
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?
Annotations indicate read-only, non-destructive, idempotent behavior. The description adds significant context: deprecation status, data quality issues (oral tradition, scattered manuscripts), cost (10 credits), and an example request body. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with deprecation warnings, which is good, but it repeats deprecation in multiple places (title, beginning, bold warning). The example and metadata add some length. Could be more concise without losing essential info.
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 required parameter and no output schema, the description provides the basic purpose, deprecation status, and an example. However, it omits details about the output format and does not clarify the extra parameters in the example, leaving 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?
The input schema has only one required parameter (date) with no description, and schema description coverage is 0%. The description does not describe the date parameter explicitly, but the example request body includes extra parameters (time, timezoneOffset, latitude, longitude) beyond the schema, implying optional additional inputs without explanation. This adds some value but lacks clarity.
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 calculates Djamaspa planetary positions for a date, specifying the verb 'calculate' and the resource 'Djamaspa planetary positions'. It differentiates from siblings by flagging deprecation and advising migration to broader /reference endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the tool is deprecated, RED quality, and slated for sunset, and advises to migrate to broader /reference endpoints or remove dependency. This provides clear when-not-to-use guidance and directs to alternatives.
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?
Annotations indicate readOnlyHint=true and idempotentHint=true, so the tool is a safe read operation. The description adds value by specifying the operation is calculating a connection chart, and includes cost and group info. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and includes group, cost, and a helpful example. Every sentence is meaningful with no waste.
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 two-chart tool with no output schema, the description lacks details on what the output contains (e.g., list of channels or interpretations). The example helps but does not specify return format or prerequisites.
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 100% coverage with descriptions for each parameter. The description provides an example request body showing structure, which adds value beyond schema alone. However, it does not detail each parameter further.
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 Human Design connection chart (compatibility) between two people, listing specific channels like electromagnetic connections, compromise, dominance, and companionship. This distinguishes it from single-chart tools like human_design and other compatibility 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 HD compatibility but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings like synastry or other HD tools. The example is helpful but lacks context for choosing this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the tool is expensive (250 credits) and advises confirmation, going beyond the openWorldHint annotation. However, it does not describe the return format or any side effects other than cost.
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?
Extremely concise with no wasted words; the purpose, inputs, and cost warning are front-loaded in a short, clear format.
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?
Lacks details on output format and the exact meaning of 'outer-planet transits clustered by month.' For a complex, heavy tool, more background on what the report contains 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?
Adds some value by noting year defaults to next year and that length 'long' gives a full report, but given low schema coverage (20%), it does not adequately explain the chart object or other parameters in depth.
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 'Long-form annual report' that 'combines natal context with the year's major outer-planet transits clustered by month,' which is specific and distinct from sibling tools like reports_ai_monthly_narrative or reports_ai_natal_narrative.
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?
Provides explicit guidance to use the 'long' length for a full annual report and includes a cost warning ('Heavy — confirm with user before invoking'). However, it does not explicitly list when not to use or mention alternatives.
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?
Annotations already indicate non-read-only and non-destructive. The description adds valuable context: premium cost (5000 credits, ~50% of free monthly budget) and a required user confirmation step. This goes beyond the structured annotations.
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 formatted metadata (group, cost). Front-loaded with core purpose, then cost warning. No unnecessary words; highly efficient.
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?
Covers purpose and cost well but lacks output format details (e.g., response is a PDF blob or URL). No output schema, so this information is needed. Given the tool's complexity and many sibling tools, 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 description coverage is 50%, and the tool description does not add extra parameter meaning beyond what the schema provides. The example request body illustrates usage but does not explain parameters in the description text itself.
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 renders a synastry PDF report with specific contents (side-by-side Big Three, cross-chart aspects, element balance). It distinguishes itself from sibling tools like 'synastry' (raw data) and 'synastry_aspect_grid' by specifying PDF output.
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?
Includes a clear cost warning and requirement for user confirmation before invoking. However, it does not explicitly guide on when to use this tool versus other synastry-focused siblings like 'synastry_aspect_grid' or 'synastry_attraction_score'.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds a credit cost (50 credits, Tier 3) and an example showing the 'converse' parameter, which are behavioral traits beyond annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences plus metadata (group, cost, example). It is front-loaded with the core action and includes a representative example without 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 defines the core purpose and provides an example, but does not explain the return structure or differentiate from similar tools like 'primary_directions'. For a complex astrological calculation, the agent may need more context on output and alternatives.
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 detailed descriptions of the body object including required fields and defaults. The description adds an example request body that maps parameters to real values, clarifying usage. This enhances understanding 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 clearly states the verb 'calculate' and resource 'symbolic arc directions', specifying the types (1° per year, solar arc, Naibod) to natal points for a target date. This distinguishes it from sibling tools like primary_directions or progressions by naming specific arc methods.
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 includes a group label '[Group: Prognostics]' and an example request, but lacks explicit guidance on when to use this tool versus alternatives (e.g., primary_directions, profections). No when-not-to-use 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety. Description adds behavioral detail that it reports top-3 emphasized houses, which is useful for agent understanding. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: one sentence for purpose, then group/cost, then example. Front-loaded and every sentence serves a purpose. No unnecessary words.
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?
Input schema is fully detailed, but description lacks output structure details (only mentions 'top-3 emphasized houses'). Given no output schema, more detail on return format would improve completeness for agent usage.
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 per-parameter descriptions. Description does not add extra meaning beyond schema but provides an example request body that clarifies format and defaults, adding 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 states it locates personal planets in partner's houses and reports top-3 emphasized houses, with a specific verb and resource. It distinguishes from sibling tools like synastry and synastry_aspect_grid by focusing on house overlay.
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 implies usage for house overlay analysis but does not explicitly state when to use vs alternatives like synastry or synastry_aspect_grid. No when-not or exclusions provided, only implied context.
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?
Annotations already indicate a read-only, idempotent operation. The description adds behavioral context about the computed sequence, truncation of the first period, and the reliance on birth data. It does not contradict annotations and provides useful logic details beyond structural hints.
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, using only a few lines to convey essential information. It is front-loaded with the core functionality and includes group/cost details without unnecessary wording.
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 complexity and lack of output schema, the description provides the core algorithm but omits what the response looks like (list of periods). While adequate, it could be slightly more complete by mentioning the return format.
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 clarifying that lat/lon/tz default to 0 and that real values are needed for accuracy, plus an example request. This context helps the agent understand parameter usage 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 computes the 'Canonical Vimshottari Mahadasha sequence' with specific details like the 9 planets, 120-year cycle, and the rule based on Moon's nakshatra. It distinguishes itself from other dasha tools in the sibling list by focusing solely on Vimshottari Mahadasha.
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 does not explicitly guide when to use this tool versus alternatives like sub-period dashas or other dasha systems. It implies usage through the name and context, but lacks explicit '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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context by detailing the content of the remedy (remedy + day + donation + mantra) and the parameter behavior. No contradictions exist between description and annotations.
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: two sentences plus a group label and an example request body. Every part serves a purpose, with no unnecessary words. It is efficiently structured 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?
The description covers the main functionality and parameter usage. However, it lacks details about the output format or structure. Given that there is no output schema, a brief mention of the return type would improve 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?
Schema description coverage is 100% for birth data fields, which already describe the required parameters. The tool description adds meaning by explaining the effect of the optional 'planet' parameter on the output, going beyond the schema's structural 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 'Per-planet Lal Kitab remedies (upayas): the canonical Mathur-tradition remedy + day + donation + mantra.' It clearly identifies the tool's function and distinguishes it from sibling Lal Kitab tools that cover other topics like houses or dashas.
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 implicit usage guidance by explaining the effect of the optional 'planet' parameter ('With optional planet param, returns single-planet upaya; without, returns all 9'). However, it does not explicitly compare this tool to alternatives or specify when to use it over other Lal Kitab tools.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds the cost (50 credits, Tier 3) and group (Vedic), and reinforces the advisory nature. This provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: four sentences plus meta-data lines and an example. It front-loads the purpose and each sentence adds necessary information without redundancy. No wasted words.
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 7 parameters and no output schema, the description provides a good overview of purpose and usage context but does not describe the return format or explain all parameters. An AI agent might infer the output from 'auspicious-window scanner', but explicit details 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?
Schema description coverage is 0%, so the description should compensate. It includes an example request body that demonstrates some parameters (search_window_start, search_window_end, latitude, longitude, timezoneOffset) but does not explain all 7 parameters, especially ayanamsaId and topN. The example adds some value but is insufficient for full 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 it is an 'Auspicious-window scanner for elective surgery', using a specific verb and resource. It distinguishes itself from sibling muhurat tools by specifying 'surgery' and explains the inverted polarity for day preferences.
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 clear context for use, including that it is for elective surgery and that the output is advisory with medical scheduling taking precedence. However, it does not explicitly mention when not to use or compare with alternatives among the sibling muhurat tools.
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?
Annotations already provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds that it uses 'per-pair astro.com orb matrix' and returns specific fields (type, exactAngle, orb, isApplying). It does not contradict annotations. The description adds useful behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus group/cost and an example. It is highly concise, front-loaded with the core purpose, and every part adds value without redundancy.
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?
The tool returns an aspect list and the description explicitly lists the returned fields. There is no output schema, so the description adequately covers the return format. It also states what it excludes (planet positions, houses, midpoints). The example request body provides a complete usage pattern. Some minor gaps like default parameter values are covered by the schema.
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 all parameters are already described. The description includes an example request body with values for date, time, timezoneOffset, etc., which aids understanding but does not add significant semantic meaning 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 starts with 'Standalone aspect calculation — full inter-planetary aspect list with type / exactAngle / orb / isApplying,' clearly stating the tool's specific output. It explicitly contrasts with sibling tool 'chart' by noting it provides the same aspect calculation without planet positions/houses/midpoints overhead, effectively distinguishing its purpose.
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 'Same calcAspects() as /chart but without planet positions / houses / midpoints overhead,' guiding the agent to use this tool when only aspects are needed. While it doesn't explicitly state when not to use it, the context and sibling tools provide sufficient inference. The group and cost annotation also aid usage decisions.
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?
Annotations (readOnly, idempotent) already indicate safe, non-destructive behavior. The description adds meaningful behavioral context by listing specific computed outputs (companion/mother/output/control/wealth, clashes, trine support) beyond what annotations provide. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an example and group tag. Every sentence adds value: the first describes the action, the second lists outputs. No fluff.
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 vague schema (raw JSON body) and lack of output schema, the description does a good job explaining inputs via example and outputs via listed relations. It is almost complete for a yearly forecast tool, though more detail on the output format could help.
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 only describes a raw 'body' JSON object without properties. The description compensates by providing an explicit example ('natalDate','targetYear') that clarifies the required fields. This adds significant meaning beyond the schema, though schema coverage is 100% via the description.
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 compares target year pillar against natal day master and year branch, and returns specific element-flow relations, branch clashes, and trine support. It uses specific verbs and resources, distinguishing it from sibling BaZi tools like bazi_monthly or bazi_luck_pillars.
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 yearly BaZi forecasts via the title 'Yearly Forecast' and group tag 'BaZi (Four Pillars)'. However, it does not explicitly state when to use this vs. other BaZi tools, nor does it provide exclusion criteria or alternative tool names.
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?
Annotations already indicate safe, read-only, idempotent behavior. The description adds that it returns arcana with full meaning structure, which matches the annotations and provides useful behavioral context beyond the safety profile.
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 concise at two sentences plus metadata lines. It front-loads the core purpose and output details without unnecessary wording. Every piece of information serves a clear purpose.
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?
The description covers the output (full 22-position matrix with arcana types), the required input (date), and includes cost and group context. It does not explain the optional location/timezone parameters, but those are in the schema. Overall, it provides sufficient completeness for an agent to understand the tool's capability.
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 all parameters have descriptions in the schema. The description only mentions 'birth date' and shows an example with just 'date', but does not explain the optional latitude, longitude, and timezoneOffset parameters. The schema already does that, so the description adds minimal 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?
The description clearly states the tool calculates a Destiny Matrix via the Ladini method from a birth date, and lists the specific outputs (centre arcanum, body positions, soul positions, karmic and resource arcana with meaning structure). This distinguishes it from sibling tools which are diverse but mostly unrelated to this specific matrix method.
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 a group label ('Destiny Matrix'), a cost note, and an example request, giving context on when to use it. However, it does not explicitly compare to alternative matrix methods or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, non-destructive, and idempotent. The description adds value by explaining the calculation basis (Sun entering Gate 41), the range limit, and cost. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences plus group, cost, and an example. Every sentence adds value, and the purpose 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?
The tool is simple with two parameters and annotations cover safety. The description explains the core functionality and constraints. However, it does not describe the output format or structure, which 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 0% description coverage for the two required parameters. The description adds 'range of years' and an example request, partially compensating. However, it does not explain the valid format, allowed values, or behavior when parameters are null.
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 calculates 'Rave New Year dates' defined as 'exact moment Sun enters Gate 41' for a range of years. This is a specific verb and resource, distinct from sibling tools like hd_design_date.
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 tool is for a 'range of years' with a maximum of 50 years and provides an example request. However, it does not include explicit guidance on when not to use this tool or how it differs from similar tools like hd_design_date.
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?
Annotations already indicate read-only, non-destructive, idempotent, and closed world. The description adds that the horoscope is 'grounded in real ephemeris data' (current Moon phase, transits) and 'AI-written, not pre-generated', disclosing data freshness and content generation beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus group/cost info and an example. Key information (generate daily horoscope, data grounding, multi-language, AI-written) is front-loaded. No wasted words.
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 annotations and schema, the description covers the purpose, data source, language support, and cost. It lacks explanation of the return format and the disclaimer_inline parameter, but the overall context is sufficient for a straightforward daily horoscope 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 0%, so the description must compensate. It provides an example request body showing sign, date, and language, which adds some meaning. However, it does not explain the disclaimer_inline parameter or the date format beyond the example. This is minimally viable.
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 daily horoscope by zodiac sign, grounded in real ephemeris data. It specifies the verb 'Generate' and the resource 'daily horoscope', and distinguishes from siblings like horoscope_monthly, weekly, and yearly by focusing on daily readings.
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 clear context that the tool is for daily horoscopes, implying when to use it. However, it does not explicitly exclude other time periods or mention alternatives, though the title and content make the daily scope evident.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true. The description adds that the tool returns progressed planets, angles, and aspects to natal. It does not contradict annotations and provides useful output context.
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 two sentences with key info, plus a group/cost line and an example. It is front-loaded and no unnecessary text.
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 calculation tool with no output schema, the description explains the method and return contents. Cost and group are provided. It is sufficient for an agent to understand usage, though could mention that birth data and target date are required (already in schema).
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%, and schema includes descriptions for body properties. The tool description adds a concrete example request body, which helps 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 'Calculate secondary progressed chart (day-for-a-year) for a target date' and specifies outputs (planets, angles, aspects). It distinguishes from sibling tools like minor_progressions and tertiary_progressions by naming 'secondary' and the method.
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 target date but does not explicitly state when to use this versus alternative progression tools (e.g., minor, tertiary). No exclusions or when-not-to-use guidance 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, indicating safe, read-only behavior. The description adds that the tool draws a single card and returns a verdict based on card affinity, which is consistent with annotations. It does not contradict annotations and provides additional behavioral context (verdict logic).
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 group tag and an example. The core purpose is stated in the first sentence, and the example is front-loaded. Every element is necessary and no fluff exists.
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 yes/no draw tool, the description covers the key aspects: single-card draw, verdict type (yes/no/maybe), and example parameters. There is no output schema, but the description hints at the verdict structure. The tool is straightforward, so this level of detail is largely sufficient, though explicit output format would improve 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 input schema only specifies a 'body' object with a pointer to examples. The description provides an example with fields 'seed', 'question', and 'allowReversed', adding semantic meaning beyond the bare schema. However, it does not explicitly list field requirements or types, relying on the example to convey structure.
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 title 'RWS — Yes/No' and description 'Single-card draw with yes/no/maybe verdict from card affinity' clearly state the tool's purpose: drawing a single tarot card to provide a yes/no/maybe answer. This distinguishes it from sibling tools like 'tarot_rider_waite_draw_single' (which likely just draws a card without verdict) and other tarot draw 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 yes/no questions through its title and verdict description, but it does not explicitly state when to use this tool versus alternatives (e.g., other tarot draws, or non-tarot decision tools). No when-not-to-use or alternative recommendations are provided, leaving the agent to infer context.
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?
Annotations already indicate this is a safe, read-only operation. The description adds little beyond stating it resolves meanings, which is consistent but not further informative. No additional behaviors like rate limits or side effects 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?
The description is extremely concise: two sentences and an example, no redundant information. Every part contributes to understanding.
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?
The description covers purpose, usage, and example, but lacks details on the output structure. Given the simple input and existence of annotations, this is a minor gap.
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 only defines 'body' as a generic object, but the description provides a concrete example with 'cards' and 'question', filling the gap. However, it does not specify types, optionality, or accepted values, relying heavily on the example.
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 resolves card slugs into structured meanings with an example. It distinguishes itself from narrative interpretation by referencing AI /interpret/* tools, and the group tag clarifies the tarot system.
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 tells the agent to use separate narrative tools for full stories, providing a clear alternative. However, it does not explicitly list sibling tools or specify when not to use this tool.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so no contradiction. The description adds value by explaining that the tool returns a 'running cycle of 9 mahadashas from the chart' and details the period reductions (e.g., Ketu 7/3, Venus 20/3). This contextualizes the output beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences plus example) and front-loaded with key information: definition, scale, planet sequence, use case. Every sentence adds value, and the example request body is a helpful addition. No wordiness or redundancy.
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 states the output is 'the running cycle of 9 mahadashas from the chart' which provides basic completeness. For a dasha tool, this is sufficient context, though more detail on output format would increase completeness. The description adequately covers what the tool does and returns.
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 all parameters are documented in the schema. The description includes an example request body which is helpful but does not add per-parameter semantics beyond the schema. The baseline of 3 is appropriate since the schema already handles parameter documentation.
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 this tool computes the Tribhagi Mahadasha, a 1/3-scale variant of Vimshottari, with the same planet sequence and nakshatra-mapping rule. It explicitly distinguishes from Vimshottari by noting the scale factor and use case ('finer-grain timing'). The verb 'Returns the running cycle' is specific and tied to the resource 'Tribhagi Mahadasha'.
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 says 'Useful when finer-grain timing is needed within a Vimshottari-equivalent span', which provides clear guidance on when to use this tool versus the standard Vimshottari. While it does not list exclusions or enumerate alternatives, the context of many sibling dasha tools makes the guidance actionable.
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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false, so the tool is safe and idempotent. The description adds value by specifying it returns 'top-N days against universal Panchang criteria' and uses specific nakshatras and tithis. It does not contradict annotations and provides useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus an example, front-loading the purpose and usage. The group and cost lines are extra metadata but do not detract. The structure is efficient and clear.
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 generic nature and the presence of many specific muhurat siblings, the description sufficiently covers scope, criteria, and return type. No output schema exists, but the description says 'returns top-N days against universal Panchang criteria', which is adequate. The example provides partial parameter context, though full completeness is hindered by missing parameter explanations.
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 description coverage is 0%, so the description must compensate for parameter meaning. The description only provides an example request body showing five of the seven parameters but does not explain their purpose or constraints (e.g., ayanamsaId, topN behavior). This compensation is minimal and insufficient for full 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 it is a 'generic favourable-window finder' for when no specific activity applies, such as Sankalpa, prayer, or fallback. It mentions using universal Pushya/Hasta nakshatras and standard shubha tithis, which distinguishes it from other specific muhurat tools like vedic_muhurat_marriage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'when no specific activity applies (Sankalpa, prayer, fallback)', providing clear guidance on when to use this generic tool versus the specific activity tools. It implies not to use it for specific activities, which are handled by sibling tools.
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?
Annotations (readOnlyHint: true, idempotentHint: true) already indicate no side effects. The description adds the cost implication and mentions the output is a PDF, which is beyond annotations. No contradictions found.
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 sentences plus metadata and an example. Every sentence adds value: purpose, parameter behavior, cost warning, group label. Front-loaded with the core action. Highly efficient.
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?
Covers purpose, parameters, cost, and example. Lacks details on response format (e.g., whether PDF is returned as URL or binary) and authentication requirements, but these are implicit from context. Adequate 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 0%, so description must compensate. It explains the chart parameter's role (use own data vs sample) and the language parameter via example. However, the chart parameter's internal structure is not described, leaving ambiguity for an agent needing to construct 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 the tool renders a sample natal report PDF using the user's white-label configuration. It distinguishes from siblings like whitelabel_logo and render_wheel_western by specifying the output type (PDF report) and the use of white-label settings.
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 explains when to pass the chart parameter vs omitting it for a bundled sample. It includes a prominent cost warning ('Premium — ~50% of free monthly budget. Confirm with user before invoking.'), guiding agents to seek user confirmation. However, it does not explicitly exclude alternative 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?
Annotations indicate readOnly, non-destructive, idempotent. The description adds constraints on step and range, plus optional filter, which are beyond annotations. Includes cost tier and group tag. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three brief lines plus a clear example, no redundant information. Purpose and constraints are front-loaded. Every sentence adds value.
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 exists, so the description should hint at return format. It says 'Return planet positions' but does not describe the structure or fields. Given the tool's complexity (date range, step, planets), more detail on output would be beneficial. However, constraints and example partially compensate.
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?
With 0% schema coverage, the description adds meaning: 'configurable step (min 0.01 days)' explains stepDays, 'Optionally filter by planetIds' explains that parameter, and the example shows expected values. Only startDate and endDate are implicit but their format is in the schema pattern.
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 'Return planet positions for a date range with configurable step', which is a specific verb+resource. The tool is distinct from siblings like 'planets' or 'horoscope_daily' which typically return single-date or interpreted data.
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?
Provides explicit constraints (step min, max range for sub-day vs. larger steps) and optional filtering, helping the agent decide valid inputs. However, it does not explicitly compare to alternatives like 'planets' for single-date queries.
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?
Annotations already indicate readOnlyHint=true and idempotentHint=true, consistent with the description's 'recommend' operation. The description adds cost (10 credits) and group information, providing additional behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences plus a one-line example), front-loaded with purpose, and every element (group, cost, example) is necessary and earned. No wasted words.
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 (single input parameter, no output schema), the description covers the main purpose, input format via example, and cost. However, it does not describe the output structure beyond 'top-N matches with score', which would help completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a generic 'body' parameter with a description pointing to the tool description. The description compensates by providing an explicit example with fields (sunSign, moonSign, intent, limit), adding essential meaning that the schema lacks.
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 recommends crystals based on natal sign placements (Sun/Moon/Asc) and intent keywords, returning top matches with scores. The verb 'recommend' and resource 'crystals' are specific, and it distinguishes from siblings like 'wellness_crystals' by focusing on natal signs and intent.
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 an example request body and mentions the input format, but it does not explicitly state when to use this tool versus alternatives or when not to use it. It gives clear context but lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false. Description adds interpretative context ('inner motivations, private self') beyond computation, enhancing transparency without contradicting annotations.
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 lines plus example and group label. Every sentence is informative; no fluff. Front-loaded with purpose.
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 calculation tool with no output schema, the description adequately explains the purpose and provides an example. The group label aids discoverability. Could mention return format, but not essential given the name and example.
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%: date required, latitude/longitude/timezoneOffset optional. Description only provides an example request body with date, adding no further detail 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?
Clearly states 'Month-branch animal' and its meaning (inner motivations and private self). Differentiates from siblings like chinese_zodiac_animal (year) and chinese_zodiac_secret_animal (day). The group label adds 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?
Implicitly guides use via naming and sibling context: this is for month-branch, while year and day are handled by other tools. No explicit 'when to use' or 'when not to use', but the purpose is clear enough.
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?
Annotations already declare safe read-only behavior (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds value by specifying the return (new houses and planet positions) and including cost and example, but does not describe any side effects or edge cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus tags and example), with no redundancy. It front-loads the core purpose and adds metadata (group, cost) efficiently. Every sentence contributes value.
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 absence of an output schema, the description specifies the return (new houses and planet positions). The example covers essential inputs. However, it could mention that target latitude/longitude are required (as per schema) or explain constraints on valid coordinates. Still, for a relocation tool with annotations, it is largely 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?
Schema coverage is 100% (single body parameter with nested natal and target). The description provides a complete example request body, clarifying the structure. While the schema itself describes subfields, the example enhances understanding. No param details beyond the example, but sufficient given schema richness.
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 verb 'recalculate' and the resource 'natal chart for a new geographic location', distinguishing it from sibling tools like 'chart' (original natal) and 'acg' (astro-cartography). It specifies inputs (same birth moment, different lat/lng) and outputs (new houses and planet house positions), 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 implies use cases ('recalculate for a new location') but does not explicitly state when not to use it or mention alternatives. The group tag 'Astro-Geography' contextualizes it, but no direct comparison with related tools like 'chart' or 'solar_acg' is provided. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail ('12 fixed positions, signs rotate per ascendant') beyond the annotations (readOnlyHint, idempotentHint). It does not contradict annotations. It could mention output format or error handling, but the core behavior is disclosed.
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 an example. It front-loads the most critical information (layout type and rendering style) and uses the example efficiently. No extraneous text.
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 schema's thorough descriptions and the annotations, the description adequately covers the tool's purpose and key behavioral traits. The example provides practical context. A minor gap is the lack of description for the options object, but the schema covers it.
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 all properties. The description adds an example request body, which provides a concrete usage pattern beyond the schema alone. This enhances 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 'North Indian diamond chart layout' with '12 fixed positions, signs rotate per ascendant', which precisely identifies the tool's function. It distinguishes from sibling tools like render_wheel_vedic_east and render_wheel_vedic_south by specifying 'North Indian' style.
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 clear context for when to use this tool: for North Indian diamond chart rendering. However, it lacks explicit exclusions or comparisons to alternative Vedic wheel layouts, so it does not fully guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds key behavioral traits beyond annotations: it does not invoke endpoints, returns breakdown with tier annotations, and has a 5-minute cache TTL. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences covering purpose, output, usage guidance, and caching. Front-loaded with key information, no wasted words.
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 1-parameter tool with no output schema, the description fully explains input, behavior, output, caching, and usage context. All relevant details are present.
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 coverage, baseline is 3. The description adds context about credit estimation but no extra parameter details beyond schema's already clear definition.
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 estimates credit cost of endpoints without invoking them, and distinguishes from actual endpoint invocation. It specifies returns total + per-endpoint breakdown.
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?
Provides explicit when-to-use guidance: 'planning multi-step workflows: estimate first, ask user confirmation, then invoke.' Does not mention alternatives or exclusions, but clear context.
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?
Annotations show readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds context: it returns narrative text and token usage, and notes the token limit (≤3200 tokens). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs effectively convey purpose, inputs, outputs, and cost warning without redundancy. Every sentence adds value, and the structure is front-loaded with core information.
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 generative AI report with no output schema, the description explains return values (narrative text, model, token usage) and the astrological grounding. It provides sufficient context for an agent to understand what to expect.
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 25% (only chart described). The description clarifies enum options for language (21 codes), tone (warm/professional/concise), and length (short/medium/long; ≤3200 tokens), adding 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?
The description clearly states it produces a 'long-form natal-chart narrative (markdown)', specifies inputs (chart, language, tone, length), and distinguishes it from other AI narrative tools by focusing on natal chart with specific astrological components (Sun/Moon/Asc, 13 bodies, 12 houses, ≤25 major aspects).
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 includes a cost warning (250 credits, Tier 5) and advises to confirm with the user before invoking, indicating heavy usage. However, it does not explicitly compare to alternatives or state when not to use this tool.
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?
Adds context beyond annotations: deprecation timeline (6-month sunset), credit cost (20 credits), group label, and zodiac type. Annotations already indicate read-only, non-destructive, idempotent behavior; description aligns and provides additional operational details.
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 relatively brief but well-structured: deprecation notice, replacement link, group, cost, example, and warning. Some redundancy (DEPRECATED appears twice), but overall each sentence serves a purpose. The example is clearly formatted.
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 deprecated tool, the description covers essential context: what it does, how to call it (with example), and why to avoid it. No output schema is provided, but the description does not need to detail return values given deprecation and alternative endpoints. It sufficiently informs agent decision-making.
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%, baseline 3. Description adds value by showing a complete example request and highlighting the 'varga' parameter semantics (e.g., 'D9 Navamsha'). It also clarifies defaults for lat/lon/tz. These details go beyond the schema's field 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 calculates a Vedic divisional chart using sidereal zodiac, and prominently marks it as DEPRECATED with a replacement recommendation. This provides a specific verb-resource pair and distinguishes from sibling per-varga endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises against using this tool ('Avoid using') and directs the agent to dedicated per-varga endpoints. Also specifies supported vargas (D1–D60) and provides an example request body, giving clear guidance on when and how to use.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds that it returns a 'plain-text human-readable summary' and clarifies the budget-checking purpose, providing useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences: purpose, usage guidance, and return format. Front-loaded with key information, no wasted words.
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?
Despite lacking an output schema, the description specifies the return format (plain-text human-readable summary). For a simple status check tool, this is complete and sufficient.
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?
Tool has zero parameters, so schema coverage is 100%. Description does not need to explain parameters, and it adds value by hinting at the 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?
Description clearly states the verb 'Check' and the resource 'API key status' with specific attributes (tier, credit balance, rate limits, monthly cycle reset). It distinguishes itself from the many sibling astrology calculation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to run this tool BEFORE invoking expensive endpoints, providing credit thresholds (Tier 4+ at 100+ credits, Tier 6/7 at 500-5000 credits) to confirm budget.
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:

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

Score Badge

Copy to your README.md:

[![astroway-mcp MCP server](https://glama.ai/mcp/servers/astroway/astroway-mcp/badges/score.svg)](https://glama.ai/mcp/servers/astroway/astroway-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/astroway/astroway-mcp'

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