0bull Phone Farm

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

Annotations are empty, so the description carries the full burden. It discloses the key side effect (stops driving the phone between steps) and the no-op behavior for not-yet-started jobs. It does not clarify the end state of the submission record (deleted, marked cancelled, etc.), but the disclosed behavior is valuable beyond the name.

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

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

Two sentences, zero fluff, and the core action is front-loaded. The behavioral clarification follows naturally. Every word earns its place.

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

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

For a simple one-parameter tool with no output schema, the description covers the action and key behavior. It omits error conditions (e.g., submission not found, already completed) and return values, but those are less critical for a cancellation operation. Overall, it is adequately 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 100% and the schema already explains the parameter ('ID of the submission to cancel, on any platform'). The description adds no extra semantic detail beyond what is in the schema, 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?

Clearly states the specific verb 'cancel' and resource 'video submission', names the supported platforms (TikTok, Instagram, YouTube), and distinguishes from siblings by focusing on the cancellation of queued/in-flight jobs. The description adds nuanced behavior (no-op for not-started) that makes the tool's purpose 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?

Provides clear context for when the tool applies (queued or in-flight submissions) and explicitly states the not-yet-started case no-ops, which is a de facto exclusion. However, it does not explicitly compare to alternative tools like delete-submission or mention when to use them instead, so it stops short of full 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, the description carries the behavioral burden. It discloses that this is a linking operation, not an external account creation, and states the key precondition that the account must already be signed in on the phone. It could mention response/return behavior or duplicate-link side effects, but the core behavioral traits are 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?

Two tight sentences, front-loaded with the core action and default platform, followed by the key prerequisite and platform-specific caveat. No filler or redundant 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 5-parameter tool with no output schema, the description plus full schema coverage gives an agent everything needed to call the tool correctly: prerequisite, platform defaults, and required google_email for YouTube. An explicit note about the success/failure response would round it out, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces platform default and google_email requirement, but these are already stated in the schema property descriptions. It adds no new parameter-level meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Link a posting account for the authenticated user' on TikTok, Instagram, or YouTube. It also disambiguates the tool's name 'create-account' by clarifying it links an already-existing account rather than creating one, distinguishing it from sibling account tools like delete/update/list/get.

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

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

The description gives clear usage context: the platform defaults to tiktok, the account must already be signed in on the phone slot, and YouTube requires google_email. It lacks explicit 'when not to use' or named alternatives, but the prerequisites and platform-specific conditions are enough for an agent to invoke it correctly.

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 empty annotations, the description carries the behavioral burden. It discloses that the tool queues a video for publication, that video_url is a public link the server downloads, and that platform defaults to tiktok. However, it does not describe the return value, whether draft mode is supported, or what happens if preconditions like phone assignment fail.

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 compact and front-loaded: it states the core purpose first, then the key parameters, then the critical precondition. Every sentence contributes necessary information, and there is no filler or redundant restatement of the tool title.

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

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

For a creation tool with no output schema and no annotations, the description omits the response shape and does not mention the draft parameter or how to obtain account_id. The schema covers parameter documentation well, and the workflow is clear, but an agent still lacks full insight into what happens after queueing or how to verify 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%, so the baseline is 3. The description adds genuine value by clarifying that upload_id comes from create_upload_url, that video_url is server-downloaded, and that exactly one video source must be supplied. It also reinforces the platform default, going slightly beyond the schema descriptions.

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: 'Queue a video to be published to a TikTok, Instagram or YouTube account.' It clearly distinguishes this from sibling tools like create-upload-url-tool, which only creates upload URLs, and from submission lifecycle tools like cancel-submission-tool.

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 explains the core publishing flow: set platform and account_id, and provide the video via exactly one of video_url or upload_id, explicitly referencing create_upload_url for the latter. It also states a hard precondition ('The account must be assigned to a phone'). It does not explicitly name when not to use this tool versus sibling submission-management tools, but the creation intent is 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 carries the full disclosure burden. It reveals the time-to-live, the allowed upload methods, the payload format, and the downstream dependency on upload_id. It does not mention authentication requirements or what happens after expiration, but the core behavior is transparently disclosed.

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 entire description is one efficient sentence. The core purpose and primary condition are front-loaded, followed by necessary operational details. No filler words or redundant explanations are present.

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 tool with no output schema, the description covers the full lifecycle: why to use it, what to do with the returned URL, how long it remains valid, and what to pass to the next tool. It does not explicitly list response field names, but references them naturally enough for an agent to use them 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?

