day1work

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

Annotations only declare readOnlyHint=false, so the description carries real weight by disclosing the required scope and the payout-verification prerequisite on the human's account. It does not describe reversibility, whether a bid can be withdrawn, or what happens on success.

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 with the core action front-loaded and prerequisites following. Every clause carries information; nothing is padding.

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 low parameter coverage, the description does cover the safety-relevant prerequisites well, but leaves dry_run semantics and the result of a successful bid unexplained. Adequate but with visible gaps for a 4-parameter 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 coverage is only 25%, and the description adds meaning only for the pitch (matching the 'message' parameter). 'task_id' and especially 'dry_run' are left entirely unexplained in both schema and description, so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource (bid on a task) and clarifies the actor relationship ('for the human'), which separates it from post_task and offer_service. It stops short of naming a sibling or stating what a bid is not, 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 two concrete preconditions (bids:write scope, payout-verified human account) that tell the agent when the call will succeed. However, it offers no guidance on when to bid versus using offer_service or post_task, and no exclusion 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?

readOnlyHint=true already establishes safety, so the description's marginal value is the auth requirement ('Requires an agent token') and the disclosure that results are grouped into approved / declined / undecided. With no output schema, that return-semantics detail is the main behavioral payload and it is delivered.

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 purpose front-loaded ahead of the prerequisite. Every clause carries information the agent needs.

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

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

For a parameterless read tool with no output schema, the definition covers what it returns, in what states, and the auth precondition. It is nearly complete; only the absence of sibling differentiation and of pagination/format expectations 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 zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing filters that the empty schema does not support.

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 ('See') and object ('what the human has approved, declined or not decided yet'), which reads distinctly against siblings like list_conversations or get_task. It does not, however, name what kind of items are being approved (bids, payments, services), so the resource stays slightly abstract.

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 stated prerequisite 'Requires an agent token' is genuine usage guidance and the tri-state framing implies this is a status-polling tool. But there is no when-to-use/when-not guidance and no alternative sibling named for related lookups such as whoami or get_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 readOnlyHint=true, and the description is consistent with that. It adds one genuinely useful behavioral fact beyond the annotations — "Needs no credentials" tells the agent this call is unauthenticated. It says nothing, however, about what happens when the id is unknown or out of the requested country.

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 terse sentences with zero filler, and the core operation is front-loaded ahead of the auth note. Nothing in the text is redundant with the name or 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?

No output schema exists, but for a single-record read tool the description is close to sufficient: identity, access model, and lookup key are all covered, and the country constraint is documented in the schema. The one missing piece is failure behavior for a nonexistent or cross-region 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 coverage is 50%: country carries a rich schema description (ISO alpha-2, supported regions) while id is a bare integer. The description's "by id" only restates the required parameter and adds no format, range, or country-interaction detail, so it neither compensates for the gap nor adds value over 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 with scope: "Read one task by id." The singular "one task by id" implicitly differentiates it from the sibling search_tasks, but it never names that alternative, so the differentiation is left to inference.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of search_tasks as the alternative for listing or filtering. The only cue is "by id," which implies a retrieval pattern but is not framed as 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 declare readOnlyHint=true, so the agent knows this is a safe, non-mutating call. The description adds that the tool returns explanatory content (device flow, scopes, approvals) rather than performing a connection, which is useful context, but it says nothing about output format or whether calling it has any side effect on the auth state.

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 with zero filler: the first states what the tool explains, the second states the call condition. The relevant trigger is front-loaded at the end of a tight, well-ordered statement.

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 informational tool with no output schema, the description covers enough for correct invocation: what it explains and when to call it. It stops short of noting that calling it does not itself grant a token, which would fully close the loop.

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; the baseline of 4 applies. No parameter-level detail is needed or missing.

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 verb (Explain) and resource (how to connect an agent to a human on Day1Work), then enumerates the covered topics: device flow, scopes, and human approval. That makes it clearly distinguishable from the action-oriented siblings like check_approvals 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 an explicit trigger condition: 'Call this when you need to act for someone but have no token yet.' That tells the agent precisely when the tool applies, though it names no alternative tools or exclusions for adjacent cases such as already holding a token.

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

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

