Ucode SMS

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

Annotations already carry the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds genuinely useful behavior: 'No login' discloses that no auth is required, and it clarifies the payment rail is USDC on Base. It stops short of noting caching, pagination, or freshness of pricing.

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 compact clauses, each earning its place, with the effort-free entry point ('No login') front-loaded. The markdown bold around the sibling tool names is mildly noisy but does not bloat the 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 zero-parameter read-only listing with an output schema, the description supplies everything an agent needs: audience, currency and chain, the follow-up purchase tool, and the human alternative. Return values are correctly left to the output schema.

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

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

The tool takes zero parameters, which sets the baseline at 4. The parenthetical (packageId, credits, usd, payTo) describes the shape of each returned pack, which is helpful context even though an output schema exists.

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

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

States a specific verb ('Lists') and resource ('prepaid credit packs priced in USDC on Base') plus the intended caller ('autonomous agents/bots'), so the agent knows exactly what it returns. It is clearly differentiated from its siblings by naming the purchase tool and the human-facing 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?

Explicitly covers when to use it (agent/bot, no login), what to do next ('Buy one with ucode_agent_buy_credits'), and the exclusion case ('Signed-in humans pay by card ... instead (ucode_render_credits)'). Both the action alternative and the audience routing are stated, leaving nothing 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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), it discloses that no account or card is needed, that the first call returns PAYMENT_REQUIRED with x402 requirements, that credits are added on the second call, and that the uc_live_ API key is shown only once but stored for the session. That is substantive behavioral context a mutation tool needs.

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?

Front-loaded with the outcome and protocol, then the two steps in order, then the pack source and the spend constraint. Every clause carries actionable information; nothing is padding.

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

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

Even with no output schema, the description covers the returns (PAYMENT_REQUIRED payload, uc_live_ key shown once) and the full call flow, which is everything an agent needs to invoke a paid, two-phase 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?

Schema description coverage is 100%, so the schema already documents all three parameters, including that pack accepts packageId or starter/plus/pro aliases and that acceptLawfulUse must be true. The description restates the same semantics and mainly adds workflow ordering rather than new per-parameter meaning, so baseline 3 is correct.

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

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

States a specific verb+resource (buy a prepaid credit pack) plus the payment rail (USDC on Base via x402), which cleanly separates it from the stripe/nowpayments credit siblings. An agent can identify the tool without opening the schema.

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

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

Spells out the exact two-step call sequence (first without paymentHeader, then with the signed header), points to ucode_agent_billing as the source of pack ids, and adds the governance rule 'Only spend what the user approved.' When-to-use and prerequisites are both explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state; the description adds value beyond that by disclosing the refund effect on the wallet and the uc_live_ API key requirement. It still does not state whether the cancellation is reversible or what happens to an already-received SMS/code.

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

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

Two short sentences, front-loaded with the action and trigger, with no filler. Every clause carries information the agent needs.

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

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

Covers the trigger, the credit-refund outcome, and the auth requirement, which is reasonable for a mutation tool without an output schema. It is nonetheless incomplete on the parameters and on how to pick this tool over ucode_sms_cancel_rental.

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

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

Schema description coverage is 0% and none of the three parameters (id, reason, reasonNote) are explained in the description. The phrase "when no SMS arrived" loosely hints at the code_not_arrived enum value but never names it or clarifies what id refers to (rental id?), so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ("Cancel an agent rental") and adds the financial effect ("credits return to the agent wallet"), which is more than a restatement of the name. However, it does not distinguish itself from the near-identical sibling ucode_sms_cancel_rental, leaving the agent to guess which cancel tool applies.

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 a triggering condition ("when no SMS arrived"), which implies usage context, but gives no explicit exclusions or alternatives despite ucode_sms_cancel_rental existing as a plausible competing choice. The condition is also narrower than the schema's reason enum, which allows service_rejected, number_has_account, and other.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful provenance context (the pollToken source and the session-API-key fallback) and frames the call as polling, but says nothing about polling cadence, timeouts, or behavior when no SMS has arrived yet.

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

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

Two short sentences, front-loaded with the action and followed by input provenance. Every clause carries information; nothing is padded.

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

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

With no output schema and only a 50%-covered 2-parameter schema, the description should say more about the return value (identifying the OTP/code or signaling a pending state). For a polling tool, the absence of any waiting/failure semantics leaves a meaningful 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 coverage is only 50% (id is documented as 'activation id', pollToken is not). The description partially compensates by explaining both parameters' origin and that pollToken can be substituted with the session API key, but it does not clarify pollToken's format or why both may be needed.

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

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

States a specific verb and resource: polling an agent rental for the SMS/OTP. An agent can tell it fetches a verification code tied to a rental. It does not, however, differentiate itself from the overlapping sibling ucode_sms_get_code, so the 5-level sibling-distinguishing bar is not met.

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

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

Gives concrete guidance on where the inputs come from ('Pass id and pollToken from ucode_agent_rent, or rely on the session API key'), which is useful. It offers no when-to-use/when-not guidance and never mentions the similar ucode_sms_get_code sibling, so routing remains implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read profile is covered. The description adds genuine context beyond that: the payment rail is USDC on Base, no login is required, and it applies only without prepaid credits. It does not discuss rate limits or quote validity, keeping it out of 5.

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

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

Two sentences, front-loaded with the core purpose (exact USDC price for one number) and followed by the prerequisite. No filler or redundant restatement.

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

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

