summarize_batchSummarize raw LTspice simulation files in a batch directory into a concise overview, so you can inspect batch results without opening each file.
Summarize raw files sitting in a batch directory.
| Name | Required | Description | Default |
|---|---|---|---|
| batch_dir | Yes | ||
| workspace_root | No | Optional per-call workspace root override. |
Changes observed during successful MCP inspections.
v0.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds essentially nothing beyond that — it does not say what 'summarize' produces, how large the summary is, whether it reads raw waveform data or just metadata, or whether the batch directory must exist.
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?
A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness is under-specification rather than deliberate economy.
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?
With no output schema and no information about the return format, the agent cannot predict what a 'summary' contains — counts, aggregated metrics, or text. For a summarization tool whose whole value is the returned artifact, this is a material omission.
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 coverage is 50% and the required batch_dir parameter carries no description in the schema. The phrase 'a batch directory' weakly implies batch_dir semantics but never states path format, relativity, or required existence, and the optional workspace_root override is left entirely to the schema. The description does not compensate for the coverage gap.
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 a specific verb ('summarize') and resource ('raw files sitting in a batch directory'), which is enough to distinguish it from mutation-style siblings like submit_batch or cancel_batch. However it gives no differentiation against collect_batch_results or get_batch_status, which occupy adjacent batch-result territory, so an agent cannot fully route on the description alone.
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?
There is no when-to-use guidance, no prerequisite about the batch having been run or results being present, and no named alternative among the batch siblings (collect_batch_results, get_batch_status). The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.