Server Quality Checklist

Tool Scores

• astral_agent_manifestA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, non-destructive operations. The description adds behavioral context by specifying it includes agent rules (e.g., 'resolve birthplace first') and troubleshooting, which go 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?

  Two sentences, front-loaded with key information. The first sentence efficiently lists contents; the second gives clear usage instruction. However, it could be slightly more concise by omitting redundant phrases like 'agent-oriented setup and usage guide' (two similar terms).

  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 tool is a manifest/guide, the description fully covers what it provides (install, rules, troubleshooting) and mentions output formats. It is complete for an agent seeking an overview of how to use astral-mcp, especially with an output schema available.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 the enum parameter 'response_format'. The description adds high-level context about the tool being a 'guide' but doesn't elaborate on how parameter values affect output beyond what the schema states. 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 is an 'agent-oriented setup and usage guide' and lists specific contents (install command, recommended first calls, tool list, agent rules, troubleshooting). It distinguishes itself from sibling tools like astral_capabilities and astral_demo by being the entry point for learning how to drive the MCP.

  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 advises 'Call this to learn how to drive astral-mcp correctly,' implying it should be invoked first. It lists what the guide covers, helping agents decide when to use it, though it doesn't explicitly state when not to use it or mention alternative tools for specific tasks.

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

• astral_connection_statusA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by explaining the internal process (sample chart, dual-engine audit) and the stateless/local nature, which are 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.

  Conciseness5/5

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

  The description is three sentences, front-loaded with 'Health check,' and each sentence adds value. No unnecessary 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?

  The tool is simple with 0 required parameters and an output schema exists. The description covers purpose, behavior, and usage context adequately. No gaps.

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

  Parameters3/5

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

  Schema coverage is 100%, and the parameter is simple. The description does not add additional meaning beyond the schema's description of response_format. Baseline score of 3 is appropriate as no extra parameter guidance is needed.

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

  Purpose5/5

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

  The description clearly identifies the tool as a health check with specific actions: verifying Node version, testing ephemerides, computing a sample chart, and running a precision audit. It distinguishes from sibling tools like astral_compute_natal_chart by being a diagnostic rather than a chart computation tool.

  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 states when to use: 'Call this to confirm the install is working before computing real charts.' This provides clear context, though it does not list explicit alternatives or exclusions. The usage is well-defined.

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

• astral_data_inventoryA
  4.3/5.0
  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 beyond annotations: 'Does not compute anything or take any input beyond response_format' reinforces the read-only, no-side-effect behavior. It also clarifies the scope of what is inventoried.

  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, no wasted words. The main action ('Inventory...') is front-loaded. Every sentence adds essential information about purpose, scope, and constraints.

  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 low parameter count (1, optional, with full schema coverage), rich annotations, and existence of an output schema (though not provided), the description is complete. It explains what the tool returns (domains and tools), that it's read-only, and that it requires no substantive 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%, so baseline is 3. The description mentions that the tool 'take any input beyond response_format', which repeats the schema. The description of the parameter in the schema already explains the output shape. The description adds little new semantic value beyond what the schema provides.

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

  Purpose5/5

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

  Description clearly states the tool's purpose: 'Inventory the data domains this server exposes (natal, transits, relationship, geocoding), which tools serve each, and the recommended first calls.' It uses a specific verb ('Inventory') and resource ('data domains'), differentiating it from sibling tools like astral_compute_natal_chart or astral_current_transits which perform computations. The added clarification 'Does not compute anything' further distinguishes it.

  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 understanding server capabilities and recommended initial calls. It explicitly states 'Does not compute anything,' signaling when not to use it. However, it does not explicitly mention alternative tools or when to prefer this over others, though the context makes it clear it's a meta tool.

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

• astral_moon_phaseA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, making safety clear. The description adds that it's location-independent and requires no birth data, providing additional behavioral 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.

  Conciseness5/5

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

  The description is three sentences with zero wasted words. It front-loads the main action and outputs, follows with uniqueness (location-independence), and ends with use cases. Every sentence earns its place.

  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 read-only lookup tool with 4 optional parameters and an output schema, the description covers purpose, inputs, uniqueness, and use cases. No critical 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%, so the input schema already documents each parameter's purpose. The description does not add new parameter-specific information beyond summarizing the overall functionality. It meets the baseline but does not exceed 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 verb 'Get' and the resource 'moon phase' with specific attributes (phase, sign, illumination, angle). It differentiates from siblings by highlighting 'Location-independent — no birth data needed', distinguishing it from tools like astral_compute_natal_chart. Use cases are explicitly listed.

  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 now or a chosen local date/time' and 'location-independent'. It lists use cases (ritual timing, journaling prompts) but does not explicitly state when not to use this tool or mention alternative siblings. Nonetheless, the context is sufficient for most scenarios.

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

• astral_capabilitiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds context about the content (e.g., no interpretations) and recommended workflow, which goes beyond annotations.

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

  Conciseness5/5

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

  The description is two sentences with no redundancy. The first sentence lists key content, the second provides a directive. 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.

  Completeness5/5

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

  Given the tool is a capabilities overview, the description covers included/excluded items and workflow. Output schema handles return structure. The description is fully adequate 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?

  Schema covers 100% of the single parameter with enum and description. The description adds meaning by explaining the difference between 'markdown' and 'json' outputs, helping the agent choose appropriately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 specific verb 'explain' and resource 'astral-mcp capabilities', listing included and excluded items. It clearly distinguishes from sibling tools by being the general overview.

  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 'Read this first to plan a sequence of calls', providing clear when-to-use guidance. It also lists what is NOT included, helping avoid misuse. However, it does not explicitly state alternatives.

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

