Compare engine claims, inspect dissent and check study evidence for student questions.
Scored across 12 tools
The four domain tools (learning, money, nutrition, psychology) are functionally the same pipeline with a swapped topic, and each also overlaps with the generic refine/research/verify pipeline tools since they internally 'refine the question, fetch studies, and show named claims.' The pure-operation tools (bts_divergence, pre_mortem, decision_tournament, claim_protocol_validate) are clearly distinct, but an agent could struggle to choose between ecca_learning and ecca_research+ecca_verify for the same question.
All names share the ecca_ prefix and snake_case, which is highly consistent. The only deviation is that the four domain tools are noun-based (ecca_money, ecca_nutrition) while the pipeline tools are verb-based (ecca_refine, ecca_verify), a minor stylistic split.
Twelve tools is well within the ideal 3-15 range. Each tool maps to a recognizable step in an epistemics/research engine (entry-point domains, refine, research, synthesize, verify, plus specialized analyses), and no tool seems purely filler.
The surface covers a full reasoning lifecycle: refine, research, synthesize, verify, adversarial pre-mortem, decision tournament, divergence penalty, and protocol validation. Minor gaps exist (e.g. no explicit history/state or export tool), but core workflows appear achievable.
Measures lexical and semantic divergence across candidate assertions to penalize sycophancy.
| Name | Required | Description | Default |
|---|---|---|---|
| assertions | Yes | Array of candidate assertions or claims to measure divergence for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so an agent knows this is a safe, side-effect-free local computation. The description adds the sycophancy-penalty intent but nothing about output shape (single score vs per-pair matrix), computational cost, or how ties are handled, so it only marginally goes beyond the annotations.
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?
One compact sentence with the verb and object front-loaded and no padding or redundancy. It is efficient, though brevity here comes at the cost of the behavioral and usage detail noted elsewhere.
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 is simple (one array parameter, annotations covering safety), but it is a measurement tool with no output schema, so the description should say what is actually returned (a divergence score? a value per assertion pair?) and what range or units apply. That gap leaves the agent guessing about the result of the call.
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 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description adds only the framing that entries are 'candidate assertions', which the schema already says; no format, count, or ordering constraints are contributed.
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 a specific verb (measures) and two named dimensions (lexical and semantic divergence) over a clearly identified resource (candidate assertions), plus the downstream intent (penalize sycophancy). This clearly separates it from sibling tools like ecca_verify or ecca_synthesize, though it never explicitly differentiates itself from them.
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 phrase 'to penalize sycophancy' hints at the motivating scenario, but there is no explicit when-to-use guidance, no stated prerequisites (e.g., minimum number of assertions), and no routing to or away from siblings like ecca_verify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check one ecca.claim-protocol 1.0 document for shape: versioned, engine slots only (no vendor names), split causes from the published taxonomy, question text only with consent, seal present. Returns ok with the error list; validates shape, never the record behind it.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | The protocol document to check (docs/CLAIM_PROTOCOL.md). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: it discloses the return shape ('Returns ok with the error list') despite no output schema existing, and draws the shape-vs-record boundary. It does not mention auth or any limits, but for a pure validator this is more than adequate.
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?
Front-loaded with the verb and resource, then a colon-delimited checklist and a closing scope statement. Two sentences, no filler, and the constraint clause is placed last where it reads as a qualifier. The checklist is dense but every item is a distinct validation rule.
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 no output schema, the description compensates by stating the return value ('ok with the error list'). The single required parameter is fully documented and the tool's read-only nature is covered by annotations. Complete enough for an agent to call it correctly; only the absence of a named alternative keeps it from the top score.
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 100% with a single 'document' parameter, so the schema already carries the parameter meaning; the baseline for high coverage is 3. The description's enumeration of expected document properties is useful but describes validation rules rather than adding syntax or format meaning to the parameter itself.
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 a specific verb ('Check/Validate') and resource ('one ecca.claim-protocol 1.0 document') and enumerates exactly what is checked (versioned, engine slots, cause split, consent, seal). The scope-limiting clause 'validates shape, never the record behind it' implicitly separates it from siblings like ecca_verify, but no sibling is named, so differentiation is inferred rather than explicit.
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 closing clause 'validates shape, never the record behind it' functions as an explicit when-not boundary, telling the agent this is not the tool for validating the underlying record. It stops short of naming the alternative tool to use in that case, so it is clear context without full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates multi-option decision matrix using minimax regret and Pareto ranking over candidate pathways.
| Name | Required | Description | Default |
|---|---|---|---|
| options | Yes | List of discrete options or strategic pathways. | |
| decisionContext | Yes | Context of the decision to evaluate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the evaluation methodology (minimax regret, Pareto ranking), but does not explain return format, limits, or other behavioral traits. With annotations doing heavy lifting, a 3 is appropriate.
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, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and methods.
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 is analytically complex (multi-option decision matrix with advanced methods) and has no output schema, yet the description does not explain what the evaluation returns or how results are structured. While annotations cover safety, the description falls short on output expectations and usage 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional syntax, format, or meaning beyond what is in the schema, so the baseline of 3 applies.
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 a specific verb ('evaluates') and resource ('multi-option decision matrix') and names the techniques used (minimax regret, Pareto ranking). It is clearly about comparing decision options, but does not explicitly differentiate from sibling tools like ecca_pre_mortem or ecca_verify.
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 explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The description only states what the tool does, leaving the agent to infer its place among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Learning and study skills: refine the question, fetch studies, and show named claims before the verdict. Applies evidence and claims checks; spends one solve.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety/idempotency profile is covered structurally. The description usefully adds that the operation 'spends one solve' and runs a multi-step evidence/claims pipeline ending in a verdict, which reinforces the non-idempotent, resource-consuming nature. It stops short of explaining budget semantics, permissions, or what the verdict contains.
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 compact sentences with the domain front-loaded and no filler. The structure is efficient, though the second clause ('Applies evidence and claims checks; spends one solve') is telegraphic enough to be slightly cryptic.
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?
This is an open-world, multi-step tool with no output schema, yet the description never says what the verdict result looks like or what a 'solve' budget implies for retries. For a tool of this complexity, the description is materially under-specified.
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%, so the description must carry the burden for the single 'question' parameter. It only alludes to 'the question' being refined, adding no format, scope, or length guidance beyond the schema's own min/max constraints, so it does not compensate for the coverage 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 domain ('learning and study skills') and sketches a pipeline (refine the question, fetch studies, show named claims, render a verdict), so the general intent is inferable. However, it never states a crisp verb+resource and the phrasing is fragmented, so an agent cannot cleanly separate it from siblings like ecca_refine, ecca_research, or ecca_verify.
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 explicit when-to-use, when-not-to-use, or alternative routing. 'Applies evidence and claims checks' hints at overlap with ecca_verify but gives no rule for choosing between them. The only usage signal is the implicit cost of 'spends one solve.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Money and business: refine the question, fetch studies, and show named claims before the verdict. Applies evidence and claims checks; spends one solve.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a mutating, non-idempotent, open-world operation, and the description adds value on top: 'spends one solve' discloses a budget/resource cost the annotations do not, and the pipeline wording (refine -> fetch studies -> named claims -> verdict) reveals the internal stages. It still does not say what the verdict output looks like or whether the solve is consumed on failure.
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 tight sentences with the domain front-loaded and no filler. The telegraphic phrasing ('spends one solve', 'Applies evidence and claims checks') is compact but borders on cryptic, slightly costing readability rather than adding bloat.
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 one-parameter tool with no output schema, the description covers the workflow and cost but omits what the verdict/result contains and how this composite relates to the refine/research/verify siblings. Adequate but with clear gaps for a tool an agent must choose 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 description coverage is 0% and there is a single required 'question' parameter, so the description must carry the load. Saying 'refine the question' merely echoes the parameter name and adds no format, length, or content guidance (e.g. that it is natural-language free text capped at 2000 chars).
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 concrete domain ('Money and business') and a sequence of actions (refine the question, fetch studies, show named claims before the verdict), so an agent can tell this is a domain-scoped question resolver. It distinguishes itself from generic siblings like ecca_refine/ecca_research by the money/business framing, though it never explicitly says it is not those 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?
The 'Money and business:' prefix weakly implies the domain in which to use it, but there is no explicit when-to-use, when-not, or named alternative among the ten siblings. With ecca_refine, ecca_research, and ecca_verify present, the agent is left to infer why this composite exists versus calling those steps directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Nutrition and supplements: refine the question, fetch studies, and show named claims before the verdict. Applies evidence and claims checks; spends one solve.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds real value beyond that: it discloses a multi-stage internal pipeline (refine → fetch studies → claims → verdict) and the non-obvious cost model 'spends one solve', which is exactly the kind of budget context an agent needs before invoking.
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 dense sentences, front-loaded with the domain and the outcome, with no filler. 'Spends one solve' is terse to the point of being cryptic, but it earns its place as cost information.
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 one parameter, no output schema and annotations covering side-effect profile, the description covers the essentials: domain, pipeline, and cost. It does not describe the shape of the verdict/claims output, which leaves an agent guessing about the return structure.
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 single 'question' parameter has no description in the schema. The phrase 'refine the question' marginally implies rough phrasing is acceptable, but nothing is said about format, the 2000-character cap, or what a well-formed nutrition question looks like.
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 the domain (nutrition and supplements) and the concrete pipeline it runs: refine the question, fetch studies, surface named claims, then give a verdict. That is a specific verb+resource statement an agent can act on, though it never names or distinguishes itself from siblings like ecca_research or ecca_verify.
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 is only implied by the domain prefix 'Nutrition and supplements' – an agent can infer it is for nutrition/supplement questions, and 'spends one solve' hints that the call has a cost worth weighing. There is no explicit when-not-to-use statement or named alternative for non-nutrition questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes an adversarial pre-mortem identifying failure modes and early warning indicators using empirical argument verification.
| Name | Required | Description | Default |
|---|---|---|---|
| premise | Yes | The strategic plan, architecture, or business premise to stress-test. | |
| horizonMonths | No | Time horizon in months to simulate forward failure modes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the analytical method ('empirical argument verification'), and says nothing about output shape, runtime, or how the horizon is used — adequate but thin given the annotations do the heavy lifting.
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 front-loaded sentence with no filler or repetition. It is dense with jargon ('empirical argument verification') but every clause carries information about what the tool produces.
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 no output schema, the description is the only place return expectations could be set, and it only gestures at results ('failure modes and early warning indicators') without describing format or scope. Two parameters and an existing annotation set keep the burden modest, so this is minimally viable rather than inadequate.
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 100%, so both 'premise' and 'horizonMonths' are already documented with meaning, defaults, and limits. The description contributes no additional parameter semantics, which is the expected baseline when the schema is complete.
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 verb and artifact — 'executes an adversarial pre-mortem' — and enumerates the deliverable (failure modes, early warning indicators). It is clearly distinct from data-flavored siblings like ecca_nutrition or ecca_money, though it doesn't explicitly contrast with the closer analytical siblings ecca_verify or ecca_decision_tournament.
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 choose this tool over ecca_verify, ecca_decision_tournament, or ecca_research, all of which are plausibly adjacent analytical tools. The agent must infer the use case from the phrase 'strategic plan, architecture, or business premise to stress-test' in the schema, not from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Psychology research: refine the question, fetch studies, and show named claims before the verdict. Applies evidence and claims checks; spends one solve.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds genuinely new context beyond the annotations: 'spends one solve' signals a cost/budget resource, and the refine→fetch→claims→verdict sequence discloses that this is a multi-step, non-trivial operation. It is consistent with readOnlyHint=false and idempotentHint=false, but it doesn't say what the verdict contains, how long it takes, or what happens if the solve budget is exhausted.
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 compact sentences that front-load the domain and then the steps. The phrase 'spends one solve' is terse to the point of being opaque, but there is no padding or repetition.
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 no output schema, the description is the only source of information about what comes back, and 'show named claims before the verdict' is a partial hint at best — no format, length, or structure is given. For a one-parameter tool with rich annotations this is adequate but not complete.
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?
One parameter with 0% schema description coverage and only min/max length constraints, so the description carries the full burden. It implies the input is a research question that gets refined, but gives no guidance on phrasing, scope, length, or what makes a good versus poor input.
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 domain (psychology) and a pipeline (refine, fetch studies, show named claims, verdict), so the agent can infer what it does. However, it overlaps heavily with siblings ecca_refine, ecca_research, and ecca_verify without saying what makes this psychology-specific check distinct from those generic 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?
No explicit when-to-use or when-not-to-use guidance, and no mention of alternatives. The only implicit signal is the domain word 'Psychology'. Given ten sibling tools covering refine/research/verify/synthesize, the absence of routing guidance is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use one keyed tier-quota slot to sharpen rough student questions without adding facts; return detected niches and refinement chips. A closed engine ceiling falls back locally.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real behavior beyond that: it costs a keyed tier-quota slot, it deliberately avoids injecting facts, and it degrades gracefully ('falls back locally') when the engine ceiling is closed. The jargon ('keyed tier-quota slot') is undefined, which keeps it short of a 5.
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 dense sentences, front-loaded with the core action and followed by the return/fallback clause; nothing is wasted. The trade-off is heavy internal jargon ('refinement chips', 'engine ceiling') that trades brevity for opacity.
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 one-parameter tool whose annotations already carry the safety profile, the essentials are present, and the description partially compensates for the absent output schema by naming what it returns. It is nearly complete; the main gap is that the quota/fallback mechanics are referenced but not explained.
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?
With a single parameter at 0% schema description coverage, the description carries the burden. It conveys that the input is a rough student question, which gives the 'text' field implicit meaning, but adds no format, length, or content guidance beyond the schema's 1-2000 char bounds.
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 gives a specific verb+resource ('sharpen rough student questions') plus a meaningful constraint ('without adding facts'), and even previews outputs ('detected niches and refinement chips'). It is clear on its own, but it never distinguishes itself from any of the ten ecca_* siblings.
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 implied usage context ('rough student questions', and the fact that it consumes 'one keyed tier-quota slot'), which hints at when the cost is warranted. However, no when-to-use vs when-not guidance and no alternative sibling is named, so the agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use one keyed tier-quota slot and dispatch-ceiling reservation to fetch and grade studies from scholarly indexes; return fetched evidence and explicit gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| niche | No | ||
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description does add the useful behavioral fact that the call consumes a quota slot and a dispatch-ceiling reservation, which is real cost information not in the annotations, but it never quantifies the cost or explains what happens when the quota is exhausted.
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?
It is a single sentence with no filler and the action is front-loaded, which is good. However, the density of undefined internal jargon ('keyed tier-quota slot', 'dispatch-ceiling reservation') makes the sentence hard to parse without adding proportionate clarity.
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 no output schema, the description correctly notes it returns evidence and explicit gaps, which is helpful. But for a tool whose two parameters are entirely undocumented and whose quota/ceiling mechanics are opaque, the definition leaves meaningful gaps an agent would need resolved before a confident call.
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%, so the description must carry parameter meaning and it does not: 'niche' and 'question' are never defined, and the maxLength 2000 / minLength 1 constraints are undocumented. The ambiguous 'keyed' term might allude to the niche enum, but this is left for the agent to guess.
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 specific verbs (fetch, grade) and a concrete resource (studies from scholarly indexes), plus the return payload (fetched evidence and explicit gaps). It is distinguishable from the domain siblings like ecca_psychology or ecca_nutrition, though the jargon-heavy 'tier-quota slot and dispatch-ceiling reservation' framing muddies rather than clarifies the core purpose.
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 explicit guidance on when to select this tool over ecca_verify, ecca_synthesize, or the per-domain siblings (ecca_psychology, ecca_learning, etc.). 'Use one keyed tier-quota slot' hints at a cost/budget condition for invocation but never states the trigger or the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare answers from configured engines and inspect disagreement, with lexical similarity and final-answer agreement when measurable.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | intuitive and fast route to one engine; executive, pioneer and deep route a multi-engine dispatch (free callers: two engines first, expanding on measured divergence, one deep solve per day). Any other value is refused. | executive |
| model | No | Label echoed in the result. Every value dispatches through the same registered engines; depth decides fast or multi-engine. | axiom-reasoner |
| query | Yes | The core inquiry, hypothesis, or decision challenge to synthesize. | |
| antagonist | No | When true, forces one engine to act as adversarial red-team antagonist. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-idempotent operation, so the description needn't restate safety. It adds some value by disclosing that similarity/agreement metrics are produced only 'when measurable', but omits the resource cost (multi-engine dispatch, one deep solve per day) and what state the non-read-only nature touches.
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 tight sentence with the core action front-loaded and no filler. It is appropriately short, though the brevity is also the source of its usage-guidance gap.
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 no output schema and a non-read-only, quota-bearing operation, the description should explain what the comparison result contains and what the call costs or consumes. It leaves the return shape and resource implications unstated and does nothing to separate this tool from its crowded set of siblings.
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 100%, so depth, model, query, and antagonist are all fully documented in the schema, including the quota and enum refusals. The description adds no parameter meaning beyond that, so the baseline 3 applies.
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 a specific verb (compare) and resource (answers from configured engines), plus the analytical angle (inspect disagreement). Clear enough for an agent to grasp intent, but it does not distinguish itself from closely related siblings like ecca_bts_divergence, ecca_decision_tournament, or ecca_verify.
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 gives purpose but no when-to-use, when-not-to-use, or alternative routing guidance. With four overlapping comparison/verification siblings, an agent has no basis for choosing this tool over ecca_bts_divergence or ecca_decision_tournament.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Independently answer a question and compare the candidate against deterministic panel agreement. Show named dissent; spends one solve.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| candidate_answer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true. The description adds a genuinely useful behavioral fact beyond them: 'spends one solve' flags a resource cost, and 'show named dissent' signals the return shape. It stops short of explaining reversal, permissions, or repeat-call 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?
Two tight sentences with no filler; the core action is front-loaded. The terse 'Show named dissent; spends one solve' fragment is a little clipped but earns its place by conveying output and cost.
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 no output schema, the description should shoulder more return-value explanation; 'show named dissent' gives partial coverage and 'spends one solve' covers cost. Parameter and output details are nonetheless thin for a two-required-parameter, non-idempotent tool.
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%, so the description carries the burden of explaining the two parameters. It identifies them conceptually ('a question', 'the candidate'), which is the minimum. But it adds no detail on length limits, format, or content expectations beyond the schema's type constraints.
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 a specific verb and resource: independently answer a question and compare a candidate against deterministic panel agreement. Combined with the title 'Verify Another AI Answer,' the core function is clear. However, it doesn't explicitly distinguish itself from near siblings like ecca_refine, ecca_synthesize, or ecca_bts_divergence.
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 explicit when-to-use guidance or routing to alternatives. 'Verify another AI answer' implies the context, but with ten ecca_* siblings an agent gets no signal on when this beats refine, research, or synthesize. 'Spends one solve' hints at a cost tradeoff but not a usage condition.
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.
ecca_claim_protocol_validateecca_bts_divergenceecca_decision_tournamentecca_learningecca_moneyecca_nutritionecca_pre_mortemecca_psychologyecca_refineecca_researchecca_synthesizeecca_verifyFind AI design tools, compare catalog records, and inspect stored evidence and limitations.
Document reasoning checks: a helicopter view of claims and assumptions before handoff.
Verify claims and sources, and check whether AI assistants name a brand.
Checks a claim at its primary source and grades it. A person reviews every answer.
Add one secure layer between your agents and this server.