What does this affect?
Returns the traits found in the description, the safeguards that apply, and the questions still open.
For agents and tools
Let your agent ask before it builds.
Point an MCP coding agent here. It can check what a change affects and ask you the decisions it cannot make. No account, key, or install required.
The round trip
How an agent uses AgentDirective
Four calls, with no install or repository access. Decisions stay with the person.
- 01 / Connect
Point your agent at the hosted endpoint.
No install, no account, no key. Your agent calls the tools over HTTP and receives compiled files back as text.
https://agentdirective.org/mcp
- 02 / Analyze
The agent sends the build description.
It gets back the detected characteristics, the applicable Control Packs, and the open decisions — as questions to ask you, never as answers.
4 characteristics7 packs9 questions for you - 03 / Compile
Matched packs and recorded answers become a directive.
A decision marked confirmed must carry a real value, so an agent cannot record its own guess as something you decided. Open decisions produce an explicit draft; zero matched packs produce no directive.
Build rulesagent-directive.json · machine-readable requirementsReadable briefAGENTDIRECTIVE.md · instructions in plain language - 04 / Report back
The agent records what it reports building.
Implemented, partial, unresolved, not applicable, or rejected — with evidence pointers and limitations, keeping reported status distinct from independent verification.
implementedpartialunresolved
Model Context Protocol
One URL, no install
The endpoint speaks JSON-RPC 2.0 over HTTP, so any MCP client can use it without running code locally.
https://agentdirective.org/mcpMost clients take a remote MCP server as a URL in their configuration. A GET on that address describes the endpoint and lists its tools.
Build the hand-off
Creates the bundle when at least one safeguard applies. Open decisions stay open; no-match results are not called directives. Pass previous_directive to compare a new request with an existing one.
Check the report
Reviews the directive and the implementation status your agent reported, using metadata only.
Check what is already built
Creates a read-only checklist and a safe assessment template for the agent to complete locally.
Return the next steps
Checks the assessment and returns gaps, open decisions, and an improvement prompt.
Read the safeguards
Returns the Control Packs, their rules, questions, requirements, and evidence references.
Human authority and decision boundaries
An agent can analyze project traits and compile directives, but it cannot make policy decisions on its own. Spending limits, approval workflows, retention policies, and permissions must be confirmed by a human operator.
When generating directives, any requirement without an explicitly confirmed answer remains marked as open, prompting the agent to ask you before proceeding.
HTTP API
Or call it directly
Read-only methodology routes plus stateless compile and review. Cross-origin requests are allowed, so a browser tool can call these too.
| Route | Method | Returns |
|---|---|---|
/api/methodology | GET | Methodology, pack-library, and schema versions. |
/api/packs | GET | Every Control Pack with applicability logic, questions, requirements, and external control mappings. |
/api/oscal/catalog | GET | The same Control Pack library as a schema-validated NIST OSCAL 1.2.2 catalog, for tooling that already reads OSCAL. |
/api/failure-patterns | GET | Real-world-grounded failure patterns, each labeled by evidence kind and cited to a public source. |
/api/vocabulary | GET | Recognized platform names and the review areas they may indicate. |
/api/benchmark | GET | The detection-and-pack-agreement dataset and its latest results snapshot. |
/api/transparency | GET | The published metrics snapshot, with definitions and privacy thresholds. |
/api/changelog | GET | Dated record of product changes. |
/api/compile | POST | Compiles a directive bundle from a description, characteristics, and decisions. |
/api/existing-project/plan | POST | Creates a checklist, sanitized assessment template, and read-only inspection prompt for an existing project. |
/api/existing-project/audit | POST | Checks a coding agent's sanitized assessment and returns findings, open decisions, and a prioritized improvement prompt. |
/api/outcomes | POST | Accepts one explicitly consented, allowlisted design-change category and stores only an aggregate daily count. |
/api/review | POST | Bounded metadata review of a directive and reported status. |
/api/health | GET | Service and runtime status. |
What is stored when you call these
Nothing you send is retained. Compile and review routes are stateless: descriptions, decisions, and submitted metadata are used to produce the response and then discarded. The service records only aggregate counters — never the contents. See /transparency for what is published, /existing for an existing project, and /review for a project that already has a directive.
Before you rely on it
Current limits, stated plainly
- Every Control Pack is still in reviewNone has completed the technical and evidence review the project's own governance requires before release. Treat the library as pre-release methodology content.
- Detection is simple and repeatableTraits come from a versioned phrase list and a few context rules, not a model. You correct the starting list, and no match is not a safety conclusion.
- A compiled directive is design guidanceIt is not a security guarantee, a certification, or verification that anything was implemented.
- Versions may changeSchemas and packs are versioned and every response carries its version, but this is a v0.1 interface and shapes can still change. Pin to the versions you read.