Server Quality Checklist

Tool Scores

• get_deep_readingB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It states the tool returns 'raw per-system output from the engine,' indicating a read operation, and mentions typo-tolerance for the system slug. However, it does not disclose whether the operation is destructive, requires authentication, or has rate limits.

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

  Conciseness3/5

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

  The description is front-loaded with the main purpose but then lists all 26 system slugs inline, making it verbose. The follow-up sentence about the PDF is useful but could be separated. Overall, it could be more concise by referencing a sibling tool or using a shorter list.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 absence of an output schema and the lack of explanation about the return format leaves the agent uninformed about what to expect. Additionally, the term 'chart input' is ambiguous; the description does not clarify how year, month, day, etc., contribute to the chart. This makes the tool definition incomplete for complex 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 only 25% schema description coverage, the description adds some value by listing valid system slugs, explaining typo-tolerance, and clarifying that lat/lon override location and time_known defaults. However, many parameters (year, month, day, hour, minute, lat, lon, timezone, lang) lack any description in both design, leaving meaningful 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's purpose: to get a focused reading for one specific divination system from 26. It specifies the required inputs (chart input plus system slug) and lists all possible system slugs, distinguishing it from siblings like list_26_systems and get_system_rules.

  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 a single system reading rather than the full PDF, referencing the PDF as an alternative. However, it does not explicitly state when to use this tool versus siblings (e.g., when to use get_system_rules instead), 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.

• daily_blessingA
  3.5/5.0
  Behavior3/5

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

  Discloses determinism, bias due to Cosmic Score, and return fields. Missing details on error handling, input validation, rate limits, or auth requirements. No annotations to supplement, so some gaps remain.

  Agents need to know what a tool does to the world before 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, front-loaded with main action. No extraneous words, though the 'simplified version' note adds little 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 4 params and no output schema, description covers deterministic behavior and return fields but lacks details on error cases, parameter dependencies, or how the optional 'date' interacts with required year/month/day.

  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 description does not compensate. Although it mentions 'birth date' and 'current date', it doesn't clearly map to the four parameters (year, month, day, date) or explain their roles beyond the schema's minimal 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 verb 'Draw' and resource 'deity card' from a specific collection. Distinguishes from sibling tools like calculate_cosmic_score or get_deep_reading by being a daily blessing draw.

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

  Usage Guidelines3/5

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

  Provides context on determinism and bias, but does not explicitly state when to use this tool vs alternatives or when not to use it. Sibling get_deep_reading could be an alternative but no comparison given.

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

• list_26_systemsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full burden. It states the tool returns a list with specific fields but does not disclose behavioral traits like idempotency, safety, or read-only nature. For a simple list, this is acceptable but could be improved.

  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 only two sentences, with no wasted words. It front-loads the purpose and provides all necessary information efficiently.

  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 has no parameters, no output schema, and sibling tools exist, the description is complete. It explains the content of the list and its intended use. It could optionally mention the output format (e.g., JSON array), but that is not critical.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is 100% (empty schema). Per guidelines, baseline is 4. The description adds value by detailing what each returned entry contains, which goes beyond the schema.

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

  Purpose5/5

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

  The description clearly states the tool returns a canonical list of 26 systems, specifies each entry's fields (slug, English name, Thai name, region, required input fields), and distinguishes it from sibling tools by mentioning 'canonical' and its use with get_deep_reading.

  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 advises 'Use this tool first when a user asks "what systems do you support?"', providing clear context. It does not mention when not to use it, but for a simple list tool this is adequate.

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

• calculate_cosmic_scoreA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses determinism ('same input always returns the same output'), behavior when time_known is false (flags approximate), and limitations of free preview (systems beyond free are noted with upsell). No destructive actions, so adequate 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 a single paragraph with front-loaded purpose. It is informative without fluff, listing examples of systems and explaining return structure. Could be slightly more structured (e.g., bullet points) but still concise.

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

  Completeness4/5

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

  With 12 parameters and no output schema, the description explains the return value (numeric score, tier, percentile, per-system summary) and covers key parameters' behavior. It is sufficiently complete for an AI agent to understand the tool's output and options.

  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 explaining typo-tolerant system names, time_known default inference from hour, and offline location resolution, going beyond the 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 starts with a clear verb+resource: 'Compute the Mythsensus Cosmic Score (1-999) for a birth date.' It distinguishes itself from sibling tools by being the core scoring function, unlike informational tools like about_mythsensus_engine or list_26_systems.

  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: computing a cosmic score for a birth date. It details optional parameters (systems[], time_known, location) but does not explicitly state when not to use this tool or mention alternatives like get_deep_reading. Still, the usage is clear from context.

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

• get_system_rulesA
  4.4/5.0
  Behavior5/5

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

  No annotations provided, so description fully discloses behavior: returns rules, optional system parameter (typo-tolerant), and return differences based on parameter presence. Also identifies as authoritative reference.

  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 comprehensive but somewhat verbose with imperative sentences. Front-loaded with main purpose, but could be more concise while retaining key info.

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

  Completeness4/5

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

  With 1 optional parameter and no output schema, description covers key aspects: what is returned, optional behavior, and authoritative nature. Lacks details on output structure but sufficient for 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 has 100% coverage, baseline 3. Description adds clarity by explaining that omitting system yields consensus methodology and overview, and passing it gives specific system ruleset. Additionally notes typo-tolerant, already in schema but reinforced.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 canonical interpretation rules with specific verb 'Return' and resource 'rules'. It distinguishes from siblings by emphasizing grounding in framework instead of improvising.

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

  Usage Guidelines4/5

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

  Explicitly tells when to use: 'to GROUND a divination/astrology answer in Mythsensus's framework instead of improvising'. Does not explicitly list alternatives but gives clear usage context.

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

• about_mythsensus_engineA
  4.7/5.0
  Behavior5/5

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

  With no annotations, description carries full burden. It discloses specific limitations (e.g., 'Vedic ayanamsa hardcoded, BaZi solar terms approximated') and mentions open-source roadmap, giving detailed transparency.

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

  Conciseness5/5

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

  Three sentences, front-loaded with purpose and contents, then usage guidance, then additional context. 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?

  Given no parameters and no output schema, description covers purpose, contents, and usage guidance sufficiently. It fully addresses what an agent needs to know to decide when to invoke this 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?

  No parameters, so baseline is 4. Description adds value by explaining what the tool returns (metadata, limitations, links), compensating for lack of parameter details.

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

  Purpose5/5

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

  Description clearly states it 'Return engineering-honest metadata about the Mythsensus engine' including architecture, tier, limitations, roadmap, and links. It distinguishes from sibling tools by specifying when to use it: when users ask about credibility or accuracy.

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

  Usage Guidelines4/5

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

  Explicitly says 'Use this tool when a user asks "is this real?" or "how accurate is it?"' providing clear usage context. Does not explicitly state when not to use, but the unique purpose is evident.

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