Mqttable
Back to docs

Agent quickstart for Mqttable MCP

The minimal agent flow for discovering Mqttable runtime state, reading schemas, planning actions, and verifying results.

Jun 24, 2026Mqttable EngineeringMqttable Engineering

An agent should treat Mqttable as a live tool, not a pile of static docs. Discover the runtime first, then ask the catalog what it can safely do.

Interactive diagram

Agent path: commands, runtime info, doctor, schema, plan, confirm, apply, verify.

Placeholder for the interactive diagram. Replace with the generated artifact when ready.

placeholder

Start with discovery

  • bin/mqttable-cli commands --json shows the local CLI catalog.
  • bin/mqttable-cli runtime info --json shows which runtime the CLI will use.
  • bin/mqttable-cli doctor --json explains missing or stale runtime context.
  • bin/mqttable-cli mcp client-config --json prints client config with the proper authorization header when runtime info is fresh.

Use schemas before payloads

Agents should not guess JSON. Use get_mqttable_schema for an action, workflow, or resource before building input. Use get_mqttable_example when a concrete compact tool call is needed.

Write only through plans

Broker changes, connection changes, publish actions, benchmark runs, proxy toxics, TLS binding, and report persistence should go through plan_mqttable_action. The apply step accepts only plan_id and confirmation.confirmation_token.

Read after every write

The final step is not “done”. The final step is verify_mqttable_plan, plus any resource read the agent needs to show the human what changed.