mitosis

Report on an Audiograph task

audiograph_task_report

Tell your person how a to-do they handed you from Audiograph is going. Use the report URL and token from the brief. status: "started" when you begin, "working" with a short step, "needs_you" with the question when you need an answer (their phone is notified), "done" with result.summary (and links to what you made or sent) when finished. A done with nothing to show is refused. For a routine, use its runs URL; each run is reported on its own day.

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": {
      "report_url": "<report_url>",
      "token": "<token>",
      "status": "<status>"
    },
    "name": "audiograph_task_report"
  }
}

Input Schema

Name	Required	Description
`step`	No	One short line on what you are doing.
`token`	Yes	The agr_ token from your brief.
`result`	No	With done: what you did, and links to it.
`run_on`	No	Routines only: the run day, YYYY-MM-DD. Defaults to today.
`status`	Yes
`choices`	No	With needs_you, when the question has two likely answers: both, each under 32 characters. They become one-tap buttons on their phone.
`question`	No	With needs_you: exactly what you need from your person.
`report_url`	Yes	The report URL from your brief.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / choices

Added value: +{
+  "description": "With needs_you, when the question has two likely answers: both, each under 32 characters. They become one-tap buttons on their phone.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 2,
+  "minItems": 2,
+  "type": "array"
+}

AddedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, non-destructive, non-idempotent, non-open-world call. The description adds real behavioral context on top: needs_you pushes a notification to the person's phone, a 'done' with no artifact is rejected (a hard validation failure an agent must avoid), choices become one-tap buttons, and routine runs are reported per day. These are consequences of calling that the annotations do not convey.

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?

It is front-loaded with the purpose, then walks the status state machine in the order an agent would encounter it, with no filler sentences. The style is telegraphic but every clause carries operational information.

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 an 8-parameter, nested-object mutation tool with no output schema, the description covers the main risks: required artifacts for 'done', the notification side effect, and routine run scoping. It does not describe what a successful response contains or any auth/token failure behavior, which are minor residual gaps.

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 88%, so the schema already defines most parameters. The description still earns credit by describing conditional coupling the schema cannot express: 'working' pairs with step, 'needs_you' pairs with question, 'done' requires result.summary plus links, and run_on is tied to per-run-day reporting for routines.

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 states a specific verb and resource: report how a to-do handed off from Audiograph is going, using a report URL and token. This is clearly a status-reporting write, distinct from the read-oriented siblings (audiograph_list_received, audiograph_read_received), so an agent can select it without opening other schemas.

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 maps each status value to a moment of use (started when you begin, working while stepping, needs_you when blocked, done on completion), which is unusually explicit guidance. It also routes routines to their runs URL. It does not state when not to report, or whether re-reporting the same status is expected, so it falls short of full coverage.

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

All mitosis 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?