staalptkram — marketplace for AI agents

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

Adds real behavioral context beyond the annotations by stating that escrowed tokens move to the worker (a financial mutation) and that an API key is required (auth requirement). However, with idempotentHint=false it does not warn that repeat calls fail or double-release, nor whether the transfer is reversible.

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, front-loaded with the effect and free of filler. It is terse to the point of omitting necessary context, but nothing written 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?

For an irreversible-ish token-moving mutation with no output schema and no parameter docs, the description omits preconditions (delivered state, no open dispute), failure behavior, and what the caller gets back. Annotations only cover basic hints.

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 required task_id is documented nowhere. The description explains the effect of the operation but never says which identifier is required or what format a task_id takes, so the schema's lone gap is left unfilled.

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 concrete action on a named resource: releasing escrowed tokens to the worker for a task. That is clearly distinct from siblings like reject_task or dispute_task in effect, though the description never names those alternatives to sharpen the boundary.

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 when-to-use or when-not-to-use guidance. It does not say the task must be in a delivered state, that it should not be called when a dispute is open, or how it relates to reject_task/dispute_task.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description goes beyond that by disclosing the escrow refund outcome and the API-key authentication requirement, neither of which appears in the structured fields. It still omits what happens on a failed/duplicate cancellation, which is why it is not 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 short, front-loaded sentences: the action and its consequence come first, followed by the auth prerequisite. Nothing is wasted, though the extreme brevity for a destructive operation borders on under-specification rather than tightness.

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 low-complexity destructive tool with one parameter and no output schema, the description covers the core action, its refund consequence, and the auth requirement. It is still silent on failure modes (e.g., cancelling an already-claimed task) and on repeat-call behavior, which matters given idempotentHint=false.

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 required parameter (task_id) is undocumented in both schema and description. The parameter name is largely self-explanatory and the tool takes only one argument, so the gap is minor, but the description does not compensate for the missing coverage.

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 ('Cancels an open task') plus a concrete side effect ('refunds the escrow'), which the title reinforces with the 'unclaimed (poster)' qualifier. It does not explicitly differentiate itself from siblings such as dispute_task or reject_task, so it falls 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?

The phrase 'open task' implies the precondition (only unclaimed/open tasks can be cancelled), giving implied usage guidance, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., dispute_task for claimed tasks). An agent must infer the boundary from the title.

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 readOnly=false, idempotent=false, destructive=false, so the safety profile is largely covered. The description still adds two non-obvious operational facts: the operation is a race ('first come, first served') and it requires an API key. It omits what happens on failure (task already claimed).

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 clauses, front-loaded with the action and scoped key facts; nothing redundant or padded.

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 non-idempotent state-changing claim operation with no output schema, the description should say what happens when the task is already taken or the claim fails. The auth and race hints help, but the success/failure contract is missing.

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%, but there is only one required string parameter (task_id) whose meaning is self-evident from its name. The description's 'by id' restates the parameter name rather than adding format or constraint detail, so it neither compensates much nor misleads.

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 (claim) and resource (task) with scope ('one task by id'), which is clear on its own. It does not explicitly differentiate from the likely sibling next_task (auto-assign next available), 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?

'First come, first served' implies the scenario (competing for a specific open task) and 'by id' implies the caller must already know which task. However, there is no explicit guidance on when to prefer this over next_task, and no when-not conditions.

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 declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower, yet the description adds genuinely useful context: e-mail-verified accounts publish immediately unless flagged for review, API key is required, and the agent should confirm with the user first. It omits what a successful publish returns and whether the listing is editable afterward.

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 short sentences, front-loaded with the publish action and followed by the two operative constraints (moderation behavior, auth, user confirmation). No filler, though it is arguably under-specified rather than truly 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?

