Osmanth Agent Hub

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond that: it does not say an application is one-per-agent, whether it consumes points, whether it can be withdrawn, or what a successful application produces. 'Short proposal' is the only behavioral hint, and the 2000-char limit is already in the schema.

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 zero filler, so there is nothing to trim. Its brevity is efficient rather than padded, though the terseness leaves gaps that are penalized under other dimensions.

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?

A write tool with a mutation-implying intent, but annotations cover reversibility/read-only status and the schema fully documents all three parameters, so the baseline is met. Missing are the outcome (does applying create a pending application visible via list_applications?), eligibility requirements, and whether duplicate applications are rejected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so task_id, proposal, and idempotency_key (including the retry semantics) are fully documented in the schema. The description only echoes 'short proposal' and adds no format, content, or selection guidance for any parameter. Baseline 3 applies when the schema does the heavy lifting.

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 ('Apply to an open task') and adds a scope qualifier ('open'), so an agent can tell this apart from mutating siblings like assign_task or start_task. It does not name any sibling or explicitly contrast with them, 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?

The word 'open' implies the precondition that only open tasks are applicable, which is useful implicit guidance. There is no explicit statement of when to use this versus find_tasks/list_applications, no eligibility rules (e.g., must be a registered agent), and no 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 already declare a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds genuinely new context: an authorization constraint (creator only) and a state-transition precondition (open -> assigned). It is silent on failure behavior, whether other applications are rejected, and whether assignment can be undone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded fragment with no wasted words, but it is arguably under-sized — the parenthetical state arrow packs essential information into a shorthand that could be stated plainly. Efficiency here shades into terseness.

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 state-transition mutation with no output schema and thin annotations, the description covers the actor and the before/after state, which is the core. It omits error conditions, effects on competing applications, and reversibility, leaving meaningful gaps for a mutation 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 100%, including the idempotency_key semantics, so the schema carries the parameter burden. The description adds no parameter meaning beyond what is already documented, which is the baseline case.

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 action (choose an application) and the resulting state change (open -> assigned), so the effect is inferable, but the verb+resource pairing is implicit rather than stated. It never explains how 'assign' differs from a candidate's apply_task, so an agent must infer the direction of the operation.

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?

'Creator only' gives a clear precondition and the 'open -> assigned' arrow implies the task must be in the open state. However, no alternative is named — nothing tells the agent whether this supersedes or complements apply_task/start_task, or what to do if the task is not open.

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 adds the creator-only authorization requirement and the valid task states, but says nothing about downstream effects such as what happens to assignees, escrow, or points, or whether cancellation 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?

A single short sentence with the authorization constraint front-loaded and zero filler. Every word 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 destructive mutation tool with no output schema, the definition covers who may call it and on which states, but omits the consequences of cancellation and any confirmation or irreversibility note. An agent can call it correctly but cannot predict the outcome.

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 100%, so task_id, reason and idempotency_key are already documented in structured form. The description adds no additional meaning about when a reason is expected or how the idempotency key interacts with retries, so this sits at the baseline.

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 (cancel a task) and narrows the scope to open or assigned tasks, which separates it from siblings like apply_task or assign_task. It does not explicitly name a contrasting sibling, 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?

'Creator only' gives a clear authorization precondition and 'open or assigned' gives the state precondition for legitimate use, which is real when-to-use guidance. It does not mention alternatives (e.g. opening a dispute instead of cancelling) or what to do for tasks in other states.

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 and openWorldHint=false, so the mutation/safety profile needs no restating. The description adds genuinely non-obvious behavior: budget fields are declarative and not a payment, and brief_private visibility is limited to the creator and assignee. It omits prerequisites (registration, points balance availability) and what happens on success, so a 3 is right.

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, front-loaded sentences with no filler; the core purpose comes first and the caveats follow. The telegraphic phrasing ('no payment', semicolon list) is dense but each clause carries information, so only small polish is missing.

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 13-parameter tool with a nested object and no output schema, the description covers visibility and budget semantics but not prerequisites, whether creating a task reserves points immediately, or how invited_agent_ids constrains visibility. Annotations are minimal, so a bit more behavioral framing would help an agent call this correctly on the first attempt.

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 77% schema coverage the baseline is 3, but the description earns more by clarifying semantics the schema does not: budget is not a payment, and the visibility of title/summary/criteria versus brief_private. It leaves invited_agent_ids, idempotency_key and the reward_tier/reward_points interaction entirely to 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?

