Server Quality Checklist

Tool Scores

• compute_constellation_trajectoryA
  3.6/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations. Annotations indicate read-only, non-destructive, and idempotent operations, but the description specifies 'deterministic interpolation (0 tokens)' (implying no token cost or randomness), 'cosine ease-in-out for perceptually smooth transitions,' and that each step includes 'full 5D coordinates.' This clarifies the algorithm, output format, and performance characteristics, enhancing transparency.

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

  Conciseness5/5

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

  The description is highly concise and well-structured. It uses three sentences: the first states the core purpose, the second adds technical details (deterministic, token-free), and the third explains the interpolation method and output utility. Every sentence adds value without redundancy, making it front-loaded and 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?

  Given the tool's complexity (interpolation between states), rich annotations (read-only, idempotent), and the presence of an output schema, the description is mostly complete. It covers purpose, algorithm, and output format, but could improve by clarifying how it differs from sibling tools or specifying error conditions. The output schema likely handles return values, so the description doesn't need to detail them.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 fully documents parameters (state_a, state_b, steps). The description doesn't add specific parameter semantics beyond what's in the schema, such as explaining 'canonical state' further or detailing interpolation mechanics. It meets the baseline of 3 since the schema handles parameter documentation 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 the tool's purpose: 'Compute smooth interpolation trajectory between two canonical states.' It specifies the verb ('compute'), resource ('trajectory'), and scope ('between two canonical states'), but doesn't explicitly differentiate from siblings like 'apply_constellation_preset' or 'generate_constellation_composition' which might involve similar state transitions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 minimal usage guidance. It mentions the trajectory is 'suitable for attractor prompt generation or multi-domain composition input,' which hints at downstream uses, but doesn't specify when to choose this tool over alternatives like 'generate_constellation_attractor_prompt' or 'generate_constellation_composition.' No explicit when/when-not rules or prerequisites are stated.

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

• generate_constellation_compositionA
  4.2/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: 'deterministic zero-LLM-cost approach' (efficiency and consistency), 'highly efficient for batch processing' (performance characteristics), and 'geometric translation' (methodology). It doesn't contradict annotations and provides useful implementation 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?

  The description is well-structured with clear sections: purpose statement, methodology note, Args, and Returns. It's appropriately sized for the tool's complexity. However, the Args section could be more concise since it largely repeats schema information, and the methodology note could be integrated more seamlessly.

  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 moderate complexity, rich annotations (readOnly, idempotent, etc.), 100% schema coverage, and detailed output schema in the Returns section, the description provides complete context. It explains what the tool does, how it works (deterministic geometric translation), what inputs it expects, and what outputs it produces, leaving no 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.

  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 thoroughly. The description's Args section restates parameter names but adds minimal semantic value beyond the schema. It does clarify that 'include_mythology' affects 'mythological themes' and 'response_format' controls output structure, but this is largely redundant with 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's purpose: 'Translates astronomical star patterns into practical compositional guidance for image generation.' It specifies the verb ('translates') and resource ('astronomical star patterns') while distinguishing from siblings like 'get_constellation_coordinates' (raw data) or 'apply_constellation_preset' (applying existing presets).

  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 image generation' and 'consistent results for batch processing.' It implies when to use this tool (needing composition guidance from constellations) but doesn't explicitly contrast with alternatives like 'generate_constellation_attractor_prompt' (which might focus on prompts rather than composition parameters) or 'apply_constellation_preset' (which applies existing presets rather than generating new ones).

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

• list_all_constellationsA
  4.2/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond this: it specifies the exact count (22 constellations), the type of information returned (abbreviations, primary themes), and characterizes it as a 'quick overview' for 'browsing options'. This enhances understanding 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 a clear purpose statement, usage context, and separate Args/Returns sections. It is appropriately sized, but the Args section repeats schema information without adding value, slightly reducing efficiency. Most sentences earn their place by providing useful context.

  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 low complexity (1 optional parameter), rich annotations (safety and behavior hints), and existence of an output schema (implied by 'Returns' note), the description is complete. It covers purpose, usage context, and output content adequately without needing to detail return values or behavioral traits already in annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameter 'response_format' fully documented in the schema (enum values, default). The description repeats this information in the Args section but adds no additional semantic meaning beyond what the schema provides, such as guidance on when to choose one format over another. Baseline 3 is appropriate given high schema coverage.

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

  Purpose5/5

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

  The description clearly states the verb ('List') and resource ('all available constellations'), specifying the scope as 'all 22 major constellations' with 'basic information including abbreviations and primary themes'. It distinguishes from siblings like 'search_constellations' (filtered search) and 'list_constellation_presets' (presets rather than constellations).

  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 usage ('useful for browsing options or understanding the full scope'), but does not explicitly state when not to use it or name specific alternatives. It implies this is for a complete overview vs. filtered searches, but lacks explicit exclusions or named sibling tool comparisons.

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

