agent-covenant

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, yet the description fails to disclose any behavioral traits such as idempotency, permissions, or effects. It merely states the tool describes itself, without elaboration.

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?

While extremely brief, the description is too terse and cryptic ('Fleet-standard self-description'). It fails to earn its place by providing actionable information, making it under-specified rather than concise.

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?

Despite having an output schema, the description does not explain the return value or provide any context about the tool's behavior. This leaves the agent uninformed about what the tool actually produces.

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 the schema coverage is 100%. Per guidelines, baseline is 4. The phrase 'self-description' adds minimal meaning beyond the empty 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 'Fleet-standard self-description' is vague; it does not specify what aspect of the agent is described (e.g., capabilities, metadata) and does not distinguish from sibling tools 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 given on when to use this tool versus alternatives. The sibling tools are unrelated, but the description offers no context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

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.