Agent Action Preflight v1
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Agent Action Preflight v1preflight a note write to demo-notes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Agent Action Preflight v1
Agent Action Preflight sits between an AI agent and its tools.
Before a concrete tool call executes, it records the current principal, destination, scope, authority evidence, and relevant relations, then determines whether that exact action is formed in the current configuration.
If it is formed, the tool may execute and an evidence receipt is recorded. If it is not formed, no tool call occurs and the missing or incompatible relations remain inspectable.
This free, dependency-free v1 provides one real, locally reproducible MCP path:
MCP client → execute_preflighted_note → Agent Action Preflight → local_notes.write → local text file
local_notes.write writes a .txt file only beneath the configured local storage root. It is intentionally the only integration in v1.
Quick start
Requires Node.js 20 or newer. There are no package dependencies.
git clone https://github.com/jinen-project/agent-action-preflight-v1.git agent-action-preflight-v1
cd agent-action-preflight-v1
npm test
npm run demoThe demo starts the MCP server, makes a real JSON-RPC tools/call, observes a created local file for the formed case, then makes the matched call without a destination and confirms the file was not created. It prints a temporary receipt directory you can inspect:
AAP_RECEIPTS_DIR=/path/printed/by/demo node src/cli.mjs recent
AAP_RECEIPTS_DIR=/path/printed/by/demo node src/cli.mjs show PRE_RECEIPT_IDRelated MCP server: Dvarapala
Run with an MCP client
Start the stdio server from this directory:
npm startUse the execute_preflighted_note tool with a proposal such as:
{
"principal": "agent-01",
"action": "write_note",
"tool": "local_notes.write",
"arguments": { "filename": "hello.txt", "content": "hello" },
"referent": "a local note",
"destination": "demo-notes",
"scope": "demo-notes",
"authority_evidence": "sample-authority-agent-01-demo-notes"
}By default, receipts are placed in .aap-receipts and notes in .aap-notes. Configure a different sample configuration or local storage with AAP_CONFIG, AAP_RECEIPTS_DIR, and AAP_STORAGE_ROOT.
Inspecting actions
node src/cli.mjs recent
node src/cli.mjs show PRE_RECEIPT_IDThe CLI gives a compact history (FORMED or NOT_FORMED) and the detail is the complete inspectable JSON receipt: principal, action, destination/referent, configuration ID, relations present/missing/incompatible/unresolved, formation basis, occurrence, evidence references, and provenance.
EXECUTABLE is not stored as a permission. Each pre-action receipt derives whether T ∈ EXECUTABLE_DOMAIN(C) from the current supplied configuration.
What it does not claim
This product is not:
a universal AI safety system;
a legal compliance guarantee;
proof that an action is morally correct;
proof that external information is true;
proof that a successful action created value; or
a replacement for external authorization systems.
Formation is separate from occurrence. A formed action can still fail at its tool, and a successful file write does not establish user value, world success, adoption, or causation.
Product boundary and status
Price: free. Billing, subscriptions, paywalls, enterprise tiers, user management, and analytics are absent.
The included demo is LIVE_OBSERVED locally when you run it. Automated tests are TESTED; they do not by themselves prove a third-party MCP client or any external tool integration. The actual file-writing tool invocation is observed by the demo's MCP tools/call and filesystem assertion.
Publication status: PUBLICATION_READY. This repository contains only source, sample configuration, and generated-on-demand local demo data. Run npm run secrets:scan before publishing. No publication occurs automatically.
Deferred: further tools, browser automation, policy suites, and generalized agent frameworks are outside v1.
Related free tools
Evidence Packet — inspect the relationship between claims and supplied evidence.
Reversibility Review — inspect what returned after a local file change.
Available Tools
1 toolexecute_preflighted_noteC
Preflight a concrete local note action, then write it only when the present configuration forms that transition.
| Name | Required | Description | Default |
|---|---|---|---|
| proposal | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. It mentions a preflight step and a conditional write, implying mutation, but does not explain what happens when the condition fails, what the preflight entails, or whether the write is destructive. This is insufficient for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and roughly structured as a two-step process, but its cryptic wording reduces clarity. It avoids verbosity, yet the brevity does not compensate for the ambiguous and opaque language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one nested object parameter, no annotations, and no output schema, so the description must supply nearly all operational context. It does not explain what a 'proposal' is, what 'preflight' validates, what 'configuration' and 'transition' refer to, or what the tool returns. The description is far from adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description makes no reference to the 'proposal' parameter or its expected structure. Since the agent must construct a valid 'proposal' object, the lack of any semantic guidance for this parameter is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—preflight a local note action and conditionally write it—so it goes beyond a tautology. However, the phrase 'when the present configuration forms that transition' is vague and fails to define what sort of transition or action is involved, leaving the overall purpose murky.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, what prerequisites exist, or what alternatives might apply. The only condition mentioned—'write it only when the present configuration forms that transition'—is too abstract to serve as practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
execute_preflighted_note
TDQS
Scored across 1 tool
With only one tool, there is no risk of overlapping purposes or misselection. The single tool's responsibility is clearly unique by default.
The sole tool name follows a verb_object pattern (execute_preflighted_note) and there are no mixed conventions to penalize.
A one-tool server feels thin for an 'Agent Action Preflight' scope, though the tool itself is non-trivial and narrowly focused.
Only an execute-with-preflight operation is exposed; agents have no way to inspect current configuration, separate preflight from execution, or recover from failed writes, creating significant gaps.
Related MCP Connectors
Pre-action attestation perimeter for AI agents — 8 primitives, signed C18 receipt per call.
Preflight, approve, and prove consequential agent actions with signed evidence and x402 tools.
Pre-execution policy gate for consequential agent actions with durable trust receipts.
Runtime permission, approval, and audit layer for AI agent tool execution.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides cryptographic governance receipts for AI agents, enabling pre-execution evaluation and signed verdicts (EXECUTE/BLOCK/REVIEW/SHADOW) with offline-verifiable audit trails.MIT
- AlicenseNot gradedqualityCmaintenanceProvides permission gates and tamper-evident audit logging for AI agent tool executions, with declarative policies, consent ladders, and hash-chained verification.MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents and MCP clients to screen proposed actions, enforce deterministic policies and limits, and produce tamper-proof signed audit receipts before any external side effect is executed.2 npmMIT
- AlicenseBqualityBmaintenanceEnables AI agents to execute actions under an accountability layer with identity passports, mandates, a permission gate, and a tamper-evident journal, while requiring human confirmation for irreversible operations.73AGPL 3.0