legwork

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

With no annotations, the description carries the full burden. It discloses the key behavioral consequences: releasing escrowed budget and completing the task. This implies finality and irreversibility. It also emphasizes verification before approval, adding important context about the acceptable workflow.

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 sentences, front-loaded with the core action and followed by a critical precaution. No fluff or redundancy, every sentence earns its place.

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

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

For a simple mutation tool with one required parameter and no output schema, the description covers the main operation, its financial impact, and the essential verification requirement. It could mention return values or error handling, but these are not critical for basic usage given the tool's simplicity.

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 schema already documents api_key and feedback with descriptions. task_id lacks a description but its purpose is obvious from the context. The description adds helpful context about verifying criterion responses, which indirectly relates to task_id, but it doesn't elaborate on parameter usage beyond what the schema provides. With 67% schema coverage, the description provides minimal added parameter semantics.

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 tool's purpose: 'Accept submitted work: releases the escrowed budget to the human and completes the task.' It uses a specific verb (accept) and a specific resource (submitted work) and distinguishes from siblings like request_changes and cancel_task by indicating the completion action.

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 instruction 'Verify each criterion response (and open attachment URLs) first' provides clear contextual guidance on when to use this tool: only after verification. While it doesn't explicitly name alternatives like legwork_request_changes, the condition is clear enough to prevent misuse.

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

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

With no annotations, the description carries the transparency burden. It discloses important behavioral aspects: 'full refund' and allowed states, implying side effects and conditions. However, it omits details such as refund timing, reversibility, and failure behavior for disallowed states, leaving the agent to infer these.

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, front-loaded with the action verb. Every word contributes value, stating the operation, benefit, and conditions without 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?

For a cancellation/refund tool with no annotations or output schema, the description is fairly useful but incomplete. It includes the key constraint (allowed states) and outcome (full refund), but lacks details on refund processing, error handling, and whether the operation is reversible. This leaves some important ambiguity for an agent.

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 description adds no parameter-specific information beyond the schema. It only implies the task_id's role via 'Cancel a task', but does not explain its format or required values. The api_key has a schema description, but task_id lacks one, and the description does not compensate for that gap.

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

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

The description clearly states the action ('Cancel a task') and the outcome ('for a full refund'), making it distinct from sibling tools like legwork_approve or legwork_post_task. It also specifies the allowed states ('open, or claimed-and-overdue'), further clarifying the tool's scope.

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 provides clear context on when cancellation is allowed ('open, or claimed-and-overdue'), which guides use cases. However, it does not explicitly mention when not to use the tool or name alternatives like legwork_request_changes, so it lacks full exclusion guidance.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the side effect of a $10 fee credit and priority access, but does not explain what happens to declarations over time, whether they are mutable, or any operational limits. It is transparent about the benefit but not about underlying behavior.

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

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

The description is two sentences, front-loaded with the core purpose, and includes a concrete benefit. There is no unnecessary repetition or fluff; every sentence adds value.

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 the nested intents structure and no output schema, the description covers the core concept and benefits but omits details on how declarations are used, how to verify them, or any prerequisites. It is sufficient for basic understanding but not comprehensive for a tool with multiple nested parameters and side effects.

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% (only api_key has a description). The description lists the fields within intents (category, description, locations, cadence), which provides some semantics, but it does not elaborate on formats or constraints beyond the schema's enum for category. The description partially compensates for the missing parameter descriptions but not fully.

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 tool's function ('Pre-register the kinds of tasks you expect to post') with a specific verb and resource. It distinguishes from sibling tools like legwork_post_task by emphasizing pre-registration for future tasks, and highlights unique benefits (priority access, fee credit).

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 implies usage for planning future tasks and notes benefits, but it does not explicitly state when to use this tool over alternatives like legwork_post_task, nor does it provide exclusions or prerequisites. The context is clear but lacks explicit guidance on alternatives.

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

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

With no annotations, the description must carry the burden. It discloses that wait_seconds blocks and that it returns status, submissions, messages, and advice. It does not mention side effects (none expected), auth requirements beyond api_key (present in schema), or rate limits. Adequate but not exhaustive.

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 concise sentences, front-loaded with the main purpose and then usage parameters. No redundant or fluff content, every sentence earns its place.

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

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

The tool is fairly simple (read operation with polling). The description covers what is returned, the polling parameters, and the advice field. No output schema exists, so the description's enumeration of returned data is crucial and sufficient. Lacks details on error handling and output format, but acceptable for this 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 only 20% (api_key has a description). The description adds meaningful details for wait_seconds (max 55, blocking) and since_status/since_messages (from last look), which compensates for the sparse schema. It does not detail task_id, but that is 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 description clearly states the tool fetches a single task and lists specific components (status, submissions with evidence and URLs, message thread, advice field). This differentiates it from sibling tools like legwork_my_tasks (listing) and legwork_post_task (creation).

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 provides clear context for polling usage: wait_seconds to block, since_status/since_messages for incremental retrieval. However, it doesn't explicitly name alternatives or state when not to use it, though the context makes its role obvious.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by noting the data is 'Live' and that no authentication is required, but it does not explicitly state that the operation is read-only or describe any response behavior, limits, or side effects.

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

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

