QuanterLab

card_setting

Read-onlyIdempotent

For a circuit's result card only, which calls it when a card's control changes: the circuit that ran with the card's changes, on the same stock and years. A change already run today, by anyone, answers at once with its card (its words, figures and chart); a new one runs, the card lighting each of the circuit's cards as the engine runs it, and asks again until it answers. It uses none of the day's runs; an account makes at most 40 new results a day from the cards' settings and the slider together. The circuit itself is not saved: the answer's lab_url opens it in the lab with the changes.

    Args:
        task_id: The task_id of the run the card shows.
        changes: Every change from the run as it ran, each {"card": its id, "setting": its key, "value": ...}.
        run: The id of that change's run as the last answer gave it, sent back while it goes on.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>",
      "changes": "<changes>"
    },
    "name": "card_setting"
  }
}

Input Schema

Name	Required	Description	Default
`run`	No
`changes`	Yes
`task_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Beyond the annotations, it discloses meaningful behavior: caching (a change already run today, by anyone, answers at once), an async polling loop via the returned run id, a rate limit of 40 new results per day, and that the circuit itself is not saved and lab_url reopens it. The annotations already declare readOnly/idempotent, and the description is consistent with them.

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

Conciseness2/5

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

The text is long and awkwardly constructed, with ornamental clauses ('the card lighting each of the circuit's cards as the engine runs it', 'its words, figures and chart') that obscure the actionable facts. Key routing and behavioral facts are buried rather than front-loaded.

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?

For a complex async tool with no output schema, the description covers the async polling pattern, caching, rate limits, the non-persistence of the circuit, and how to reopen it via lab_url. It is largely complete, missing only a clearer description of the final answer's structure.

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 coverage is 0%, so the description must compensate, and it does: it explains task_id ('the run the card shows'), defines the shape of each item in changes (card/setting/value), and clarifies that run is the id from the previous answer to be echoed back during polling. This is good coverage for three undocumented params, though the changes item schema remains loosely specified.

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

Purpose3/5

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

The description conveys that it runs a circuit with changes to a card's settings and returns the result card, which is a real verb+resource. However, the phrasing is convoluted ('For a circuit's result card only, which calls it when a card's control changes') and never distinguishes it from near-identical siblings like card_settings or card_slider.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It implies when it is called ('when a card's control changes') and explains that repeats are served from today's cache while new changes trigger a run. But it never explicitly names an alternative tool or states when not to use this one versus card_settings/card_slider.

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

All QuanterLab tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?