The tool has zero parameters, so there is no parameter semantics to clarify in the schema. The description adds value by explaining the returned artifacts (upload_url and upload_id) and how they should be used, which is sufficient for this parameterless tool.

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 action ('Mint'), a precise resource ('short-lived signed URL for uploading a video directly'), and an explicit condition ('when you do not have a public video_url'). It clearly differentiates itself from create_submission by describing this tool as a prerequisite step in that workflow.

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 explicitly states when to use the tool: only when no public video_url exists. It also provides concrete usage steps, including the HTTP methods (POST/PUT), accepted payload formats (raw video or multipart 'video' field), the 15-minute expiry, and the requirement to pass upload_id to create_submission. This leaves little 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?

With no annotations, the description carries the full burden and does useful work by scoping the destructive effect to the farm account only and clarifying that the platform account is untouched. It also states the authorization precondition ('authenticated user is allowed to manage'). It does not disclose irreversibility or downstream effects on submissions, but the core behavioral boundary is clearly communicated.

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 no filler. The primary action and scope are front-loaded, and the critical caveat about not deleting the platform account is in the second sentence. 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?

For a one-parameter delete tool with no output schema, the description is largely complete: it states the target resource, authorization scope, supported platforms, and the key non-effect. The main gaps are unspecified consequences or return behavior after deletion, but given the low complexity, these are minor rather than blocking.

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 the schema already documents account_id. The description adds the platform list (TikTok, Instagram, YouTube) and the 'allowed to manage' constraint, which gives slight extra context. However, it does not explain where to find the ID or any ID format expectations, so the added value beyond the schema is modest.

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

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

The description names a specific verb and resource ('Delete a posting account') and adds the exact scope: authenticated-user-managed accounts across TikTok, Instagram, or YouTube. This clearly differentiates it from sibling tools like delete-submission-tool and update-account-tool without needing to inspect their schemas.

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

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

The description gives clear context for when to use the tool: deleting a managed posting account from the farm. It also states an important exclusion ('does not delete the account on the platform itself'), which prevents misuse. It does not explicitly name alternative tools, but the resource-level clarity makes the intended use 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 disclosure burden and it discloses the destructive scope well: it deletes both the submission and its stored video, and it clarifies that in-flight submissions are off-limits. It does not mention irreversibility, permissions, or side effects beyond the stored video, but the core behavior is clearly and honestly stated.

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 contain all essential scoping information with no filler. The primary action and resource are front-loaded, and the key exclusion is stated immediately after.

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, no-output-schema delete tool, the description covers the action, eligible states, platforms, and the critical in-flight constraint. It is slightly incomplete because it does not explicitly direct the agent to cancel-submission-tool for in-flight submissions or describe the result of a successful deletion.

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 the baseline is 3; the schema already documents submission_id as the ID of the submission to delete on any platform. The description adds mild semantic value by specifying which submission states are eligible, but it does not add syntax, type, or format 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?

The description states a specific verb ('Delete'), a precise resource ('finished video submission and its stored video'), and enumerates the eligible statuses and supported platforms. It also draws a clear boundary against in-flight submissions, which distinguishes it from the sibling cancel-submission-tool.

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 clearly indicates when this tool is appropriate: for published, drafted, failed, or cancelled submissions on any supported platform. It explicitly warns that in-flight submissions cannot be deleted, but it does not name the alternative (cancel-submission-tool) for that case, so the routing guidance is not fully explicit.

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

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

