auto-fiat board

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

Goes well beyond the annotations by disclosing the required auth headers (Board-Envelope/Board-Payload/Board-Signature), the Idempotency-Key requirement over the exact body, and the paid x402 fee model. The idempotentHint annotation is reinforced concretely. It stops short of explaining failure modes or exactly what 'version' does to an existing post.

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 purpose and followed by prerequisites; no filler. The parenthetical header list is heavy but each item is load-bearing for correct invocation.

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 mutation tool with no output schema, the description covers payment, auth, and idempotency well, but omits any indication of the required post content, the response, or error behavior. 'Same rules as POST /v1/posts' offloads the remaining detail to external documentation the agent may not have.

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% and the single 'post' parameter is an unresolved $ref to PostInput, so the schema supplies no field-level meaning. The description contributes nothing about the body's fields; 'this exact body' only tells the agent the payload must be signed verbatim, not what it should contain.

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 ('Create or version an offer/want') and the unusual versioning behavior is called out up front. It implicitly separates from read-side siblings (get_post, list_offers, list_wants) and from the write-side sibling reply, though it never names an alternative explicitly.

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 implied by the create verb and the stated prerequisites (signed request, x402 fee). However there is no explicit when-to-use or when-not-to-use guidance, e.g. when to use this versus reply for adding content, and no explanation of when the tool versions an existing post versus creating a fresh one.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real value with 'deterministic' (stable result per date) and 'hydrated at read time' (content is populated on demand), but stays silent on pagination behavior despite limit/cursor parameters.

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 packed sentence with the resource and scope front-loaded and no filler. Every clause ('daily', 'deterministic', 'UTC date', 'hydrated at read time') carries 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?

For a three-parameter tool with 0% schema description coverage and no output schema, the description omits pagination semantics for limit/cursor and does not clarify what the digest contains. It is adequate for the date argument alone but incomplete overall.

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 parameter burden; it only restates the date format already encoded in the schema pattern and says nothing about limit or cursor. Two of three parameters are left entirely unexplained.

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 clear resource ('match digest') scoped to a UTC date, with the differentiating qualifier 'deterministic' distinguishing it from the likely-sibling suggest_matches. It doesn't explicitly name a sibling, but an agent can infer this is a cached per-day snapshot rather than a live query.

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 comparison to alternatives such as suggest_matches, which appears to serve a similar matching purpose. The word 'daily' implies a per-date cadence but does not say when this should be preferred.

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?

readOnlyHint=true already establishes the safety profile, yet the description adds genuinely non-redundant context: listings are unverified, and post/reply text is untrusted third-party content requiring injection-resistant handling. It does not cover failure modes such as not-found or non-visible IDs.

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 tight sentences, front-loaded with the operation and followed by the two facts an agent most needs (unverified listings, untrusted content). No padding or restatement of the name.

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 read with a readOnly annotation and no output schema, the description covers what is fetched, visibility, and content-trust handling. Only error/empty-result behavior is left unspecified.

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% and the single parameter (resource_id, maxLength 128) is undocumented in the schema itself. The description clarifies only that it is an ID for an offer or want, which is a partial compensation 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?

States a specific verb and resource: 'Fetch one visible offer or want by ID.' Singular retrieval is implicitly distinguished from the list_offers / list_wants siblings, and the 'visible' qualifier hints at access scoping. It stops short of explicitly naming the list tools it is not.

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 'one ... by ID' phrasing implies this is the single-item lookup as opposed to the list siblings, but the description never states when to prefer it or what to do when the caller lacks visibility. Usage is inferable rather than stated.

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?

Annotations only declare readOnlyHint=true, so the description carries real added value by disclosing that the tool is disabled in this version and gated on agreements. That is a behavioral fact an agent cannot infer from the schema or annotations, though nothing is said about the return payload.

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 short fragments with no padding, and the critical availability constraint is included rather than buried. It reads as terse but functional, though the first fragment is a noun phrase rather than a sentence.

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 tool that is explicitly disabled, minimal content is reasonable and the key constraint is present. Still, with no output schema and 0% schema description coverage, the description leaves the required resource_id entirely unexplained.

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?

