TvojeLajky

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

Discloses the side effect (creates an order), the non-charging nature (unpaid), sensitive output handling (protect orderToken), and idempotent retry behavior—context beyond the readOnly/idempotent/destructive hints. 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?

Three sentences with no filler: core purpose first, then an important consent precondition, then output handling and idempotency guidance. 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?

With no output schema, the description still tells the agent what to return to the user (checkout URL), what to keep secret (orderToken), how to retry, and when invocation is appropriate. The missing customerEmail semantics are minor for successful invocation since it is optional.

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

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

Schema descriptions are absent (0% coverage), so the description must compensate. It explains idempotencyKey's retry purpose and implies quoteId via 'accepted quote', but customerEmail is never mentioned and no guidance is given on its role or optionality, leaving a clear 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 action ('Create'), object ('order'), and precondition ('from an accepted quote'), and the 'unpaid' modifier distinguishes it from pay_order while read-only siblings are clearly different. This is a clear, non-tautological purpose.

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

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

Gives clear context: only when user intent to order exists and only for accepted quotes, plus retry guidance via idempotencyKey. It does not explicitly name sibling alternatives or exclusion cases, but the unpaid-order framing makes the relationship to pay_order evident.

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 read-only, idempotent, and non-destructive behavior. The description goes beyond them by explaining the required access mechanism (private token or authorized connection) and adding the important domain caveat that payment status does not guarantee delivery. 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?

Two tightly written sentences with no filler. The core purpose is front-loaded, and the second sentence earns its place by adding a non-obvious interpretation rule.

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 getter, the description covers purpose, access, and a domain nuance. However, it omits how orderId and orderToken interact and does not explain what happens when the order is not found or the connection is unauthorized. These gaps matter because no output schema exists to fill them.

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 no property descriptions and 0% coverage, so the description must compensate. It partially explains orderToken as the 'private token', but it never explains the role of the required orderId, the relationship between orderId and orderToken, or when each auth path applies. This is a meaningful gap for a tool with one required 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 opens with a specific action, 'Read', names the resource as 'the payment and delivery status of an order', and clarifies the auth path. This distinguishes it from mutating siblings such as create_order and pay_order, and the added statement 'A paid order is not necessarily delivered' sharpens its semantic 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?

It clearly indicates when to use the tool: when you need to inspect an order's payment and delivery state without modifying it. It does not explicitly name alternatives or exclusions, but the read-only framing and sibling names make the intended use obvious enough.

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, idempotentHint, and non-destructive behavior. The description adds useful return-value nuance with 'Missing numbers are null' and clarifies that it fetches an 'actual public' profile, but it does not describe output structure, error conditions, or data freshness.

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 deliver the primary purpose and one valuable null-handling detail without filler. The main action is front-loaded and every word earns its place.

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

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

For a simple 2-parameter read operation with no output schema, the description is adequate but sparse. It conveys purpose and hints at numeric fields, yet omits the returned profile shape, supported platform behavior beyond the schema enum, and any caveats about 'missing' data other than numbers.

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, but it does not explain the platform enum, username formatting, or how the two parameters work together. The only parameter meaning comes from the schema's property names and enum values.

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 opens with 'Look up an actual public social profile' — a specific verb and resource. 'Actual public' and 'using ScrapeCreators' help distinguish it from sibling tools like get_order, get_wallet, or list_posts.

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 no guidance on when to use this tool versus alternatives such as list_posts or get_wallet. 'Using ScrapeCreators' identifies the source but does not help an agent decide between profile lookup and other operations.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this by stating 'Does not purchase or charge.' It adds useful behavioral details beyond annotations: the price is valid for 15 minutes and likes/views are divided evenly across selected posts.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the extra behavioral notes are compact and relevant.

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 the description covers the most important behavioral context, but given no output schema and no parameter descriptions, an agent still lacks guidance on how quantity, username, platform, and postUrls interact. It is minimally viable but incomplete.

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 0% description coverage, so the description must carry parameter meaning. It only mentions 'likes/views' and 'selected posts' in passing; it does not explain platform, username, type, quantity, or postUrls semantics. This is insufficient for a 5-parameter 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 uses a specific verb ('calculate') and a clear resource ('server-verified price'), and immediately distinguishes itself from purchase-related siblings by stating it 'does not purchase or charge.' This makes the tool's purpose unambiguous.

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

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

