Deny-by-default authority leases for agents wielding real power.
Scored across 7 tools
Each tool serves a distinct purpose: granting, revoking, checking, listing, status, auditing, and self-description. No two tools overlap in function.
Most tools follow verb_noun pattern (e.g., grant_covenant, check_act), but covenant_status uses noun_noun, a minor inconsistency.
Seven tools cover the covenant lifecycle without bloat, fitting well within the 3-15 optimal range.
Core operations (grant, revoke, check, list, status, audit) are covered. Missing a dedicated tool to view a single covenant's details, but list_covenants and covenant_status likely suffice.
Check (and if allowed, record) a proposed act against a covenant. Deny-by-default. Idempotent on act_id — retries never double-consume budget. Every check lands on the audit chain.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | ||
| act_id | Yes | ||
| covenant_id | Yes | ||
| amount_minor | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behaviors: deny-by-default, idempotent on act_id (no double consumption), and every check lands on audit chain. Missing error or permission details, but sufficient for core behavior.
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 sentences, no filler. Front-loaded with purpose, then behavioral constraints. Every sentence adds value 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?
Given 4 parameters, no annotations, and an output schema (unseen), the description covers core behavior but omits parameter details and return format. Adequate for a check tool but with clear gaps in parameter documentation.
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 0% (no parameter descriptions), and the description does not explain any parameters beyond their titles. Parameter names like covenant_id and act_id are somewhat self-explanatory, but amount_minor and scope lack context. The description fails to add meaning to the schema.
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 clearly states the action: 'Check (and if allowed, record) a proposed act against a covenant.' It specifies the verb (check/record) and the resource (act, covenant), distinguishing it from sibling tools like covenant_status or grant_covenant which handle different operations.
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 provides clear context with 'Deny-by-default' and idempotent behavior, but does not explicitly state when not to use or compare to alternatives. However, the sibling list implies there are other covenant tools, so the guidance is adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current state, consumed/remaining budget, and check count.
| Name | Required | Description | Default |
|---|---|---|---|
| covenant_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects (likely read-only), prerequisites, or rate limits. Agent lacks behavioral context beyond what is stated.
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?
Short one-sentence description efficiently communicates core functionality, but could benefit from breaking into multiple points for readability.
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?
With output schema present and simple parameter, description covers key return fields, but misses parameter explanation and usage context, leaving gaps for an agent.
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?
Single parameter 'covenant_id' lacks any description beyond its name and type; schema coverage is 0%, and the description adds no additional meaning or guidance on obtaining the ID.
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?
Clearly states the tool returns 'current state, consumed/remaining budget, and check count' for a covenant, distinguishing it from listing, granting, revoking, or auditing tools.
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?
Implies usage for retrieving status of a specific covenant, but no explicit guidance on when to use versus alternatives like list_covenants or verify_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fleet-standard self-description.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It merely says 'self-description,' which does not state whether the operation is read-only, what data it returns, whether it has side effects, or any constraints. No behavioral traits are disclosed beyond the bare concept.
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 extremely short, but this is under-specification rather than effective conciseness. The phrase 'Fleet-standard self-description' is a fragment that conveys almost no useful information. Every word does not earn its place because the phrase is vague and lacks substance.
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?
Although an output schema exists, the description is too minimal to be considered complete. It does not explain what 'self-description' means, how the output is structured, or when to invoke the tool. The presence of the output schema helps, but the description itself leaves critical context unresolved, especially given the zero annotations and no usage guidance.
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, so the baseline for this dimension is 4 per the rubric. The description adds no parameter semantics, but none are needed since the input schema is empty and coverage is trivially 100%. The description does not hinder parameter understanding.
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 'Fleet-standard self-description' is essentially a tautology of the tool name 'describe_agent'; it restates the concept without specifying what the self-description contains or what action is performed. The modifier 'Fleet-standard' adds branding but not functional clarity, making it insufficiently distinct from the name itself.
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 provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, and none of the sibling tools are referenced. This is a complete absence of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grant an agent a covenant: an explicit lease of authority. scopes support wildcards ('payments.', ''); budget_minor is the total spend ceiling in minor units; expires_at is ISO-8601. Returns the covenant_id.
| Name | Required | Description | Default |
|---|---|---|---|
| scopes | Yes | ||
| agent_id | Yes | ||
| principal | Yes | ||
| expires_at | Yes | ||
| budget_minor | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions returning covenant_id but lacks details on side effects, permissions needed, or idempotency. Adequate but not thorough.
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 sentences: first defines purpose, second provides key parameter details. Front-loaded and no wasted words.
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?
Covers purpose and important parameter details. Output schema exists (returns covenant_id) but not elaborated. Missing explanation of principal and agent_id roles, but overall sufficient for a tool with 5 required params.
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 0%. Description adds meaning for scopes (wildcards), budget_minor (total spend ceiling in minor units), and expires_at (ISO-8601). Principal and agent_id are not explained, relying on parameter titles.
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?
Description clearly states 'Grant an agent a covenant: an explicit lease of authority,' specifying the action and resource. It distinguishes from sibling tools like revoke_covenant and list_covenants by focusing on creation.
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?
Provides parameter usage details (wildcards in scopes, budget_minor as spend ceiling, ISO-8601 for expires_at), implicitly guiding when to use. Lacks explicit when-not-to-use or alternatives, but context is clear from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List covenants, optionally filtered by state (ACTIVE|REVOKED|EXPIRED) and/or the bound agent.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| agent_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It only hints at listing but does not disclose pagination, rate limits, permissions, or whether all covenants are returned. The read-only nature is implied but not explicit.
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?
Single sentence with front-loaded purpose ('List covenants'). No fluff or 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?
Given two simple optional parameters and an output schema, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, leaving gaps for agent decision-making.
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 description partially explains the 'state' parameter with enum values but does not describe 'agent_id' semantics. Schema coverage is 0%, so the description should compensate more.
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 clearly states the tool lists covenants and specifies optional filters by state and agent. It is distinct from sibling tools like covenant_status (which likely returns a single covenant) and grant/revoke mutations.
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?
No guidance on when to use list_covenants versus alternatives like covenant_status or check_act. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Revoke a covenant immediately and terminally. All subsequent checks deny.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| covenant_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the irreversible, terminal nature and the effect on subsequent checks, but lacks details on authorization requirements, side effects, or return behavior beyond the output schema.
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 sentences, front-loading the main action without extraneous words. Every sentence adds essential meaning.
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 description covers the action's core purpose and effect, but given the lack of parameter explanations and the presence of an output schema (not shown), it is still incomplete for an agent to use correctly without additional context.
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 description does not explain either parameter ('covenant_id' or 'reason'), and the schema provides no descriptions either (0% coverage). This leaves the agent without guidance on required input or optional reasoning.
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 uses the specific verb 'Revoke' and the resource 'covenant', clearly distinguishing it from sibling tools like 'grant_covenant' and 'list_covenants'. It also adds immediacy and terminality as key differentiators.
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 implies use for permanent revocation with 'immediately and terminally' and 'all subsequent checks deny', providing clear context. However, it does not explicitly state when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the tamper-evident audit chain of allowed/denied acts.
| Name | Required | Description | Default |
|---|---|---|---|
| covenant_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must explain behavior fully. It only says 'verify', implying a read operation, but does not disclose permissions, cost, or what constitutes failure. No return value or side effects are mentioned.
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 a single sentence, concise and front-loaded, but might be too minimal for a tool with no annotations. It earns its place but lacks structure or elaboration.
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?
Given the simplicity (1 param, no nested objects) and presence of an output schema, the description is too brief. It fails to explain what the output represents or how to interpret results, leaving the agent under-informed.
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 sole parameter covenant_id is described only by its schema title 'Covenant Id'. The description adds no additional meaning or constraints beyond the schema. With 0% schema description coverage, this is a significant 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 'Verify the tamper-evident audit chain of allowed/denied acts' clearly states the verb 'verify' and resource 'tamper-evident audit chain' with specific scope. However, it does not distinguish from siblings like check_act or covenant_status.
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?
No guidance is provided on when to use this tool versus alternatives like check_act or covenant_status. There are no hints about prerequisites or when not to use it.
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.
check_actcovenant_statusdescribe_agentgrant_covenantlist_covenantsrevoke_covenantverify_auditPre-execution policy gate for consequential agent actions with durable trust receipts.
Identity and authorization in one system: allow, deny, the reason, and a record.
Credential broker for AI agents: scoped, revocable API access with policy enforcement and audit.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Add one secure layer between your agents and this server.