Skip to main content
Glama
dmarsters

Constellation Composition MCP Server

by dmarsters

Compute Smooth Trajectory Between Two Constellation States

compute_constellation_trajectory
Read-onlyIdempotent

Calculate smooth interpolation trajectories between two constellation states for AI image generation, using cosine ease-in-out transitions with full 5D coordinates at each step.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYesInput for computing trajectory between two constellation states.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The compute_constellation_trajectory tool is defined here as an MCP tool, using _interpolate_states to compute smooth interpolation between two canonical states.
    @mcp.tool(
        name="compute_constellation_trajectory",
        annotations={
            "title": "Compute Smooth Trajectory Between Two Constellation States",
            "readOnlyHint": True,
            "destructiveHint": False,
            "idempotentHint": True,
            "openWorldHint": False
        }
    )
    async def compute_constellation_trajectory(params: TrajectoryInput) -> str:
        """
        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.
        """
        coords_a = _get_state_coordinates(params.state_a)
        coords_b = _get_state_coordinates(params.state_b)
        trajectory = _interpolate_states(coords_a, coords_b, params.steps)
    
        # Compute Euclidean distance between endpoints
        dist = math.sqrt(sum(
            (coords_a[p] - coords_b[p]) ** 2
            for p in CONSTELLATION_PARAMETER_NAMES
        ))
    
        return json.dumps({
            "state_a": params.state_a,
            "state_b": params.state_b,
            "steps": params.steps,
            "euclidean_distance": round(dist, 4),
            "parameter_names": CONSTELLATION_PARAMETER_NAMES,
            "trajectory": trajectory
        }, indent=2)
  • _interpolate_states helper function that performs the actual smooth cosine interpolation logic used by the tool.
    def _interpolate_states(
        state_a: Dict[str, float],
        state_b: Dict[str, float],
        steps: int
    ) -> List[Dict[str, float]]:
        """Smooth sinusoidal interpolation between two states (half-period: A → B)."""
        trajectory = []
        for i in range(steps):
            t = i / max(steps - 1, 1)
            # Smooth ease-in-out via cosine interpolation
            alpha = 0.5 * (1.0 - math.cos(t * math.pi))
            state = {
                p: (1.0 - alpha) * state_a[p] + alpha * state_b[p]
                for p in CONSTELLATION_PARAMETER_NAMES
            }
            trajectory.append(state)
        return trajectory
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.

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