For a read-only quote tool with safety already covered by annotations and no output schema, the description supplies what an agent needs: what is quoted, in what currency/network, and the input dependency. The one gap is that it never states the quote is informational only and does not rent the number.

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 both 'service' and 'country' are already documented in the schema. The description reinforces the source of the 'service' code but adds no format or syntax detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource: an exact USDC (Base) price quote to rent one number for a service/country. The 'without prepaid credits' clause meaningfully disambiguates it from credit-based siblings like ucode_sms_prices and ucode_sms_rent_with_credits. It stops short of naming an alternative sibling explicitly, so it lands at 4 rather than 5.

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

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

Gives clear context for when this tool applies (pay-as-you-go quoting without prepaid credits) and a concrete prerequisite: pull the 'service' code from ucode_find_numbers and supply a countryId. It stops short of explicit when-not-to-use guidance or naming the credit-based alternative to avoid.

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

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

Annotations only declare it is a non-read-only, open-world, non-destructive operation; the description goes well beyond that by disclosing the two payment paths, the exact key-activation sources (buy_credits, use_api_key, Bearer header), the x402 USDC-on-Base PAYMENT_REQUIRED handshake, and the returned phone/id/pollToken. This is the auth and billing context an agent needs before invoking.

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?

Front-loaded with the core action and efficient overall, but the parenthetical list of key sources makes one sentence long and dense. No wasted sentences, though the payment-branch explanation is compressed into a single run-on.

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

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

There is no output schema, so the description carries the return contract and does so (phone, id, pollToken), names the next tool to call, and names the alternative for a different caller class. For a 6-param, 3-required mutation with a two-step payment flow, nothing essential 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 adds real meaning on top by explaining how apiKey becomes active and what paymentHeader is for in the retry flow. It does not, however, clarify country resolution defaults or the purpose enum beyond what the schema already lists.

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

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

States a specific verb and resource ("Rent one virtual number for a lawful SMS verification") and immediately distinguishes itself from the sibling it is not for ("Signed-in human accounts should use ucode_sms_rent_with_credits instead"). An agent can separate this from ucode_sms_rent_packages, ucode_sms_rent_with_credits, and ucode_sms_rent_provider_direct without opening any schema.

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

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

Gives explicit when-to-use branches: with an active uc_live_ key it pays from the agent wallet; without a key it falls into pay-per-SMS and must be retried with paymentHeader. It also names the alternative tool and the condition that selects it, plus the follow-up call to ucode_agent_check_sms.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is partly covered. The description adds that the key must be previously issued and that activation is session-scoped, but it does not disclose what happens with an invalid or expired key, whether the session activation persists, or how it interacts with other auth flows.

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 with the purpose front-loaded and the qualifying condition appended. No filler, no restatement of the title.

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

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

For a one-parameter, no-output-schema session-auth tool, the description covers what it does, what it needs, and when to reach for it. The remaining gap is the relationship to sibling auth tools (ucode_authenticate, ucode_connect, ucode_login_start) and failure behavior, which is minor at this complexity.

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

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

Schema description coverage is 0%, so the description must carry some of the burden; it does clarify that the single apiKey parameter is a previously issued uc_live_ key, which matches the schema's pattern. That is modest added value over the raw pattern constraint, but it gives no guidance on sourcing or handling the key.

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

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

The description gives a specific verb (Activate), a specific resource (a previously issued uc_live_ agent API key), and the scope of the effect (this MCP session). It implicitly separates itself from the header-based auth path used by sibling tools like ucode_authenticate, though it does not name any sibling tool explicitly.

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

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

The parenthetical "for clients that cannot set an Authorization header" states the precise condition under which this tool is the right choice, which is genuinely useful routing information among many auth-related siblings. It stops short of naming an alternative tool or stating an explicit when-not-to-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 already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds that the balance is for the agent wallet tied to the active uc_live_ API key, but it does not describe auth requirements, return format, or pagination behavior. With annotations covering the safety profile, this limited added context warrants a 3.

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 with no filler. Every word contributes to identifying the resource and its scope.

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

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

For a simple read-only balance lookup with no output schema, the description states the returned resource ('Credit balance') and the scoping key ('active uc_live_ API key'), while annotations cover the safety profile. It is complete enough to call correctly, though it could clarify the requiredness of the apiKey parameter.

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 sole parameter is apiKey, and schema description coverage is 0%, so the description must carry parameter meaning. It adds that the key is a live 'uc_live_' key tied to an active session, which is useful, but it does not say whether apiKey is required, optional, or what format is expected. Partial compensation for a one-param tool lands at 3.

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

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

States a specific resource (credit balance of the agent wallet) and scope (behind the active uc_live_ API key), so the agent knows what it retrieves. It does not explicitly differentiate from siblings like ucode_agent_billing or ucode_credits_status, so it stops short of 5.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative among the many sibling balance/billing tools. The description only states what the tool returns, leaving the agent to infer when to select it over ucode_credits_status or ucode_agent_billing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds platform-specific behavioral context (web vs native) but does not disclose other traits such as response size, pagination, or authentication needs. Since the annotations cover the baseline, a 3 is appropriate – the description adds some value but not rich behavioral detail.

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 that front-loads the tool's purpose and immediately follows with actionable platform guidance. There is zero waste; every word contributes to selection or usage. This is exemplary conciseness.

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 tool has an output schema and a single parameter with clear guidance, the description covers all essential information: what it returns, which platform to use, and the parameter value semantics. No other context is necessary for an agent to invoke it correctly. The existence of an output schema means return values are documented elsewhere, so the description is complete for its scope.

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

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

