QuanterLab

card_share

Idempotent

For a ready test's result card only, its Share button: a public page on QuanterLab for the result the card shows (the run's own, or a slider's stop), made on the press: the test in plain words, its chart against simply holding, three figures, the day it ran and a link to run it in the lab. Nothing about the person. An account sharing the same result twice gets the same page; an account makes at most 10 pages a day.

    Args:
        task_id: The task_id of the ready test the card shows.
        value: The slider's stop the card shows; left out, the run's own result.

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>"
    },
    "name": "card_share"
  }
}

Input Schema

Name	Required	Description	Default
`value`	No
`task_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The description adds substantial behavioral context beyond annotations: the page is public, contains no personal information, repeat shares of the same result return the same page (reinforcing idempotency), and there is a rate cap of 10 pages per day per account. This is genuinely useful disclosure, though the writing style makes some of it ambiguous.

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

Conciseness3/5

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

The description is a dense, oddly phrased block; phrases like 'a slider's stop' and 'its chart against simply holding' force re-reading. The key constraint is somewhat front-loaded, but the prose could be significantly tightened for clarity.

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?

With two parameters, no output schema, and annotations covering the safety profile, the description covers what the tool produces (a public page with specified contents) and its rate/idempotency rules. It is complete enough for an agent to invoke correctly, despite the awkward phrasing.

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 carry parameter meaning, and it does: task_id is the ready test the card shows, and value is the slider's stop, omitted to use the run's own result. This clarifies both parameters and the default behavior, compensating well for the absent schema descriptions.

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 conveys a specific action: creating a public QuanterLab page that shares a ready test's result card, including what appears on the page. The purpose is identifiable, but the convoluted prose ('made on the press', 'its chart against simply holding') makes it hard to parse quickly, and it doesn't explicitly name how it differs from siblings like show_report_card 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 Guidelines4/5

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

'For a ready test's result card only' clearly constrains when the tool applies, implying it is the share action for a result card rather than report viewing. However, no explicit alternative tool is named for cases that don't fit, so routing still relies on inference.

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?