The description conveys when to use this tool: to obtain a price before any commitment, with a 15-minute validity window. It also states what the tool does not do ('Does not purchase or charge'), but it does not explicitly name the sibling tools that should be used for the actual purchase/order flow.

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 and destructiveHint=false, establishing that this is a safe read. The description adds useful context ('authenticated', 'approved agent budget', 'integer CZK halere'), but does not disclose deeper behavior such as authentication failure behavior, whether the budget resets, or how the approved budget is computed.

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, well-structured sentence that front-loads the operation and resource, then specifies the returned values and units. There is no filler, tautology, or redundant restatement of the tool name.

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 no output schema, the description adequately identifies the two returned values and their unit. The phrase 'remaining approved agent budget' is slightly ambiguous about whether it is a per-agent or global budget, but this does not materially block 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?

There are no parameters, so the baseline for a zero-parameter tool is 4. The description cannot add parameter-level detail, but it does clarify what the returned values represent, which is the most relevant semantic contribution 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 description states a specific verb ('Read'), a specific resource (the authenticated wallet), and the exact values returned (wallet balance and remaining approved agent budget) with units. This makes it clearly distinguishable from sibling tools like get_profile, get_quote, and get_order.

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

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

The description implies the appropriate use case: call this when the agent needs wallet or budget information. It does not explicitly state when-not-to-use or name alternatives, but the zero-parameter read-only nature and absence of any other wallet-specific sibling make the intended usage clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds a concrete limit ('up to 20'), recency ('recent'), and the fact that returned URLs are directly usable in a quote, which is useful behavioral context beyond the annotations. No 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 a single, front-loaded sentence with no filler. Every clause adds information: the list nature, the limit, recency, ownership, and the quoting use case.

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

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

With only two simple parameters, read-only annotations, and no output schema, the description covers the core operation and the most relevant output characteristic (quote-usable URLs). It does not describe the full return shape, but this is a minor gap for such a scoped list operation.

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 for undocumented parameters. It indirectly references 'profile' for username but never explains the platform parameter or the exact meaning of username in that platform context. The enum on platform is self-explanatory, but the description leaves parameter semantics largely to inference.

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 ('List') and names the resource ('posts') with clear boundaries: up to 20, recent, belonging to a profile. It also states the intended downstream use ('URLs usable in a quote'), which distinguishes it from the sibling list_services and other 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 clearly conveys when to use this tool: when recent posts from a profile are needed, especially for quoting. It does not explicitly name counter-indications or alternatives beyond the phrase 'for a quote', but the context is clear enough given the sibling set.

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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context that only starting prices are provided and prices are in integer CZK halere, plus a pointer to get_quote for exact amounts. However, it does not describe return format or pagination, so the added value beyond annotations is modest.

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

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

Two short sentences, with the main action and output details front-loaded in the first sentence and the cross-reference to get_quote placed cleanly in the second. Every word earns its place with no redundancy.

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

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

For a zero-parameter, read-only list tool with annotations covering safety and open-endedness, the description provides all essential facts: what is listed, the included fields, the currency unit, and how to obtain exact prices. No critical information 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 the schema properties are empty, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because there is nothing to compensate for.

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

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

Description uses the specific verb 'List' and names the precise resource ('purchasable Instagram and TikTok services') with key output details ('quantity limits and starting prices'). It also differentiates itself from the sibling get_quote by explicitly pointing out that exact pricing is obtained through that other tool.

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

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

The description tells the agent this tool is for listing purchasable services with their limits and starting prices, and explicitly directs to get_quote when an exact price is needed. This provides a clear condition for choosing an alternative, satisfying the when/when-not requirement.

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 signal a dangerous, non-read-only, idempotent operation, but the description adds the critical context that real prepaid credit is spent, that authorization and budget approval are required, and that retries must reuse the same idempotencyKey. This goes well beyond the annotation flags and warns the agent of financial consequences.

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 tight sentences, no filler: core action first, then prerequisites, then retry/anti-pattern guidance. Every sentence earns its place and the most important safety information is 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?

The description covers the essential safety context (real credit, auth, budget, destructive nature) and the idempotency behavior for a two-parameter tool with no output schema. It is missing only minor niceties such as success/failure response details or what state the order transitions to, but nothing an agent needs to avoid a critical mistake is absent.

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 0% schema description coverage, the description must compensate for the bare schema. It gives orderId meaning as the existing order being paid and idempotencyKey operational meaning as a token to reuse after timeouts—semantics the schema's pattern/length constraints cannot convey. It stops short of explaining the key's creation or what happens on failure, so not a 5.

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

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

The description opens with a specific verb phrase—'Spend real prepaid credit and initiate delivery for an existing order'—that names both the action and the resource. 'Existing order' explicitly differentiates it from create_order, and the rest of the sentence leaves no ambiguity about the tool's role.

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 the authorization prerequisite (wallet:spend), the need for a user-approved budget, and gives concrete retry guidance: reuse idempotencyKey after timeouts and never create a replacement order. This tells an agent both when the tool is appropriate and which alternative (create_order) to avoid.

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