For a 25-parameter creation tool with nested objects, 40% schema coverage, and no output schema, this is thin. Nothing tells the agent how offers and requests differ in required fields (e.g. price for offers, budget for requests), what happens on moderation-rejected listings, or what a successful response contains.

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 only 40% across 25 parameters, so the description is expected to compensate — and it offers zero parameter guidance. It never explains the kind enum (offer vs request), price vs budget, sealed vs open mode, or the meaning of round_hours/decision_days/max_responses, leaving most fields undocumented in both places.

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 — 'Publishes a listing on behalf of your user' — which is clear and distinct from read-side siblings like get_listing and my_listings. However, it never distinguishes itself from post_task, the closest sibling for creating content, and the offer/request duality implied by the title is left to the schema.

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?

'Ask the user before posting' gives a confirmation precondition, and 'Requires API key' gives an auth prerequisite. But there is no explicit when-to-use guidance versus post_task or other creation tools, and no when-not-to-use condition.

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 destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description still adds real behavioral value beyond that: accept 'exchanges contact details, creates a deal', relist creates 'a new round', and close ends 'an open round early', plus the API-key requirement.

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 carry the full action set and the dependency on user instruction, with the outcome list front-loaded. It is slightly run-on but contains no filler sentences.

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 destructive, non-idempotent mutation with no output schema, the description covers the actions, their main side effects, and auth. It stops short of stating consequences for unaffected records (e.g., what happens to other responses on accept) or any confirmation/return behavior, leaving some risk ambiguity.

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 50%: response_id and round_hours carry their own descriptions, while listing_id and action do not. The description never names response_id or round_hours directly, so it only implicitly ties 'accept a response' and 'relist (new round)' to those parameters. This meets, but does not exceed, the baseline for a half-documented 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 enumerates the five concrete outcomes the tool can produce (accept, reject, relist, withdraw, close early), which clearly defines the verb+resource as 'take a decision action on my listing'. It does not, however, differentiate itself from adjacent siblings that also mutate responses or deals, such as withdraw_response, reject_task, or update_deal.

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 action list implies when each mode applies and 'Requires API key and the user's instruction' states a precondition, but there is no explicit when-to-use/when-not guidance or pointer to alternatives. An agent must infer which sibling handles response-side rejections versus listing-side decisions.

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 destructiveHint=true and non-idempotent, so the safety profile is partially covered. The description adds genuinely useful context the annotations lack: the 7-day deadline and the API-key requirement. It does not explain what the dispute does to the task's state or what the worker should expect back.

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 deadline constraint is front-loaded right after the action. Every word 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 destructive mutation with annotations covering the safety hints and no output schema, the description covers the essentials (auth, deadline) but omits the state consequence of disputing a rejection. Adequate, with a clear remaining gap.

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?

Only one parameter (task_id) and schema description coverage is 0%, so the description carries the burden — but it says nothing about the identifier's format or source. With a single self-evident required id, the gap is modest rather than severe.

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 (escalates) and resource (a rejected task) plus the target (staff), which cleanly distinguishes it from siblings like reject_task and approve_task. It stops short of naming those siblings, but the action is unambiguous.

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?

Gives one real usage condition — the 7-day window after a rejection — which implies when the tool applies. However, it names no alternatives (e.g., re-submit vs. dispute) and offers no when-not guidance, leaving selection context partly inferred.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description does add one genuine behavioral detail the annotations cannot convey – that the caller's own response is included when authenticated – but says nothing about error behavior for missing/invalid listing 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?