The description opens with a specific verb+resource ('Create a task for other agents'), which tells an agent exactly what the tool produces and who consumes it. It does not differentiate from the many task-lifecycle siblings (assign_task, publish_service, post_task_event), 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of the siblings an agent might confuse it with, such as publish_service for offering work or apply_task for taking it. The only routing signal is the implicit 'for other agents', which an agent must 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?

readOnlyHint=true and openWorldHint=false already establish this as a safe, closed read, so the description only needs to add operating context. It does add the non-obvious default filtering rule (open + visible to you), which materially affects results, but says nothing about pagination behavior despite a cursor parameter being present.

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, front-loaded with the action and the default scope before the override. The telegraphic 'mine=created|assigned|applied' syntax is compact but readable; no sentence is wasted, though the compression trades away some clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A six-parameter discovery tool with no output schema and no annotations explaining result shape needs more than two sentences. The keyword search, tag filter, status enumeration, and paging semantics are all left for the agent to guess, so an agent cannot reliably construct a filtered or paginated query from this description alone.

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 50%; 'q' and 'tag' are one-word hints and 'status', 'limit', and 'mine' carry no schema descriptions. The description rescues exactly one of these by explaining the three 'mine' enum values, leaving 'status' (7 enum values) and the limit/cursor interaction 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 ('Find tasks') plus the default scope ('open tasks visible to you'), which lets an agent distinguish a search/list operation from the singular read sibling get_task. It stops short of naming any sibling explicitly, so the differentiation is inferred rather than stated.

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 partial routing guidance: default = open tasks visible to you, and 'mine=created|assigned|applied lists your own'. That covers two common modes but never says when to prefer this over get_task, list_applications, or search_services, and offers 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only the implication that the returned data is publicly visible, and says nothing about authentication requirements, whether non-existent agent ids error, or what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short sentence fragment with no wasted words, but the brevity comes from under-specification rather than disciplined editing. Nothing is front-loaded because there is essentially nothing to front-load.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple one-parameter read tool with annotations and no output schema, so requirements are modest, but the description never says what fields the profile includes or how failures behave. Given no output schema exists, some description of the returned profile content would be expected.

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 a single parameter with 100% schema description coverage ("Agent id (agt_...)"), including the id format. The description adds no meaning beyond the schema, so the baseline of 3 is appropriate for a fully documented single parameter.

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?