The description is a single, front-loaded sentence that conveys the core purpose and an important access trait. Every word earns its place with no redundancy or filler.

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

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

For a zero-parameter, low-complexity tool with no output schema, the description covers the essential context: what data is available, that it is live, and that no auth is needed. It does not detail output shape or pagination, but that is not critical for this simple marketplace stats tool.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies because there are no parameter gaps to compensate for.

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 identifies the tool as providing live marketplace stats and recent open tasks, which distinguishes it from siblings like legwork_my_tasks and legwork_get_task. It lacks an explicit verb, but the noun phrase is specific enough to convey the resource and scope.

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 implies usage for browsing marketplace-wide stats and open tasks, and 'No auth needed' gives a practical access note. However, it does not explicitly state when to choose this over alternatives or mention any exclusions, so usage guidance is only 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?

No annotations are provided, so the description must carry the burden. It does not explicitly state that the operation is read-only or mention any side effects, rate limits, or authentication requirements. As a listing tool, these aspects are somewhat implied, but explicit disclosure would improve transparency.

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 concise and well-structured, consisting of two clear sentences without unnecessary detail. It efficiently communicates the core functionality and a key use case.

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 the rich schema descriptions and lack of an output schema, the description provides sufficient context about the task listing. It mentions the relevance of submitted statuses, which adds value. However, it could be slightly more complete by noting any default behavior when no status filter is applied, but overall it is adequate.

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 schema already provides detailed descriptions for both parameters (status enum and api_key guidance). The description adds minimal extra value beyond noting that submitted tasks need review, which is more about context than parameter meaning. Thus, it meets the baseline for a well-described 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 clearly states the tool's function: listing tasks the user has posted, and it distinguishes this from sibling tools like approve or cancel. It also adds specific context about submitted tasks needing review, which reinforces its 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?

The description implies when to use this tool (to view your own tasks and identify those needing review) but does not explicitly contrast it with alternatives like get_task or marketplace. It provides enough context for typical use cases without direct comparison.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the budget goes entirely to the worker, is escrowed, includes a 15% platform fee (waived during beta credit), and releases on approval. It also explains that acceptance criteria are answered with evidence. This covers financial and workflow behaviors beyond the annotations (none exist), though it doesn't mention edge cases like cancellation or refunds (though deadline_hours schema touches on it).

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

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

The description is a single paragraph but front-loads the core action ('Hire a human: post a paid task'). It then efficiently covers budget mechanics, criteria, and timing. Each sentence adds value, though it's slightly verbose with parentheticals. It's well-structured for an MCP tool 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?

Given 8 parameters and no output schema, the description covers essential operational context: budgeting, fee, approval flow, criteria rigor, and human latency. It also points to the polling tool for follow-up. It doesn't detail return values, but that's not required since no output schema exists and the focus is on 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 description coverage is 75% (moderate, not >80%), so the description should add value. It does: it explains that budget includes a 15% fee and escrow, and it guides criteria writing ('individually verifiable checks'). It also frames the human timeline for deadline considerations. It doesn't cover api_key or location, but those are well-described in the schema. Overall, it enriches parameter understanding 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?

The description immediately states 'Hire a human: post a paid task to Legwork,' which is a specific verb (post) + resource (paid task) and clearly distinguishes this tool from siblings like legwork_get_task (poll) and legwork_approve (approve). It also names the platform and the action, making the purpose unmistakable.

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

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

The description gives explicit usage guidance: 'post early, keep working, then poll with legwork_get_task' and notes that humans take minutes-to-hours, indicating when to use this tool in a workflow. It references the polling tool but does not explicitly contrast with other task tools (e.g., legwork_marketplace) or list exclusion criteria, so it's strong but not fully exhaustive.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral facts: it is 'Instant', returns an 'api_key' that must be saved durably, waives fees in beta, and should be called once per project. This provides actionable context beyond the schema. Missing details like what happens on duplicate calls are minor because the one-time guidance mitigates that risk.

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 three sentences long, each earning its place: the first states the action, the second highlights the critical return value and storage instruction, and the third adds the beta waiver and usage frequency. Information is front-loaded and there is no redundant or vague wording.

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 registration tool with no output schema, the description covers the primary return value (api_key), operational guidance (save it, once per project), and the beta benefit. It stops short of describing error responses or how the api_key connects to sibling tools, but this is adequate for the tool's simplicity.

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 input schema has 100% coverage, with descriptions for all 5 parameters including the nested intents array. The tool description itself does not add parameter-specific meaning beyond what the schema already provides. Thus the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Create a Legwork agent account.' This clearly distinguishes it from sibling tools like legwork_post_task or legwork_wallet, which handle different operations. The purpose is unambiguous and directly 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?

The description provides explicit usage guidance: 'Do this once per project, not per session.' This is a clear frequency guideline and implies a one-time setup step. It also notes the beta fee waiver, which is an incentive for using this tool at the right time. No alternatives are named or needed since this is the sole registration tool.

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

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

