AXF MCP server

AXF

Fit the repository once. Let every agent follow the same paved path.

An agent can read your code. It still has to rediscover how this repository wants to be built, tested, searched, diagnosed, and operated. The clues are usually scattered across scripts, package tasks, prose, CI, and human memory.

AXF (Agent eXoskeleton Framework) turns that repeated local ceremony into small, self-describing capabilities. Fit the exoskeleton deliberately once; later agents can discover the right route, inspect its contract, and run it without rebuilding the procedure from scratch.

recurring repository ceremony
          ↓ fit once
inspectable AXF capabilities
          ↓ reuse
agent discovers → inspects → runs

AXF is a traffic cop, not a replacement vocabulary. It preserves a provider's existing command family by default, then projects or normalizes only the parts that need a clearer agent-facing contract. The goal is not to automate judgment. It is to spend less judgment on reconstructing the same route.

The five caller concepts

You do not need the framework vocabulary to use a fitted repository:

root-sensitive contracts, AXF distinguishes the project root used for discovery from the execution root used as the runtime working directory.

• Workspace — the repository context whose operating paths you need. In

or a repository-owned validation pack.

• Module — a reusable capability pack, such as the built-in echo module

side effects, lifecycle, policies, and an execution target.

• Capability — one named operation with declared arguments, output modes,

authority requirements.

• Inspect — read the complete contract before execution.
• Run — execute through that contract after checking its effects and

The smallest proof of life is:

npm install --global @smartergpt/axf
axf doctor
axf list --compact
axf inspect echo say
axf run echo say --message hello

AXF 2.1.3 is published under Apache-2.0; earlier npm releases retain their published terms. Outside a fitted workspace, with no root override, this example discovers the bundled manifests in the installed package. doctor reports that project root separately from the current execution directory. An explicit AXFPROJECTROOT overrides discovery; an empty directory without an axf.workspace.json marker has no capabilities. A fitted repository normally adds its own capabilities; echo.say only proves that the registry, resolver, adapter, and executor are connected.

Before and after fitting

Before AXF, a new agent searches multiple instruction files, reverse-engineers package scripts, guesses the safe validation subset, and repeats that work in the next session.

After a deliberate fit, the repository can expose stable entries such as context, check, and handoff. A caller starts with axf guide, inspects the selected capability, and runs the repository-owned route. AXF makes the route visible; the repository still owns it.

Is this repository a fit?

AXF helps when:

• agents repeatedly guess which build, test, or validation command applies;
• the same repository facts must be rediscovered before editing;
• local safety rules live in scattered prose, convention, or human memory;
• brittle shell chains keep being rebuilt for repo-specific chores.

AXF is probably not a fit when one obvious command already covers the work, the ceremony is unlikely to recur, or the provider surface changes faster than the team can maintain a capability contract.

The adoption question is:

Does this repository have repeated local operating ceremony that is worth

fitting once into stable, inspectable agent capabilities?

For a bounded, strictly read-only assessment, give an agent this prompt:

Shortened. The full README is on GitHub.