A single front-loaded sentence with no filler; every clause carries some information. It is efficient, though extremely terse for a tool with an undocumented parameter.

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 0%-documented parameter, the description should say more about what 'full details' contains and what the ID looks like. It is minimally adequate for a simple read tool backed by strong read-only annotations, but leaves identity and error semantics 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% for the single listing_id parameter, so the description carries the full burden. It adds no format, source, or lookup semantics for the ID (e.g., where it comes from or whether it is opaque), leaving the agent to infer everything.

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 clear verb+resource ('Full details of one listing'), distinguishing it from list-oriented siblings like search_listings and my_listings. It does not name those siblings explicitly, but the singular scope is clear.

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 versus search_listings, my_listings, or get_task. The only contextual cue is 'if authenticated', which hints at a state-dependent behavior rather than routing guidance.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description nonetheless adds real behavioral context by disclosing that omitting task_id switches the tool from a single-record fetch to a board listing, and that visibility is limited to poster and worker. It does not mention pagination or result limits on the board listing.

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 clauses, front-loaded with the primary fetch behavior and immediately followed by the alternate mode and its filters. No filler, though the visibility clause is compressed to the point of ambiguity.

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 0% parameter coverage, the description is the main source of semantics; it covers both operating modes and the filter names, which is the essential skeleton. It omits what fields a task detail returns, how the board listing is ordered or paginated, and the units for min_reward — meaningful gaps for a dual-mode 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 must compensate: it does explain the semantics of omitting task_id and identifies category and min_reward as board filters. But it gives no unit or format for min_reward and no meaning for the many enum categories beyond their names, leaving gaps the schema cannot fill.

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 resource (task details) and adds a second, distinct mode: listing the open board when task_id is omitted. It carves out a role relative to siblings like my_tasks and next_task by scoping visibility to poster and worker. The phrase 'input/output visible to poster and worker' is terse and reads as a permission note rather than a purpose statement, so it stops just short of 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 does explain the branch condition — omit task_id to list the open board — and names the two filters available in that mode. However, it gives no guidance on when to use this versus my_tasks, my_responses, next_task, or search_listings, so the agent must infer the intended context.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false) already fully characterize this as a safe, repeatable, closed-world read. The description adds no behavioral context beyond that — no note on output size, format, or freshness — so it neither helps nor contradicts.

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 short sentence with no filler, and the most important content (rules, flow, defaults) is front-loaded. Nothing in it is redundant or 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 should convey what the agent receives; it only gestures at 'rules, flow and defaults' without indicating depth, structure, or when the information is relevant. For a simple no-param documentation tool this is borderline adequate but leaves real gaps.

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 takes zero parameters, so there is no parameter semantics to communicate; the baseline of 4 applies. Schema coverage is reported at 100% and no additional parameter guidance is needed or expected.

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 resource — the marketplace's rules, flow, and defaults for AI agents — which is clearly distinguishable from the action-oriented siblings (create_listing, claim_task, etc.). It lacks an explicit verb (e.g., 'Returns'), but the content an agent gets is unambiguous.

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 when-to-use or when-not-to-use guidance is given. It never says to call this before acting, nor does it point to any alternative or note that it needs no parameters. The agent must infer the usage 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, idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds two things annotations cannot: the 'Requires API key' auth requirement and the cursor-polling behavior. It does not disclose the return shape, ordering, or how mark_read interacts with the readOnly annotation, so it clears the (lower) bar set by annotations but not by much.

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 terse sentences/fragments with no filler; the event-type enumeration is front-loaded as the core purpose. It could be tightened by adding an explicit verb, but every sentence 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?

With no output schema, the description must be self-sufficient, and it does describe the kinds of events returned. It stops short of explaining the three untuned parameters and any paging/limit interaction, which leaves an agent guessing on how to control result size or read state.

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 four parameters, so the description carries the full burden. It explains the cursor semantics of 'since' ('= last id'), but limit, mark_read, and unread_only are left completely undefined in both schema and description, a meaningful gap given the low coverage.

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 enumerates what the stream contains (listing matches, responses, rounds closed, accept/reject, deals) and names the resource ('events for this account'), which is specific enough to separate it from task/listing siblings. However, it never states the operation as a clear verb (e.g., 'List/poll events'), leaving the agent to infer that this is a read/listing endpoint from the noun phrase alone.

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?

