delegate-to-mcp-server

Audits plugin-held Senzing facts against the live MCP server and writes delegation specs.

Updated Jul 13, 2026
One-click install
npx skills add https://github.com/docktermj/senzing-bootcamp-claude-plugin-development --skill delegate-to-mcp-server-docktermj
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: delegate-to-mcp-server
Source: https://github.com/docktermj/senzing-bootcamp-claude-plugin-development/tree/main/.claude/skills/delegate-to-mcp-server
Command: npx skills add https://github.com/docktermj/senzing-bootcamp-claude-plugin-development --skill delegate-to-mcp-server-docktermj

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A plugin that caches Senzing facts goes silently stale as the Senzing MCP server ships new coverage; this Skill systematically finds facts the plugin still owns that the server now serves, and produces specs to delegate them to runtime calls. ## Core Features & Use Cases - Coverage sweep: Compares the plugin's Senzing-fact surface (attributes, flags, error codes, SDK shapes, install config, invariants) against live MCP server answers, tracking both the server version and the docs index build. - Verdict ledger: Records every decision (delegate, contradicted, retire-workaround, keep-server-lacks-it, keep-by-design, not-a-senzing-fact) in an append-only JSONL ledger so future runs never re-litigate settled sites. - Spec generation: Writes implementation-ready specs under specs/ quoting both the plugin text and the server's answer, naming the exact MCP call, fallback, and affected tests. - Use Case: A maintainer runs a periodic sweep after a Senzing MCP server release to find newly covered topics, retire stale workarounds, and file upstream feature requests for remaining gaps. ## Quick Start Ask the assistant to run the delegate-to-mcp-server sweep to check which Senzing facts the plugin can now delegate to the MCP server.

Frequently Asked Questions about delegate-to-mcp-server

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check which plugin content the Senzing MCP server now covers?▼

Run the sweep, which calls get_capabilities and search_docs to record the server version and docs index build, then inventories the plugin's Senzing-fact surface and asks the owning MCP tool about each site. Results are classified into six verdicts and recorded in the ledger.

How do I keep track of delegation decisions across runs?▼

Use the coverage_ledger.py script with record, stale, summary, and inventory subcommands. It stores verdicts in specs/mcp-coverage.jsonl as append-only, last-wins rows keyed by a stable slug, and expires rows when either the server version or docs index changes.

Does this skill modify the plugin code directly?▼

No. It writes only specs under specs/ and ledger rows; it never edits plugin code, hooks, scripts, or skills. Implementing the specs is a separate step handled through the issue implementation path.

Why track both server version and docs index build?▼

The MCP server software and its documentation corpus are versioned independently. Senzing can rebuild the docs index without a server release, changing search_docs answers while the server version stays fixed, so verdicts must be stamped with both to expire correctly.

When should a fact be kept in the plugin instead of delegated?▼

Keep it when delegation fails any of six tests: offline steps, unusable generic responses, deliberately narrower measured values, invariants requiring local text, missing fallback on call failure, or added user-visible round-trips. Such keeps are recorded as keep-by-design with a named reason.