• generate_constellation_attractor_promptA
  4.3/5.0
  Behavior4/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, covering safety and idempotency. The description adds valuable context beyond this: it explains the tool's role as 'Layer 2: Deterministic vocabulary extraction (0 tokens)' and mentions that coordinates can be 'derived from a canonical state name.' This provides insight into the tool's deterministic nature and input flexibility, though it doesn't detail 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.

  Conciseness5/5

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

  The description is well-structured and front-loaded: the first sentence states the core purpose, followed by layers, translation details, and output modes. Every sentence adds value—explaining the tool's phase, output formats, and input options—with zero wasted words. It's appropriately sized for the tool's complexity.

  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 moderate complexity, rich annotations (readOnly, idempotent, etc.), 100% schema coverage, and the presence of an output schema, the description is complete enough. It covers purpose, usage context, behavioral traits, and parameter semantics without needing to explain return values (handled by output schema). No significant gaps remain 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 description coverage is 100%, so the schema already fully documents all parameters (coordinates, canonical_state, mode, strength). The description adds some semantic context by mentioning '5D parameter coordinates' and listing the three output modes with brief explanations, but this largely repeats or paraphrases what's in the schema. No additional parameter details beyond the schema are 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's purpose: 'Generate image-generation-ready prompts from 5D constellation coordinates.' It specifies the verb ('Generate'), resource ('prompts'), and source ('5D constellation coordinates'), distinguishing it from siblings like 'generate_constellation_composition' or 'get_constellation_visual_types' which handle different aspects of the constellation 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 provides clear context for when to use this tool: 'Translates abstract parameter coordinates into concrete visual vocabulary suitable for Stable Diffusion, ComfyUI, DALL-E, or Midjourney.' It also explains the three output modes and their best-use cases (e.g., 'composite' for direct image generation). However, it doesn't explicitly state when NOT to use it or name specific alternatives among sibling tools.

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

• get_constellation_domain_registry_configA
  4.3/5.0
  Behavior3/5

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

  Annotations already cover key behavioral traits (readOnlyHint: true, destructiveHint: false, idempotentHint: true), so the description adds value by specifying it's a 'Pure lookup' with '0 tokens' and details the return content. It does not contradict annotations, but could provide more context like rate limits or auth needs 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 front-loaded and concise, with every sentence earning its place: the first states the purpose, the second clarifies it's a lookup with no cost, and the third details the return content. There is no wasted information, making it efficient for agent comprehension.

  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 (registry configuration), rich annotations, and the presence of an output schema, the description is complete enough. It explains what the tool does, its behavioral context, and the return content, without needing to detail output values since an output schema exists.

  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 parameters and 100% schema description coverage, the baseline is high. The description compensates by explaining that no inputs are needed ('Pure lookup (0 tokens)'), which adds semantic clarity beyond the empty schema, ensuring the agent understands this is a parameterless operation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with specific verbs ('Return', 'lookup') and resources ('Tier 4D integration configuration', 'domain signature'), distinguishing it from siblings like 'get_constellation_coordinates' or 'list_constellation_presets' by focusing on registry configuration rather than coordinates, presets, or other 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 provides clear context for usage ('for registering with aesthetic-dynamics-core multi-domain composition'), implying this tool is needed for integration purposes. However, it does not explicitly state when not to use it or name specific alternatives among the siblings, such as 'get_constellation_coordinates' for different data types.

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