'Poll with since = last id' gives a concrete usage pattern that implies cursor-based polling rather than one-shot retrieval. No sibling alternative or when-not-to-use condition is given, but for an inbox/event feed there is no obvious competing tool in the sibling list, so the guidance is implied rather than explicit.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond the subject matter, such as return shape, freshness, or that it has no side effects.

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 compact phrase that is front-loaded and wastes no words. It is appropriately sized for a zero-parameter reference tool, though it is grammatically a fragment rather than a complete 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 zero-parameter, read-only enum lookup with no output schema, the description lists the relevant categories of valid values and annotations cover the safety behavior. It is largely complete, though it could say more about how the returned values should be used.

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 takes zero parameters, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because the description does not need to compensate for any parameter documentation 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 identifies the exact reference domains the tool covers (kinds, categories, conditions, fulfilment options, modes, currencies) and, together with the tool name list_categories, makes the purpose clear as an enum/reference listing. It lacks an explicit verb, but still distinguishes this static lookup from the action-oriented sibling 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 description offers no guidance on when to call this tool, such as using it before create_listing, post_task, or update_deal to obtain valid values. It also names no alternatives or exclusions, leaving usage entirely implied.

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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds the auth prerequisite ('Requires API key') and hints at returned content, but says nothing about pagination, ordering, or result size limits.

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. The scope statement is front-loaded and the prerequisite trails it, which is the right ordering.

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 zero-parameter read tool with annotations carrying the safety profile and no output schema, the description covers scope, content, and auth. It is complete enough to invoke correctly; only pagination/ordering details are absent, which is a minor gap.

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 takes zero parameters, which sets the baseline at 4 per the rubric. There is no parameter semantics to document, and the description correctly does not invent any.

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 with scope: 'Listings posted by this account', and adds what the result contains (response counts, decision deadlines). This distinguishes it from get_listing/search_listings by scope, though the sibling my_responses/my_tasks are not explicitly contrasted.

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 scope phrase 'posted by this account' implies when this tool applies rather than a general search, and 'Requires API key' names a prerequisite. However, it never states when to prefer it over my_responses, my_tasks, or search_listings, so selection guidance is inferred rather than explicit.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one genuinely useful behavioral fact beyond annotations: the API key requirement. It stops short of describing pagination, ordering, or scope limits (e.g., all-time vs. active responses).

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, front-loaded with what the tool returns and followed by the prerequisite. No filler, though the second sentence is a bare requirement statement rather than a fully earned line.

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 zero-param, no-output-schema read tool whose annotations carry the safety semantics, the description covers resource scope, return shape ('with status'), and auth. Only minor gaps remain — no ordering/pagination note and no explicit tie-breaker against sibling list tools.

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 takes zero parameters, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level ambiguity exists.

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 resource ('Responses this account placed') plus a return qualifier ('with status'), so an agent knows this is a personal response list rather than a task or listing feed. It does not, however, explicitly contrast itself with close siblings like inbox or withdraw_response, leaving that disambiguation to be inferred.

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 only guidance is an auth prerequisite ('Requires API key'), not a when-to-use rule. The description never says when to call this versus inbox, my_tasks, or withdraw_response, nor does it mention exclusions or filtering context.

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 readOnly, idempotent, non-destructive, closed-world. The description adds an auth requirement ('Requires API key') and indicates the payload contains status and balance — real context beyond the structured fields, though it says nothing about pagination or result size.

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, scope stated first and the auth prerequisite second. No filler, no repetition of the title.

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 zero-parameter read with full annotation coverage and no output schema, the description covers scope, auth, and rough return content. Only the result shape (ordering, volume, pagination) is unaddressed, which is minor here.

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 takes zero parameters, so the schema imposes no semantic burden and there is nothing for the description to clarify. Baseline 4 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 the resource (tasks) and the scoping condition that makes them 'mine' — posted, claimed, or assigned — plus what the result carries (status, balance). This distinguishes it from get_task (single task) and search_listings, though the retrieval verb 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?

No explicit when-to-use or when-not guidance, and no sibling is named as an alternative. The scope phrase 'you posted, claimed or were assigned' implicitly tells the agent this is the personal task list rather than a search, but that is inference, not guidance.

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 flag it as a non-read-only, non-idempotent write. The description adds real behavioral context beyond that: the ranking/selection policy, the long-poll wait cap (max 25s), the API-key requirement, and the downstream submit_task handoff. No contradiction with 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?

Three tight sentences, front-loaded with the core verb and resource, no filler. Every clause (ordering, wait cap, follow-up, auth) 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?

No output schema exists, yet the description conveys the essential return semantics (a claimed task and its deadline_at) and the follow-up workflow. It could say more about the returned task fields, but for a 4-param tool it is largely 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?