Schema description coverage is 0%, but the description adds meaning to the single 'platform' parameter by explaining the semantic distinction between web (Stripe/crypto web packages) and ios/android (native). This goes beyond the raw enum values and helps the agent choose correctly, thus compensating for the lack of schema descriptions. It does not go into detail about the snapshot contents, but that is not parameter-related.

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 returns a 'combined snapshot' listing the specific components (packages, rentals, credit status, settings). This differentiates it from sibling tools like ucode_credit_packages or ucode_credits_status, which focus on individual aspects. The verb 'snapshot' plus explicit contents make the 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?

The description gives actionable guidance on platform selection ('Use platform web for ChatGPT... ios/android for native'), which clarifies when each parameter value is appropriate. It implicitly distinguishes this combined tool from individual endpoints via the 'combined' phrasing, though it does not explicitly name alternatives or state when not to use this tool. Overall, the context is clear, but explicit exclusions are missing.

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

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

Annotations already indicate this is not read-only, so the description is not burdened with proving mutation. It adds useful behavioral context by framing this as a hidden escape hatch, restricting it to developer/mobile-token usage, and warning against suggesting it for normal login. It could go further in describing what 'linking' changes, but it exceeds the minimum.

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 deliver the key constraint first, the usage boundary second, and the alternative routing third. No filler or redundant restatement.

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

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

With one fully documented parameter, an output schema, and annotations covering side-effect flags, the description supplies the remaining critical context: when to invoke this tool and which sibling to prefer instead. Nothing essential is missing 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?

The single parameter accessToken is fully described in the schema with coverage at 100%, so the baseline is 3. The description reiterates the same developer/mobile-token restriction but 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?

Description uses a specific verb ('Link') and resource ('Ucode account') and clearly scopes it as a developer/mobile-token-only escape hatch. It also names sibling alternatives (ucode_login_start + ucode_login_poll), distinguishing it from normal sign-in.

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

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

Explicitly states when to use: only if the user already has a mobile Bearer token and explicitly asks to use it. It also gives a when-not-to-use instruction and names the exact alternative flow, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns linkUrl + sessionId and that it requires polling, which is useful behavioral context. However, it does not disclose details like whether a browser window opens automatically, how long the link is valid, or what happens on cancellation.

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 waste. The core action is front-loaded, the return values are stated, and the next step is given. 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 parameterless tool with an output schema and annotations covering safety, the description is nearly complete. It explains the purpose, the return values, and the required follow-up polling. The only minor gap is not explaining how this differs from ucode_login_start, but the sibling list and the 'in-card button' title provide enough context.

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 0 parameters, so the schema provides no parameter documentation. The description compensates by explaining the return values (linkUrl + sessionId) and the follow-up action (poll ucode_login_poll), which is sufficient for a 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 states a specific verb ('Starts browser sign-in') and resource ('visual card Connect button'), and distinguishes it from the sibling ucode_login_start by noting it is the in-card button variant. It is clear but does not fully explain how it differs from ucode_login_start beyond the UI context.

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 usage context: it is for the visual card Connect button, and it explicitly instructs to poll ucode_login_poll until linked. It does not explicitly state when not to use it or name alternatives like ucode_login_start, but the polling instruction provides actionable guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context ('badges' and 'gift breakdown') but is too vague to disclose what the operation entails, such as whether it returns a list or a summary. It does not contradict the annotations.

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

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

The description is extremely short, but it is under-specified rather than concise. A few words do not constitute a clear or well-structured explanation, and it lacks a clear verb or resource. It is similar to the 'Process' example that scored 2.

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?

Despite the tool's simplicity (no parameters) and the presence of an output schema, the description does not adequately clarify the tool's purpose or behavior. An agent would likely be uncertain whether to call this tool over its siblings. It is incomplete for even a minimal understanding.

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, so the baseline is 4. The description does not need to explain parameters, and no parameter semantics are expected.

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

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

The description is a fragment: 'Free-credit badges / gift breakdown.' It vaguely hints at gift credits and badges but does not clearly state the tool's function or what it returns. It does not distinguish itself from sibling tools like ucode_credit_referral_stats or ucode_credit_packages.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or relationships to the many credit-related siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a little context by saying the data is the same as ucode_render_credits and mentioning the agent-facing x402 USDC on Base context, but it doesn't disclose additional behavioral traits such as auth requirements or response specifics.

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 each clause contributes either data equivalence, user routing, or agent context. The fragment 'Agents: x402 USDC on Base' is terse and slightly cryptic, but overall the structure is efficient and front-loaded.

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, no-parameter read-only listing tool with an output schema present, the description is largely complete. It identifies the sibling, clarifies the audience split, and notes the agent-specific payment context, leaving little that an agent needs to decide whether to invoke it.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description; the input schema is already complete. A score of 4 is appropriate because nothing more is needed for parameter understanding.

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 title directly states 'List credit packages' and the description clarifies it exposes the same packs as ucode_render_credits, giving a clear resource and action. It distinguishes itself from the sibling tool by noting the data overlap and human preference for the sibling, though it relies somewhat on that reference rather than fully defining its own 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 gives routing guidance: humans should prefer ucode_render_credits and the website dashboard, while the 'Agents:' note points agents toward this tool with x402 USDC on Base. It names the alternative and provides audience-based selection, but doesn't fully spell out when not to use this tool in all cases.

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

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

Annotations declare it is a non-read-only (mutating) operation that is not destructive, so the safety profile is partly covered. The description adds value beyond that: the one-per-account limit, the program-active precondition, and the anti-brute-force warning are all behavioral facts not present in the structured fields.

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: the purpose is front-loaded and the constraints follow with zero filler. Every clause earns its place.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description covers the precondition, the once-per-account limit, and the anti-abuse rule, which is nearly complete for a one-parameter mutation, though code-format expectations remain thin.

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

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

