api/*.js or api/*.ts files for new data APIs — the legacy pattern is deprecated and being removed.
This guide walks through adding a new RPC to an existing service and adding an entirely new service.
Enforcement:npm run lint:api-contractruns in CI (see.github/workflows/lint-code.yml). It walks every file underapi/, pairs each sebuf gateway (api/<domain>/v<N>/[rpc].ts) with a generated service undersrc/generated/server/worldmonitor/, and rejects any file that is neither a gateway nor listed inapi/api-route-exceptions.json. The manifest is the only escape hatch for endpoints that genuinely cannot be proto — OAuth callbacks, binary responses, upstream proxies, operator plumbing — and every entry is pinned to @SebastienMelki via.github/CODEOWNERS. Expect reviewer pushback on new entries. Generation freshness: After modifying any.protofile, runmake generatebefore pushing. The generated TypeScript insrc/generated/is checked in and must stay in sync;.github/workflows/proto-check.ymlfails the PR if it drifts.
Prerequisites
You need Go 1.21+ and Node.js 18+ installed. Everything else is installed automatically:- buf — proto linting, dependency management, and code generation orchestrator
- protoc-gen-ts-client — generates TypeScript client classes (from sebuf)
- protoc-gen-ts-server — generates TypeScript server handler interfaces (from sebuf)
- protoc-gen-openapiv3 — generates OpenAPI v3 specs (from sebuf)
- npm dependencies — all Node.js packages
src/generated/client/{domain}/v1/service_client.ts— typed fetch client for the frontendsrc/generated/server/{domain}/v1/service_server.ts— handler interface + route factory for the backenddocs/api/{Domain}Service.openapi.yaml+.json— OpenAPI v3 documentation
Adding an RPC to an existing service
Example: addingGetEarthquakeDetails to SeismologyService.
1. Define the request/response messages
Createproto/worldmonitor/seismology/v1/get_earthquake_details.proto:
2. Add the RPC to the service definition
Editproto/worldmonitor/seismology/v1/service.proto:
3. Lint and generate
npx tsc --noEmit will fail because the handler doesn’t implement the new method yet. This is by design — the compiler enforces the contract.
4. Implement the handler
Createserver/worldmonitor/seismology/v1/get-earthquake-details.ts:
5. Wire it into the handler re-export
Editserver/worldmonitor/seismology/v1/handler.ts:
6. Verify
api/seismology/v1/[rpc].ts. createSeismologyServiceRoutes() picks up the new RPC automatically — no route-table or vite.config.ts edits are needed.
7. Check the generated docs
Opendocs/api/SeismologyService.openapi.yaml — the new endpoint should appear with all validation constraints from your proto annotations.
Adding a new service
Example: adding a hypotheticalWeatherService. (No weather domain exists in this repo — the example below is purely illustrative; copy-pasting any path from this section will hit a 404.)
1. Create the proto directory
2. Define entity messages
Createproto/worldmonitor/weather/v1/weather_station.proto:
3. Define request/response messages
Createproto/worldmonitor/weather/v1/list_weather_stations.proto:
4. Define the service
Createproto/worldmonitor/weather/v1/service.proto:
5. Generate
6. Implement the handler
Create the handler directory and files:server/worldmonitor/weather/v1/list-weather-stations.ts:
server/worldmonitor/weather/v1/handler.ts:
7. Add the per-domain edge gateway
Createapi/weather/v1/[rpc].ts as the thin Edge entry point for this service:
api/<domain>/v1/[rpc].ts gateway, and the generated create<Service>Routes(...) function enforces the RPC path names and HTTP annotations for that domain.
8. Register in the Vite dev server
Editvite.config.ts — add the lazy import and route mount inside the sebufApiPlugin() function. Follow the existing pattern (search for any other service to see the exact locations).
9. Create the frontend service wrapper
Createsrc/services/weather.ts:
10. Verify
MCP exposure decision
Every new public OpenAPI operation needs an explicit MCP decision before review. MCP is a curated agent surface, not a 1:1 mirror of REST: expose operations that are safe, predictable, and useful as tools; keep REST-only operations documented when they mutate state, spend per-call LLM or upstream budget, or need manual cache-key review. Use this checklist for each new or changed RPC:- Decide whether this operation should be exposed to MCP.
- If yes, identify the owning MCP tool and add the exact
METHOD /api/...entry to that tool’s_apiPaths. - If cache-backed, confirm the tool has the right
_cacheKeys/_coverageKeys, freshness metadata, andseed-meta:<key>health coverage. - If no, add or update the
tests/mcp-api-parity.test.mjsexclusion with the matching category prefix and a concrete reason. - If
fetch-on-miss, include one enforced secondary signal (high-cardinality-input,paid-upstream, orllm-cost) and name the upstream cost, cardinality, and tier policy that makes open MCP exposure unsafe for now. - If
mutatingorllm-passthrough, document the separate threat/cost model before proposing an MCP wrapper. Formutating, answer every question in Mutating MCP tools. - Run
./node_modules/.bin/tsx --test tests/mcp-api-parity.test.mjsand include the result in the PR.
covered operation is declared in a tool _apiPaths entry. For REST-only operations, the parity test accepts these exclusion categories:
The MCP reference docs render the current
_apiPaths coverage table in MCP Overview. The parity test is canonical for the current covered/excluded split, so do not rely on stale counts in a PR description.
Mutating MCP tools
Every MCP tool is read-only today. The agent feedback channel (#8721) plans the first one that writes. A tool that writes state is a new kind of surface: any agent can call it, often without an account, and its input reaches people and systems we own. Before a mutating operation gets an MCP wrapper, write a decision record indocs/architecture/ that answers each question below with a concrete value, and link it from the PR.
- Abuse. Can an anonymous caller trigger the write? What are the per-IP, per-principal, and global limits, and which code enforces each one on each entry path? The MCP door does not pass through the gateway’s endpoint limiter. Are they all fail-closed, including when Redis is degraded? A global bucket is required whenever anonymous writes are allowed, because IP rotation defeats per-IP limits. Define which callers count as keyed; free accounts and anonymous sessions cost nothing to create.
- Idempotency. What happens when the same call arrives twice? Name the key that identifies a retry. Keep retry handling separate from any content deduplication, which can silently drop a later caller’s evidence. Set
idempotentHintfrom the answer, not by default. - Injection. Who or what reads the stored text: email, terminal, GitHub, an LLM? How is the text escaped for each of them? Does any automation act on it?
- Privacy. What identity is stored, and is it derived from authentication or from the body? Which credential shapes are redacted at ingest? How long is each state retained?
- Cost. What is the daily ceiling for writes, storage, email, LLM spend, and upstream fetches at the configured limits?
- Tool contract. State the access class and all four annotations (
readOnlyHint,destructiveHint,idempotentHint,openWorldHint). Name the downstream path. A free-tier tool must reach no credentialed downstream, so any exception has to be stated and pinned by test. Say how the tool obtains the caller’s IP, user agent, and request id, because_executedoes not receive the request. - Re-open conditions. Which future changes invalidate the record?
agent-feedback-threat-model.md is the first such record and a worked example. A second mutating tool needs its own record; it does not inherit an existing one or its exceptions.
Proto conventions
These conventions are enforced across the codebase. Follow them for consistency.File naming
- One file per message type:
earthquake.proto,weather_station.proto - One file per RPC pair:
list_earthquakes.proto,get_earthquake_details.proto - Service definition:
service.proto - Use
snake_casefor file names and field names
Time fields
Always useint64 with Unix epoch milliseconds. Never use google.protobuf.Timestamp.
Always add the INT64_ENCODING_NUMBER annotation so TypeScript gets number instead of string:
Validation annotations
Importbuf/validate/validate.proto and annotate fields at the proto level. These constraints flow through to the generated OpenAPI spec automatically.
Common patterns:
Shared core types
Reuse these instead of redefining:Comments
buf lint enforces comments on all messages, fields, services, RPCs, and enum values. Every proto element must have a// comment. This is not optional — buf lint will fail without them.
Route paths
- Service base path:
/api/{domain}/v1 - RPC path:
/{verb}-{noun}in kebab-case (e.g.,/list-earthquakes,/get-vessel-snapshot)
Handler typing
Always type the handler function against the generated interface using indexed access:Client construction
Always pass{ fetch: (...args) => globalThis.fetch(...args) } when creating clients:
globalThis.fetch is required for Tauri compatibility AND for the runtime fetch interceptor — fetch.bind(globalThis) is banned because it freezes a reference to the global fetch at module-init time, which bypasses any later interceptor (auth headers, request logging, retry shims) installed on globalThis.fetch. The arrow-function wrapper resolves globalThis.fetch on every call.
Generated documentation
Every time you runmake generate, OpenAPI v3 specs are generated for each service:
docs/api/{Domain}Service.openapi.yaml— human-readable YAMLdocs/api/{Domain}Service.openapi.json— machine-readable JSON
- All endpoints with request/response schemas
- Validation constraints from
buf.validateannotations (min/max, required fields, ranges) - Field descriptions from proto comments
- Error response schemas (400 validation errors, 500 server errors)
