Skip to main content
Glama
dmarsters

Constellation Composition MCP Server

by dmarsters

Get Tier 4D Domain Registry Configuration

get_constellation_domain_registry_config
Read-onlyIdempotent

Retrieve domain configuration for registering constellation-based compositional parameters with aesthetic-dynamics-core multi-domain systems.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The tool `get_constellation_domain_registry_config` is defined here as an MCP tool, returning Tier 4D integration configuration for compositional limit cycles.
            "title": "Get Tier 4D Domain Registry Configuration",
            "readOnlyHint": True,
            "destructiveHint": False,
            "idempotentHint": True,
            "openWorldHint": False
        }
    )
    async def get_constellation_domain_registry_config() -> str:
        """
        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.
        """
        presets = {}
        for name, cfg in CONSTELLATION_RHYTHMIC_PRESETS.items():
            presets[name] = {
                "period": cfg["steps_per_cycle"],
                "pattern": cfg["pattern"],
                "state_a": cfg["state_a"],
                "state_b": cfg["state_b"],
                "trajectory": _generate_preset_trajectory(cfg)
            }
    
        state_coords = {}
        for sname in CONSTELLATION_CANONICAL_STATES:
            state_coords[sname] = _get_state_coordinates(sname)
    
        return json.dumps({
            "domain_id": "constellation",
            "display_name": "Constellation Composition",
            "mcp_server": "constellation_composition_mcp",
            "parameter_names": CONSTELLATION_PARAMETER_NAMES,
            "parameter_count": len(CONSTELLATION_PARAMETER_NAMES),
            "canonical_states": state_coords,
            "presets": presets,
            "all_periods": sorted(set(
                p["steps_per_cycle"] for p in CONSTELLATION_RHYTHMIC_PRESETS.values()
            )),
            "visual_types": list(CONSTELLATION_VISUAL_TYPES.keys()),
            "tier_4d_compatible": True
        }, indent=2)
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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dmarsters/constellation-composition-mcp'

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