Schema description coverage is 0% for the single "code" parameter, so the schema only conveys type and length bounds (4-20). The description implies provenance (a friend's real code) and forbids fabrication, but adds no format or syntax detail, leaving the semantics only partially supplemented.

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

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

The description gives a specific verb+resource ("Apply a friend's referral code") that clearly separates it from the referral-adjacent sibling ucode_credit_referral_stats (read stats) versus this (redeem). It does not explicitly name a sibling to contrast with, so it falls just short of the top anchor.

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 supplies real preconditions: once per account, and only when the referral program is active. The final sentence ("Never guess, generate or loop over codes") tells the agent the code must come from a legitimate source, which is genuine usage guidance, though it never names an alternative tool.

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

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

Annotations already declare the tool read-only and non-destructive, so the safety profile is covered. The description adds that the tool returns a referral code and earnings summary, but it does not disclose any behavioral nuances beyond that. No contradiction with annotations.

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

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

The description is six words and contains no filler. It front-loads the resource and the return content, 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 zero-parameter, read-only tool with an output schema, the description is largely complete: it states what the tool returns and annotations cover side effects. It could be slightly clearer about whose referral stats are being reported (e.g., the current user), but the complexity is low enough that this is a minor gap.

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

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

The tool has zero parameters, so there is nothing for the description to document. The baseline of 4 applies because no parameter semantics are needed and the description does not introduce any conflicting parameter expectations.

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

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

The description names the resource (referral) and the content of the result (referral code and earnings summary), which distinguishes it from credit status or gift breakdown siblings. It lacks an explicit action verb such as 'get' or 'view', so it falls just short of the strongest purpose clarity.

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

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

There is no guidance on when to use this tool versus alternatives. With many credit-related siblings like ucode_credits_status, ucode_credit_gift_breakdown, and ucode_credit_referral_redeem, the description does not help an agent select the correct one.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: credits are not a currency wallet, the agent must phrase balances as 'you have X credits', and calling the tool refreshes the ChatGPT card. This is helpful and does not contradict the annotations.

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

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

The description is three sentences with no filler. It front-loads the key semantic distinction ('credits are in-app points... not a bank balance') before giving usage guidance and output phrasing rules. 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?

There are no parameters, an output schema exists, and the annotations cover the read-only/destructive safety profile. The description adds the missing operational context: when to call the tool, how to phrase the result, and what semantic pitfall to avoid. An agent has what it needs to invoke and use this correctly.

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

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

The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to clarify. The zero-parameter baseline applies, and the description does not need to compensate for anything here.

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 title 'Credit balance' and the description clearly identify this as the tool for checking credit status, and the description clarifies that credits are in-app points, not a bank balance. It doesn't use an explicit verb like 'get' or 'fetch' and doesn't contrast itself with sibling tools such as ucode_render_credits, but the intent is still fairly clear.

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

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

The description gives concrete guidance: 'After a dashboard or x402 payment, call this so the ChatGPT card refreshes.' This gives the agent a clear when-to-use trigger. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for a simple status 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 minimal (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It says 'verify' but does not disclose side effects such as crediting the user, consuming the transaction, idempotency, or failure behavior. This is a significant gap for a server-side verification call that may mutate state.

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

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

One concise sentence with no redundant phrasing. Required parameters are listed compactly and the platform enum is naturally embedded in the prose.

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?

An output schema exists, so return format is covered. The description names the operation, platforms, and required inputs, but lacks context about when to call it after a client purchase, the source of tokens, and what happens on success or failure. Given the large sibling toolset, this leaves some selection ambiguity.

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

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

Schema coverage is 0%, so the description must compensate. It lists all five parameters and adds a conditional rule ('purchaseToken for Android') that clarifies the otherwise-optional schema field. However, it does not explain the meaning of packageId/transactionId/productId beyond their names, so compensation is partial.

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: 'Server-side verify of RevenueCat / store purchase', and names the platforms (iOS/Android). This distinguishes it from sibling verifiers like ucode_payments_stripe_verify, so an agent can tell it applies to app-store/Play purchases.

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 ('same as mobile') but does not explicitly name sibling alternatives or state when not to use this tool. Usage is implied by the purpose rather than clearly routed against the numerous payment and credit siblings.

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

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

Annotations already declare destructiveHint=false and readOnlyHint=false, but the description adds valuable behavioral context: it clears only the MCP session, not the account, and it shows the welcome card with Connect again. This goes beyond the annotations and helps the agent understand the 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?

Three sentences, each earning its place: what it does, when to use it, and what the user sees afterward. No fluff, front-loaded with the core action.

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 an output schema and annotations, the description is complete. It covers the action, the scope, the trigger phrases, and the post-condition. The only minor gap is not explicitly naming ucode_sign_out as the alternative for full account sign-out, but the 'not account deletion' clarification covers that.

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

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

The tool has zero parameters, so the description doesn't need to explain parameter semantics. The baseline for 0 params is 4, and the description appropriately focuses on behavior rather than 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 clearly states the specific action ('Sign out / unlink this ChatGPT conversation from Ucode'), the resource affected (the MCP session), and what it is not (not account deletion). It distinguishes itself from the sibling ucode_sign_out by clarifying it only clears the MCP session, not the account.

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

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

Explicitly states when to use: 'Use when the user asks to sign out, log out, disconnect, or switch accounts.' It also implies the alternative (ucode_sign_out) by clarifying this is not account deletion, giving the agent enough context to choose 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?

Annotations already establish readOnly=true, destructive=false, openWorld=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: 'No sign-in needed,' which is an authentication prerequisite the annotations do not capture. It still omits pagination/return-shape details, so not a 5.

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

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

Front-loaded with the key differentiator ('No sign-in needed') then purpose, then routing, and every sentence carries weight. The routing sentence is dense with tool names but each is load-bearing for a multi-persona workflow, so it stays useful rather than padding.

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

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

With no output schema, the description does describe what comes back (apps/services in stock, per country, with price in credits) and covers the auth and safety context via annotations. It is complete enough to call correctly, missing only explicit error/empty-result 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%, with each of the three parameters documented (search, country filter, limit for max countries). The description only loosely echoes these ('by country'), adding no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

The description gives a concrete verb (search/find) and resource (which apps/services have virtual numbers in stock, by country, with price in Ucode credits), which is more specific than the title alone. It distinguishes itself from renting siblings by flagging the no-sign-in scope and positioning itself as the discovery/quote step, though it never explicitly contrasts with the similarly named ucode_sms_prices sibling.

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

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

It states explicit routing: 'Use this first whenever someone asks for a number or a price,' then names the exact next-step alternatives for two distinct caller personas (signed-in humans vs autonomous agents). An agent knows both when to pick this tool and where to go afterward without opening other schemas.

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

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

The description adds useful behavioral context: it uses an OpenAI key from Panel or OPENAI_API_KEY and respects the 'AI help' toggle. However, this strongly implies external OpenAI API access, which contradicts the annotation openWorldHint=false that signals no open-world/external interaction. This is an annotation contradiction.

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 purpose, followed by two concise sentences covering key sources and the toggle. Every sentence adds useful information without 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?

With one well-schemaed parameter and an output schema, the description does not need to explain return values. It covers key and toggle behavior, but it omits failure behavior when the key is absent or the toggle is off, and it does not address overlap with ucode_instructions.

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 only parameter, 'question', is fully documented in the schema with 100% coverage, so the schema carries the semantic weight. The description's mention of 'Ucode features and flows' loosely aligns with the parameter but adds no new detail about question formatting, scope, or edge cases.

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 purpose: natural-language help about Ucode features and flows, with a clear verb ('help') and resource. It does not explicitly distinguish itself from the sibling ucode_instructions, so differentiation is left to inference.

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

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

The description says the help is 'optional' but provides no when-to-use or when-not-to-use guidance. It does not mention alternatives such as ucode_instructions or explain how the agent should choose between this tool and the many other Ucode tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no contradiction exists. The description reinforces read-only status and adds routing context about signed-in state, but it does not disclose additional behavioral traits such as return format or whether authentication is required.

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. The routing guidance and official site link are relevant and concise; no sentence is wasted.

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

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

With no parameters and an output schema present, the tool is simple to invoke. The description covers the most important routing decisions, though it could have added a brief positive use case to fully ground when to select ucode_instructions over siblings.

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 schema description coverage is 100%, so there are no parameter semantics to explain. Per the zero-parameter baseline, this is adequate.

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 the tool is a 'Full product guide (read-only)', clearly identifying the resource and verb. It does not differentiate from ucode_help or other guide-like siblings, but the read-only guide framing is specific enough to be usable.

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 explicitly says not to use it as the first message and names ucode_welcome as the alternative to call first. It also gives a clear condition for routing unsigned users to ucode_welcome/ucode_login_start, though it does not state a positive 'use this when...' 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: this is a polling operation that must be retried, and completion must come from the browser flow rather than user-supplied tokens or a 'done' message. It doesn't discuss timeouts or rate limits, but the presence of an output schema and the simple read-only nature make that gap minor.

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 wasted words. The critical relationship to ucode_login_start is front-loaded, followed by the repeated-polling instruction and the guardrail about not relying on user tokens or 'done'. 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 single-parameter, read-only polling tool with an output schema, the description provides the essential flow context: when to call it, that it must be called repeatedly, and that the completion signal should come from the browser flow. Nothing material is missing 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 description coverage is 100%: the only parameter, sessionId, is already described as 'sessionId returned by ucode_login_start' with a minLength constraint. The tool description adds no further parameter-level detail, so the baseline of 3 applies since the schema carries the 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 description uses a specific verb ('Poll') and resource ('after ucode_login_start'), states the outcome ('Links the ChatGPT session when the user has finished in the browser'), and is clearly differentiated from its sibling login_start by naming it as the prerequisite. The title 'Finish browser sign-in' reinforces the intended phase.

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 when to use this tool ('after ucode_login_start'), how to use it ('call repeatedly until complete'), and what not to do ('do not ask users to paste tokens or to type “done” as the only completion signal'). This gives the agent concrete invocation guidance and avoids common failure modes.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the URL is one-time and must be followed by polling ucode_login_poll. This is meaningful context for a correct invocation flow.

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 filler. The core action is front-loaded, followed by the preferred alternative and the required polling step. 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?

Complete for a no-parameter tool: annotations cover safety, an output schema exists, and the description provides the full usage flow and sibling routing. An agent has everything needed to invoke and continue the login process.

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 need not document parameters. With 0 params the baseline is 4, and the description still clarifies the one-time sign-in URL behavior, which is the only context 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?

States a specific verb and resource: it creates a one-time browser sign-in URL. It also distinguishes itself from the sibling ucode_connect and connects to ucode_login_poll, so an agent can tell what this tool does at a glance.

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

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

Gives explicit guidance: prefer the in-card Connect button (ucode_connect) instead, and poll ucode_login_poll(sessionId) until linked. This clearly frames when to use the tool, when not to, and what follow-up is needed.

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

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds the 'no auth' detail and domain warning, which is useful but not extensive. It does not contradict annotations.

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

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

Very concise: one sentence covering purpose, no auth, and a domain warning. Every piece of information is essential and front-loaded.

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 tool's simplicity (no parameters, no complex behavior) and the presence of an output schema, the description is complete enough. It covers the essential details an agent needs: it's a public, safe, read-only health check.

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

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

With zero parameters and 100% schema coverage (no properties to document), the description has no need to explain parameter semantics. Baseline for 0 params is 4, and the description appropriately focuses on other aspects.

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 it as a public health check for the Ucode Panel, distinguishing it from other ucode_* tools that are likely auth or data operations. It is specific enough for an agent to know what it 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?

The description notes it is a public health check with no auth, which implies it can be used without credentials, but it does not explicitly state when to use it versus other tools. However, for a health check, this is acceptable.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), and the description's 'Creates a crypto invoice' is consistent with that. It adds audience context, but doesn't disclose side effects such as whether calling it generates a payable obligation, whether invoices expire, or whether payment must later be verified via the status tool.

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

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

Three short sentences, each earning its place: the first states the action and audience, the second and third explicitly route non-target users to the correct alternatives. Information is front-loaded 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?

The description is strong on purpose and routing, and an output schema exists to cover return values. However, it leaves the required packageId unexplained, which is a significant gap for a tool that cannot be invoked correctly without knowing what packageId should contain.

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

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

Schema description coverage is 0%, so the description needed to compensate for the undocumented parameters. It only hints at 'web/Telegram' mapping roughly to the platform enum, but says nothing about the required packageId, returnUrl, or cancelUrl semantics. An agent would still need to guess what packageId refers to.

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 ('Creates'), a precise resource ('crypto invoice (NOWPayments)'), and the intended context ('human web/Telegram top-ups'). It also implicitly differentiates from siblings by naming what this tool is not for: ChatGPT humans and autonomous agents/bots.

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 when-to-use guidance for human web/Telegram top-ups and clearly names alternatives: ChatGPT humans should use https://ucode.uk/app/credits, and autonomous agents/bots must pay via USDC on Base through x402, not NOWPayments. This leaves no ambiguity about when to choose this tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a minor behavioral nuance by saying 'Poll', which implies the status can be checked repeatedly and may change, but it does not mention external latency or error 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 one front-loaded sentence with no filler. Every phrase adds meaning, and it avoids repeating the title or schema.

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

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

Given one required parameter, an output schema, and read-only annotations, the description is nearly complete for invocation. The only real gap is not addressing when in the payment flow this should be used, which is more of a usage-guidance issue.

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

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

Schema description coverage is 0%, so the description must compensate. It does convey the key semantic: paymentId is a NOWPayments id. For a single string parameter, this is sufficient to call the tool correctly, even though the description does not explicitly name the parameter.

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

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

The description states a specific action ('Poll'), a specific resource ('invoice / payment status'), and the identifying namespace ('NOWPayments id'). This clearly distinguishes it from payment creation or Stripe verification tools in the sibling list.

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

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

No explicit when-to-use guidance or alternatives are mentioned. The verb 'Poll' implies repeated status checks after a NOWPayments payment is created, but the choice against sibling tools like ucode_payments_stripe_verify is left to inference.

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

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

The description adds environmental context ('blocked in ChatGPT', 'in-card Stripe is blocked') but does not explain what happens when the tool is invoked, what side effects it has, or what prerequisites exist. The annotations do not carry this burden either, so the description is thin on behavioral 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 short, front-loaded with the critical warning, and every sentence provides actionable routing. There is no filler or repetition.

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 complete for redirecting an agent away from this tool)Skip() and toward the correct alternativearen't enough. However, it omits any explanation of what the checkout tool does or how it behaves, so an agent that might legitimately need this tool would still lack essential context.

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 high (75%), with packageId and stripeProductId already described in the schema. The tool description adds no parameter-level meaning, so it neither improves nor harms the agent's understanding. 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 title indicates 'Create Stripe checkout,' but the description never states what the tool does. It only warns against use and redirects to alternatives, so an agent cannot learn the tool's function from the description itself.

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 when-not-to-use guidance: 'Do not use in ChatGPT' and 'In-card Stripe is blocked.' It also names exact alternatives for different actors: humans should call ucode_render_credits and open the credits URL, while agents/bots should call ucode_agent_billing and pay via x402. This is model usage guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about resolving fiat display rather than exposing raw IDs, but it does not disclose additional behavioral details such as error handling or invalid-ID 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 compact, front-loaded with the rare-usage warning, and contains no filler. Every clause earns its place, and the key caution is immediately visible.

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

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

