Exports constellation metadata and compositional thematic guidance in Markdown format for integration into documentation and AI prompts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Constellation Composition MCP Server map the Orion constellation to a 1024x1024 canvas layout"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that translates astronomical constellation patterns into compositional parameters for AI image generation.
22 major constellations with geometric and mythological metadata
Zero-LLM-cost deterministic mapping from star patterns to focal points
Mythology integration for thematic guidance
Multiple output formats (JSON and Markdown)
Canvas scaling from 512x512 to 4096x4096 pixels
Related MCP server: astronomy-oracle
pip install -e ".[dev]"Add to Claude Desktop configuration:
{
"mcpServers": {
"constellation-composition": {
"command": "constellation-composition-mcp"
}
}
}from constellation_composition_mcp.server import (
generate_constellation_composition,
search_constellations
)
# Search for constellations
results = await search_constellations(query="hunting")
# Generate composition
composition = await generate_constellation_composition(
constellation_name="Orion",
canvas_width=1920,
canvas_height=1080
)search_constellations - Search by theme, shape, or brightness
generate_constellation_composition - Map constellation to composition parameters
list_all_constellations - Browse all available constellations
# Install with dev dependencies
pip install -e ".[dev]"
# Run tests
./tests/run_tests.sh
# Format code
black src/ tests/
ruff check src/ tests/See docs/ directory for detailed documentation:
Architecture overview
Integration examples
Constellation database reference
MIT License - See LICENSE file for details
Dal Marsters - Lushy.app
Apply a Phase 2.6 rhythmic preset, generating a complete oscillation sequence over one full period.
Layer 2: Deterministic sequence generation (0 tokens).
Returns a trajectory of 5D coordinate states tracing one complete cycle of the preset oscillation. This output is directly usable by:
Tier 4D integrate_forced_limit_cycle for single-domain orbits
Tier 4D integrate_forced_limit_cycle_multi_domain for composition
Phase 2.7 generate_constellation_attractor_prompt for keyframe prompts
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for applying a rhythmic preset. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Compute smooth interpolation trajectory between two canonical states.
Layer 2: Deterministic interpolation (0 tokens).
Uses cosine ease-in-out for perceptually smooth transitions. Each step includes full 5D coordinates suitable for attractor prompt generation or multi-domain composition input.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for computing trajectory between two constellation states. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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 image-generation-ready prompts from 5D constellation coordinates.
Layer 2: Deterministic vocabulary extraction (0 tokens).
Translates abstract parameter coordinates into concrete visual vocabulary suitable for Stable Diffusion, ComfyUI, DALL-E, or Midjourney. Three output modes are available:
composite: Single prompt string combining keywords and geometric specs. Best for direct image generation.
split_keywords: Categorized keyword lists (visual type, specifications, parameter descriptors). Best for ComfyUI prompt engineering.
descriptive: Narrative paragraph prompt. Best for DALL-E / Midjourney.
Coordinates can be provided directly, or derived from a canonical state name.
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for generating image-generation prompts from attractor coordinates. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Generate detailed composition parameters mapped from a constellation's geometry and mythology.
Translates astronomical star patterns into practical compositional guidance for image generation, including focal point placement, visual flow, balance characteristics, and thematic elements derived from constellation mythology.
This uses a deterministic zero-LLM-cost approach for geometric translation, making it highly efficient for batch processing and consistent results.
Args: params (ConstellationCompositionInput): Configuration including: - constellation_name: Name or abbreviation of constellation - canvas_width: Target canvas width in pixels (512-4096) - canvas_height: Target canvas height in pixels (512-4096) - include_mythology: Include mythological themes (boolean) - response_format: Output format (json or markdown)
Returns: str: Structured composition parameters in requested format, including: - focal_points: List of primary visual anchors with positions and weights - visual_flow: Directional movement and rhythm patterns - balance: Visual balance type and center of mass - spatial_distribution: How elements spread across frame - mythology_themes: Key thematic elements from constellation story - suggested_elements: Concrete suggestions for subjects, lighting, atmosphere, colors
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for generating composition from constellation. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Extract normalized 5D parameter coordinates for a canonical state or constellation name.
Layer 1: Pure taxonomy lookup (0 tokens).
If a canonical state name is given (e.g. 'orion_grandeur'), returns its exact coordinates. If a constellation name is given (e.g. 'Orion'), returns the nearest canonical state's coordinates with distance metric.
Coordinates are suitable for:
Trajectory computation (Phase 1A)
Rhythmic composition input (Phase 2.6)
Attractor visualization (Phase 2.7)
Multi-domain composition (Tier 4D)
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| response_format | No | Output format for responses. | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Return Tier 4D integration configuration for compositional limit cycles.
Layer 2: Pure lookup (0 tokens).
Returns the domain signature for registering with aesthetic-dynamics-core multi-domain composition. Includes domain_id, parameter names, preset periods, and canonical state coordinates — everything needed for integrate_forced_limit_cycle_multi_domain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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 all constellation visual types with their coordinates and keywords.
Layer 1: Pure taxonomy lookup (0 tokens).
Returns the complete visual vocabulary catalog used by the attractor prompt generator. Each visual type represents a region of the 5D constellation parameter space with associated image-generation keywords.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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 metadata, capabilities, and Phase 2.6/2.7 status.
Layer 1: Pure reference (0 tokens).
Returns comprehensive information about the constellation composition server including available tools, parameter space dimensions, canonical states, rhythmic presets, and visual vocabulary types.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all available constellations with basic information.
Provides a quick overview of all 22 major constellations available in the system, including their abbreviations and primary themes. Useful for browsing options or understanding the full scope of available compositional patterns.
Args: response_format: Output format ('markdown' or 'json')
Returns: str: Complete list of constellations with basic metadata
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format for responses. | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List all available Phase 2.6 rhythmic presets with their parameters.
Layer 1: Pure taxonomy lookup (0 tokens).
Returns preset names, periods, oscillation patterns, state pairs, and descriptions. Presets define temporal oscillation patterns between canonical constellation states for rhythmic composition and Tier 4D multi-domain limit cycle discovery.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | Output format for responses. | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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 for constellations by name, theme, visual characteristics, or shape.
Useful for discovering which constellations match specific compositional needs or thematic requirements. Returns constellation details including mythology, visual characteristics, and shape patterns.
Args: params (ConstellationSearchInput): Search parameters including: - query: Text search for name/theme/characteristic - shape_type: Filter by geometric shape - brightness: Filter by brightness pattern - response_format: Output format (markdown or json)
Returns: str: List of matching constellations with their characteristics
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes | Input for searching constellations. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0apply_constellation_presetcompute_constellation_trajectorygenerate_constellation_attractor_promptgenerate_constellation_compositionget_constellation_coordinatesget_constellation_domain_registry_configget_constellation_visual_typesget_server_infolist_all_constellationslist_constellation_presetssearch_constellationsMost tools have distinct purposes with clear boundaries, such as apply_constellation_preset for generating oscillation sequences, generate_constellation_attractor_prompt for creating image prompts, and get_constellation_coordinates for coordinate extraction. However, some tools like get_constellation_visual_types and list_all_constellations might overlap slightly in providing catalog-like information, but their descriptions help differentiate them by focusing on visual vocabulary versus basic constellation metadata.
The naming follows a mixed convention with some tools using verb_noun patterns like apply_constellation_preset and generate_constellation_attractor_prompt, while others use noun-based names like get_constellation_coordinates and list_all_constellations. This inconsistency is noticeable but still readable, as most names are descriptive and follow a general structure related to constellation operations.
With 11 tools, the count is well-scoped for the server's purpose of constellation composition and image generation. Each tool serves a specific role in the workflow, from listing and searching constellations to generating prompts and computing trajectories, ensuring comprehensive coverage without unnecessary bloat.
The tool set provides complete coverage for the domain of constellation-based composition, including listing and searching constellations, extracting coordinates, generating trajectories, creating image prompts, and integrating with multi-domain systems. There are no obvious gaps; tools support the full lifecycle from discovery to application in image generation and rhythmic composition.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
AI-native art catalogue. Catalogue works, parse provenance, and generate signed RAIs.
AI-native digital asset management: semantic search, generative image edits, and CDN delivery.
Turn AI conversations into visual knowledge maps. Create, connect, search, and organize thoughts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dmarsters/constellation-composition-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
