Skip to main content
The cards API ships four AI-forward verbs that make manifest authoring self-serve. They wrap the platform’s existing capabilities — LLM, policy engine, observer — and surface them through care-framed HTTP endpoints. All four are read-style POSTs. They don’t mutate state, so they don’t take Idempotency-Key or If-Match. They’re idempotent by construction.

scaffold — natural language to a manifest

You describe what you want; the platform writes the starting manifest.
Response:
  • manifest — editable YAML. Run it through PUT /v1/alignment/<scope>/<id> to commit, or hand it to the mnemom/cards-action for PR review.
  • reasoning — care-framed prose explaining the choices.
  • suggested_catalog_entries — values the model would recommend; consider them, then accept or adjust.
  • coverage_gaps — primitives the model thinks would benefit from operator attention.
  • cached — true when the response was served from the description-hash cache (24h TTL).
See Card Management for the full authoring flow.

explain — why did the policy engine flag this?

You ask “what’s wrong with this agent’s spec?”; the platform runs the policy engine and translates the structured findings into prose you can act on.
Response:
Each remediation carries a method + url hint that points at the sub-resource verb that would resolve it. Care-framing throughout — the prose uses “would benefit from”, “depends on”, “would close this gap” rather than compliance language. Set "enrich": true in the body to call the LLM and expand the structured remediations into long-form prose (off by default; rate-limited). See the explain guide for the full debug-and-fix flow.

simulate — dry-run before you commit

You describe a hypothetical tool call; the platform runs the gateway and observer evaluators against the agent’s current spec and tells you whether the call would be allowed.
Response:
allowed is one of:
  • "true" — both gateway and observer pass with no conditions.
  • "false" — at least one verdict is fail.
  • "conditional" — passes but requires a receipt or carries warnings. The conditions[] array names what’s needed.
Use this before you commit a manifest change, or to test whether a specific tool call would clear the policy. See the simulate guide for the full pre-commit workflow.

tools/import — bulk preview from OpenAPI or YAML

You point the endpoint at an OpenAPI 3.0+ spec or a connector tool manifest; the platform walks the operations, extracts proposed tool definitions, and LLM-infers the class + domain for each.
Response:
The preview never auto-commits — you iterate imported[] and write each tool individually via POST /v1/tools. Platform-admin only. See the bulk import guide for the full ingest-and-confirm workflow.

Rate limits

LLM-backed verbs (scaffold and tools/import-with-inference) share a per-principal budget: On exceed: 429 Too Many Requests with a Retry-After header and a care-framed body. explain and simulate are pure-sync (no LLM by default); they don’t consume the LLM budget unless you pass "enrich": true.

Care-framed by construction

Every customer-facing string in the response surface — error messages, reasoning prose, suggested remediations — is asserted by the platform’s care-framing test to avoid compliance vocabulary (Blocked / Denied / Required / Forbidden / Violation / Must). The replacement vocabulary is would benefit from, depends on, run X then retry, you’d be supported by. LLM-generated prose runs through a post-check that swaps any slips automatically.

Cache + freshness

scaffold and tools/import-with-inference cache LLM responses by hash of the input. Identical inputs return identical outputs without burning the LLM budget. Cache TTLs:
  • scaffold: 24 hours (description-hash → manifest + reasoning)
  • tools/import inference: 7 days (tool_name + method + path + tags → class + domain inference)
explain and simulate are not cached — they consume live spec state.