For a one-parameter read-only lookup with complete schema coverage and an output schema present, the description plus annotations fully cover safety, usage, and alternative routing. Nothing essential 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?

The input schema already fully documents the single parameter: 'Comma-separated Stripe price_… or prod_… IDs'. The description reinforces the prod_/price_ distinction but adds no new parameter semantics 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 names a specific operation ('Resolve fiat display') and a specific resource ('Stripe IDs'), and it explicitly contrasts this tool with ucode_credit_packages for storefront-style copy. An agent can distinguish it from the many payment/credit siblings without opening schemas.

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

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

The description marks the tool as rare, states its intended use, and gives explicit when-not-to-use guidance: do not read raw prod_/price_ strings to end users. It also names the alternative tool, ucode_credit_packages, for storefront-style copy. This is full routing guidance.

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

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

The description discloses the key side effect: 'Panel credits the account', which is mutation and aligns with readOnlyHint=false. It does not add much beyond annotations; it omits failure modes, idempotency, or what happens if the session is invalid. With minimal annotations, this is acceptable but not rich behavioral 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, well-structured sentence that front-loads the timing condition and uses bold for key terms. Every word earns its place, and it is appropriately sized for a simple two-parameter tool.

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 that an output schema exists and the tool is a straightforward verify-and-credit action, the description covers the essential when and what. It lacks explicit mention of the create_checkout sibling or potential duplicate-call behavior, but it is sufficient for basic 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 0%, so the description is the only source for parameter meaning. It maps 'checkout session id' to sessionId and names packageId directly, which provides some context beyond the raw property names. However, it does not explain how to obtain these values or their relationship, so it only partially compensates for the schema gap.

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

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