Annotations are empty, so the description carries the behavioral burden. It adds one useful constraint: only accounts the authenticated user is allowed to view are returned. It does not mention that the operation is read-only, what happens on unauthorized access, or return/error behavior, but for a simple fetch-by-ID this is moderate disclosure.

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 sentence with no wasted words. The core action, scope, and platform coverage are all front-loaded efficiently.

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 fetch tool with no output schema and no annotations, the description covers what is fetched, who may view it, and which platforms are supported. It does not describe the returned account shape or failure modes, but the low complexity and complete parameter schema mean little is missing for a correct call.

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 the schema already documents account_id. The description repeats the 'on any platform' nuance from the schema but adds no meaningful parameter-level semantics beyond that, so the baseline score 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 states a specific verb ('Fetch'), a clear resource ('a single posting account'), and the access scope ('the authenticated user is allowed to view'). It also names the supported platforms (TikTok, Instagram, YouTube), which distinguishes it from sibling create/update/delete/list account tools without needing to inspect their schemas.

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

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

The description clearly indicates this is for fetching one account by ID, and the word 'single' implicitly differentiates it from list-accounts-tool. However, it does not explicitly state when to prefer an alternative or provide exclusion conditions, 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?

Annotations are empty, so the description must disclose behavioral traits. It does list the possible return statuses (pending, approved, declined, failed, expired), which is useful. However, it does not state whether the operation is read-only, any side effects, error handling, or auth requirements. For a simple status check, this is 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?

A single sentence that front-loads the purpose, then immediately provides the output states. Zero waste and perfectly sized for the information content.

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

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

For a tool with one parameter, no output schema, and no annotations, the description covers the essential purpose and return values. It omits details like error conditions or response structure beyond status, but those are minor for a status-checking 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 100% and the parameter description already explains the request_id as 'The `request_id` request-phones-tool returned.' The tool description adds no further parameter detail, so it meets the baseline without exceeding it.

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 specific verb 'Check' with the resource 'billing request' (a phone-count change) and explicitly ties it to request-phones-tool, distinguishing it from any generic status tool. The returned statuses are enumerated, leaving no ambiguity about what the tool does.

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 specifies the context (checking approval of a phone-count change filed by request-phones-tool) and names the source tool. It does not explicitly list alternatives or when not to use it, but the scope is clear enough that an agent can infer it is for this specific follow-up.

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 are empty, so the description carries the full behavioral burden. It declares the operation is a read, explains that pending orders defer charging until assignment, and describes the per-phone monthly renewal cycle. This gives an agent an accurate model of side effects and internal billing semantics, though it stops short of mentioning authentication requirements or failure 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?

Three sentences with no wasted words: the first gives the summary, the second explains the billing model required to interpret the result, and the third supplies the usage directive. Information is front-loaded and each 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?

For a parameterless read tool with no output schema, this description covers the essential return semantics (phone count, cost, renewal dates, pending orders) and the special billing model (separate monthly cycles, deferred first-month charge). Nothing critical is missing for an agent to invoke and interpret the tool 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?

