Give your agents tools, not a shell.

Dogubako’s 249 tools are also an MCP server, an HTTP API and a command line. Run it on your own machine for one agent, or on a server for many. Each agent gets its own account, its own token and a list of the tools it may run.

Connect an agent Agent docs

MCP over stdio or HTTP · OpenAPI 3.1 · a CLI with --json

An animation of an agent using Dogubako over MCP: it searches the tools for “transcribe”, uploads interview.m4a, runs speech.transcribe with SRT output, and gets interview.srt back as a file.

    On your machine, or on a shared server.

    Dogubako speaks MCP over two transports. Same tools, same checks; what changes is where the work runs and how files get there.

    Local, over stdio

    Your agent starts dogubako mcp serve itself. File parameters take local paths and results land in a folder you choose. Narrow it with --allow, --deny, --permissions and --fs-root.

    $ claude mcp add dogubako -- \
    dogubako mcp serve --discovery compact

    Shared, over HTTP

    Many agents on different machines use one self-hosted server and its engines, so none of them needs FFmpeg or Tesseract. Each connects to /mcp with its own bearer token; files go up once and are passed by id.

    $ claude mcp add --transport http dogubako \
    https://tools.example.ts.net/mcp \
    --header "Authorization: Bearer dgb_…"

    Other clients work too: the docs have the JSON config for Claude Desktop and similar apps, and a bridge for clients that only speak stdio. Agents with their own shell can keep using local programs; MCP is an option, not a requirement.

    249 tools, without filling the context.

    Listing every tool with its full schema would use up a good part of an agent’s context before it has done anything. In compact mode the agent sees eight small meta-tools instead. It searches when it needs something, reads one tool’s schema, and runs it by id.

    Choose it
    Per server (DOGUBAKO_MCP_DISCOVERY), per agent, per token, or per connection with /mcp?discovery=compact.
    Long jobs
    dogubako_run_tool waits up to wait_seconds, then hands back a job id to poll with dogubako_job_status.
    Not a permission
    Discovery only decides what is listed. A tool the agent never saw is still checked, and refused if it isn’t allowed.

    tools/list → 8 definitions

    • dogubako_search_toolskeywords → ids
    • dogubako_describe_toolone tool’s schema
    • dogubako_run_toolrun any allowed tool
    • dogubako_job_statuspoll a long job
    • dogubako_job_cancelstop it
    • dogubako_list_categorieswhat’s allowed, by category
    • dogubako_upload_filesend a file (HTTP)
    • dogubako_list_filesyour files and outputs

    Counted for an agent allowed to use every tool, on a server.

    One account per agent, and a list of what it may run.

    Agents start with no tools and no capabilities. Allow what each one needs, by category or by tool, and every call is checked against that list in the engine, whether it arrives over MCP, the HTTP API or as a tool name the agent only guessed.

    $ dogubako users create media-bot --role agent \
    --allow 'video.*' --allow 'speech.*'
$ dogubako tokens create --user media-bot --name laptop-agent
dgb_…

    Run these on the server host, with docker compose exec dogubako in front for Docker, or use Admin → Users & agents. Permissions and policies

    media-botagent · video.*, speech.*
    1. video.compress mcpallowed
    2. speech.transcribe mcpallowed
    3. pdf.merge mcpdenied
    4. video.to_gif apiallowed
    5. system.processes mcpdenied
    6. network.http_headers apidenied

    Refused calls go to the audit log, like every run.

    Tokens
    dgb_ plus 256 random bits, shown once, stored as a hash. Revocable, with an optional expiry.
    Scopes
    A token can narrow its owner’s policy further, never widen it. Tokens can’t create tokens.
    Files
    An agent sees only its own uploads and outputs. Everyone else’s files are a 404.
    Sessions
    MCP sessions are bound to the token that opened them. Revoke the token and they stop.

    Or skip MCP: HTTP and the command line.

    Every tool is described once. The app’s form, the CLI flags, the HTTP endpoint and the MCP tool are all generated from that description, and the same engine runs them.

    HTTP API

    Upload, run, fetch the result. Each tool has a typed request schema in the OpenAPI 3.1 document, generated from the live tool registry: GET /api/v1/openapi.json, or dogubako api openapi.

    PUT  /api/v1/files/raw?name=talk.mov        → {"id": "f_…"}
POST /api/v1/tools/video.compress/run
     {"params": {"input": ["f_…"]}, "wait_seconds": 60}
GET  /api/v1/files/f_…/content              → the file

    CLI, for scripts and CI

    Every tool is a command: inputs as arguments, every option as a flag, --json for machine-readable output and exit codes you can branch on.

    $ dogubako image compress shot.png -o shot-small.png
$ dogubako pdf merge a.pdf b.pdf -o merged.pdf --json
$ echo '{"b":1}' | dogubako dev json
# exit codes: 0 ok · 1 failed · 2 bad input · 3 missing engine
#             4 not permitted · 5 timeout or limit · 130 cancelled

    Have your agent set it up.

    A coding agent can install the server for you and connect itself. The page it follows is written for agents: build it with Docker, keep it on your tailnet, create a scoped agent account and token, add the MCP server, and ask you before touching ports or the firewall.

    Read agent-install.md

    Prompt

    Install Dogubako on this server and connect it to me over MCP. Follow the instructions at https://dogubako.app/agent-install.md and ask me before any step that opens ports or changes the firewall.

    The how-to lives in the docs

    HomeWhat Dogubako is, and the app in motion DownloadAlpha status, the Mac app, building from source