• list_constellation_presetsA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations: it specifies this is a 'pure taxonomy lookup (0 tokens)' operation, describes what data is returned (preset names, periods, oscillation patterns, etc.), and explains the purpose of presets. No contradiction with annotations 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 efficiently structured with two sentences: the first states the core purpose and return data, the second explains the broader context of presets. Every phrase adds value without redundancy. The 'Layer 1' note is concise and informative.

  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 simplicity (one optional parameter, read-only operation), rich annotations, and existence of an output schema, the description is complete. It explains what the tool does, what data it returns, and the purpose of presets. The output schema will handle return value documentation, so the description appropriately focuses on 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 only one optional parameter (response_format) fully documented in the schema. The description doesn't mention parameters at all, which is acceptable given the high schema coverage. However, it doesn't add any semantic context about parameter usage beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and resource 'Phase 2.6 rhythmic presets' with their parameters. It distinguishes from siblings like 'apply_constellation_preset' (which applies rather than lists) and 'list_all_constellations' (which lists constellations rather than presets). The mention of 'pure taxonomy lookup' further clarifies this is a retrieval operation.

  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 'taxonomy lookup' of presets with their parameters, and mentions their purpose for 'rhythmic composition and Tier 4D multi-domain limit cycle discovery.' However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings, though the context implies it's for listing rather than applying presets.

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