The description states the tool's role: after checkout, pass session ID and packageId so Panel credits the account. This clearly implies verification and credit action, and the 'After Checkout completes' condition gives context. It does not explicitly name the alternative create_checkout, but the purpose is understandable without opening schemas.

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

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

The description gives a clear temporal condition: use this after checkout completes. This is sufficient context for an agent to know when to invoke it. However, it does not explicitly reference sibling tools like ucode_payments_stripe_create_checkout or state that it should not be used before checkout, so it falls short of a full 5.

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

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

Beyond the readOnlyHint annotation, the description meaningfully explains behavior: the card shows current wallet balance, ChatGPT cannot run Stripe inside the iframe, the user must tap through to the external credits URL, and the expected follow-up is ucode_credits_status. This gives the agent an accurate mental model of what happens without overstating 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?

Four short, purposeful sentences front-load the primary action, then add the external-payment limitation, follow-up step, and agent alternative. Every sentence earns its place with no redundant filler.

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

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

With an empty input schema, an existing output schema, and readOnly/destructive annotations already provided, the description completes the picture by explaining the human flow, external URL, post-payment status check, and the correct sibling for agents. Nothing needed to select and invoke this tool correctly 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?

The input schema has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and the description doesn't need to compensate for schema gaps because none exist.

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

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

