Skip to content

Other MCP clients

agentry is exposed as a standard MCP server via stdio transport. Any harness or tool that speaks MCP can talk to agentry without changes on our side.

Dedicated walkthroughs exist for Claude Code, Cursor, Roo Code, Continue.dev, Hermes, and OpenClaw. Everything below is the generic recipe for any other client.

Most harnesses look like this

  • A JSON config file lives somewhere under your home directory.
  • That file has an mcpServers block.
  • Each server entry has command and args.

For agentry, you always want:

json
{
  "mcpServers": {
    "agentry": {
      "command": "agentry",
      "args": ["mcp"]
    }
  }
}

If the path search doesn't find agentry, replace "agentry" with the absolute path from which agentry.

What agentry mcp does

When your harness invokes agentry mcp:

  1. The CLI opens a long-lived MCP session against app.agentry.run, authenticated with your device cert.
  2. It listens on stdin for MCP requests (tools/list, tools/call, etc.).
  3. Each tool call is dispatched to your currently-selected server via the the bridge tunnel.
  4. Responses stream back over stdout.

The process stays alive for the duration of the harness session. Kill it and the harness reconnects on the next tool call (assuming it's configured to restart MCP servers, which most do).

Pin a server

By default, agentry mcp uses the server set as current (agentry server use <name>). Override per-session with --server:

json
{
  "mcpServers": {
    "agentry": {
      "command": "agentry",
      "args": ["mcp", "--server", "homelab"]
    }
  }
}

Useful when one harness should be pinned to one server even when your default changes.

Tools your harness will see

The MCP server exposes (full reference at /reference/mcp-tools):

  • Lifecycle: sandbox_create, sandbox_list, sandbox_delete, app_probe, service_probe, deployment_status
  • Shell: command_run, command_start, command_logs, command_interrupt
  • Files: file_read, file_write, file_list, file_grep, file_replace, file_multi_edit
  • Ports: port_wait
  • Projects: project_start, project_stop, project_create, project_list, project_logs
  • Services: service_list, service_bind
  • Secrets: secret_set, secret_list
  • Code interpreter: code_exec, code_close
  • Docs: docs_read

Switching models

If your harness lets you configure the model endpoint, point it at OpenRouter for one-key access to ~200 models. Base URL https://openrouter.ai/api/v1, OpenAI-compatible API, model strings like anthropic/claude-3.5-sonnet, openai/gpt-4o, meta-llama/llama-3.3-70b-instruct.

If your harness has hardcoded providers, you can also run LiteLLM locally to translate between any API shape and the model of your choice. Most harnesses don't need this — OpenRouter covers the common case.

Verify it works

In your harness, ask:

Which agentry tools do you have?

You should get a list with ~30 entries. If you don't:

  • Run agentry mcp from a terminal. It should print nothing and wait for input. Hit Ctrl-C.
  • If it errors, run agentry login first.
  • If your harness logs MCP stderr, check there for the cause.
  • See MCP wiring troubleshooting.

Want to build your own MCP client?

The agentry server is a vanilla MCP server — no agentry-specific protocol additions. See the Model Context Protocol spec for transport and message shapes.

You don't need agentry's permission to build a custom client. If you ship one publicly, send a pull request to add it to this page.

Next

agentry — run AI-built apps on your own hardware.