mcp-metsuke-crunchtools

Official

by crunchtools

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Save Output Tool

save_output_tool

Persist gathered report findings with source URLs to complete an in-flight run, enabling cited report compilation.

Instructions

Persist a gathered report output, completing the run that opened it.

The gatherer writes findings here after sweeping the sources. Each finding in payload should carry its own source URL so the compiler can cite it. Pass the run_id Metsuke handed you in the fire callback so this completes that exact in-flight run (one row per fire). Omit run_id for an ad-hoc direct save; Metsuke stamps a fresh run identity either way.

Input Schema

Name	Required	Description	Default
`run_id`	No	The run to complete (from the fire callback); None = direct save
`status`	No	One of "gathering", "ready", "compiled", "failed" (default: "ready")	ready
`payload`	Yes	List of findings. Each needs a non-empty summary and should carry its source_url; see Finding for the other allowed keys
`window_end`	No	End of the reporting window (ISO date/datetime)
`report_name`	Yes	The report definition this output belongs to
`window_start`	No	Start of the reporting window (ISO date/datetime)
`gatherer_run_ref`	No	Opaque reference to the gatherer run that produced this

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv1.1.0Sep 27, 2026

changedInput schema / properties / payload / description

Previous value: -"List of finding objects, each ideally carrying a source URL"New value: +"List of findings. Each needs a non-empty summary and should\ncarry its source_url; see Finding for the other allowed keys"

changedInput schema / properties / payload / items / additionalProperties
```
Previous value: -trueNew value: +false
```

addedInput schema / properties / payload / items / description

Added value: +"One gathered finding.\n\nThe fields are declared, not left as a free-form dict, because a model\ncalling the tool fills in what the schema names: with a bare ``object``\nitem, strict tool-calling models emitted ``{}`` for every finding (RT #1505).\n``summary`` is the one field every report uses and the one a finding is\nworthless without. The rest are the keys the live reports use; a report\nthat needs one more adds it here.\n\nExample::\n\n    {\"summary\": \"Fedora 45 Beta shipped with Podman 6.\",\n     \"source_url\": \"https://fedoramagazine.org/...\",\n     \"section\": \"rss-news-roundup\", \"theme\": \"RHEL/Linux\"}"

addedInput schema / properties / payload / items / properties

Added value: +{
+  "actors": {
+    "anyOf": [
+      {
+        "items": {
+          "maxLength": 200,
+          "type": "string"
+        },
+        "maxItems": 2000,
+        "type": "array"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "People or teams involved, by name."
+  },
+  "category": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Source category, e.g. the feed category the item came from."
+  },
+  "date": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "When it happened, ISO date (YYYY-MM-DD)."
+  },
+  "outcome_ref": {
+    "anyOf": [
+      {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Tracker key this finding advances, e.g. a Jira issue key."
+  },
+  "section": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Report section this belongs in, as named by the report's gather prompt."
+  },
+  "source_type": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Kind of source, e.g. 'jira', 'slack', 'email', 'rss', 'web'."
+  },
+  "source_url": {
+    "anyOf": [
+      {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Clickable link to the evidence; null when no source exists."
+  },
+  "summary": {
+    "description": "One or two sentences stating the finding itself.",
+    "maxLength": 2000,
+    "minLength": 1,
+    "type": "string"
+  },
+  "theme": {
+    "anyOf": [
+      {
+        "maxLength": 200,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Grouping within a section, e.g. 'Security' or 'AI/Agentic'."
+  },
+  "title": {
+    "anyOf": [
+      {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "default": null,
+    "description": "Headline of the source item, when it has one."
+  }
+}

addedInput schema / properties / payload / items / required
```
Added value: +[
+  "summary"
+]
```

addedInput schema / properties / run_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The run to complete (from the fire callback); None = direct save"
+}

changedInput schema / properties / status / description

Previous value: -"One of \"gathering\", \"ready\", \"compiled\" (default: \"ready\")"New value: +"One of \"gathering\", \"ready\", \"compiled\", \"failed\" (default: \"ready\")"

changedInput schema / properties / status / enum

Previous value: -[
-  "gathering",
-  "ready",
-  "compiled"
-]New value: +[
+  "gathering",
+  "ready",
+  "compiled",
+  "failed"
+]

First observedv0.2.0Aug 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it discharges most of it: it discloses run-completion semantics, the one-row-per-fire cardinality, and that Metsuke stamps a run identity even on ad-hoc saves. It does not cover failure behavior or what happens when run_id refers to an already-completed run.

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?

Four short sentences, front-loaded with the primary effect (persist and complete the run), then the payload convention, then the run_id branch. Every sentence adds operational information; nothing is padding.

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 mutation tool with no annotations, the description covers the essentials, and an output schema exists so return values need no explanation. The main residual gap is error/edge-case behavior (invalid run_id, duplicate fires), which a writer would still want stated.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains where run_id comes from (the fire callback), what omitting it does, and that payload findings should each carry source_url so the compiler can cite them.

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?

States a specific verb and resource ('Persist a gathered report output') and adds the consequential nuance that it 'completes the run that opened it.' This distinguishes it from read-side siblings like get_output_tool and list_outputs_tool, which cannot complete a run.

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?

Explicitly covers the two invocation modes: pass run_id from the fire callback to complete an in-flight run, or omit it for an ad-hoc direct save. It also states the triggering context ('after sweeping the sources'). It stops short of naming sibling tools (e.g. upsert_definition_tool, get_output_tool) as alternatives.

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

Deploy Server