Building tools

OtoDock's tools are built on the open Model Context Protocol (MCP), so you can give agents new abilities by writing your own tool server — and the platform handles the hard parts: sandboxing, credentials, file paths, prompt instructions, and lifecycle. This page is the developer's overview.

Anatomy of a tool

A tool is a folder with a manifest.json and your server code. The manifest is the one place you describe everything OtoDock needs to know:

{
  "name": "my-tool",
  "label": "My Tool",
  "description": "What this tool does, in one line.",
  "category": "community",
  "server": {
    "runtime": "python",
    "transport": "stdio"
  },
  "skills": [{ "id": "how-to", "file": "skills/how-to.md", "description": "When to use this tool" }],
  "credentials": { "...": "..." },
  "config": { "...": "..." }
}

The fields you'll most often set:

• name / label / description — identity and a short summary (the description is shown to agents).
• category — core (always on), custom (bundled, opt-in), or community (installable from the catalog, opt-in).
• server — how it runs (see below).
• skills — how-to files loaded into the agent's prompt (see below).
• credentials / config — what secrets and settings it needs.

Runtimes and transports

Pick what fits your tool:

Runtime	Good for
Python	Most tools; gets its own isolated environment.
Node.js	JavaScript tools; gets its own dependencies.
Docker	Heavier tools or anything needing system-level dependencies; runs in its own container.

Transport	Use
stdio	The common case — a Python or Node subprocess speaking MCP over standard input/output.
HTTP	A service speaking MCP over HTTP — used by Docker tools, whose container lifecycle OtoDock manages.

Teaching the agent to use it

• Skills are short Markdown files you reference from the manifest. When the tool is enabled for an agent, OtoDock injects them into the agent's prompt — keep them concise: what each tool does, its arguments, and any gotchas.
• Dynamic context lets you inject live state into the prompt at session start — a list of available resources, the connected account, and so on — using simple placeholders the platform fills in.

Credentials

Declare what your tool needs and let the platform provide it securely:

• None — no secrets required.
• Per-user — each user supplies their own (a username/password, an API key).
• Infrastructure — a shared, admin-configured secret.
• Instances — multiple configured endpoints or accounts (several SSH hosts, say).
• OAuth — declare the provider and OtoDock runs the full sign-in, storage, and refresh for you.

Secrets are stored encrypted and delivered to your tool privately at runtime — never written into config files or exposed to the agent.

Scope-aware file paths

Rather than hardcoding paths, your tool reads standard environment variables OtoDock injects on every launch (workspace directory, allowed roots, the session's user, scope, and role, and more), so you write path logic once and it resolves correctly for every session.

If your tool needs path-bearing settings of its own, declare them by role in the manifest and OtoDock resolves each to the right location for the session.

When a tool argument is a file path the agent supplies, declare it too — OtoDock validates it against the session's permissions and translates it to the right location before your tool sees it. Trust what you receive and just use it; re-checking the path yourself is redundant and breaks across platforms and scopes.

Reaching an internal service

If your tool dials a service on the operator's network, declare it as a network target in the manifest (which setting holds the address, and the default port). OtoDock keeps the agent's network locked down by default and carves access to exactly that target when the admin enables the tool's network toggle. See Local network access.

Opting out of contexts

Use exclude_from to skip your tool where it doesn't belong — for example a tool that has no place in an autonomous task, or one that only makes sense in a chat you're watching.

Packaging and installing

Package your tool as a folder containing the manifest and your code (or a reference to a published package), zipped up, and an admin installs it from Admin → MCP Servers. The platform validates the manifest, fetches dependencies, and wires it in.

No secrets in the archive

Install archives must not contain .env files — they're rejected. All secrets belong in the platform's encrypted credential store, configured after install.

Sharing with the community

The community catalog lives in OtoDock's public repositories. This page is the overview — the complete contract (every manifest field, the credential and OAuth schemas, path and cost conventions, versioning, and the PR review checklist) lives in the community MCPs CONTRIBUTING guide. Submit your tool there and, once merged, anyone can install it from their dashboard — and keep it current with automatic weekly updates.

Next steps

• Using Tools → — how a tool gets authorized and enabled once built.
• Community Catalog → — where shared tools live.
• Local network access → — declaring internal targets.