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., "@Aegis inject LAND context and block any done-claim without live proof"
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.
Fail-closed control layer for coding agents. MCP tool, not a chat app.
Hooks inject. Tools execute. File-exists is not a receipt. You do not certify.
Tool | Job |
| Force LAND context this turn ( |
| BLOCK a done-word with no live proof |
| Freeze the seat after BLOCK |
| Run the scar engine on a prompt |
Related MCP server: Sensory-Grounding MCP
.cursor/mcp.json:
{
"mcpServers": {
"aegis": {
"command": "npx",
"args": ["-y", "github:Viss007/aegis"]
}
}
}Local clone:
{
"mcpServers": {
"aegis": {
"command": "node",
"args": ["bin/aegis-mcp.mjs"]
}
}
}Hook (inject, not a tool):
{
"version": 1,
"hooks": {
"beforeSubmitPrompt": [{ "command": "node hooks/land.cjs" }]
}
}Same file on disk. No live proof.
inject on → refuse. file-exists side door blocked.
inject off → liar says DONE.
POST /mcp JSON-RPC. Same methods as stdio (initialize, tools/list, tools/call).
Run the LAND scar engine on a user prompt. Inject on = file-exists side door blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | No | ||
| inject | No | Default true. LAND inject this turn. | |
| prompt | Yes | ||
| file_exists | No | ||
| live_verified | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, yet it only hints that injection is a side effect ('Inject on... side door blocked') without stating permissions, reversibility, or side effects on the user prompt. The phrase 'side door blocked' implies a gating condition but is too cryptic to act on.
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?
Two short sentences with no filler and the action front-loaded. The trade-off is that the second sentence is compressed to the point of being unparseable, so brevity comes at the cost of comprehension.
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?
A five-parameter tool with one required parameter, no output schema, and no annotations needs a description that explains inputs and effects; this one leaves most parameters and the entire return/behavior model unexplained. Only the inject/file_exists interaction is gestured at.
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 coverage is only 20% (just 'inject'), so the description must compensate, and it partially touches the inject/file_exists relationship. However, it adds nothing for required 'prompt' or for 'claim' and 'live_verified', leaving three parameters undocumented in both places.
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?
It gives a verb ('Run') and a named resource ('LAND scar engine'), but the resource is undefined jargon that an agent cannot decode, and the second sentence ('Inject on = file-exists side door blocked') is telegraphic and does not clarify what the tool actually produces or decides. Nothing here distinguishes 'decide' from siblings land_inject, no_fake_done, or trust_freeze.
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?
There is no statement of when to use this tool versus the sibling tools, no prerequisites, and no exclusions. The fragment about inject/file_exists is parameter behavior, not usage guidance, so an agent has no routing information at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force LAND context this turn. Returns additional_context the model must see before the prompt. Hooks inject. Tools do not.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that context is forced this turn and that additional_context is returned before the prompt, but says nothing about permissions, side effects, reversibility, or the shape of the injected context.
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?
Four very short sentences, front-loaded with the effect and return value, contain no filler. The cryptic fragments ('Hooks inject. Tools do not.') are inefficient for comprehension even though they are brief.
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?
There is no output schema and no annotations, leaving the description as the only source of truth. It fails to define 'LAND context', explain how additional_context should be used, or clarify when the forced injection is warranted, so an agent lacks enough to invoke it confidently.
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?
The tool has zero parameters and an empty schema, so there is no parameter semantics for the description to add. Per the baseline rule for 0 params, a 4 is appropriate.
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 states an effect ('Force LAND context this turn') and a return field ('additional_context'), but 'LAND context' is undefined domain jargon. An agent cannot identify the resource or domain, and the distinction from siblings like trust_freeze or decide is not made clear.
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 line 'Hooks inject. Tools do not.' hints at a manual injection scenario, but there is no explicit when-to-use, when-not-to-use, or named alternative among the sibling tools. Usage remains largely inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fail-closed done gate. BLOCK if a done-word is claimed without live proof. file-exists is not a receipt. You do not certify.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | The done-claim to gate. | |
| file_exists | No | Path exists on disk. | |
| live_verified | No | Live proof matching the claim this turn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is fail-closed and blocks unproven claims, and clarifies that file-exists is not considered a valid receipt. It does not detail what happens on success, error output, or whether the tool is pure (no side effects), leaving some behavior implicit.
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?
Extremely concise, front-loaded with the core purpose. Every sentence is short and contributes to understanding the gating behavior without redundancy.
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?
For a 3-parameter tool with no annotations or output schema, the description adequately covers the core behavior and the critical distinction about proof. It misses some operational details (e.g., return format, interaction with siblings) but is largely complete for an agent to invoke it correctly.
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 coverage is 100%, so the schema already documents the parameters. The description adds marginal meaning by implying that live_verified is the key proof and file_exists alone is insufficient, but does not extend parameter documentation beyond what the schema provides. Baseline 3 is appropriate.
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?
States the tool's function as a fail-closed done gate that blocks completion claims lacking live proof. The verb (BLOCK) and resource (done-claims) are specific, though the phrasing is terse and not clearly differentiated from siblings like trust_freeze or decide.
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?
Clearly indicates when to use: whenever a done-word is claimed without live proof. Contrasts with the alternative (file-exists alone is insufficient) and emphasizes this is a gate. However, it doesn't specify when the tool should NOT be used or how it relates to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freeze the seat after a no_fake_done BLOCK. Second catch. Fail-closed.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose a meaningful behavioral trait ('Fail-closed') and that it activates on a second violation, but it does not say what freezing entails, whether it is reversible, scope of effect, or required permissions for a clearly mutating operation.
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?
Three terse fragments with the trigger front-loaded ahead of the fail-closed posture; there is virtually no filler. The extreme compression costs some clarity, but nothing is wasted.
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?
For a state-mutating tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It omits the effect of a freeze, reversibility, and the meaning of both inputs, leaving an agent unable to call it confidently.
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 never mentions the 'reason' or 'source' parameters. The two params are somewhat intuitable by name, but the description adds no format, allowed values, or meaning beyond the bare schema, leaving the compensation gap the low coverage demands.
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 verb 'Freeze' plus the trigger relationship to the sibling no_fake_done ('after a no_fake_done BLOCK') hints at the tool's role, and 'Second catch' positions it relative to a first catch. However, the core domain noun 'the seat' and what freezing actually does are left opaque, so an agent without prior context cannot fully distinguish it from 'decide' or 'land_inject'.
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?
It states a trigger condition ('after a no_fake_done BLOCK', 'Second catch'), which is a usable when-to-use cue tied to the sibling tool. It names no explicit alternatives or exclusions, and the condition is expressed in jargon that requires inference to map to a callable state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0decideland_injectno_fake_donetrust_freezeScored across 4 tools
land_inject and decide both concern LAND context injection, making their boundary unclear. no_fake_done and trust_freeze are sequentially coupled but their distinct roles are not obvious from names alone, so an agent could easily misselect.
All names use snake_case, but the patterns are mixed: land_inject is verb_noun, no_fake_done is a negation phrase, trust_freeze is noun_verb, and decide is a single verb. It is readable but not predictable.
Four tools is a reasonable size for a specialized guardrail server. However, the overlap between land_inject and decide suggests some consolidation might be warranted.
The inferred domain is agent safety and enforcement, but there is no tool to unfreeze trust, check current state, or submit proof/receipts. These gaps could lead to deadlocks or agent failures.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
Governance layer for AI coding agents: knowledge-graph grounding, session audit, policy controls.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
