Skip to main content

MCP in Worka

Worka uses MCP as the contract for tool exposure and tool invocation.

That matters because the platform needs a structured way to:

  • discover tools
  • call them with typed input
  • receive structured results
  • move those results into views, workflows, and follow-up steps

What Worka expects from MCP tools​

A good Worka-facing MCP tool does three things well:

  • it declares a clear input schema
  • it returns structured output
  • it keeps the free-form text summary secondary rather than primary

The reason is simple: Worka needs tool results to be machine-usable, not only readable in a transcript.

Where MCP sits in the runtime​

In the current pack model, the host runtime invokes pack tools through MCP. That is true whether the tool was called from:

  • a view action
  • an AI team member
  • another pack through an allowed dependency path

MCP gives those different callers one consistent contract.

Why structured results matter​

If a tool returns only prose, every downstream consumer has to guess.

If it returns structured content, Worka can:

  • bind it into views
  • hand it to another AI team member
  • inspect it in hooks
  • keep the workflow legible

That is why Worka puts so much weight on structured results.