Evaluate an architectural brief for determinism, negative invariants, and Axiom Completeness Index to identify specification gaps before implementation.
Evaluate architectural brief determinism, negative invariants floor, and Axiom Completeness Index (ACI).
| Name | Required | Description | Default |
|---|---|---|---|
| brief_text | Yes | Markdown content of the architectural intake brief to evaluate |
Changes observed during successful MCP inspections.
v3.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Evaluate', without stating whether the tool is read-only, whether it returns a report or score, whether it modifies anything, or how the evaluation is performed. This leaves significant ambiguity about side effects and expected 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?
A single, tightly worded sentence contains no filler and front-loads the action. It efficiently communicates the tool's scope in three parallel items without unnecessary explanation.
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 lack of annotations and output schema, the description omits what the tool returns, how results are expressed, and what the caller can expect after invocation. An agent would know what the tool evaluates but not what it will get back, making the definition incomplete for a tool with no other structured 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?
Schema coverage for the single required parameter is 100%, so the schema already documents brief_text as Markdown content. The description adds the evaluation dimensions (determinism, negative invariants, ACI) but does not elaborate on how brief_text is used or formatted beyond what the schema states. 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?
The description begins with a specific verb, 'Evaluate', and identifies the resource ('architectural brief') plus three concrete evaluation dimensions: determinism, negative invariants floor, and ACI. This clearly distinguishes it from sibling tools like prune_file and resolve_context_bundle, which operate on different resources with different purposes.
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?
Usage context is implied: it is used when an architectural brief needs evaluation. However, there is no explicit statement of when to prefer this tool over alternatives, no exclusions, and no guidance about prerequisites or typical invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.