If you already live inside Claude or Codex, you do not want a browser tab for every tool you use. You want to trigger the action from where you are already working. That is the actual demand behind MCP adoption, not novelty.
Cadencz is MCP-ready for Claude, Codex, and other MCP clients. That fact is simple to state. The design consequence is not.
When the client owns the UI, your tool names are the UI
A normal product controls its own interface. Buttons, labels, confirmation dialogs, all of it designed by you.
Expose your pipeline as MCP tools and that control disappears. The client renders whatever it wants. The model decides which tool to call based on the tool's name, description, and argument schema. Those three things are now your entire interface.
Here is roughly the shape of a tool definition:
{
"name": "list_drafts",
"description": "List queued social post drafts awaiting approval. Returns id, platform, and status for each draft.",
"parameters": {
"type": "object",
"properties": {
"status": {
"type": "string",
"enum": ["pending", "approved", "rejected"]
}
}
}
}
A vague description here is not a cosmetic issue. It is a routing bug. If the description says "manage content" instead of naming the exact action and its return shape, the model has nothing precise to match against user intent. It will call the wrong tool, or the right tool with the wrong arguments, and there is no UI affordance to catch that before execution.
The constraint you cannot hide behind a nice description
Cadencz's own workflow is: learn the product, plan and draft, approve in a queue, then schedule and publish.
An MCP client can reasonably ask to draft a post. It can reasonably ask to list what is in the queue. Publishing is different. That step needs a human approval, and the tool surface has to say so explicitly, not imply it through a comment nobody reads.
Concretely, that means no single publish tool that silently sends. Instead, something like list_drafts, get_draft, and a separate request_approval or mark_approved step that a human, not the model, triggers. The boundary between "the model can do this" and "a person has to do this" has to live in which tools exist, not in a policy note.
If your schema makes an unsafe action look identical to a safe one, the model will eventually treat them the same way.
The takeaway
Write tool descriptions as if the model has no other context, because it usually does not. Name the exact action, the exact return shape, and the exact preconditions.
Return errors a model can act on. "Draft not found" with the id it searched for is useful. A generic 500 is not; the model cannot retry, correct, or explain the failure to the user.
If you are building an MCP server for your own product, this is the design review worth doing before you ship it: read every tool name and description as if you were a model with zero prior knowledge of your app. Would you call the right one?
Top comments (0)