Copies a bundled example into the server working folder, executes it with tracing enabled, and returns its tape ID, output, and stats for inspection and replay.
Copy one bundled example into the server's working folder, run it with tracing on and return its tape_id, its printed output and the tape's stats. Then question the tape with inspect_tape and replay.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| timeout_s | No |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It usefully discloses side effects (copying into the server's working folder, running with tracing on) and return content, but it omits important behavior for an execution tool: what happens on timeout, whether an existing working folder is overwritten, error behavior for missing examples, and any permission or sandbox constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and every clause contributes useful information. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, side effects, and return values (useful since no output schema exists), but it is incomplete for an execution tool: timeout behavior and error conditions are unaddressed, and the 0% parameter coverage leaves important invocation details undocumented. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only weakly implies the `name` parameter via 'one bundled example' and says nothing about `timeout_s`, leaving a required parameter and a meaningful execution-control parameter unexplained. This is a significant gap for a two-parameter tool with no schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs and resources: copies one bundled example, runs it with tracing, and returns tape_id, printed output, and tape stats. It names the follow-up tools (inspect_tape, replay), so an agent can distinguish it from siblings like get_example or list_examples without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the workflow by saying to then question the tape with inspect_tape and replay, which is useful downstream sequencing. However, it does not say when to choose run_example over list_examples or get_example, nor does it mention prerequisites such as requiring a valid example name or that the example must already be listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.