mcp-metsuke-crunchtools
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| METSUKE_DB | No | SQLite database path | ~/.local/share/mcp-metsuke/metsuke.db |
| METSUKE_DB_FILE | No | Path whose contents override METSUKE_DB (container secret-file convention) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_reports_toolA | List all report definitions in the catalog. Returns each definition with its gather prompt, owner agent, schedule, source config, and last-updated time. |
| get_spec_toolA | Return the gather spec (prompt + source config) for a report definition. This is what the autonomous gatherer calls on callback to learn what to collect for the named report. |
| upsert_definition_toolB | Create or update a report definition. The owner_agent field makes the gatherer identity data, not code, so gathering can be re-homed to another agent without a rebuild. The schedule is a live cron expression: Metsuke's built-in scheduler fires the report when it comes due, in the given timezone. |
| trigger_report_toolA | Fire a report gather right now, without waiting for its schedule. Dispatches the same callback the scheduler uses: Metsuke POSTs the trigger to the Trentina alert endpoint, which forwards it to the owning gatherer. Requires the callback to be configured (TRENTINA_ALERT_URL + METSUKE_ALERT_TOKEN). |
| save_output_toolA | 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. |
| get_output_toolA | Read a gathered report output for compiling a report. Returns the most recent output by default, or the latest output gathered on a specific date when gathered_date is given. |
| list_outputs_toolA | List saved report outputs (the run history), newest first. Returns one lightweight row per saved gather — id, report_name, gathered_at, reporting window, status, and a finding_count — but NOT the payloads, so the full history stays cheap to browse. Use get_output_tool to pull one run's findings, and delete_output_tool / prune_outputs_tool to prune. |
| delete_output_toolA | Delete one saved report output by id. Returns the deleted output's metadata (with deleted=True). Find ids with list_outputs_tool. Raises if no output carries that id. |
| prune_outputs_toolA | Bulk-prune a report's saved outputs. Returns the count and ids deleted. Give exactly one criterion: keep_last retains the N most recent outputs and deletes the rest (keep_last=0 deletes them all); before_date deletes every output gathered strictly before that date. |
| get_sweep_toolA | Read the pre-gathered sweep for a run. Swept reports are gathered by Metsuke before the gatherer is called: fixed source calls, reply-state checks and noise filters run in code, and the results are stored on the run as sections of compact records. Call with no section for the index (window, overall status, per-section record counts and errors), then page through each section you need. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
The tools split cleanly along resource lines (definitions vs. outputs vs. sweep vs. trigger), and single-vs-bulk deletion (delete_output_tool vs. prune_outputs_tool) is clearly delineated. The only mild overlap is get_spec_tool versus list_reports_tool, since list_reports already returns the gather prompt and source config that get_spec_tool exists to expose.
All ten tools follow a predictable verb_noun_tool pattern (get_output_tool, list_outputs_tool, prune_outputs_tool), which is easy to scan and reason about. Minor inconsistency in the noun chosen for the same entity: report definitions are called both 'definition' (upsert_definition_tool) and 'reports' (list_reports_tool).
Ten tools is well-scoped for a report gatherer/compiler: definition management, output lifecycle, triggering, and sweep reading each get exactly the operations they need. No redundant or filler tools.
Output lifecycle is fully covered (save, list, get, delete, prune) and definitions support list/create/update plus read via get_spec_tool. The one clear gap is the absence of a delete/remove operation for report definitions, so stale reports cannot be retired through the tool surface.