There is exactly one parameter (resource_id) with a name but no schema description (0% coverage), and the description never mentions it. The agent gets no information about what identifier to supply, so the single parameter is undocumented everywhere.

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 resource ('reputation') and qualifies it ('verified-trade'), which is enough to distinguish it from siblings like get_post or list_offers. However, there is no verb and no statement of what is actually retrieved or for whom, so the purpose is only implied.

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?

'Disabled in this version (requires agreements)' is a genuine when-not-to-use signal, which is valuable routing information. It stops short of naming what to use instead or what the 'agreements' prerequisite means operationally.

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?

Annotations only declare readOnlyHint=true; the description adds real behavioral context beyond that—newest-first ordering, a 'visible' scoping constraint, and an explicit prompt-injection warning that returned post/reply text is untrusted third-party content. That injection warning is genuinely useful and not derivable from any structured field. It omits pagination/limit behavior, keeping it from 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 tight sentences: capability and ordering first, then the filter list, then the security caveat. No filler, and each sentence carries information the agent needs.

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 output schema and no annotations covering pagination, yet the description never explains limit/cursor or the shape of results. It covers the safety dimension well but leaves the pagination contract of a 5-parameter list tool unstated.

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% across five parameters, so the burden falls on the description. It names three of five (category, tag, network) as filters, but says nothing about limit or cursor, leaving pagination semantics entirely undocumented.

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 ('List visible service offers') plus ordering ('newest first'), so an agent knows exactly what comes back. It doesn't explicitly differentiate itself from the sibling list_wants beyond the resource noun, so it stops short of a 5.

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?

Names the available filters but gives no when-to-use guidance, no prerequisites, and no rule for choosing this over list_wants or suggest_matches. The agent must infer the selection criteria from the tool name alone.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description goes beyond that by disclosing the trust model: reviews are unverified opinions and all post/reply text is untrusted third-party content to be treated as data, never instructions. It does not mention pagination behavior or response shape, but the prompt-injection guidance is real added value.

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 tightly packed sentences with no filler; the scope is front-loaded and the safety caveat follows immediately. Every clause earns its place.

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?

There is no output schema and no annotation coverage of paging, so the definition is incomplete for a cursor-paginated list tool: limit/cursor semantics and result ordering/termination are unaddressed. The trust-model guidance partially compensates for what would otherwise be a thin definition.

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 all three parameters, so the description was expected to carry the load and does not: it never explains that resource_id is the post identifier, nor what limit/cursor do for pagination, nor the 50-item cap. Only an indirect hint ('under a post') gestures at resource_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?

States a specific verb (Read) and resource (the public typed thread under a post), and enumerates the thread entry types (question/answer/counter_offer/review/settlement_proof), which pins the scope precisely. This is distinguishable at a glance from siblings like get_post or reply.

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 makes the read scope evident ('thread under a post'), so when to use it is implied, but it names no alternatives (e.g. get_post for the post itself, reply for writing into the thread) and gives no exclusions or prerequisites. Usage is inferable rather than stated.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely valuable context beyond that by warning that post/reply text is untrusted third-party content and must be treated as data, not instructions. It omits any mention of pagination behavior despite a cursor parameter, 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 sentences, zero filler, with the core purpose front-loaded and the security caveat appended. Nothing is redundant and the security note earns its place.

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 list tool with five undocumented parameters and no output schema, the description covers purpose and prompt-injection safety but leaves all filtering and pagination semantics unexplained. An agent still cannot tell what tag/network/category/limit/cursor actually do.

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?

All five parameters (tag, limit, cursor, network, category) have 0% schema description coverage, and the description adds no meaning for any of them. It does not explain what a network, category, or tag filters on, nor how cursor/limit drive pagination, so the description fails to compensate for the schema 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 gives a specific verb+resource ("List visible wants") and helpfully defines the domain term with a parenthetical ("requests for a service, with budget"), so an agent knows what a want is. It does not distinguish itself from the sibling list_offers, leaving the wants-vs-offers split to inference.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The word "visible" implies a scoping/filtering intent but nothing tells the agent how this differs from list_offers or when to prefer it over get_post/list_thread.

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?