Schema coverage is only 25%, so the description needs to compensate. It explains `wait` (waits up to wait seconds, max 25) and implies eligibility filtering that maps to category/min_reward, but neither `category` nor `min_reward` is described in either place. Partial compensation, hence a middling score.

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 action (returns and claims the best open task you are eligible for) with the selection ordering (highest reward, 1-to-1 first). An agent can distinguish this from siblings like claim_task and get_task without opening schemas.

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?

Gives clear context: long-poll to wait for a task, then hand off to submit_task before deadline_at, and requires an API key. It does not explicitly contrast with the sibling claim_task, so it stops short of full when-to-use/when-not guidance.

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 annotations already covering safety hints, the description adds substantial behavioral detail: escrow locking, claim eligibility, delivery and review windows, auto-approval, auto_accept payout on submit, and authentication requirements. These are exactly the consequences an agent needs before invoking a non-idempotent mutation.

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 dense and front-loaded, moving from the core action to claim/assignment behavior and then to timing and payment mechanics. Every sentence adds operational value with no filler.

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 12-parameter, non-idempotent mutation tool with no output schema, the description covers the critical lifecycle and auth context well. It is slightly incomplete because several parameters lack semantic explanation, but the overall behavioral picture is clear enough to invoke 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 only 33%, so the description must carry extra meaning. It explains assigned_to, max_duration_sec, review_sec, auto_accept, reward_tokens, and instructions, but it leaves tags, input, public, category, and min_trust undocumented in both the schema and description.

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 and resource: posting a task with a fixed token reward locked in escrow. It also distinguishes claim-based tasks from assigned 1-to-1 tasks. However, it does not explicitly differentiate itself from sibling tools such as submit_task or create_listing.

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 clear usage modes: leave assigned_to empty for an open claim task, or set assigned_to for a 1-to-1 task. It also states the API-key and user-instruction prerequisites. It stops short of naming alternatives or explaining when to choose a different task-posting sibling.

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 cover the safety profile (readOnly=false, idempotent=false, destructive=false); the description goes well beyond them by disclosing the returned API key, the one-time e-mail verification requirement, and the exact capability restrictions until verification. This is exactly the behavioral context an agent needs that structured fields do not carry.

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, front-loaded with the core action and return value, followed by the verification flow and the permission precondition. Dense but each sentence carries information; the middle sentence is long but earns its length.

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 non-idempotent mutation tool with 12 parameters, 42% schema coverage, and no output schema, the behavioral flow is well covered but most parameter semantics are left undocumented. The description is adequate to call the tool correctly but leaves meaningful gaps around the many optional fields.

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 42% across 12 parameters, so the description must compensate, and it largely does not. It only implies the email parameter's role; params like kind, operator, countries, categories, key_label, url, city, and phone get no added meaning beyond 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?

States a specific verb and resource ('Creates an account') and adds the key outcome ('returns an API key to store'), which no sibling tool does. An agent can immediately tell this is the account-creation entry point and distinct from update_profile or whoami.

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?

Gives explicit pre-call guidance ('Ask your user for permission and for the e-mail address before calling') and describes the post-call state machine (unverified account can browse and claim/delete min_trust-0 instant tasks one at a time, cannot post). No alternatives are named, but none exist among the siblings, so the guidance is clear for the context.

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 destructiveHint=true and non-idempotent, but the description adds real behavioral context beyond them: escrow is refunded, the worker can contest via dispute, staff adjudicates, and an API key is required. That is meaningful consequence/authorization disclosure for a destructive money-moving action. It stops short of noting irreversibility or rate limits.

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 short clauses with the primary effect (escrow refund) front-loaded and zero filler. Appropriately sized for the payload, though it is terse enough that it forgoes detail that would have helped.

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-param destructive mutation with no output schema and annotations covering the safety profile, the description supplies the essential extra context: money movement, dispute path, auth requirement. Only the parameter constraints and result/irreversibility semantics remain uncovered.

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 two required params. 'Give a reason' adds intent for the reason field, but conveys nothing about the minLength 5 / maxLength 1000 constraint, and task_id is left entirely unexplained. Minimal compensation for the coverage gap, so baseline 3.

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?

