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": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
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), unless the owner is a pull owner (METSUKE_PULL_OWNERS): then the run is opened and left for the owner. |
| 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
Most tools target clearly distinct resources (definitions, outputs, runs, sweeps) with a clean verb split (list/get/save/delete/prune). The only mild overlap is get_output_tool vs get_sweep_tool, since both retrieve gathered data, but the descriptions distinguish compiled findings from pre-gathered sweep sections well.
Every tool follows the same verb_noun_tool pattern (list_reports_tool, get_output_tool, upsert_definition_tool, prune_outputs_tool), with consistent snake_case and singular/plural conventions (list uses plural, get/upsert use singular). No mixed styles.
Ten tools is well-scoped for a report-gathering management server, covering the full lifecycle of definitions, outputs, triggering, and sweeps without redundancy. Each tool earns its place with a distinct role.
Outputs have full lifecycle coverage (save, get, list, delete, prune) and definitions support list/get_spec/upsert, but there is no delete_definition_tool, leaving a gap in definition management. Agents can work around it, but the surface is not fully closed.