Skip to main content
Glama
README.md
# TOCA MCP Server

Deterministic execution layer for ChatGPT governed by the TOCA_OS business source of truth in Google Drive.

## Production status

The repository is beyond bootstrap. The production foundation currently includes:

- private Streamable HTTP MCP transport at `/mcp`;
- health/readiness boundaries;
- Meta OAuth, webhook and secret-management boundaries;
- provider-backed Instagram history/insights reads;
- Meta Ads read capabilities;
- persistent PostgreSQL scheduling;
- TOCA-managed Instagram scheduling tools;
- an autonomous singleton Cloud Run daemon that claims due jobs from PostgreSQL;
- idempotent Instagram publication with provider-backed reconciliation before retry;
- private GCS asset delivery through short-lived signed URLs;
- audit, dead-letter and fail-closed execution controls;
- a single Autonomy Gate, Autopilot Readiness Gate, scoped kill switches, shadow/canary governance and provider-backed capability evidence gating.

`TOCA_OS / Google Drive` remains the business source of truth. GitHub is the source of truth for code, schemas, tests and infrastructure. External providers remain authoritative for external side effects.

## Active production topology

```text
ChatGPT
  -> TOCA_OS business policy/context
  -> private TOCA MCP service
       -> typed MCP tools
       -> PostgreSQL scheduled_jobs / audit_events / provider_publications
  -> TOCA-managed Instagram daemon (singleton Cloud Run service)
       -> claimDue()
       -> approval/audit gate
       -> provider reconciliation
       -> idempotent Instagram publication
       -> provider confirmation
```

Scheduling is an application operation and must use the protected `instagram.toca_schedule.*` MCP surface. Git commits and application redeploys are not the normal publication clock or scheduling API.

## Quality gate

Every promoted change must pass:

```bash
pnpm install --frozen-lockfile
pnpm format:check
pnpm architecture:check
pnpm lint
pnpm typecheck
pnpm test
pnpm build
```

See `docs/architecture/README.md`, `docs/architecture/routes-capabilities-v1.md`,
`docs/architecture/toca-managed-instagram-scheduler-v1.md`,
`docs/operations/infrastructure-control-plane.md` and
`docs/operations/autonomy-readiness-closeout-2026-08-26.md` for the current contracts and release evidence.

TDQS

B3.1/5.0

Scored across 12 tools

Disambiguation4/5

Most tools have clearly distinct purposes (e.g., toca.workflow.create vs toca.workflow.get vs toca.workflow.advance). The exception is toca.system.health versus toca.verify—both touch on readiness/state but from different angles. Minor overlap is acceptable.

Naming Consistency5/5

All tool names follow a consistent pattern of 'toca.<domain>.<verb>' with clear verbs (get, create, advance, query) and nouns (capability, workflow, approval, audit, event). No mixing of styles or conventions.

Tool Count5/5

12 tools is well within the ideal 3-15 range. Each tool covers a distinct operation across core domains (system, capabilities, workflows, approvals, audit, events), and the count feels appropriately scoped for the server's purpose.

Completeness3/5

The server covers key operations but has notable gaps: workflow lacks an update/abort/delete, approval only has create/get (no approve/deny), and there is no event publishing—only reading. The execute tool is comprehensive but may serve as a generic workaround, yet missing lifecycle operations could still cause agent failures in certain flows.

Maintenance

ActivityActive
ResponsivenessResponsive