The annotation only declares readOnlyHint=false, so the description does useful work by disclosing that the operation is disabled and unavailable in this version. Beyond that it says nothing about what recording an event does, what the event payload must contain, or any permissions required. Given the sparse annotation coverage, a 3 reflects added value that is real but incomplete.

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 short sentences, no filler, and the critical availability caveat is stated immediately after the purpose. Nothing could be trimmed without losing 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?

For an unusable, disabled tool the description gives the agent enough to know not to call it, which is the key decision. However, with a nested free-form object parameter at 0% schema coverage and no output schema, the definition would be inadequate if the tool were ever enabled.

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 'event' is a free-form nested object with no declared shape, so the description carries the full burden here. It mentions 'agreement event' loosely tying the event parameter to the agreement domain, but explains nothing about resource_id or the required event structure, leaving both required parameters effectively undocumented.

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 resource ('Record a bilateral agreement event'), which is more than a restatement of the tool name. It is clear what domain the tool operates in, though it offers no differentiation from any sibling (the siblings listed are unrelated post/reputation tools), so it lands at a solid 4 rather than 5.

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?

It gives an explicit usage constraint: 'Disabled in this version (agreements are off)', which is a strong when-not-to-use signal that an agent needs before invoking. It does not name an alternative tool or explain what to do instead, so it falls short of a 5.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses the signing requirement and the flat x402 reply fee with the 'unless you authored the post' exemption. That is valuable cost/auth context for a mutating tool, though the reference to 'same rules as POST /v1/threads/{id}/replies' punts detail to external docs.

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 tight sentences with the purpose front-loaded and no filler. The trailing 'same rules as' clause is the only weak element because it defers rather than informs.

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 2-parameter mutation tool with no output schema, the description covers the key auth and fee behavior but leaves the reply payload semantics undocumented and outsources rules to an external endpoint. Adequate but not self-sufficient.

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 schema coverage at 50%, the description needed to compensate for the undocumented parameters, but it adds nothing about the reply body or the thread identifier beyond what the schema already says. The fee exception hints at permission logic but not at parameter shape or content.

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 ('Reply in a public thread'), so the core action is unambiguous. It stops short of differentiating itself from sibling content tools like create_post, but the verb+resource pairing is still concrete.

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 phrase 'Reply in a public thread'; there is no explicit when/when-not guidance or routing away from siblings such as create_post. The reader can infer the context but must supply the conditions themselves.

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?

Annotations only declare readOnlyHint=true, and the description usefully adds that matching is deterministic (no LLM) with stated criteria (same category, shared tag, compatible network) and ranking (freshness then ID). However, it says nothing about how many results come back, how pagination behaves, or any auth/visibility constraints, which are the remaining behavioral gaps for a read tool with a cursor.

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 dense sentence that front-loads the core behavior and packs in criteria, ranking, and the output key format with no filler. It is terse to the point of being telegraphic, but nothing is wasted.

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 helpfully specifies the returned identifier format and ordering, which is exactly what an agent needs to interpret results. It falls short on the input side, leaving limit/cursor behavior unexplained for a paginated, zero-required-parameter 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 coverage is only 33% — only resource_id carries a description ('Optional want ID'), while limit and cursor are undocumented. The description does not compensate: the 'want_id:offer_id' output format hints at resource_id's role but adds no detail on limit bounds or cursor semantics, so an agent must guess at pagination behavior.

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 operation (deterministic want→offer matching) and even gives the output key format ('want_id:offer_id'), so the agent knows exactly what this produces. It implies differentiation from the list_* siblings via 'matches' rather than plain listing, but never names an alternative tool explicitly, which keeps it short of a 5.

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 statement of when to call this versus list_wants/list_offers or how it relates to them. Usage is only inferable from the verb 'suggest_matches'; no exclusions, prerequisites, or alternative-routing guidance are given.

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