Outcome
Complete Gitworthy's MCP surface as the primary agent-facing product contract: clear tool descriptions, safe annotations, validated structured results, protocol-correct errors, cancellation/progress support, and parity with the CLI/core.
An MCP host should be able to discover the right tool, understand whether it is read-only/idempotent, call it with validated input, and act on structured output without parsing prose.
Why this matters
Cursor, ChatGPT, Hermes, and other agents are already the main way Gitworthy is used. Thin tool registration and ordinary-text error responses leave too much interpretation to the host agent and make integrations brittle.
Scope
- Retain current tool names through 1.0 unless a documented compatibility migration is unavoidable.
- Add concise descriptions, intended use, examples, cost/budget notes, and read-only/idempotent annotations where supported.
- Use the same input schemas as the CLI.
- Validate results before serialization.
- Return structured content where the pinned SDK supports it, with JSON text as compatibility representation.
- Mark operational failures as MCP errors rather than successful ordinary content.
- Include schema version, Gitworthy version, run ID, decision ID, retryability, required capability, and partial status where applicable.
- Add cancellation and progress for long-running scan/hunt/recheck operations where supported.
- Guarantee no logs, diagnostics, or telemetry contaminate stdio stdout.
- Document primary onboarding tools versus advanced evidence/debug tools.
Primary onboarding tools
doctor
worth_check
hunt
brief
outcome_record
Advanced provider tools remain available but should be labeled as evidence/debug surfaces rather than final decisions.
Non-goals
- No proprietary agent protocol replacing MCP.
- No write actions against external repositories.
- No requirement that every host support progress or rich structured content identically.
- No prose parsing by machine consumers.
Dependencies and readiness
Acceptance criteria
Tests and validation
Likely implementation areas
src/mcp/server.ts registration and handlers.
- Shared schemas and serializers.
- Cancellation/run-budget plumbing from hunt.
- MCP integration docs and example host configs.
Compatibility
Treat tool names, input schemas, and structured output as public 1.0 surfaces. Any unavoidable change needs an alias/deprecation period and explicit migration documentation.
Outcome
Complete Gitworthy's MCP surface as the primary agent-facing product contract: clear tool descriptions, safe annotations, validated structured results, protocol-correct errors, cancellation/progress support, and parity with the CLI/core.
An MCP host should be able to discover the right tool, understand whether it is read-only/idempotent, call it with validated input, and act on structured output without parsing prose.
Why this matters
Cursor, ChatGPT, Hermes, and other agents are already the main way Gitworthy is used. Thin tool registration and ordinary-text error responses leave too much interpretation to the host agent and make integrations brittle.
Scope
Primary onboarding tools
doctorworth_checkhuntbriefoutcome_recordAdvanced provider tools remain available but should be labeled as evidence/debug surfaces rather than final decisions.
Non-goals
Dependencies and readiness
Acceptance criteria
Tests and validation
Likely implementation areas
src/mcp/server.tsregistration and handlers.Compatibility
Treat tool names, input schemas, and structured output as public 1.0 surfaces. Any unavoidable change needs an alias/deprecation period and explicit migration documentation.