Skip to main content

Coding Agents

Telo manifests are dense and the standard library moves fast. The Telo hub — the federated discovery index over every registered module — exposes a Model Context Protocol server at https://telo.sh/mcp that any MCP-aware coding agent can plug into. Once connected, the agent can search for a resource kind by what it does, fetch the owning module's telo.yaml, and follow a built-in primer that explains how Telo works — so a model with no prior Telo context can compose a working manifest.

No authentication is needed for reads.

What the agent gets​

On initialize, the server publishes its tools and an instructions primer. The ones an agent composes with:

  • search_resources(query | queries) — searches resource kinds across every registered module, on any host or transport, for one need or several in one call. The unit an agent composes with is a kind it can import, not a package, so hits are grouped under the module that owns them — its exact location ref + version stated once — and each carries the bare kind suffix (e.g. Bucket — the prefix is your chosen import alias), its capability and description.
  • get_kinds(kinds) — the definitions of exactly the kinds named, across modules: each module's imports: line with its version and integrity pin, each kind's Telo.Definition, and every shape or parent kind it references. This is the agent's source of truth for field shapes, at a fraction of a whole manifest's size.
  • list_libraries(publisher?) — every tracked library in one line each: ref, name, summary, exported kinds and instances.
  • get_module_manifest(ref, version?) — returns the raw telo.yaml for a tracked module by its location ref (e.g. oci://ghcr.io/telorun/console or oci://ghcr.io/acme/telo-s3). version defaults to latest. For when the whole module is wanted rather than a few of its kinds.
  • Instructions primer — explains Telo's runtime model, built-in kinds (Telo.Application, Telo.Library, Telo.Definition), CEL !cel "…" templating, and the recommended workflow: search → read the kinds → compose.

The primer is surfaced to the LLM as system context, so the model knows Telo before you've written a single message.

The hub only indexes discovery metadata and cached manifests — it never stores artifact payloads. Installing and running resolve against each module's own origin, so the discovery surface and the resolution path are fully decoupled.

Claude Code​

claude mcp add --transport http telo https://telo.sh/mcp

Verify:

claude mcp list

The next session picks up the tools and the primer automatically.

Cursor​

Add to ~/.cursor/mcp.json (or .cursor/mcp.json in your project root for a per-project setup):

{
  "mcpServers": {
    "telo": {
      "url": "https://telo.sh/mcp",
      "transport": "http"
    }
  }
}

Restart Cursor and the tools become available to the agent.

Claude Desktop​

Claude Desktop's MCP client speaks stdio rather than HTTP, so it needs a small bridge. mcp-remote (npm) adapts any HTTP MCP server to a stdio transport:

{
  "mcpServers": {
    "telo": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://telo.sh/mcp"]
    }
  }
}

Put that in ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows), then restart Claude Desktop.

What to ask​

Once connected, prompts that lean on the catalog work well:

  • "Build me a Telo manifest for an HTTP API that writes feedback entries to SQLite."
  • "Wire up an MCP server in Telo that exposes get_user and list_users against a Postgres database."
  • "Add a daily job that reads new rows from a SQL database, summarizes each with Ai.Text, and writes the summaries to S3."

The agent will call search_resources, read the definitions of the matching kinds with get_kinds, and produce YAML against the actual schemas — no guessed kind names, no stale field shapes.