Skip to main content
Glama

circuit_step

Puts the circuit opened with build_circuit together, one step after another, each checked as the lab checks it: a card type from the catalog (list_primitives), ports by name, settings inside their ranges and the cards the account's plan has. Steps run in order; one that cannot be done stops the rest and says why, and the ones before it stay done. The answer gives each card's id, ports and settings, the wires, and what the circuit still needs before it runs.

    Args:
        steps: One to twelve steps, each an object with an op:
            {"op": "add_card", "type": "ticker", "id": "tk", "params": {"symbol": "KO"}, "after": "x"}
                a card from the catalog; id (optional, lower case, like "tk") names it, after (optional)
                places it to the right of another card; params left out keep the card's own
            {"op": "connect", "from": "tk.ticker", "to": "tpl.ticker"} an output port to an input port
            {"op": "set_card", "card": "bt", "params": {"horizon": "2y"}} changes settings
            {"op": "remove_card", "card": "tk"}; {"op": "disconnect", "from": "...", "to": "..."}
            {"op": "set_anchor", "date": "YYYY-MM-DD"} the day the forward test starts from (else the last
                three years, up to the last month's end)
            {"op": "clear"} empties the circuit
            A Signal Module's rule is its config, one JSON object written as text, e.g. {"direction": "long",
            "entry": {"indicator": "rsi", "params": {"length": 2}, "operator": "crosses_below", "value": 10},
            "exit": {"indicator": "rsi", "params": {"length": 2}, "operator": "crosses_above", "value": 70},
            "confirm": null}. A forward test covers three years at most; asked for more, it is held at three.
    

Input Schema

NameRequiredDescriptionDefault
stepsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Discloses the non-obvious semantics annotations cannot: steps run in order, a failing step halts the remainder while prior steps persist, each step is validated against catalog/ports/param ranges/plan entitlements, and the response includes unresolved requirements. It also states the forward test caps at three years and the anchor defaults to the last three years ending at the prior month's end.

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?

Front-loaded with purpose, ordering, and failure behavior before the argument detail; every paragraph carries information the agent needs. It is dense and longer than average, but the length is justified by the seven-op payload and the format example has no filler.

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?

No output schema exists, and the description still summarizes the return ('each card's id, ports and settings, the wires, and what the circuit still needs'). Combined with the prerequisite, partial-failure, and validation semantics, an agent has everything required to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0% and the single parameter is an untyped object array, so the description carries the entire burden. It enumerates every op (add_card, connect, set_card, remove_card, disconnect, set_anchor, clear), gives literal JSON examples, and documents optional fields like id/after/params defaults, including the Signal Module rule config format.

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?

States a specific verb+resource ('puts the circuit opened with build_circuit together, one step after another') and ties itself to the sibling that creates the circuit, so an agent can tell it apart from build_circuit and run_circuit. It stops short of explicitly contrasting with circuit_draft, which is the nearest ambiguous alternative.

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?

Establishes the prerequisite ordering ('the circuit opened with build_circuit') and points to list_primitives as the source of valid card types. There is no explicit when-not-to-use guidance versus circuit_draft or build_circuit, so a small inference remains.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources