Turn a product into something AI assistants can operate, then make it discoverable

Why an organized workflow matters

A server can appear finished while still being impossible to ship. Its tool list may grow during development. The release metadata may disagree with the binary. A test suite can pass without proving that a downloaded release works with a real MCP client. A directory form can then repeat an unverified claim.

KittyClaw made those risks visible as separate stages. A ticket could advance only when it carried the proof required by the next stage. Agents handled research, implementation, testing, release preparation and submissions. The owner handled the one architecture choice that changed the product boundary.

What KittyClaw coordinated

The real run

The brief fixed the first version at exactly seven tools. The implementation embedded a Streamable HTTP endpoint at /mcp and used the official ModelContextProtocol.AspNetCore SDK. Independent validation covered 21 MCP tests and 88 API tests.

During implementation, a committer refused a change that targeted the wrong repository and routed the conflict to an explicit human decision. The owner settled the product boundary, then the workflow resumed through reconstruction, validation and approval.

Before submission, the tagged v0.16.0 archive was downloaded and launched, then a real client listed all seven tools. The registry entry io.github.Ekioo/kittyclaw was active when the evidence was verified. Ticket and comment timestamps put the tracked stages at about 4 hours 56 minutes, so we use the cautious formulation "less than 5 hours of estimated active work." This reconstruction is not an exact timer, and a future run is not guaranteed to take the same time.

What we learned

Freeze the public promise before implementation. Treat release proof as a separate deliverable, not as a consequence of passing source tests. Route a scope-changing disagreement to one named human instead of letting agents negotiate it indefinitely. Finally, plan distribution in the brief so registry metadata is checked alongside the product, not written from memory after release.

How to do this with KittyClaw

Prerequisites

• A KittyClaw project connected to the product repository.
• An existing product API that the MCP tools can call.
• A human owner available for decisions that change scope or architecture.
• A client capable of initializing an MCP server and listing its tools.

Minimal pipeline

Configuration

Create the columns above in one KittyClaw pipeline. Assign one processor to each automated column. Give every processor a narrow mission, the required evidence paths and one configured success route. Configure failure routes back to the stage that can correct the problem. Keep the Owner decision column manual. The included workflow file provides reusable processor missions, passage rules and ticket templates.

For the server itself, register the official SDK, map /mcp, expose only thin wrappers over existing operations and put activation behind a product setting. KittyClaw currently exposes its own server through the persistent Enable the MCP server setting. Your product can use an equivalent explicit control.

Limits

• This workflow does not decide which product actions are safe to expose. That needs product and security judgment.
• A registry listing proves discoverability, not adoption.
• Directory rules can change. Reopen the official instructions before each submission.
• The sample code contains placeholders and must be adapted to the product's API and authorization model.

Bootstrap kit

The kit separates the KittyClaw workflow from the MCP implementation. Run install-kittyclaw-workflow.ps1 against an existing project to create the pipeline, columns, processors and routes through the KittyClaw API. Then use the ticket templates, decision brief, endpoint example, registry metadata and submission checklist.