There are zero parameters, so the baseline is 4. The description provides no parameter documentation because none is needed, but it compensates by explaining the shape and meaning of the returned data (`lines` and `pending_orders`), which is the only semantic information an agent needs.

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 ('Read'), a precise resource ('the authenticated user's phone rentals'), and enumerates concrete outputs: device count, cost, renewal dates, and unassigned orders. It also clarifies the conceptual model (per-phone subscriptions, pending orders), making it clearly distinguishable from sibling tools.

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

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

The closing instruction, 'Start here before proposing any billing change,' explicitly tells an agent when to call this tool first. It does not enumerate exclusions or compare directly with get-billing-request-tool, but the contextual guidance is clear enough for the main use case.

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 are empty, so the description carries the full burden. It only says 'get one visible phone run' without disclosing return format, handling of missing run IDs, or the meaning of 'visible'. No side effects or safety notes are provided, and there is no contradiction with annotations (which are empty).

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, clear sentence with no wasted words and is front-loaded with the core action. It conveys the essential information efficiently, earning a high score.

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 retrieve-by-id tool with two parameters and no output schema, the description is functionally adequate. However, it omits context around the 'visible' qualifier and error behavior, which could matter when the agent invokes it. Given the low complexity, a mid-range score is fair.

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% with descriptions for both slot and run_id. The description adds no extra semantic context beyond what the schema provides (e.g., it doesn't explain that slot refers to a phone from list-phones, which the schema already does). Baseline 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 states a specific verb ('Get') and resource ('visible phone run') with a clear scope ('one' and 'by its run id'). It differentiates from list-phone-runs-tool which would list multiple runs, so an agent can easily distinguish this from siblings.

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 use this tool versus alternatives like list-phone-runs-tool. The description does not mention any prerequisites or conditions for selection, leaving the agent to infer that this is for a specific known run ID.

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 empty annotations, the description carries the full behavioral burden. It discloses permission scope ('authenticated user is allowed to view'), single-item scope, and frames the call as polling, which implies safe repeated reads. It doesn't explicitly state 'no side effects', but 'fetch' and 'poll' are strong non-mutating signals.

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

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

Two sentences, zero filler. The first sentence front-loads the core operation and scope; the second supplies the intended use case. Every clause earns its place and the whole text is easy to scan.

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 one-parameter get tool with no output schema, the description is nearly complete: it states what is fetched, under what authorization, on which platforms, and for what purpose. It stops short of describing the return fields, but the phrase 'publishing outcome' already signals the relevant content. A brief return-format note would push this to 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 schema covers the single parameter 100% with its own description ('ID of the submission to fetch, on any platform'). The tool description adds minimal new meaning beyond that, mainly reinforcing the cross-platform aspect. Baseline 3 is appropriate because the schema does the parameter documentation work.

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 ('Fetch'), a concrete resource ('a single video submission'), and clear scope ('the authenticated user is allowed to view'). It also disambiguates from list and mutation siblings by emphasizing single-fetch semantics and naming the supported platforms. This is immediately actionable for an 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?

The description gives a clear use context: 'Use it to poll a submission for its publishing outcome.' This tells the agent when to invoke it. It does not explicitly name alternative tools or exclusions, but the distinction from list/cancel/delete submission tools is strongly implied.

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

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

With empty annotations, the description carries the behavioral burden. It discloses authentication scope, ordering ('newest first'), page size ('50 per page'), and the default 'every platform is included' behavior. It does not mention errors or output shape, but 'List' clearly implies a non-mutating read operation.

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 with no filler. The first sentence front-loads the action, resource, platforms, ordering, and pagination; the second clarifies platform-filter behavior. 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?

This is a low-complexity list tool with zero required parameters and a fully described schema. The description covers authentication scope, platforms, ordering, pagination, and the default platform behavior – everything an agent needs to invoke it correctly. Since no output schema exists, the implicit return of account objects is acceptable for a list 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 schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds value by stating the global ordering ('newest first') and the '50 per page' behavior, which complements the `page` parameter description and clarifies the `platform` omission behavior.

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

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

The description states a specific verb ('List'), a clear resource ('the authenticated user's posting accounts'), and explicitly names the three platforms covered. The plural 'accounts' and pagination scope distinguish it from singular account tools like get-account-tool, and the verb clearly separates it from create/update/delete siblings.

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

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

The description makes the tool's purpose obvious: retrieve a paginated list of posting accounts. It gives functional guidance on when to narrow to one platform via the `platform` parameter. However, it does not explicitly contrast with get-account-tool for single-account lookups or other list tools, so it falls short of a 5.

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

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

With empty annotations, the description carries the burden of disclosure. It mentions auth scoping, per-phone filtering, and sort order, which is good. It does not disclose pagination behavior or what the returned run objects look like, leaving gaps for a tool with no output 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 dense sentence with no filler. The verb, scope, and order are front-loaded, making it easy to scan.

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 list operation, the description covers the essential invocation context (auth, one phone, ordering). However, since there is no output schema, the lack of any hint about the return shape or pagination limits leaves some uncertainty. Overall it is minimally viable with clear gaps.

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

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

Schema description coverage is 100%; both page and slot are documented there. The description adds only the 'one phone' context, which reinforces the slot parameter. This meets the baseline for schema-covered parameters.

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 a specific verb and resource ('List the phone runs'), and scopes it to 'authenticated user' and 'for one phone', which differentiates it from list-phones and get-phone-run. The ordering 'newest first' adds useful detail. This is clear and non-tautological.

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 context (authenticated, one phone) but does not name alternatives or state when not to use it. The slot schema reference to 'list-phones' is helpful but lives in the schema, not the description. Usage 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?

With no annotations, the description must carry the behavioral disclosure burden. It adds useful context beyond the schema: results are scoped to the authenticated user and include live video and session state. However, it does not mention pagination, empty-result behavior, or any limits or caveats around the 'live' data.

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

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

A single compact sentence front-loads the action, resource, scope, and returned content. Every word earns its place, with no redundancy or restatement of the tool title.

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

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

For a zero-parameter tool with no annotations and no output schema, the description gives a reasonable high-level picture of the result but leaves the exact return shape and edge cases unspecified. It is adequate for basic invocation, yet an agent would need more detail to confidently parse 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?

The input schema has zero parameters and 100% schema description coverage, so there is nothing for the tool description to add. The baseline for a zero-parameter tool applies, and no parameter detail is 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?

The description states a specific verb ('List'), a clear resource ('farm phone slots'), a scope ('the authenticated user can view'), and the included data ('live video and session state'). It also distinguishes itself from sibling tools like list-phone-runs-tool by targeting current slots rather than run history.

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 use when an agent needs the phone slots visible to the current user, but it does not explicitly contrast with sibling tools or state when not to use it. No alternative routing is provided, so usage guidance remains implicit 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?

With no annotations, the description carries the behavioral burden, and it does well: it states ordering (most recent first), page size (50), default behavior (all platforms), and the effect of the platform filter. It does not explicitly say 'read-only' or describe the response shape, but 'List' strongly implies a non-mutating operation.

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 with no filler. The core action and scope are front-loaded, and the platform-filter nuance is stated in the second sentence. Every clause contributes useful 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 low-complexity list tool with two optional parameters and no output schema, the description is complete: it covers scope, ordering, pagination, default behavior, and filtering. An agent has enough context to invoke it correctly without needing to infer hidden behavior.

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

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

Schema description coverage is 100%, so the description is not required to carry parameter documentation. It adds useful behavioral context such as 'most recent first' and '50 per page,' but mostly restates what the schema already says about platform omission and page defaults. This meets the baseline for schema-covered parameters without adding substantial new 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?

The description names a specific action and resource: listing the authenticated user's video submissions across TikTok, Instagram, and YouTube. It also adds sorting and pagination details, and the platform-scope statement clearly distinguishes it from single-item or mutation siblings like get-submission-tool or create-submission-tool.

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

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

The description gives clear context for when to use the tool: for the authenticated user's own submissions, latest first, with optional single-platform narrowing. It does not explicitly name alternatives or say 'use get-submission for a single record,' but the list-vs-get distinction is clear enough from the sibling names.

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 full behavioral disclosure. It explains that the tool returns a run id, that the run succeeds only after the phone executes the command, and that get_ip and clipboard_get return result.value. It also notes op-specific fields are only sent when provided, which is important. It does not mention error handling or side effects beyond the listed ops, but the ops themselves (e.g., reboot, clear_photos) are self-evidently destructive.

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 efficiently structured with a clear purpose, a compact list of operations, and a concise note on return behavior. It front-loads the core action and does not waste words, though the op list could be considered slightly long.

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 covers the essential return behavior (run id and result.value for specific ops), the slot requirement, and all operations. It does not elaborate on error cases or timeouts, but for a command tool with no output schema, it provides sufficient context 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 100%, so the baseline is 3. The description adds value by mapping each op to its relevant parameters (text, url, level, on) and clarifying that these fields are only transmitted when provided. This goes beyond the schema's individual parameter descriptions and helps the agent understand conditional usage.

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 sends a device command to a farm phone and enumerates specific supported operations. This makes the purpose unambiguous and distinct from siblings like phone-ocr-tool or phone-snapshot-tool, though it does not explicitly reference 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 provides a critical precondition (the slot must be cast/live) and lists operations, implying when to use the tool. However, it does not explicitly contrast with sibling tools like phone-control-tool or state when not to use this tool, leaving some inference to the agent.

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 full transparency burden. It discloses that execution is synchronous ('the call returns once farmd acks'), defines the coordinate system (fractions 0..1), and enumerates the available ops with their effects. It stops short of describing error handling or rate limits, but the core behavior is well 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?

The description is compact and front-loaded with the core purpose, followed by the critical distinction from phone_command and coordinate rules. The ops are presented as a readable bullet list. Every sentence contributes; there is no filler.

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

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

For a tool with 11 parameters, no output schema, and no annotations, the description covers the essential operational knowledge: the required slot state, the op types, coordinate semantics, and synchronous execution. It does not specify the return value format or error scenarios, but for a raw-input tool these are secondary and partly implied by the ack statement.

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 the baseline is 3, but the description adds real semantic value beyond the parameter descriptions: it explains that coordinates are fractions of screen dimensions (0 = left/top, 1 = right/bottom), clarifies each op's parameter mapping (e.g., swipe start/end points, steps controlling gesture speed), and gives the default for steps. This helps the agent construct correct parameter combinations.

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 ('Send a raw input primitive to a farm phone') and explicitly distinguishes itself from sibling phone_command by contrasting queue-based shortcuts with direct farmd socket ops. An agent can immediately understand what this tool does and how it differs from its closest alternative.

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 explicitly says 'Unlike phone_command (which queues an on-phone Shortcut), these are direct farmd socket ops and run synchronously', giving a clear when-to-use-this-vs-that. It also states a precondition ('The slot must be cast/live') that an agent must check 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?

With no annotations, the description carries the full disclosure burden. It explicitly states the operation is read-only, that it snapshots the slot, and that the slot must be cast/live as a precondition. It does not cover error behavior or exact output formatting, but for a low-risk read operation this is adequate.

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 short and front-loaded, leading with the main purpose and then stating the key precondition. Every sentence earns its place and there is no redundancy with the 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?

The description covers purpose, primary output, read-only behavior, and the critical precondition, which is enough to invoke the tool correctly. Since there is no output schema, mentioning that it returns OCR-recognized text is important and included. It could have explicitly referenced phone-snapshot-tool as an alternative, but that is not necessary 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 100%, so the schema already documents both parameters. The description adds value by clarifying that 'slot' must be the UUID from list-phones and that display names like 'slot12' are not accepted, which is not present in the schema. Width remains self-explanatory and optional.

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 a specific verb and resource: 'Read the on-screen text of a farm phone' and explains it snapshots the slot to return OCR-recognized text. This clearly distinguishes it from sibling tools like phone-snapshot-tool, which would return an image rather than recognized 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?

The description gives clear usage context: use this when you need OCR text from a phone screen. It also provides the important precondition that the slot must be cast/live. It does not explicitly name alternative tools or exclusion cases, but the intended use is clear enough among the 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?

With no annotations available, the description carries the burden of behavioral disclosure. It does disclose a key behavioral constraint (the slot must be cast/live) and the output type (JPEG snapshot), but it does not explain failure modes, permissions, or side effects. This is adequate for a simple read-style capture but 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 short sentences with no filler. The key action is front-loaded, and the critical prerequisite follows immediately. Every word earns its place.

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

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

For a simple tool with only two parameters and no nested objects, the description plus the fully covered schema is nearly complete. It lacks explicit failure behavior or output format details, but the mention of 'JPEG snapshot' partially covers the output, and no output schema exists to supply the rest.

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 the schema already documents both parameters. The description adds no new parameter semantics beyond restating the cast/live requirement for `slot`, which is also in 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 clearly states a specific action ('Capture a JPEG snapshot') and a specific resource ('a farm phone screen'). It is distinct enough from siblings like phone-command-tool and phone-ocr-tool, though it does not explicitly differentiate itself from 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?

The description gives an important precondition ('The slot must be cast/live'), which tells the agent when the tool can be used. However, it provides no explicit guidance on when to choose this tool over alternatives like phone-ocr-tool or phone-command-tool.

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

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

Annotations are empty, so the description carries the full disclosure burden. It delivers: async-only behavior, approval link, immediate-application exception, `applied: true` semantics (order placed and hold, not charge), card-decline outcome, and a required terms-consent step. This is exemplary 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 dense yet every sentence earns its place: core purpose, examples, async behavior, exception, financial semantics, and required consent. It front-loads the action and examples before edge cases, and there is no filler.

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

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

For a tool with no output schema and no annotations, the description covers invocation semantics, return-link behavior, follow-up action, conditional immediate application, authorization flow, card handling, and required user consent. Nothing essential is missing for correct selection and calling.

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 already 100%, but the description adds value with natural-language usage examples, the additive vs. total-distinction, mutual exclusivity implied by examples, and the significance of `applied: true` for interpreting the result. It enriches rather than repeats 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 action ('Change how many phones the rental covers') tied to a clear resource, then gives concrete examples (`add: 1`, `add: -2`, `phones: 5`). This makes it clearly distinct from sibling tools like start-rental-tool or phone-control-tool.

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?

Describes when the change is only filed versus applied immediately (standing allowance), explicitly instructs polling get-billing-request-tool for approval, and mandates accept_terms before calling. It lacks an explicit 'use start-rental-tool for initial rentals' exclusion, but the provided context is strong.

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 behavioral burden. It meaningfully discloses that runs are queued, return immediately, and may take minutes, plus instructs the agent to poll the phone or account for the outcome. It does not cover failure modes or response 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?

The description is well-structured, front-loads the key constraint, and uses a compact bullet list for the mutually exclusive options. It earns its length, though it somewhat duplicates schema text.

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 4-parameter async tool with no output schema or annotations, the description covers the essential invocation constraints, the two modes, and what to do after calling. It does not state what the immediate return value is, which is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds some context (registry resolution, scalar params, steps needing an 'action'), but this is largely redundant with 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 clearly states the tool runs a step list on a farm phone and distinguishes the two input modes (workflow vs steps). It does not explicitly differentiate from sibling tools like run-phone-agent-tool, so it misses the top of the scale.

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 clear preconditions ('slot must be cast/live') and an explicit exclusivity rule ('Give exactly one of workflow or steps'). However, it does not say when to choose this tool over alternatives or 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?

With no annotations, the description carries the behavioral disclosure burden. It clearly states the key async contract: 'the call only acks the start; the agent streams progress separately.' This is meaningful beyond the name and schema. It does not cover failure modes, cancellation, or permissions, but the core invocation behavior is 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 definition is two sentences with no filler: the first states purpose, the second states the async execution contract. Both parts of the second sentence add necessary behavioral information. It is front-loaded and easy to scan.

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 async contract is described, which matters because there is no output schema. However, the description does not point to get-phone-run-tool or list-phone-runs-tool for observing the streamed progress, nor does it clarify what 'narrow task' excludes. For a 2-parameter async tool this is adequate but leaves meaningful gaps.

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

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

Schema description coverage is 100%, and the schema already gives detailed meaning for both parameters: slot must be a UUID from list-phones and must be cast/live, while task is a plain-language instruction. The description adds only the 'narrow task' qualifier, which is modest extra semantics. Baseline 3 is appropriate because the schema carries the parameter documentation load.

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 first sentence names a specific action ('ask ... to carry out') and resource ('on-phone GUI agent,' 'farm phone'), making the tool's purpose clear. It does not explicitly contrast with siblings like run-macro-tool or phone-command-tool, but 'GUI agent' and 'narrow task' provide enough differentiation. 'Narrow' is somewhat vague but not misleading.

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 sibling alternatives are named or excluded. The phrase 'narrow task' implies a scope limit, but the description does not say to prefer get-phone-run-tool for checking results or phone-command/run-macro for scripted operations. An agent selecting among the many phone-related siblings must infer placement.

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 are empty, so the description carries the full burden — and it does so well. It discloses that nothing is charged at link creation (card saved, one month per phone held), that charging happens later either when an admin assigns phones or when an admin confirms fulfillment, and that monthly renewal charges apply until cancellation. It also surfaces the consent requirement. Minor undisclosed aspects: behavior on cancellation, refunds, or a stale/expired checkout link.

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

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

The description is dense at roughly 130 words, but every sentence is load-bearing for a financial tool: flow, parameter routing, consent prerequisite, and follow-up. It is front-loaded with the core purpose in the first sentence. The length is justified by the monetary side effects it must disclose, and there is no filler.

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

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

For a four-parameter tool with no output schema and no annotations, this description covers the full lifecycle: what happens at call time, the payment hold, the admin-assignment delay, the prerequisite, and the recommended polling follow-up. The output is at least identified as a link to hand to the user. A residual gap is the absence of explicit error/edge-case behavior (invalid country, failed checkout, cancellation), but nothing critical for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the either/or relationship between `phones` and `items` ('Ask for one country with `phones`... or spread the order across several with `items`'), and by clarifying the financial semantics of quantity ('holds one month per phone'). This routing logic and the per-phone cost implication are genuinely useful.

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+outcome: 'Order phones by returning a Stripe Checkout link.' It then explains the asynchronous flow (admin assigns phones, held amount charged on assignment), which makes the tool's role unmistakable. It does not explicitly distinguish itself from siblings like request-phones-tool or create-submission-tool, though its payment/Stripe Checkout framing makes it identifiable.

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 routing guidance: use `phones` (+ optional `country`) for a one-country order versus `items` to spread across several countries. It states the mandatory prerequisite (accept_terms must be true, with the exact terms URLs and the consent requirement) and the follow-up action ('poll get-billing-tool'). It lacks explicit when-not-to-use guidance against sibling tools, but the parameter-selection and prerequisite guidance is concrete and actionable.

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 full burden of behavioral disclosure. It clearly states that only supplied fields are changed and that the platform cannot be altered, which are key behavioral traits not evident from the schema alone. It could go further (e.g., mentioning error cases or permission failures), but the essential behaviors are 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?

Two sentences with no redundant words. The purpose is front-loaded, and the key constraint (platform immutability) is placed at the end. Every word contributes to the meaning, making it concise and well-structured.

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 relatively simple update tool with no output schema and no annotations, the description covers purpose, platform scope, partial-update behavior, platform immutability, and permission context. It omits response format and error handling, but these are less critical for a tool of this complexity, and siblings like get-account/list-accounts can supplement.

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 descriptions cover all 5 parameters (100% coverage), so the schema already explains each parameter's meaning. The description adds a general semantic note about partial updates but does not enhance any specific parameter beyond the schema. Baseline 3 is appropriate given the high 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 states a specific verb ('Update'), a resource ('a posting account'), and explicitly lists the platforms (TikTok, Instagram, YouTube). It distinguishes itself from create/delete/list siblings by clarifying that the platform cannot be changed here and that only supplied fields are modified, making it unambiguously an update 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?

It provides context on when to use the tool: for accounts the authenticated user is allowed to manage, and it notes the partial-update behavior ('Only the supplied fields are changed'). It does not explicitly name alternative tools (e.g., 'use create-account for new accounts') but the purpose and constraint effectively route an agent to use this for updates rather than creation or deletion.

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