The description states a specific action and resource: it 'Opens the Add credits card with the current wallet balance.' It also immediately distinguishes this visual picker from agent/bot billing by explicitly directing agents to ucode_agent_billing, preventing confusion with similarly named credit and billing tools.

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

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

The description gives explicit when-to-use guidance: this tool is for the human-in-the-loop visual purchase flow, while agents/bots should call ucode_agent_billing instead. It also provides the follow-up step to call ucode_credits_status after payment, which is concrete workflow guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat those. The description adds valuable behavioral context: it specifies the render action, the connect button, and the restriction on tool use until the account is linked. This goes beyond the annotation safety profile, though it doesn't describe the exact card layout or interaction details.

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, both essential. The critical instruction ('Call on the first user message') is front-loaded, and the second sentence adds important usage constraints. Zero wasted words — 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?

The tool is simple (no params, has output schema), and the description fully covers when to use it, what it does, and what to do until account linking. For a render tool, this is complete — an agent knows exactly when and how to invoke it and what to expect.

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 nothing to explain. With schema coverage at 100% (vacuously) and no parameters, the description doesn't need to add parameter details. Baseline for no-param tools is 4, and the description doesn't need 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 exact action ('Renders the interactive Ucode card with a Connect Ucode account button'), the specific trigger ('on the first user message in every new chat'), and it implicitly distinguishes from sibling render tools like ucode_render_credits and ucode_render_services. No ambiguity about what this 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?

Explicitly says when to call ('Call on the first user message in every new chat') and provides a clear restriction ('Until linked, only welcome/connect/login tools — never rent or checkout'). This gives an agent precise routing guidance and prevents misuse with other tools.

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

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

Annotations already mark the tool as read-only and non-destructive. The description adds useful context that this is a visual picker optimized for in-chat cards, but it does not describe failure modes, auth requirements, or whether the picker is persistent. The annotations carry the main safety burden here.

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 with no filler. The comparison to ucode_sms_summary is valuable routing context, and the in-chat card optimization is explained without 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?

The tool is simple and has an output schema plus safety annotations, so the core purpose is conveyed. However, the limit parameter is left entirely unexplained, and 'when the user wants a number' is vague enough that an agent may struggle to decide when this tool is the correct choice.

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

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

Schema description coverage is 0%, so the description must explain what limit and search do. It mentions search as a feature but does not clarify what search matches or what limit controls. Without this, an agent cannot confidently decide how to populate either parameter.

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

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

The description clearly states the action ('opens the visual service picker') and the content ('popular apps + search'). It also distinguishes itself from ucode_sms_summary by noting the same data is presented in an in-chat card format, so an agent can tell this apart 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 description gives explicit trigger conditions: call after sign-in or when the user wants a number. It references ucode_sms_summary as the data-equivalent tool, which helps routing, though it does not list exclusions or other alternatives like ucode_services_catalog.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds behavioral context by stating results are paginated and sourced from the Panel database, plus per-country availability, but it does not clarify pagination defaults, response behavior, or availability semantics beyond that.

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 packs the essential information—paginated, catalog, per-country availability, and data source—without filler. It earns its place and remains readable.

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

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

For a simple read-only query tool with an output schema and safety annotations, the core behavior is reasonably covered. However, it lacks usage guidance relative to siblings and leaves the meaning of 'per-country availability' ambiguous—especially since there is no country parameter in the input schema.

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

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

