Coming October 2026Launch offer: 25% off your first year until 30 November 2026

MCP & agents

Rilbo ships a first-class MCP server in the same binary, so coding agents — Claude Code, Codex, anything MCP-capable — can work your tracker directly.

Transports

  • stdio — rilbo mcp-stdio, for clients that spawn a local process:

    claude mcp add rilbo -- rilbo mcp-stdio

  • Streamable HTTP — served at /mcp alongside the web UI (http://127.0.0.1:7373/mcp).

Tools

39 tools: 17 read (search, issues, projects, cycles, reports, views, labels, workflow states, activity …) and 22 write (create/update issues, transitions, comments, attachments, time logging, relations, git links, bulk updates, projects, milestones, teams …).

  • Read tools are free. A Pro licence unlocks the write tools; on Free they return a clear requires_pro error rather than failing mysteriously.
  • Every write tool supports dry_run — a preview of exactly what would change, evaluated against a snapshot, nothing persisted. It is part of the write tooling, so it needs the same Pro entitlement the write itself needs: a preview runs the real operation against a full copy of your database.

Guard rails

Agents are useful precisely because they act — so Rilbo gives you independent controls:

  • Tool scopes — allowlist what's callable, per install: RILBO_MCP_TOOL_SCOPES="read" (or a comma-separated list of tool names, and the read/write group keywords). Out-of-scope tools aren't even advertised to the client.
  • Propose-writes mode — RILBO_MCP_PROPOSE_WRITES=1 (or the config equivalent): agent writes are queued as proposals with a summary instead of being applied. You review and approve them in the web UI (Admin → Proposals).
  • Per-service approval policy — Team service accounts can be set to Direct, Always propose, or Selected tools under Settings → Service tokens. Direct applies writes immediately; Always propose queues every write; Selected tools queues exactly the selected write tool ids. An empty selection means no tools are selected, never all tools.
  • Session write toggle — writes can be disabled per session; disabled tools are filtered from the advertised list.

The process-wide propose-writes mode is the safety floor: a service policy can require additional review but cannot bypass it. Consequently, Direct and an unmatched or empty Selected tools policy still queue writes whenever RILBO_MCP_PROPOSE_WRITES=1. This decision is enforced on every tools/call, not only through tool discovery.

Every write tool accepts dry_run, but only the JSON boolean true takes the non-persisting preview path and avoids proposal enqueue. A quoted "true" or another non-boolean value is rejected; false follows the effective approval policy. Dry-run previews still require the same licence entitlement as the real write because Rilbo evaluates them against a full database snapshot.

When a service write is queued, the proposal stores stable ids for the requesting service and exact service-token row, never the bearer secret or its hash. Approval and rejection separately retain the authenticated human decider. Revoked or expired tokens, disabled services, inactive owners, and Team licence lapse prevent new proposals, while the service policy and pending or completed proposal history remain visible. Requester and decider attribution survives revocation, expiry, service removal, and licence downgrade.

Resources & prompts

Agents can read workspace context without burning tool calls:

  • Resources: rilbo://workspace, rilbo://docs, plus templates for issues, comments, projects, current cycles, saved views, issue search and doc search (e.g. rilbo://issue/ENG-42, rilbo://search/issues?q=flaky).
  • Prompts: implement_issue, triage_inbox, plan_project, daily_standup, release_notes.

Agent attachments

Agents can attach files — a screenshot of a failing test, say — via the add_attachment tool, and get back a ready-made Markdown token to embed the image inline in comments. Attachments are stored inside your SQLite database: still one file, still yours.

The API underneath

Everything MCP can do, the JSON API can too: REST under /api/v1, an OpenAPI document at /api/v1/openapi.json, and server-sent events at /api/v1/events for live updates. See configuration for auth modes and API tokens.