Turn your coding agent into a backend expert with Apso

Connect the Apso MCP server to Claude, Codex, or another compatible coding agent. The connection gives the agent an Apso operating contract, the current project schema, the full schema reference, and tools for designing, validating, generating, diagnosing, and deploying a service.

Describe the product outcome in plain language. The agent selects the appropriate Apso workflow, explains important backend decisions, and verifies its work. You do not need to translate the request into CLI commands.

Agent workflowTurn your coding agent into a backend expert with Apso.

Skills + MCP

You

“Add team invitations with owner and admin roles. Explain the tenant boundary, then build and test the workflow.”

Apso contextProduct rulesSchema referenceProject-aware toolsSafety boundaries

01
InspectRead the current project and schema.
02
ModelPropose entities, scope, and permissions.
03
GenerateBuild from the validated contract.
04
VerifyRun migrations, tests, and one real workflow.

Ask for the product outcome. The agent can choose the Apso tools and show its backend decisions before it changes the project.

What makes the agent a backend expert

Layer	What the agent receives	Why it matters
Operating rules	Apso’s source-of-truth, tenancy, extension, validation, and safety conventions	The agent follows the same backend boundaries across tasks
Product knowledge	The `.apsorc` schema reference and the current project schema	The agent uses valid Apso structures instead of guessing
Project tools	MCP tools for schema design, validation, generation, diagnostics, local development, and deployment	The agent can act on the real project and inspect the result
Ownership boundary	Instructions to preserve `src/autogen/` and place product logic in `src/extensions/`	Regeneration stays predictable and your code remains portable

The expert instructions are sent automatically when an agent connects to apso mcp serve.

Install the full Claude plugin

The Apso plugin for Claude Code bundles the MCP connector, expert guidance, schema references, and task skills for schema design, API generation, auth, migrations, testing, and deployment.


claude plugin marketplace add apsoai/skills
claude plugin install apso@apso

After installation, start Claude Code from the Apso project and describe the product outcome. The plugin supplies the specialist workflows and connects the project tools.

Connect any MCP-compatible agent

Codex and other MCP-compatible agents receive the Apso expert operating contract, schema resources, and project tools directly from apso mcp serve. Install the Apso CLI, then add the MCP server to the agent:

MCP configuration


{
  "mcpServers": {
    "apso": {
      "command": "apso",
      "args": ["mcp", "serve"]
    }
  }
}

Start the agent from the directory containing your Apso project. The MCP server will locate .apsorc in that directory or its parents.

The agent receives the same local access as the apso process. Keep production credentials out of the development environment and require explicit approval before migration or deployment changes.

Add durable project guidance

The MCP connection supplies the Apso expert rules. You can reinforce the role for every contributor by adding this section to the project’s AGENTS.md, CLAUDE.md, or equivalent instruction file:

AGENTS.md


## Apso backend work
 
Act as the Apso backend expert for this project.
 
- Inspect `.apsorc` before proposing backend changes.
- Treat `.apsorc` as the source of truth for the generated service.
- Use the Apso MCP server and schema reference instead of inventing Apso syntax.
- Explain entities, relationships, tenant boundaries, indexes, and migration risk before generation.
- Never edit `src/autogen/` directly.
- Put product-specific behavior in `src/extensions/`.
- Validate before generation, then run the relevant build, tests, and diagnostics.
- Ask for product decisions when roles, ownership, billing, retention, or destructive behavior are ambiguous.

Ask for the outcome

Describe the product behavior. Let the expert select the tools.


Build the backend for a multi-tenant project workspace.

Each workspace has owners, admins, and members. Members can create projects
and tasks. Only owners can invite people or change roles. Start with the
smallest useful data model, explain the tenant boundary, then generate and
test one complete project-and-task workflow.

You do not need to ask for design_schema, validate_schema, or scaffold_api. Those are implementation details the agent can choose from the requested outcome.

The expert workflow

Inspect the project. Read the current schema, framework, generated boundary, and existing extensions.
Clarify the product. Identify actors, resources, ownership, access rules, and workflows. Ask when a product decision is unresolved.
Propose the model. Explain the smallest useful entity and relationship design before writing .apsorc.
Validate and generate. Use the Apso schema reference and MCP tools, then generate from the validated contract.
Verify the result. Run the framework build, relevant tests, and Apso diagnostics. Exercise at least one real product workflow.
Preserve ownership. Keep generated code separate from product-specific extensions and leave normal framework code in the repository.

Change the product safely

Keep the agent in the same expert loop when requirements change:


Add milestones to contracts. A milestone has a title, amount, due date, and
status. Explain how the change affects existing records, update the Apso
schema, validate it, and show any destructive migration risk before applying it.

Require the agent to inspect the existing model before editing it. The agent must stop for approval when a migration could remove or rewrite data.

Review what the expert produces

Before accepting a backend change, confirm that:

The model matches the product workflow.
Tenant-owned entities are scoped consistently.
Authentication and authorization decisions are explicit.
Common query paths have appropriate indexes.
.apsorc validates before generation.
Generated files were not edited by hand.
Custom behavior lives in the preserved extension layer.
The relevant build, tests, and diagnostics pass.