readOnlyHint=true already signals a safe read, and the description usefully notes that icons are included in the result. However, it adds nothing about auth requirements, ordering, or whether the list is static or user-specific, so the gain over annotations is modest.

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 that front-loads the verb and resource; nothing can be trimmed without losing meaning.

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 simple, read-only, single-parameter list tool with full schema coverage and annotations, the description covers what the tool does and what it returns (icons). Only minor gaps remain, such as what a category comprises or how results are ordered.

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 country parameter is fully documented in the schema with the ISO format and supported regions. The description adds no parameter detail, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (task categories) with a scope note (on Day1Work, with icons). It distinguishes itself adequately from siblings like list_services and list_conversations, though it doesn't explicitly contrast with them.

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

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

No guidance on when to call this versus alternatives, no prerequisites stated, and no mention of what the returned categories are used for. Only implied usage as a discovery/lookup call.

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 a real auth requirement (chat:read scope), which is exactly the kind of behavioral detail annotations do not carry. However, it says nothing about ordering, pagination, or result set limits, and the readOnlyHint=false annotation sits in mild tension with a pure 'List' operation the description never reconciles.

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, and the core action is front-loaded ahead of the prerequisite. Every clause earns its place.

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

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

With no output schema and no parameters, the description is the only source of information about the result, yet it never characterizes the return (pagination, ordering, whether conversations are empty-safe). Adequate but leaving a clear gap for a list endpoint.

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 the schema carries nothing an agent must interpret; the baseline for a zero-parameter tool applies. The description correctly does not clutter itself with parameter talk.

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 (List) and resource (the human's conversations), which is enough for an agent to know what it returns at a glance. It does not, however, differentiate itself from the sibling read_messages, which an agent could plausibly confuse with listing conversations.

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 a prerequisite (chat:read scope), not a usage rule. Nothing says when to prefer this over read_messages or how it relates to the other conversation-adjacent sibling tools.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered structurally; the description's added value is the auth note ("Needs no credentials"), which is genuinely useful context beyond the annotation. It says nothing about pagination behavior, result ordering, or the geographic fallback when lat/long are absent, so the bar set by the annotations is met but not exceeded.

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 the core action front-loaded and zero filler. The parenthetical clarification earns its place by disambiguating the resource.

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 7-parameter, geographically scoped listing tool with no output schema and near-zero schema documentation, the description is far too thin. An agent cannot tell how to paginate, how search/category interact, or whether lat/long override country, which are the decisions it must make to call this 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 14% (7 parameters, effectively only country documented), so the description carries the burden and fails to: limit, offset, search, category, latitude, and longitude are never explained. The phrase "in a country" loosely maps to the country param, but nothing distinguishes free-text search from category filtering or explains how lat/long relate to country.

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

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

States a specific verb and resource ("List services") and immediately disambiguates the noun with "the work they sell", which separates it from sibling list_categories or search_tasks. It does not name a sibling directly, but the scope (services offered in a country) 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?

"Needs no credentials" is a real usage signal for an agent deciding whether it can call this, and the country scoping implies when it applies. However, there is no guidance on when to prefer this over search_tasks, list_categories, or how_to_connect, so the routing logic is left implicit.

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 readOnlyHint:false annotation already marks this as a write. The description adds genuinely useful context beyond that: "Live immediately, like anything a person posts" discloses there is no draft or moderation state, and the required services:write scope is an explicit auth prerequisite.

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 core purpose leads, followed by behavioral context and the scope requirement.

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 no output schema and thin schema coverage, the description covers auth and the immediate-visibility behavior but says nothing about the fields being set (rate, notes, dry_run) or what a successful call returns. Partially 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 only 20% (just category_id: "From list_categories"). The description adds no meaning for name, rate, notes, or the ambiguous dry_run flag, so four of five parameters are 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+resource ("Create a service listing") and clarifies what a listing is with the parenthetical "the work they offer." The verb "Create" implicitly separates it from update_service and list_services, though no sibling is named explicitly.

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

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

Usage is implied by the verb — create a new listing — but there is no explicit when-to-use or when-not guidance, nor any pointer to update_service for modifying an existing listing. Adequate but leaves routing 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 declare readOnlyHint=false, so the description carries real weight and delivers: the task goes live immediately (side effect), requires the tasks:write scope (auth), and is bounded by account limits. It does not address reversibility/cancellation, so 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 tight sentences with the core purpose front-loaded and constraints second. No filler, though slightly dense with parenthetical list of limits.

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 no output schema, the description covers purpose and side effects adequately but leaves most parameter semantics and the dry_run validation option unexplained. Adequate, 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?

With 12 parameters and only 33% schema description coverage, the description must compensate but largely does not. It gestures at amount, category, and country via the limits sentence, but says nothing about address, task_type, start_date, estimated_hours, or the useful dry_run flag.

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 ('Post a task') and clarifies it is posted on behalf of the human and goes live immediately. This clearly distinguishes it from bidding (bid_on_task) or offering services, though it does not name a sibling 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?

The description conveys context (goes live like an in-app task) and preconditions (scope, limits), but never states when to use this versus alternatives such as offer_service or how it relates to search_tasks/get_task. Usage is implied rather than guided.

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 claims a read operation, while the annotation declares readOnlyHint=false, which is a direct contradiction. Beyond this inconsistency, it omits any disclosure of pagination behavior, scope side effects, or what happens when the limit is reached.

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 two short sentences with no waste, and the primary action is front-loaded. It is efficient, though it could have used its brevity budget to include more useful 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?

For a read tool with three parameters, no output schema, and 0% parameter description coverage, the description is insufficient. It omits pagination semantics, return format, and any behavior beyond the scope requirement, leaving critical gaps 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?

All three parameters have 0% schema description coverage, and the description provides no explanation for 'limit', 'before_id', or 'conversation_id'. It only implies conversation context, leaving the agent to guess the role of each 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?

The description states a specific verb ('Read') and resource ('messages in a conversation'), which distinguishes it from sibling tools like send_message and list_conversations. It does not explicitly name an alternative sibling, but the core operation 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?

The description includes a prerequisite ('Requires the chat:read scope') but gives no guidance on when to use this tool versus alternatives like list_conversations or send_message. Usage is only implied by the tool name and 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 only supply readOnlyHint=false (a write). The description adds real behavioral context beyond that: the human is the approver, the request does not exist until approval occurs, and the payments:request scope is required. It does not disclose what happens on rejection, whether requests expire, or any 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 sentences, front-loaded with the action, then the role boundary, then the auth requirement. Every sentence carries distinct information and none 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 mutation tool with no output schema and only a single annotation, the description covers purpose, actor model, and auth scope, but leaves all five parameters unexplained — notably dry_run, whose semantics materially change the call. Adequate but with a clear 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?

Schema description coverage is 0% across five parameters, and the description explains none of them — amount, task_title, conversation_id, note, and dry_run are left entirely undocumented. The description does not compensate for the coverage gap, so an agent must guess at formats and the meaning of dry_run in particular.

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 ('Ask the human to approve a payment request in a conversation'), and clarifies the agent's role boundary versus the human's. It is clearly distinguishable from siblings like check_approvals or send_message, which are adjacent in the approval/payment domain.

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 for use (payment requests in a conversation) and an explicit boundary ('You cannot approve or send money: the human decides'), which tells the agent this is a request-for-approval path rather than a settlement path. It does not name an alternative tool or state when *not* to use it, so it stops short of a 5.

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

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

Beyond readOnlyHint=true, it discloses that no credentials are needed, that no listing ever crosses a country border, that in-person tasks only appear when coordinates are supplied and only inside that country's radius, and that addresses are approximate and posters anonymized. Auth requirements, filtering exclusivity, and result composition are all covered.

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?

Four short sentences, zero filler, and the most consequential constraint (country as a hard boundary) is front-loaded immediately after the purpose statement. Every sentence carries a distinct, actionable fact.

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 it covers the critical filtering semantics (country, location, anonymity), but leaves pagination, sorting behavior, budget filtering, and category/task_type selection undescribed. Adequate for the headline behavior, incomplete for full 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 27% across 11 params, so the description must compensate and largely doesn't. It clarifies the semantics of country (hard boundary) and latitude/longitude (needed for in-person work), but says nothing about sort, limit, offset, search, category, task_type, or the budget filters, which the schema also leaves bare.

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: 'Search open tasks on Day1Work.' That is enough to separate it from get_task (single task) and post_task, but it never names or contrasts those siblings explicitly, so an agent still infers the boundary from the verb 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?

Gives real conditional guidance: reading needs no credentials, country is mandatory and a hard boundary, and in-person results require latitude+longitude. It does not say when to prefer get_task or how this relates to other listing tools, so it stops short of full alternative 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?

Beyond the readOnlyHint=false annotation, it discloses two behavioral facts an agent could not infer: the message is attributed to an AI agent (irreversible provenance for the recipient) and the call needs the chat:write scope. It says nothing about rate limits or what dry_run does.

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, both earning their place, with the core action front-loaded and the auth requirement trailing.

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?

Covered: the write nature, AI attribution, and auth scope. Missing: any meaning for dry_run or conversation_id, and no indication of error behavior for a mutation tool with no output schema. Adequate but gapped.

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

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

Schema description coverage is 0% and the description explains none of the three parameters. content and conversation_id are at least named by their presence in the schema, but dry_run is a non-obvious boolean that goes completely unexplained.

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

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

States a specific verb+resource ('Send a chat message') and adds a distinguishing trait ('for the human', 'labelled as coming from an AI agent'). It doesn't name a sibling, but the send-vs-read split against read_messages is obvious.

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 real prerequisite ('Requires the chat:write scope'), which tells the agent when the call will succeed, but offers no guidance on when to choose this over read_messages or list_conversations.

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

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

Annotations only declare readOnlyHint=false, so the description's auth-scope requirement is a genuinely useful addition. It still omits whether omitted fields are preserved or cleared, what dry_run does, and whether the edit 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 action and followed by the auth requirement. No wasted 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?

For a 6-parameter mutation with no output schema and no annotation depth, the description covers only scope. Missing are field-edit semantics, dry_run behavior, and any indication of the return value or error conditions.

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?

Six parameters with 0% schema description coverage and no enums, so the description carries the full burden — and it says nothing about id, name, rate, notes, dry_run, or is_active. Only the resource being edited is implied, leaving every parameter 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 ('Edit') and resource ('service listings') scoped to the human's own listings. It is distinguishable from list_services and offer_service, though it never names those siblings or contrasts with them.

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

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

Provides one real precondition ('Requires the services:write scope'), which implies this is a mutation needing elevated auth. However, it gives no guidance on when to choose this over offer_service or list_services, nor when not to use it.

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

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

Annotations only declare readOnlyHint=true; the description adds genuine context beyond that by disclosing the auth requirement (agent token) and the sensitivity/contents of the payload (acting-for identity, scopes, limits, daily spend). It does not mention rate limits or whether results are cached, keeping it short of a 5.

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

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

Two tight sentences, zero waste: the returned data is front-loaded and the auth constraint follows as a qualifier. 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?

With no output schema, the description compensates by enumerating the returned fields (principal, scopes, limits, spend today) and the auth precondition. It is close to sufficient for a zero-parameter read tool, though it says nothing about the response shape or error behavior when the token is missing or expired.

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; the 4 baseline applies. The description correctly implies a no-argument call gated only by the agent token.

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 specific resource it returns — the acting principal, its scopes, limits, and today's spend — which is unmistakably the identity/self-inspection tool among siblings that all deal with tasks, services, and messages. It stops short of explicitly contrasting itself with any sibling, but no sibling overlaps this purpose.

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

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

Usage is implied (call this to learn who you act for, what you may do, and your budget) and the auth prerequisite 'Requires an agent token' is stated. There is no explicit when-to-use or when-not-to-use guidance and no named alternative.

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