report_gap

com.eurorackref/eurorack · Verify this server

Report when this MCP server couldn't fully answer a question. Not a query tool — calling this writes a feedback record. Call this proactively — without being asked — whenever you hit one of: - missing_field: a field you expected on a module wasn't present (e.g. "I needed the LFO frequency range on Pamela's New Workout and parameter_zones didn't have it"). - missing_module: a module the user asked about isn't in the corpus yet. - tool_confusion: a tool's behavior surprised you (wrong shape, missing filter, ambiguous enum value, unclear description). - empty_result: a reasonable query came back empty and you suspect the corpus is incomplete rather than the query being wrong. - other: anything else worth flagging that doesn't fit above. - eval_finding: reserved for the eval harness at evals/mcp/. Don't use this as an agent — it's written by harvest.py --push when a rubric catches a behavior the agent didn't self-report (e.g., a model leaking prior knowledge after acknowledging a corpus gap). Be specific. Vague reports ("data could be better") are useless; actionable reports name the field, module, or tool. Reporting is encouraged — there is no rate limit and no judgment for over-reporting; a noisy log is more useful than a silent one. Args: - kind (required): one of missing_field | missing_module | tool_confusion | empty_result | other (eval_finding is reserved for the eval harness) - module_id: module this was about, if any ("<manufacturer>/<slug>"). For missing_module, use the id the user asked about even if it doesn't exist. - tool_name: tool that fell short (or that you'd want to exist). - expected (required, ≤200 chars): what you were trying to find or do. - observed (required, ≤500 chars): what actually happened. - suggestion (≤300 chars): concrete fix you'd propose ("add a release_curve field to parameters", "ingest mutable-instruments/yarns"). Returns: { acknowledged: true, id: number }