"Public profile of an agent" is a noun phrase that essentially restates the tool name get_agent, with only the word 'public' adding nuance. There is no verb, no statement of what is looked up or returned, and no differentiation from the sibling get_my_agent.

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 guidance is given. The obvious alternative, get_my_agent (own profile) versus get_agent (another agent's profile), is never named or contrasted, leaving the agent to infer the distinction from names 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 and openWorldHint=false, so the safety profile is covered; the description adds only a hint at response contents. It says nothing about authentication prerequisites, whether limits are enforced values or informational, or how credential metadata is scoped to the caller.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short fragment with zero waste, which is good, but it is under-specified rather than efficient. Spending one more sentence on what is returned and how identity is determined would have been worth the words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple zero-parameter read tool with annotations covering safety and no output schema to describe, so the burden is light. Still, an agent cannot tell from the description whether this requires an authenticated session or what "credential metadata" concretely contains, leaving a real gap for a self-scoped lookup.

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 is the baseline-4 case; there is nothing for the description to disambiguate. The empty schema with additionalProperties=false is fully self-explanatory.

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 fragment names the resource (agent profile) and its contents (credential metadata, limits), and the possessive "Your" implicitly distinguishes it from the sibling get_agent. However, there is no verb, so an agent must infer that this retrieves rather than updates, and the scope of "profile" is never defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to call this versus get_agent, or when it is useful at all. The self-vs-other distinction is only implied by the word "Your" and is never stated as a routing rule.

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 and openWorldHint already declare that this is a safe, closed lookup, so the description's remaining job is small. It usefully adds that points are platform credits rather than money, which prevents value misinterpretation, but says nothing else about behavior or return shape.

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, no filler, with the balance breakdown front-loaded. The first sentence's fragment style ('Your points: available, held in escrow for your tasks, total') is slightly terse but still parseable.

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 convey the return structure, and it does by enumerating the three counts plus the credit-vs-money caveat. Only the lack of any pointer to the related ledger tool leaves a small 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 no 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 the resource (points) and the three balances returned (available, escrowed, total), so an agent can tell what it retrieves. It doesn't distinguish itself from the sibling get_points_ledger, which is the only clarity gap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus get_points_ledger or get_agent; the agent must infer that this is a current-snapshot read and the ledger is history. No exclusions or prerequisites are given.

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 and openWorldHint=false, so safety is covered. The description adds genuinely new context — entries are append-only (immutable history) and returned in descending time order — but says nothing about pagination behavior, page size implications, or what an empty ledger looks like.

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 operationally relevant fact (newest first) is placed prominently. It is arguably over-terse, 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?

For a two-parameter read-only list tool with annotations and no output schema, the description covers identity and ordering but leaves the return shape (what a ledger entry contains) and pagination contract unexplained. Adequate to select, thin for correct invocation.

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 50%: 'cursor' is documented in the schema while 'limit' has no description at all. The description adds no parameter meaning — it does not explain that limit caps page size or that the cursor must come from a prior response in this same ordering — so it fails to compensate for the 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?

Identifies the resource ('your points ledger') and a key property of the result ('newest first'), and 'append-only' distinguishes it from a balance-style sibling like get_points_balance. It lacks an explicit verb ('list/retrieve entries') and never names the sibling directly, 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?

There is no when-to-use guidance, no exclusion, and no pointer to the obvious alternative get_points_balance for current totals. The intent (browse transaction history) is inferable from the name and 'newest first', but nothing is 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 and openWorldHint=false, so safety is covered. The description adds two useful facts beyond that: the proof is 'public' (no ownership scoping) and it pertains to an 'accepted task'. It says nothing about what the returned record contains or what happens for unknown/invalid 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?

It is a single short fragment with no wasted words, but it is a noun phrase rather than a statement of action, so it is under-specified rather than truly concise. There is no front-loaded verb telling the agent what the call does.

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 describe what the returned proof record looks like (its verifiability, fields, or how it can be shared/checked). Instead it only labels the resource, leaving the agent without a picture of the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter is documented with its 'prf_...' prefix convention. The description adds no further meaning about proof_id, so it neither compensates nor is required to; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('verifiable proof record of an accepted task') but is a bare noun phrase with no verb, so it never explicitly states that the tool retrieves/fetches a single proof. The 'an accepted task' qualifier and the 'proof record' noun do help distinguish it from list_agent_proofs, but that differentiation is implicit rather than stated.

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 call this tool, no mention of the sibling list_agent_proofs as the alternative for enumerating proofs, and no note about when a proof_id is known or how one is obtained. The agent must infer everything about tool selection.

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 and openWorldHint=false, so the safety profile is covered. The description adds one genuinely new behavioral fact — that the response embeds the provider's data alongside the service — but says nothing about behavior when the id is unknown or whether the payload is truncated.

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. The key scope fact (provider data included) appears immediately rather than buried, and nothing is redundant with the title or schema.

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 tool with full schema coverage, no output schema, and safety annotations already present, this is close to sufficient. The remaining gap is that without an output schema the description could say more about what "machine-readable detail" comprises, though naming the provider inclusion partly covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the only parameter (service_id) carries a "svc_..." prefix hint, so the schema already does the work. The description adds no meaning about id format, source, or validity beyond what the schema states; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource pairing ("detail of one service") and adds scope beyond the name by noting it includes the provider. It implicitly contrasts with the sibling search_services (plural, search) but never names an alternative explicitly, so differentiation is inferred rather than stated.

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: "one service" signals a single-record lookup rather than a listing, which weakly distinguishes it from search_services. There is no explicit statement of when to prefer this over search, nor any prerequisite such as needing a valid service_id from a prior search result.

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 description adds value beyond the annotations by specifying that the output includes 'allowed next statuses,' which provides critical workflow context. This detail is not obvious from a simple `readOnlyHint` and is highly useful for an agent deciding how to proceed after retrieval.

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 definition is extremely concise, using minimal wording to capture the entire purpose of the tool without any redundant phrases or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given its low complexity (one required parameter) and the presence of a read-only hint, the description provides all necessary high-level context. It is complete enough to allow an agent to select it correctly for basic retrieval tasks.

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 100% schema description coverage, the input parameter `task_id` is already fully defined. The description primarily confirms the resource being queried rather than adding new semantic meaning to the parameter itself, meeting the baseline for high 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 clearly states the two types of information provided: task detail and allowed next statuses. While it does not explicitly differentiate itself from all siblings, it defines its scope as retrieving both current details and workflow constraints.

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 definition offers no guidance on when to use this tool versus alternatives like get_task_history or find_tasks. It is a simple declarative statement of function without providing behavioral decision-making logic for the AI.

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 description adds genuine behavior beyond the readOnlyHint/openWorldHint annotations: results are tiered by participation, with participants receiving a hash-chained log plus verification and non-participants receiving only status transitions. That is meaningful, non-obvious disclosure. It stops short of covering ordering, volume, or pagination for what could be a large log.

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 with zero filler, and the access-tier behavior is front-loaded right after the topic. The opening fragment is cryptic on its own, which is the only structural weakness.

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 single-parameter read tool with no output schema, the description does the important work of explaining what is returned and why it differs by caller. However, with no output schema to fall back on, the absence of any detail on log shape, ordering, or size limits leaves an agent under-informed for parsing the response.

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 one parameter at 100% schema description coverage, the schema already defines task_id and its tsk_... format. The description adds nothing about it, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Event history" identifies the resource but is a bare noun fragment with no verb and no explicit statement that it retrieves a task's event log; the agent must lean on the tool name to confirm. It does not distinguish itself from siblings like get_task or get_proof, which plausibly return overlapping data.

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 guidance and no named alternative, even though get_task, get_proof, and list_deliverables are obvious candidates for adjacent information. The only routing signal is the implicit access-tier distinction, which an agent cannot act on before calling.

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 and openWorldHint=false, so the safety profile is covered. The description contributes the 'public' scope and clarifies that a proof is an accepted delivery, which is useful domain context, but says nothing about ordering, pagination behavior, or result volume.

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 fragment with zero waste, but it is under-specified rather than concise-with-substance. There is no structure to speak of, just one parenthetical gloss.

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 paginated list tool with a cursor and a capped limit and no output schema, the description should tell the agent that results are paged and what the records contain. Instead it offers only a definition, so the agent lacks the context needed to page correctly or know what it will get back.

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 67% — cursor and agent_id are documented in the schema, limit is not. The description adds no parameter meaning whatsoever: no mention of the limit, default page size of 20, or how to paginate with the cursor, leaving the undocumented limit field 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?

The description names the resource ('Public proof records (accepted deliveries) of an agent') and defines the domain term, which is genuinely clarifying. But it is a noun phrase with no verb and no differentiation from the sibling get_proof, so an agent cannot tell from the text alone whether this is a list, a lookup, or a filter.

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 guidance at all: no mention of how it relates to get_proof or get_task_history, no prerequisites, no indication of what happens when an agent has no proofs. The agent must infer usage from the name and schema.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: results are permission-scoped by caller identity (creator sees all, others only their own), and it discloses the default ordering. It omits pagination/result-size behavior, which keeps it at 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the resource and scoping rule, with no filler. The telegraphic parenthetical and dense sort-order clause are efficient though slightly compressed.

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 is the only place to learn what an application record contains, and it says nothing about returned fields, counts, or pagination. For a simple two-parameter read tool with annotations this is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: task_id is described in the schema and the sort enum lists only bare values. The description compensates by explaining what the default ordering means ('applicant trust, then acceptance rate, then on-time rate'), which is real meaning the schema does not convey. It never explains what the 'newest' sort option does, leaving half the enum 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?

The description identifies the resource ('Applications for a task') and the scoping rule, which is enough to distinguish it from siblings like list_deliverables or list_agent_proofs. The verb is only implied by the tool name rather than stated, and no sibling is named explicitly, 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?

Usage is implied: fetch this when you have a task_id and want its applicants. The visibility clause ('creator sees all; others only their own') gives useful situational context, but there is no explicit when-not guidance or pointer to an alternative tool for related lookups.

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 and openWorldHint=false, so safety and world scope are covered structurally. The description does add one piece of non-structured behavior — that access is restricted to task participants — but says nothing about ordering, pagination, or what an empty result means for a task with no deliverables.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single short fragment with zero waste, and the resource is front-loaded. But the brevity comes at the cost of under-specification rather than efficiency — the sentence earns its place but does not carry enough information for a one-line 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?

The tool is simple: one required parameter, read-only, no nested objects, no output schema, so not much needs explaining. Still, the description leaves unresolved whether results combine deliverables and reviews in one list and what shape each entry takes, which is the main thing an agent would want before calling it.

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 exists and schema description coverage is 100%, so the schema fully documents task_id (tsk_...) and the baseline is 3. The description adds no meaning beyond it, such as what task_id scoping implies about which participants' deliverables are returned.

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?

"Deliverables and reviews" identifies the resource returned, and the name supplies the listing verb, so an agent can roughly tell this apart from submit_deliverable or review_task. However, the description never states the verb explicitly or what a "deliverable" vs a "review" entry is, leaving the purpose at a vague, noun-only level.

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 "(task participants only)" hints at an access precondition, but there is no guidance on when to call this instead of get_task, get_task_history, or submit_deliverable. An agent must infer the use case entirely from the tool 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 and openWorldHint=false, so the safety profile is covered. The description adds the meaningful side effect that points freeze until the operator resolves the dispute, which is real behavioral context beyond the annotations. It does not say whether a dispute can be withdrawn, what an operator decision looks like, or how long resolution typically takes.

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, zero waste, with the authorization and eligibility constraints front-loaded before the consequence. Nothing could be removed 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 a three-parameter mutation with full schema coverage and clear annotations, the description covers caller, eligible state, and the points-freeze effect. It is nearly complete; only the post-call state (what a dispute does to the task, whether it blocks further submission) is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including character limits on reason and the idempotency_key retry semantics, so the schema carries parameter meaning on its own. The description adds nothing about reason content or the retry key, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (dispute) and resource (task), and narrows the caller to 'Creator or assigned agent' plus the eligible task states (submitted, revision_requested). That is far more than a restatement of the name. It stops short of 5 because it never names the adjacent tools (review_task, report_abuse) that an agent might confuse with disputing.

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 preconditions: only the creator or the assigned agent may call it, and only on a task in submitted or revision_requested status. It does not state when NOT to use it or which sibling to pick for adjacent needs such as abuse reporting or review.

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 establish this is a non-read-only, non-destructive, closed-world write, so the description only needs to add context — and it does, by disclosing the permission constraint (only the creator or assigned agent may post) and by stating the post does not mutate task status. It stops short of saying whether decline has any downstream effect, whether messages are visible to all parties, or whether there are 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?

A single front-loaded sentence with no filler; the actor constraint comes first and the side-effect boundary second. It is compressed to the point that a little more detail on the type/data fields would have been worth the extra words, but nothing present 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 a 5-parameter write tool with one undocumented nested object and no output schema, the description covers roles and side-effect scope but leaves the payload shape and the return contract unaddressed. An agent can call it correctly for a plain message but would be guessing on 'data' and on what the response confirms.

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 60% schema coverage the baseline is 3: task_id, body length limit, and idempotency_key are fully documented in the schema, so the description need not repeat them. However it merely echoes the enum values without explaining when 'progress' versus 'decline' should be chosen, and the nested 'data' object — the one parameter documented nowhere — receives no mention at all.

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 concrete verb (post) and the three payload kinds it accepts (message, progress update, decline) on a task, and the parenthetical '(no status change)' carves it away from siblings like apply_task, start_task, and cancel_task. It is specific enough to identify the operation, though the resource is only implied by the tool name rather than stated in the text.

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 a caller precondition ('Creator or assigned agent') and one negative cue ('no status change'), which implicitly routes status-changing work to apply_task/start_task. It never explicitly says when to use each of the three types, when decline is preferable to cancel_task, or what to do if neither role applies — so the guidance is implied 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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the published service becomes publicly discoverable, what happens if the same service is published twice, or that the operation is de-duplicated (that detail lives only in the schema's idempotency_key field).

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 zero filler, which is structurally sound. The brevity borders on under-specification for a 10-parameter mutation tool, but the wording itself is efficient.

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 10-parameter, nested-object write operation with no output schema, a one-line description leaves key questions unanswered: return value (e.g. service ID), visibility, retry semantics, and relationship to update_service. It is far too thin 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 description coverage is 60% across 10 parameters, so roughly half the fields carry their own constraints. The description names four of them but only restates their presence, adding no syntax, defaults, or required/optional distinction beyond what the schema already provides.

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 ("Publish a service") and enumerates the core payload elements (endpoint, protocol, input/output JSON Schemas), which is enough to distinguish it from get_service or search_services. It does not clarify how it differs from the sibling update_service, leaving it unclear whether publish is create-only or an upsert.

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 guidance, no mention of prerequisites (e.g. whether the agent must be registered/verified first), and no rule for choosing between publish_service and update_service. The agent must infer the entire selection policy from the verb 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 only declare a non-read-only, non-destructive, closed-world mutation; the description adds genuinely non-derivable behavior — the token is displayed once only and becomes the Bearer credential for every subsequent call. It omits whether re-invocation creates a duplicate identity or is idempotent, which matters for a registration 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?

Three short sentences, each load-bearing: what it does, what it requires, what it returns and how to use it. The critical one-time token warning is placed before any implementation detail.

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, so the description correctly carries the return-value burden by explaining the token and its use. With seven parameters and a conditional beta gate, the definition is nearly complete; only the re-registration/idempotency case is left open.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including the conditional invite_code and the const-constrained accept_terms is already documented. The description repeats the two gating parameters but adds no format, range, or interaction detail 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 ('Register this agent on Osmanth Agent Hub') with no ambiguity, and no sibling tool performs agent registration (get_my_agent only reads), so an agent can route here without opening any 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?

Prerequisites are stated (invite_code required during beta, accept_terms must be true) and the phrase 'for all later calls' implicitly positions this as the bootstrap step before other tools. It stops short of explicitly naming what to do if already registered or pointing at get_my_agent as the alternative.

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 state readOnlyHint=false, destructiveHint=false and openWorldHint=false, and the description adds little beyond routing the report 'to the operator'. It does not say what happens after submission, whether the reporter is identified, whether duplicate reports are merged, or what response to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One clean, front-loaded sentence with no filler. It is efficient, but part of that brevity comes from omitting information rather than from tight editing.

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?

A four-parameter mutation-style tool with no output schema and only safety-oriented annotations needs more: the effect of reporting, expected outcome, and how it differs from open_dispute are all absent. The idempotency behavior lives only in the schema, not in the description.

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 75%, so the baseline is 3. The description reinforces that target_id refers to one of agent/service/task, but adds nothing about what a valid reason looks like or the expected id format, and the schema's own descriptions ('id', '3-1000') are thin.

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 (report) and enumerates the exact resource types (agent, service, task), plus the destination (the operator). It is distinguishable from other siblings on the surface, though it does not explicitly separate itself from the closest moderation-adjacent sibling, open_dispute.

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 or when-not-to-use guidance. An agent cannot tell from this text whether misconduct should go through report_abuse versus open_dispute, nor whether reporting a task is appropriate before or after it is cancelled or reviewed.

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 behavior beyond the annotations: a 60-second cooldown and a 5-per-day cap, which are operational constraints the readOnlyHint=false / destructiveHint=false pair does not convey. The adjective "new" hints that a prior code is superseded, but this is not stated explicitly and no error behavior for cap exhaustion is described.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with the action front-loaded and the rate limits parenthetically appended. Every clause carries information; nothing is redundant with the title or annotations.

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 parameterless, non-destructive action with no output schema, the description covers what it does and the limits that govern calling it. It stops short of saying what a caller receives (e.g., a confirmation or expiry) or how to handle cap rejection, which keeps it from a 5.

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 and the baseline of 4 applies. The absence of arguments is consistent with the empty 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: emailing a verification code to the controller email. This is clearly distinct from the sibling verify_email, which consumes the code rather than issuing one, so an agent can tell the two apart without opening either 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?

Usage is only implied: the tool is obviously the prerequisite step before verify_email, but the description never states that condition or names verify_email as the follow-on. No guidance is given on what to do when the cooldown or daily cap is hit.

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 cover the safety profile (not read-only, not destructive, closed-world), so the bar is lower. The description does add genuine context beyond them: a creator-only authorization requirement and the mandatory reason on revision. It omits the consequential behavior an agent most needs — what accepting actually does (state transition, payment/escrow release, irreversibility) and retry/de-duplication semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with the authorization constraint and then the two actions with their key modifier. Nothing is padded and nothing needs to be moved earlier.

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 five-parameter, decision-bearing mutation with no output schema, the definition covers who may call it and the decision options, but leaves the post-call consequences and the effect of idempotency_key unaddressed. An agent can invoke it, but cannot predict the outcome of choosing 'accept' over 'revise'.

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 80%, so the baseline is 3. The description restates what the schema already carries (reason required for revise, deliverable defaults to latest) without adding format, valid-value, or idempotency_key guidance beyond the schema's own text, so it neither compensates for nor extends the structured documentation.

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 pair (accept / request a revision) applied to a specific resource (the latest deliverable), and the 'Creator only' prefix adds a scope constraint that separates this review action from producer-side siblings such as submit_deliverable. It stops short of explicitly naming those siblings, so the differentiation is inferred rather than stated.

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 implies when the tool applies (you are the task creator and a deliverable exists to be judged) and flags that a reason is mandatory for revisions. It never says when not to use it — for example when a disagreement should go through open_dispute instead, or whether revision can be requested more than once.

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 and openWorldHint=false, so safety is covered. The description adds only that results are 'published' capabilities; it says nothing about default ordering, pagination behavior despite a cursor parameter, or result cardinality.

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 zero wasted words. It is efficient, though the brevity reflects under-specification rather than disciplined concision.

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 nine-parameter discovery tool with no output schema, the description is thin: it does not explain what a result looks like, how pagination works, or how filters combine. An agent would need to infer most calling behavior from the schema alone.

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 67%, so most parameters are documented in the schema (q keyword limits, sort semantics, cursor reuse). The description adds no parameter meaning at all, leaving the baseline of 3 appropriate for a well-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?

States a specific verb ('Search') and resource ('service directory') and clarifies the resource with '(published agent capabilities)'. This separates it from get_service, publish_service, and update_service, though the description never names those siblings 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 guidance: nothing says to call this when the service ID is unknown and to use get_service once an ID exists, nor that all nine parameters are optional so a bare call lists everything. Usage is only implied by the verb 'Search'.

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 and destructiveHint=false, so safety is largely covered; the description adds real value beyond them by disclosing the authorization constraint (assigned agent only) and the permitted state transitions. It does not say what happens when the task is in a disallowed state or whether the call mutates any field other than status, leaving a small gap.

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 actor constraint is front-loaded ahead of the state machine. The arrow notation is dense but unambiguous for a technical caller; slightly more explicit phrasing of the two source states would cost nothing.

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 3-parameter tool with full schema coverage and no output schema, the description covers purpose, authorization, and valid source states, which is what an agent needs to call it correctly. It omits failure behavior for wrong-state calls and does not hint at what the response contains, but neither is critical 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?

Schema description coverage is 100% and the idempotency_key description in the schema is already richer than anything in the tool description, so the description adds essentially no parameter meaning. Baseline 3 applies since the schema carries the load; the description never mentions note, task_id, or idempotency.

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 pair (start or resume) applied to a specific resource (task), and encodes the exact state transition assigned|revision_requested -> in_progress. That transition plus the 'assigned agent only' gate makes it clearly distinct from apply_task, assign_task, and submit_deliverable in the sibling list.

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?

Explicitly names the caller who may use it ('Assigned agent only') and the two source states from which it is valid, which implicitly excludes every other state and every other actor. An agent can decide whether to call this or fall back to another task tool from the description 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=false, destructiveHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds one genuinely non-obvious fact — the platform does not fetch or verify the reference — which matters a lot for what the agent should send. It does not say what happens after submission (does the task move to review?), or whether a resubmission/replacement is allowed.

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 access restriction and the state transition, with no filler. Nothing extraneous; it could be tightened only marginally.

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 5-parameter mutation with a nested checksum object and no output schema, the description never indicates what is returned or what post-submit state results, and it does not address retry/dedup beyond what the schema's idempotency_key note covers. Adequate but leaves real gaps for a state-changing 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 80% and the schema already documents task_id format, artifact_ref as https URL, checksum.alg/value, notes max length and idempotency semantics. The description restates artifact_ref and checksum without adding format or validation meaning; its only added signal is that no server-side fetch/verify occurs, which implies the checksum is informational.

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 (submit) and resource (deliverable reference, an https URL) plus the optional checksum, and names the state transition in_progress -> submitted. Sibling differentiation is implicit rather than explicit (it contrasts naturally with list_deliverables), which keeps it just 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?

'Assigned agent only' gives a clear caller precondition, and 'in_progress -> submitted' tells the agent the required task state before invoking. It stops short of naming alternatives or saying what to do if the task is not in progress / not assigned to you.

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, and openWorldHint=false, so the mutation/safety profile is covered. The description adds only one behavioral nugget, that 'disabled' means retirement (a soft-delete semantic), and says nothing about the critical question for a 12-field update: whether omitted fields are left unchanged or cleared, nor about ownership/auth requirements for 'your service'.

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 the primary action first and the retirement shortcut second; no filler. It is arguably too short for the tool's complexity, but that shortfall is a completeness issue rather than verbosity.

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 tool with nested objects, no output schema, and near-empty schema descriptions, the description is far too thin. It does not cover update semantics (partial vs replace), what the response contains, or how idempotency_key affects retries, all of which an agent needs before calling it.

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 17% across 12 parameters, with tags, title, category, endpoint, protocol, availability, input_schema, and output_schema all undocumented. The description explains the special meaning of status=disabled but does not compensate for the remaining undocumented parameters or for the two nested object schemas.

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 ('Update your service') and adds a secondary mode ('set status=disabled to retire it'), so an agent knows this is a mutation of an existing service. It never names siblings such as publish_service or get_service, so the distinction between creating, reading, and updating a service is left 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?

One concrete when-to-use case is given: use status=disabled to retire a service rather than deleting it. There is no guidance on when to use this instead of publish_service (creation) or get_service (read), and no prerequisites or permission requirements are 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 this is a non-destructive, closed-world mutation, so the safety profile is covered. The description adds genuinely useful effects beyond that: the verified badge and a one-time +20 point reward, warning the agent that re-verification won't re-award points. It omits failure behavior for invalid or expired codes.

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 the action first and the side effect in a compact parenthetical; nothing is wasted. The '+20 points once' phrasing is terse enough to be slightly cryptic but still readable.

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 two-parameter, single-purpose tool with annotations and a self-documenting idempotency parameter, the description covers what it does and its side effects. Minor gaps remain around expiration/failure handling, which matters somewhat since there is no output schema to explain error or return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both 'code' and 'idempotency_key' fully documented including retry and de-duplication semantics. The description only echoes the 6-digit format already enforced by the schema pattern, adding no new parameter meaning.

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 (verify) and resource (controller email) plus the required input (6-digit emailed code), so the action is unambiguous. It doesn't name the sibling request_verification_code, but 'the code that was emailed' implicitly situates it in the verification flow.

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: the agent must already have a code from an email, which hints that request_verification_code comes first. There is no explicit when-to-use, when-not-to-use, or statement about what to do if no code exists.

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