What To Do Instead

1

Build the capability, not the protocol

Ship a CLI or API. Structured JSON output (--output json). Good --help. Clear error codes. This is what you already know how to do.

2

Make it discoverable (3 channels)

ODR: Register your skill + CLI so agents can discover it locally. Plugin marketplace: Publish to a GitHub repo so agents can /plugin install. Docs: Publish on learn.microsoft.com so models pick it up in training. Do all three.

2b

Use MCP where centralization is the point

When you need centralized auth, policy, telemetry, and rapid distribution across an org, MCP (server, typically HTTP) is a strong fit. It’s not just “tools”: MCP also supports prompts and resources for standardizing how agents work.

3

Write an eval (and keep the design doc lean)

Do both, but prioritize evidence. Give an agent 5 real tasks that need your tool. Measure success rate, token cost, time to completion. Use those results to drive the design doc: interface shape, error semantics, auth friction, rollout plan.

4

Iterate on the interface, not the transport

If evals show agents struggle, fix your CLI's output format, add better descriptions, simplify parameters. The protocol layer is someone else's problem.