• search_constellationsA
  4.3/5.0
  Behavior4/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 valuable context about what the tool returns (constellation details including mythology, visual characteristics, and shape patterns) and mentions the response_format parameter for output control. It doesn't describe rate limits or authentication needs, but 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 efficiently structured with a clear purpose statement, usage context, and parameter/return information in separate sections. Every sentence adds value without redundancy. The Args and Returns sections are appropriately formatted and concise.

  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 comprehensive annotations, 100% schema description coverage, and an output schema (implied by the Returns section), the description provides complete context. It explains what the tool does, when to use it, what parameters control, and what information is returned, making it fully adequate for this search 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 fully documents all parameters. The description adds minimal value beyond the schema - it mentions the response_format parameter and implies search capabilities, but doesn't provide additional syntax, format details, or usage examples beyond what's in the schema descriptions. This meets the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool searches for constellations using specific criteria (name, theme, visual characteristics, shape) and returns detailed information. It distinguishes from siblings like 'list_all_constellations' (which presumably lists all without filtering) and 'get_constellation_coordinates' (which focuses on coordinates rather than thematic search).

  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 ('useful for discovering which constellations match specific compositional needs or thematic requirements'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for search-based discovery rather than listing or coordinate retrieval.

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

• apply_constellation_presetA
  4.4/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations by specifying 'Layer 2: Deterministic sequence generation (0 tokens)' and describing the output format ('trajectory of 5D coordinate states'). While annotations cover safety (readOnlyHint=true, destructiveHint=false), the description provides implementation details about the generation process and output structure that aren't captured 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.

  Conciseness4/5

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

  The description is well-structured and efficiently communicates purpose, process, and usage in three focused sentences. Each sentence serves a distinct purpose without redundancy, though the technical terminology makes it somewhat dense.

  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 presence of comprehensive annotations (readOnlyHint, idempotentHint, etc.), 100% schema coverage, and an output schema (implied by 'Has output schema: true'), the description provides excellent contextual completeness. It explains what the tool does, how it fits into workflows, and what the output contains without needing to repeat structured information.

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

  Parameters3/5

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

  With 100% schema description coverage, the input schema already fully documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation without providing additional semantic context 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 specific action ('Apply a Phase 2.6 rhythmic preset') and the outcome ('generating a complete oscillation sequence over one full period'). It distinguishes itself from siblings by focusing on preset application rather than computation, generation, or listing operations mentioned in 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 Guidelines5/5

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

  The description explicitly states when to use this tool's output by naming three specific downstream tools ('Tier 4D integrate_forced_limit_cycle', 'Tier 4D integrate_forced_limit_cycle_multi_domain', 'Phase 2.7 generate_constellation_attractor_prompt'). This provides clear guidance on the tool's role in a workflow context.

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

• get_constellation_visual_typesA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that this is a 'Pure taxonomy lookup (0 tokens)'—implying no computational cost or token usage—and that it returns 'the complete visual vocabulary catalog,' which suggests a comprehensive, static list. This enhances understanding of the tool's behavior 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?

  The description is front-loaded with the core purpose in the first sentence, followed by supporting details in a structured way. Every sentence adds value: the first defines the action, the second specifies cost and context, and the third elaborates on the output's significance. There is no wasted text, and it efficiently conveys key information in three concise sentences.

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

  Completeness5/5

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

  Given the tool's simplicity (0 parameters, annotations covering safety, and an output schema present), the description is complete. It explains what the tool does, its context ('used by the attractor prompt generator'), and the nature of the output ('complete visual vocabulary catalog' with '5D constellation parameter space'). With an output schema handling return values, no additional details are needed, making this description fully adequate for the agent's needs.

  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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline of 4 for zero parameters, as it avoids unnecessary details and compensates by explaining what the tool returns.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 action ('List all constellation visual types') and the resources involved ('with their coordinates and keywords'). It distinguishes from siblings like 'list_all_constellations' (which lists constellations, not visual types) and 'get_constellation_coordinates' (which gets coordinates for specific constellations, not visual types). The description provides precise scope: 'complete visual vocabulary catalog used by the attractor prompt generator' and 'Each visual type represents a region of the 5D constellation parameter space'.

  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: 'Pure taxonomy lookup' and 'Returns the complete visual vocabulary catalog used by the attractor prompt generator.' It implies this is for getting the full catalog of visual types, not for searching or applying them. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, though the context suggests it's distinct from tools like 'search_constellations' or 'apply_constellation_preset'.

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

• get_server_infoA
  4.5/5.0
  Behavior4/5

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

  Annotations already cover key behavioral traits (read-only, non-destructive, idempotent, closed-world), but the description adds valuable context beyond this. It specifies the tool returns 'comprehensive information' including 'available tools, parameter space dimensions, canonical states, rhythmic presets, and visual vocabulary types,' which helps the agent understand the scope and format of the response 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?

  The description is highly concise and well-structured, with two sentences that efficiently convey the tool's purpose and return details. The first sentence states the core function, and the second elaborates on the response content, with no wasted words or 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 (server metadata query), rich annotations, and the presence of an output schema, the description is complete enough. It clearly explains what the tool does and what information it returns, without needing to detail parameters or output values, as these are covered by the structured data.

  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 parameters and 100% schema description coverage, the baseline is 4 as no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's output and purpose, which aligns with the empty 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's purpose with specific verbs ('Get server metadata, capabilities, and Phase 2.6/2.7 status') and resources ('constellation composition server'). It distinguishes itself from siblings by focusing on server-level information rather than constellation-specific operations like 'get_constellation_coordinates' or 'list_all_constellations'.

  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 usage by specifying it returns 'comprehensive information about the constellation composition server,' implying it should be used for server-level queries. However, it does not explicitly state when not to use it or name alternatives, such as using sibling tools for constellation-specific data instead.

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

• get_constellation_coordinatesA
  4.7/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond this: it specifies that it's a 'Pure taxonomy lookup (0 tokens)' (implying no computational cost), explains the difference in behavior for state vs. constellation names, and lists concrete applications for the output. No contradiction with annotations 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 efficiently structured: the first sentence states the core purpose, followed by a bullet-point-like breakdown of behavior and use cases. Every sentence adds value—no fluff or repetition. It's front-loaded with the main functionality and appropriately sized for the tool's complexity.

  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 moderate complexity (2 parameters, 1 required), rich annotations (covering safety and idempotency), and the presence of an output schema (which handles return values), the description is complete. It covers purpose, usage guidelines, parameter semantics, and behavioral context without needing to explain outputs or repeat annotation 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 description coverage is 50% (only 'response_format' has a description). The description compensates by clarifying the semantics of the 'name' parameter: it explains that it accepts either a 'canonical state name' (e.g., 'orion_grandeur') or a 'constellation name' (e.g., 'Orion'), which is crucial information not in the schema. However, it doesn't detail the 'response_format' parameter beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the specific action ('Extract normalized 5D parameter coordinates') and resource ('for a canonical state or constellation name'), distinguishing it from siblings like 'list_all_constellations' (which lists names) and 'compute_constellation_trajectory' (which uses coordinates). It specifies the exact output type and scope.

  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 provides explicit guidance on when to use this tool vs alternatives: 'If a canonical state name is given... returns its exact coordinates. If a constellation name is given... returns the nearest canonical state's coordinates with distance metric.' It also lists specific use cases (e.g., trajectory computation, rhythmic composition) and distinguishes from siblings like 'search_constellations' (which likely returns names rather than coordinates).

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