• astral_compute_natal_chartA
  4.5/5.0
  Behavior4/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 important behavioral details: by default a second ephemeris audits precision, and missing birth_time defaulting to noon reduces house accuracy. This adds value 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 well-structured with front-loaded purpose and clear separation of key points. While it is somewhat long, every sentence contributes necessary information. Minor redundancy in parameter descriptions could be trimmed, but overall it earns its length.

  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 tool has an output schema (indicated by context signals), the description does not need to detail return format. It covers all essential aspects: purpose, prerequisites (astral_search_birthplace), parameter behaviors, and privacy modes. This is fully adequate for a complex computational tool.

  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?

  All 10 parameters have descriptions in the schema, and the tool description adds meaningful context beyond the schema. For example, it explains how to resolve latitude/longitude/timezone via astral_search_birthplace, warns about date range precision, and details the effect of missing birth_time. The description of privacy_mode parameter is particularly thorough.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 full natal chart from birth data, listing specific outputs like planet signs, aspects, and chart signature. It distinguishes itself from the sibling tool astral_search_birthplace by indicating that tool is for resolving location data before using this one.

  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 guidance: it is the primary tool, and if only a city name is available, astral_search_birthplace should be called first. It also explains when to use different privacy_mode settings (summary for quick read, full for detailed). However, it does not explicitly list situations where other tools 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.

• astral_search_birthplaceA
  4.5/5.0
  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. The description adds that the tool is free and requires no API key, and that it returns multiple matches to choose from. This goes beyond annotations but could still elaborate on error cases 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?

  Three sentences, all essential, no fluff. The most critical information (what it does, free, call first) is front-loaded. Every sentence adds value.

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

  Completeness5/5

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

  The description covers the tool's purpose, workflow integration, and expected output selection. Given the presence of an output schema and low tool complexity, this is fully sufficient 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.

  Parameters3/5

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

  Schema coverage is 100% with good descriptions. The tool description adds little beyond the schema: it mentions the query example 'Fortaleza, Brazil' and the response_format values. Given 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 the tool geocodes a place name into latitude, longitude, and IANA timezone using OpenStreetMap. It specifies the verb 'geocode' and the resource 'city or place name'. It also distinguishes this tool from sibling chart tools by indicating this should be called first.

  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 'Call this FIRST' and instructs to pass the returned coordinates/timezone to chart tools. It also notes that several matches are returned and the agent should pick the one matching the intended birthplace. This provides clear when-to-use and how-to-process instructions.

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

• astral_current_transitsA
  4.6/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, etc. Description adds valuable context such as return contents (aspects, windows, moon phase), behavior of on_date/on_time, and effect of privacy_mode levels. 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 well-structured with front-loaded purpose, followed by output details, data requirements, use case, and parameter options. Efficiently uses sentences without redundancy.

  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 tool's complexity (12 parameters, enums, output schema exists), the description covers all key aspects: input requirements, output nature, parameter nuances, and use case. Output schema covers return values, so additional details are not necessary.

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

  Parameters4/5

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

  Schema covers all 12 params with descriptions (100% coverage). The tool description adds extra semantic value by explaining how privacy_mode levels affect payload and the use of on_date/on_time for specific moments, going beyond schema.

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

  Purpose5/5

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

  Description clearly states verb 'Read' and resource 'planetary transits against a natal chart'. It distinguishes from siblings by focusing on transits specifically, citing use case 'what's happening for me astrologically'.

  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 tool is for transit questions and provides guidance on privacy_mode. Does not explicitly mention when to use alternatives like astral_compute_natal_chart, but the sibling list and context make it clear.

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

• astral_demoA
  4.7/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent/destructive annotations, the description adds important behavioral context: no network, no auth, no required input, and a clear mapping between the returned 'input' and 'chart' fields. This gives the agent a precise mental model of what will happen when invoked.

  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 dense but every clause earns its place: it front-loads the purpose, gives the example details, explains the output structure, and finishes with cost/access characteristics. There is no filler or repetition.

  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 zero-required-parameter demo tool with an output schema, the description is complete: it explains what the example contains, how it relates to the real compute tool, and that no network or auth is needed. Nothing essential 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 description coverage is 100% for the single optional response_format parameter, including its enum and default. The description does not need to restate that; it adds no extra parameter-level meaning, which matches the baseline 3 for fully-schema-covered 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 states a specific verb ('Return') and resource ('fully-worked example natal chart'), and explains exactly what the demo provides: a precision audit and exact payload shape. It clearly distinguishes itself from astral_compute_natal_chart by framing this as a pre-flight example rather than a real computation.

  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?

  It explicitly tells the agent when to use this tool: before sending real birth data, to inspect the payload shape. It also names the alternative (astral_compute_natal_chart) and explains how to use the output as a template for that call, which is strong usage guidance.

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

• astral_synastryA
  4.8/5.0
  Behavior5/5

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

  Discloses behavioral traits beyond annotations: mentions that missing birth_time reduces house/ascendant accuracy, and describes privacy_mode levels. No contradiction with annotations (readOnlyHint, idempotentHint, destructiveHint).

  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 with clear structure: main purpose, then prerequisites, then options. 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.

  Completeness5/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, nested objects, and output schema, the description covers prerequisite resolution, optional parameters, and edge cases (missing birth_time). Complete given available 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?

  Schema coverage is 100%, and description adds value by explaining usage (e.g., resolve with astral_search_birthplace, privacy_mode meanings, response_format options). Enhances understanding beyond 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 compares two birth charts (synastry) and returns inter-chart aspects, scored dimensions, and an overall score. It distinguishes from sibling tools like astral_compute_natal_chart (single chart) and astral_current_transits.

  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 instructs to resolve city names with astral_search_birthplace first and provides guidance on privacy_mode options. Lacks explicit when-not-to-use scenarios, but the context is generally clear.

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