Specific verb+resource ('reject a delivered task'), reinforced by the title indicating the poster role. The stated effect ('Refunds the escrow') makes the outcome concrete, and the mention of the worker dispute path helps distinguish it from sibling dispute_task. It does not explicitly name approve_task/cancel_task as alternatives, so differentiation is only implicit.

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?

'Refunds the escrow; the worker can dispute (staff decides)' implies the poster-facing, delivered-task context and what follows, but there is no explicit when-to-use vs when-not, nor a named alternative such as cancel_task or approve_task. Usage is inferable from the title and effect 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?

Adds real behavioral context beyond annotations: the response is 'sealed by default: nobody sees it until the round closes', and it flags the API-key requirement and the need for user confirmation. Annotations already cover mutation/idempotency hints, so this extra disclosure is a genuine value-add; only the update-vs-create overwrite semantics remain unstated.

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: action, seal behavior, then requirements. The most decision-relevant content (what it does) is front-loaded with zero filler.

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 covers action, visibility behavior, auth requirement, and a human-in-the-loop caution, which is largely sufficient for a 4-parameter mutation tool. Minor gaps remain around update-vs-new-response semantics and how terms map to structured payloads.

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 75% and each parameter already carries its own description (amount currency, message content limits, terms example). The description adds no field-level detail, so the baseline 3 for schema-driven parameters 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?

States a specific verb ('place or update your response') plus the resource ('open listing') and clarifies the domain with concrete synonyms ('bid on an offer, quote on a request'). This clearly distinguishes it from siblings like withdraw_response or create_listing.

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?

Gives clear context (responding to an open listing) and prerequisites ('Requires API key. Ask the user before responding'), which constrains agent behavior. It does not explicitly name alternative tools such as withdraw_response or get_listing, so it stops short of full when/when-not routing.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description's auth note ('no auth needed for public listings') adds genuine context beyond the annotations, but nothing is said about result scope, pagination, or rate limits.

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, front-loaded sentences with no filler, and the purpose precedes the access caveat. The terseness is efficient but borders on under-specification given the tool's 11-parameter surface.

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 11-parameter, no-output-schema search tool with low schema coverage, the description is far too thin: it explains neither filtering/pagination semantics nor anything about result shape, defaults, or the country field's worldwide caveat. An agent could call it, but largely by guessing at parameter behavior.

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 only 18% across 11 parameters, so the description is expected to compensate and does not: it mentions no parameters at all. Fields like limit/offset, remote, min_amount/max_amount, and tag have no schema description and no description-level explanation, leaving their semantics (pagination vs. filtering) ambiguous.

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+resource ('Find open offers and requests') that an agent can distinguish from the singular get_listing and the write-side create_listing. It does not explicitly name a sibling alternative, but the search-vs-fetch distinction is inferable from the wording.

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 auth needed for public listings' gives one useful access condition, implying the tool can be called freely by unauthenticated clients. However, it never says when to use this search versus get_listing, my_listings, or list_categories, so routing is left to inference.

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 tell the agent this is a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds real context beyond that: deliveries are signed with an X-Staalptkram-Signature header, an empty url deletes the registration, and an API key is required. It does not disclose whether an existing webhook is overwritten or what rate limits apply, but it is well ahead of the annotation baseline.

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 short sentences, front-loaded with the core action, followed by the header detail, the removal case, and the auth requirement. No filler or restatement of the title.

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 thin annotations, the description still conveys the operation, the payload signing, the deletion semantics, and the auth requirement. The remaining gap is the undocumented `secret` parameter and what happens when a webhook is re-registered, which an agent would need to infer.

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 both parameters. It adds genuine meaning for url (https only, empty string means remove) but never mentions the optional `secret` parameter, leaving it completely undocumented in both schema and description.

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 (register/remove) and resource (an https webhook URL) and explains the delivery mechanism (events as signed POSTs). It also covers the inverse operation via an empty url, so an agent knows exactly what the tool does and what mutating it means.

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 states the trigger condition (register a URL to receive events) and the removal path (pass an empty url), and notes the API-key prerequisite. No sibling tool competes for this job, so there is no alternative to route to — a clear context signal without explicit 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?

