ARBITER

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a paid model ($0.001 USDC on Base), but it does not describe ranking semantics, return format, determinism, side effects, or failure 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?

The description is relatively short and earns some of its space with cost and candidate-type context. However, it front-loads vague product branding ('Paid ARBITER semantic control-flow and arbitration') before the actionable information, and the closing price point repeats the 'Paid' emphasis from the opening.

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 four-parameter semantic ranking tool with no annotations, no output schema, and no schema descriptions, the definition is under-specified. It gives no parameter semantics, no return-value context, and no operational limits, leaving significant gaps an agent would need to call 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 description coverage is 0% for four parameters, so the description must compensate. It does not explain what 'query', 'top_k', or 'use_freq' mean or how they interact, and its list of candidate types does not clarify the candidate array contract beyond the fact that candidates are ranked.

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 (measure, rank) and a resource (candidate actions, transitions, tools, documents, etc.) against a query/current state. It is clear enough to distinguish a semantic ranking tool from a generic utility, but it never names or contrasts with the only sibling, arbiter_embed.

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-tool guidance. The description explains what the tool does with candidates and state/intent/perspective, but leaves the agent to infer when this tool is preferable to arbiter_embed.

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, the description carries the full burden. It does disclose two genuinely behavioral facts: the operation is paid ($0.001 USDC on Base) and deterministic, both of which affect agent planning. It omits auth/payment mechanics, error behavior, whether calls are batched or per-text, and what use_freq changes.

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 sentence, so it is not bloated, but it front-loads a list of marketing abstractions ('persistent machine memory, retrieval, indexing, and cross-system meaning') that restate one idea four ways. The operationally useful facts (72-dim, deterministic, paid) are buried inside that list.

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?

No annotations and no output schema, so the description must cover inputs, outputs, and behavior. It gives output dimensionality and cost but leaves the required texts parameter, the use_freq flag, return shape/ordering guarantees, and failure modes undocumented — insufficient for a 2-parameter tool with zero schema coverage.

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 says nothing about either parameter. The required 'texts' array and the optional 'use_freq' flag are completely unexplained — the agent cannot know what use_freq toggles or any input format constraints. The '72-dimensional' phrase describes output, not inputs.

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 artifact — a deterministic 72-dimensional embedding for memory/retrieval/indexing — so an agent knows what is produced. It does not, however, distinguish this from the sibling arbiter_compare, nor clarify what 'ARBITER' means operationally. Clear verb+resource, but no sibling differentiation.

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 this versus arbiter_compare, no prerequisites, no indication of batch size limits or when embedding is preferable to comparison. The only usage-adjacent statement is the price, which is a constraint but not a when-to-use rule.

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