AX Engineering Console

MCP and tools

MCP is a standardised connection, and a tool is the capability reached through it. Keeping every outside reach behind one interface is what makes it possible to bound that reach at all. MCP is the interface layer, never the business logic.

No connection exists. Nothing here opens a socket, calls an API, or reads a database. The capability each tool would carry is declared; the carrying is not implemented.

How a request would reach outside

  1. Agent
  2. Capability policy
  3. MCP
  4. Tool
  5. External system

The policy sits before the interface on purpose. A capability a role does not hold should never reach the transport at all.

Integrations

  • CodebaseCarries 6 capabilities: read_code, run_tests, edit_worktree, create_branch, commit_worktree, push_working_branch.
    Planned
  • DocumentationCarries 1 capability: read_docs.
    Planned
  • GitHubCarries 6 capabilities: github_read, read_ci, comment_issue_or_pr, create_pull_request, direct_main_push, force_push.
    Planned
  • Database metadataCarries 2 capabilities: database_metadata, database_write.
    Planned
  • No tool requiredCarries 4 capabilities: preview_deploy, staging_deploy, production_deploy, secrets_access.
    Not applicable

Every integration is Planned because none has been built. The capabilities are real declarations; the connections behind them are not.

Vendor adapters

An adapter is the file a vendor tool reads first, and nothing more. It holds no capabilities of its own: permissions come from the policy, not from which tool is being used.

  • Anthropic Claude CodeclaudeEntrypoint CLAUDE.md.Implemented

    Entrypoint

    • CLAUDE.md

    Shared instructions

    • AGENTS.md

    Commands in a project

    • /ax-task — Complete AX development cycle
    • /ax-plan — Create a bounded implementation plan (was /dev-plan)
    • /ax-dev — Implement a requested change (was /develop)
    • /ax-debug — Diagnose and fix a bug (was /debug)
    • /ax-review — Review a code diff (was /code-review)
    • /ax-ui-review — Review frontend/UI changes (was /ui-review)
    • /ax-verify — Run AX quality verification (was /verify)
    • /ax-git — Branch, commit and push safely
    • /ax-pr — Prepare and create a pull request
    • /ax-deploy — Plan and start a permitted deployment

    Installed for the person

    • /ax-init — Initialize or adopt AX in a repository

    Command namespace

    • ax-<purpose>

    Notes

    • CLAUDE.md is a thin surface that defers to AGENTS.md rather than restating it.
    • It additionally imports docs/claude-handoff.md, a session handoff rather than durable instruction.
    • Every command carries the ax- prefix, so an AX command is distinguishable from the client's own or a third party's.
    • Commands generated before 0.2.0 used generic names. `ax migrate` renames them and preserves any that were edited.
    • Renaming this repository into a Claude-specific harness is explicitly out of scope.
    • /ax-git, /ax-pr and /ax-deploy call the ax CLI, which previews first and acts only on an approved plan. The generated settings deny Claude direct git push, git commit, gh pr create, gh pr merge and gh workflow run.
    • ax migrate adds a missing /ax-git, /ax-pr or /ax-deploy to an existing workspace and never replaces a file already at those paths.
    Inspect the definition source
  • OpenAI CodexcodexEntrypoint AGENTS.md.Implemented

    Entrypoint

    • AGENTS.md

    Shared instructions

    • AGENTS.md

    Notes

    • Codex reads AGENTS.md, which is itself the vendor-neutral instruction document for this repository.
    • The entrypoint and the shared document coincide here; no Codex-specific architecture exists.
    • Nested projects keep their own AGENTS.md or CLAUDE.md, which apply when working inside them.
    Inspect the definition source