No annotations are provided, and the description 'send back' implies a state change, but it does not detail side effects, reversibility, or required permissions. The description carries some burden but is not fully transparent.

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 sentences, providing the key information without fluff. It is well-structured and easy to parse.

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 description is concise but lacks context on the overall workflow, such as what happens after revision or how feedback is used. It does not explain the parameters, and the existence of many sibling tools suggests that more context could be helpful.

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

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

Schema coverage is only 33% (only api_key has a description). The tool description does not explain task_id or feedback at all, failing to compensate for the missing parameter descriptions. This is a significant gap.

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

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

The description clearly states that the tool sends submitted work back for revision with specific per-criterion feedback, which distinguishes it from sibling tools like approve or cancel. 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?

The description implies usage when revision is needed, but it does not explicitly differentiate from other actions such as post_task or send_message. It would benefit from stating when to use this over alternatives, but the intended use is still clear.

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

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

With no annotations, the description must carry behavioral info. It reveals that the tool is part of a back-and-forth conversation ('can ask clarifying questions') and hints at urgency ('answer promptly or the work stalls'). However, it omits details like whether the action is reversible, delivery guarantees, or rate limits. It adds some insight beyond a bare description, so a 3 is appropriate.

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 brief—two sentences totaling 27 words. It front-loads the core function ('Reply on a task's thread') and then adds context. It could be slightly tighter, but every word earns its place. No redundancy.

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 message-sending tool with only 3 parameters and no output schema, the description gives essential contextual insight about human interaction and responsiveness. However, it doesn't mention what happens after sending (e.g., will the agent get a response, any confirmation), and the motivational warning, while useful, doesn't replace practical details like 'the thread updates asynchronously'. Adequate for the complexity but not exhaustive.

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

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

Schema coverage is only 33% (only api_key has a description). The description does not explicitly describe 'body' or 'task_id', though the verb 'reply' implies body is the message content and task_id is the target. This is implied rather than stated, and no additional detail (formats, limits, behaviors) is provided, so the description fails to compensate for the low schema 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 uses the specific verb 'reply' and identifies the resource ('on a task's thread'), clearly indicating this tool sends a message on a task. It distinguishes itself from siblings like 'approve' or 'request_changes' by focusing on the reply action, even though it doesn't explicitly name alternatives.

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 implies when to use this tool: when the human working the task asks clarifying questions ('the human working your task can ask clarifying questions'). It provides a clear context for use but does not explicitly mention alternatives or when not to use it. The guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the burden. It states it creates a payment link and returns a URL, and mentions sandbox behavior. However, it doesn't disclose whether this operation has side effects (e.g., if credits are actually added immediately), if it requires special permissions beyond the API key, or if it's reversible. The mention of sandbox adds some transparency.

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 concise sentences that clearly state the purpose and output. No fluff or redundant details.

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 tool with 2 parameters and no output schema, the description is fairly complete. It explains the purpose, the primary output (Stripe Checkout URL), and sandbox behavior. However, it doesn't mention details like whether the URL expires, rate limits, or prerequisites, but these are not critical for basic selection.

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% (only api_key has a description). The description does not explain the semantics of 'amount_usd' (e.g., format, range, required) beyond implying it's the amount to top up. It also doesn't clarify that api_key is optional in some contexts. Given the low coverage hug, the description fails to compensate.

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 tool creates a payment link for adding credits, with a specific verb ('Create') and resource ('payment link'). It also mentions the output (Stripe Checkout URL) and differentiates itself from sibling tools by being the only one about payments.

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 implies the tool should be used when the user wants to add credits and provides a clear context: it returns a Stripe Checkout URL to hand to the principal. It also mentions sandbox behavior, giving conditional guidance reti, but doesn't explicitly state when not to use it or alternative 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?

There are no annotations, so the description carries full responsibility for behavioral disclosure. It conveys that the tool exposes balance and ledger information and that topping up belongs elsewhere, but it does not state that the operation is read-only, describe the response shape, or mention any side effects. This is insufficiently transparent for safe tool selection.

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 wasted words. The first sentence front-loads the purpose, and the second sentence earns its place by pointing to the relevant sibling tool for credit additions.

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, single-optional-parameter wallet tool with no output schema and no annotations, the description gives the core idea and links the main sibling. However, it omits explicit read-only status and return-value expectations, leaving it only minimally 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?

The single parameter 'api_key' is fully documented in the schema, including its format, optional nature via Authorization header, and where to obtain it. The description adds no parameter-level meaning, so the baseline of 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 clearly identifies the tool as a wallet resource ('Your credit balance and ledger') and differentiates it from the related 'legwork_topup' tool by directing credit-add actions there. However, it lacks an explicit action verb like 'view' or 'get,' so it stops short of being maximally precise.

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 provides an explicit when-not-to-use signal: 'To add credits: legwork_topup.' This distinguishes wallet from a key sibling. It does not explicitly state when to check the wallet versus other status tools, but the balance/ledger framing makes the primary use case clear.

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