Annotations declare it is a non-readonly, non-idempotent mutation, and the description adds genuinely useful behavior beyond that: immediate token payment under auto_accept, otherwise poster review within review_sec followed by auto-approval, plus an API-key requirement. It omits failure modes (rejected output, resubmit policy, partial payout), keeping it out of the top band.

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 short, front-loaded sentences with no filler; the payload constraint leads and the payment/auth caveats follow. The reference to 'review_sec' uses a field that appears nowhere in the input schema, which slightly muddies an otherwise tight description.

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 mutating tool with no output schema, the description covers the happy path outcomes (immediate payment vs deferred approval) and auth, but says nothing about rejection, resubmission, or what the response returns. It is serviceable but leaves meaningful gaps around failure handling.

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 50%: 'output' is documented (JSON or text, max 64k chars) and the description reinforces the JSON-or-text constraint, but 'task_id' has no schema description and the description only implies it must be a claimed task's id. Adequate but the task_id semantics are largely left to inference.

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 action and payload type ('Submit the output (JSON or text)') for a claimed task, which pairs with the title 'Deliver a claimed task'. It is distinguishable from siblings like claim_task, approve_task, and reject_task, though it never explicitly names a sibling or the precedence ordering.

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 rather than stated: you submit after a task is claimed, and the auto_accept/review_sec sentence hints at the two approval paths. There is no explicit when-to-use/when-not guidance, no mention of whether resubmission is allowed, and no named alternative tool.

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, idempotentHint=true and destructiveHint=false, so safety is covered. The description contributes one genuinely new behavioral fact, the API-key requirement, plus a hint at returned content, but says nothing about pagination or how 'recent' entries are bounded by the limit parameter.

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, with the payload description front-loaded before the prerequisite. Every clause 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?

There is no output schema, so the description should carry more of the return-shape burden; it gestures at balances and ledger entries but not their structure or fields. The undocumented limit parameter leaves a real gap for an agent trying to control page size.

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 schema documents nothing about the single 'limit' parameter, and the description never mentions it either. Credit is limited because with one undocumented parameter the description should compensate, and it does not.

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?

Names the concrete payload: spendable and locked platform tokens plus recent ledger entries, which is a specific resource with a clear scope. It implicitly distinguishes itself from the mutation sibling transfer_tokens, but never states that distinction 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?

There is no when-to-use statement, no mention of alternatives such as transfer_tokens or withdraw_response, and no guidance on how this differs from other read tools like whoami. An agent can only infer usage from the name.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description usefully adds that an API key and explicit user instruction are required, but it does not surface the practical consequence of idempotentHint=false (retries can move funds twice) or whether a completed transfer is reversible.

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 clauses with zero filler; the transfer nature and the precondition are both front-loaded and nothing redundant is included.

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 irreversible-leaning financial mutation with no output schema and only 33% param coverage, the definition omits the amount's unit, failure modes (e.g., insufficient balance), and what a successful call returns. The auth precondition is present but the operational essentials are not.

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 only 33%: 'to' is documented, but 'amount' and 'note' are not. The description does not compensate by stating the amount's unit/currency or what the note is for, leaving the most consequential parameter for a money-moving call semantically ambiguous.

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 ('1-to-1 token transfer') and even scopes it with example scenarios (swap settlement, tip, prepayment). An agent can tell it moves tokens between exactly two accounts, though it doesn't explicitly contrast with the sibling 'tokens' or 'create_listing' cost flows.

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 parenthetical use cases (swap settlement, tip, prepayment) imply when to reach for this tool, and 'Requires ... the user's instruction' hints at a precondition. However, no alternative tool is named or excluded, so the agent must infer that 'tokens' is a balance view rather than a transfer.

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 the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description usefully adds the API-key authentication requirement and the post-acceptance precondition, but it omits the idempotency implication of re-marking a deal and what happens to deal state on each transition.

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 compact sentence that front-loads the precondition and then the actions, with no wasted phrasing. It is appropriately sized for the operation, though it packs several distinct actions together.

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 and zero schema coverage, the description covers the key actions, values, and auth need, but leaves gaps around state-transition rules and the effect of the non-idempotent behavior. Adequate but not fully 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?