Schema description coverage is 0%, yet the description names none of the five parameters except indirectly through 'paginated'. The parameter names (page, limit, search, sortBy, sortOrder) are somewhat self-explanatory, but the description does not compensate for the lack of schema descriptions, especially for search and sort 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 identifies the resource unambiguously: a paginated Ucode service catalog with per-country availability sourced from the Panel database. The absence of an explicit verb is mitigated by 'catalog' clearly implying a list/retrieve operation, though it does not explicitly differentiate from sibling catalog-like tools such as ucode_sms_services.

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 no guidance on when to use this tool versus siblings like ucode_render_services or ucode_sms_services. There are no explicit conditions, exclusions, or alternatives mentioned, forcing the agent to infer applicability from the tool name alone.

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

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

Annotations already cover read-only/non-destructive behavior, so the description doesn't need to repeat that. It adds useful behavioral context: the session-linkage check, the guardrail against processing rental requests when disconnected, and the live-number card display.

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

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

Three short sentences with the main purpose front-loaded; the second sentence delivers actionable branching logic and the third adds output context. No filler or 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 zero-parameter, read-only status check with an output schema, the description covers invocation timing, the failure branch, and what the user may see. Nothing essential 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?

The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify. No parameter-level explanation is needed.

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 operation: 'Check whether this ChatGPT session is linked to Ucode.' The description clearly identifies the resource and expected result, and the conditional reference to ucode_render_home separates it from related auth/session 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?

Explicitly says 'Use at chat start' and provides a concrete conditional rule: if connected is false, run ucode_render_home and do not process rental requests. This is a clear when/when-not guideline for an 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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds that it 'unlinks Ucode from this ChatGPT chat,' which clarifies the exact effect. It does not elaborate on side effects like session invalidation or reversibility, but given the annotation coverage, 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 two sentences, extremely concise, and front-loads the core purpose and usage. Every word earns its place, and it leverages the sibling reference to avoid repetition.

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 parameters and an output schema present, the description covers the essential context: what it does, when to call it, and that it is equivalent to ucode_disconnect. It does not describe the return value, but the output schema presumably handles that. The description is sufficient for an agent to decide when and how to invoke it.

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

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

The tool has zero parameters and schema coverage is 100% (trivially), so there is nothing to explain. The description does not need to add parameter details, and the baseline for 0 parameters is 4. It correctly avoids inventing any parameter information.

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: 'unlinks Ucode from this ChatGPT chat' and ties it to sign out, log out, or disconnect requests. It names a specific verb and resource, and even references the sibling ucode_disconnect to clarify it is the same operation, making the 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?

It explicitly tells when to use the tool: 'Call for sign out, log out, or disconnect requests.' It also mentions it is the same as ucode_disconnect, which provides an alternative reference. However, it does not explicitly state when not to use it or distinguish between the two tools beyond noting they are equivalent, so it falls just 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 already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds one useful behavioral nuance — SMS snippets are only included 'if already fetched', implying this tool does not fetch new SMS content — but does not go deeper into authentication, rate limits, or other behavioral caveats.

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

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

The description is a single, compact phrase with no filler or redundancy. Every word adds information, particularly the conditional 'if already fetched', making it appropriately sized and front-loaded.

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, zero-parameter, read-only tool with an output schema present, the description provides the essential information: what is returned and the conditional SMS snippet behavior. It is slightly terse regarding the meaning of 'received', but the output schema and annotations cover most context.

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 and the input schema is an empty object, so there is no parameter meaning for the description to clarify. The baseline of 4 applies here; the description adds no parameter semantics because none are needed.

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

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

The description identifies the resource ('active/received rentals') and the key condition ('with SMS snippets if already fetched'), making the tool's purpose fairly understandable. It lacks an explicit verb like 'list' or 'retrieve' and does not differentiate it from sibling tools such as ucode_sms_summary or ucode_sms_transactions.

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

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

Usage is only implied by the name/title and the phrase 'active/received rentals' — an agent can infer it is for checking currently active rentals. However, there is no explicit guidance on when to prefer this over related SMS tools or any exclusions/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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds valuable behavioral context: the conditional refund logic, the requirement of a cancel reason for analytics, and the edge case where an SMS arriving during cancel keeps credits charged and returns the code. This goes beyond the annotations and helps the agent anticipate outcomes.

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 filler. The core action and refund condition are front-loaded, the reason requirement is stated, and the edge case is given in one compact sentence. 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 has an output schema, so return values need not be described. The description covers the main behavior, the reason requirement, and the race condition with SMS arrival. It does not mention prerequisites like having an active rental or authentication, but those are implied by the tool's domain and sibling context. Slightly more detail on what 'code is returned' means could push it 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?

Schema description coverage is 0%, so the description must compensate. It explains the purpose of 'reason' (for analytics) and lists its enum values, which the schema already provides but the description reinforces. It does not explain 'rentalId' or 'reasonNote' beyond what the schema shows, but the tool name and context make rentalId self-evident, and reasonNote is optional. The description adds meaningful semantics for the key parameter.

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

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

The description states a specific verb ('Cancel'), a resource ('an active rental'), and the key side effect ('refund credits when no SMS has arrived'). It clearly distinguishes this from sibling tools like ucode_sms_get_code or ucode_sms_refund_expired by focusing on cancellation with refund semantics.

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 an active rental needs to be cancelled and no SMS has arrived. It also provides the required reason enum values, which guides correct invocation. However, it does not explicitly state when NOT to use it or name alternative tools (e.g., ucode_sms_refund_expired for expired rentals), 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.