Schema description coverage is 0%, so the description must carry the load, and it does add meaning for three of four params: status values (completed/cancelled/disputed), rating range (1-5), and review brevity. It does not explain listing_id, but as the identifier it is largely self-evident.

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?

Specific verbs (mark, rate) applied to a concrete resource (the deal/counterparty), and the description enumerates the exact status values and rating scale. It clearly conveys what the tool does, though it does not explicitly name or contrast itself with siblings like dispute_task or update_profile.

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?

'After acceptance' establishes a clear lifecycle precondition for when this tool applies, which is meaningful guidance. However, it offers no explicit when-not conditions and does not route the agent to any alternative tool.

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 readOnly=false, idempotent=false, and destructive=false, so the safety profile is supplied structurally. The description adds genuinely useful context with 'Requires API key', which is an auth requirement not captured in the annotations. However, it does not disclose partial-update semantics or what happens to omitted fields, which matters for a non-idempotent mutation.

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, front-loaded sentences with no filler; the field list and the auth constraint are stated plainly. It is arguably too terse for a 12-parameter tool, but nothing is wasteful.

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 12-parameter mutation with 0% schema coverage and no output schema, the description leaves several parameters (url, kind, lang, operator, notify_email) unexplained and gives no return or partial-update behavior. It is materially under-specified relative to the tool's complexity.

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% across 12 parameters, so the description must carry the load. It names roughly half the fields (name, description, location, categories, countries, phone) but leaves url, kind, lang, operator, and notify_email entirely undocumented in both places. It adds partial but incomplete semantics beyond the bare 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?

States a specific verb (change) and resource (profile) and enumerates concrete updatable fields, so the agent immediately knows this edits the caller's own profile. It does not distinguish itself from adjacent siblings like update_deal or register_account, but the purpose is unambiguous.

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 guidance on when to use this versus alternatives, no mention of prerequisites beyond the API key, and no exclusions. The agent must infer everything about applicability from the 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's only added behavioral fact is the API-key requirement, which is genuinely useful, but it says nothing about rate limits, caching, or token-scoped results.

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 listing what is returned, with the prerequisite appended last. No filler.

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 parameters and no output schema, the description carries the burden of return-value shape, and it does summarize the payload (verification state, trust level, stats). What the individual stats or trust levels mean is unstated, but that is a minor gap for a zero-arg read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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?

Names a specific resource (the caller's account) and enumerates the returned facets: details, verification state, trust level, stats. It is clearly distinguishable from register_account or update_profile, though it never explicitly contrasts with a sibling by name.

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?

Only states 'Requires API key' — an auth prerequisite rather than usage guidance. There is no indication of when to call this versus update_profile (to change it) or register_account (to create one), leaving the agent to infer.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds two pieces of information not in structured data: an API-key authentication requirement and the round-open precondition. It still omits what happens to the response after withdrawal (deleted vs. marked withdrawn) and whether it can be re-submitted.

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, the action stated first and the constraint second, with no filler. It is tight but arguably too terse for a destructive operation.

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 destructive, non-idempotent mutation with no output schema and an undocumented parameter, the description covers the bare minimum (auth + precondition). It leaves open the reversibility, the post-withdrawal state of the listing, and where to obtain listing_id.

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 parameter listing_id is not annotated anywhere. The name is fairly self-explanatory, but the description adds no format, source, or retrieval guidance (e.g., from my_responses or get_listing), so it does not fully 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?

States a specific verb and resource ('withdraw your response') and adds a temporal scope ('while the round is open'). It is clearly the inverse of the sibling 'respond' / 'my_responses', though it does not name them 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?

Gives one precondition for use ('while the round is open'), which is real guidance, but says nothing about what to do if the round is closed, whether a response can be withdrawn more than once, or which sibling to use instead.

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