ScrapingBot

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact, the '10 credits' cost, but says nothing about auth requirements, failure modes for invalid ASINs, or response latency for a scraping 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?

One sentence plus a cost clause; the resource and the ASIN key are front-loaded and nothing is padded. 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?

There is no output schema, and the description compensates well by enumerating the fields an agent can expect. For a single-parameter read tool with annotations covering safety, the remaining gaps (ASIN format, error handling) are minor.

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% and the single parameter is undescribed in the schema, so the description must carry the load. 'By ASIN' clarifies what the lone parameter is, but the ASIN format (length/charset expectations) and validation behavior are left unstated.

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 concrete resource ('Amazon product page') and scope ('by ASIN'), then enumerates the returned data (price, rating, availability, bullet points, specifications, photos, variations). That enumeration implicitly separates it from the plural/list and search siblings. It stops short of naming a sibling or stating an explicit action verb, so not a 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?

Usage is only implied: the ASIN-scoped phrasing signals a single-product lookup. There is no when-to-use vs. when-not guidance and no mention of amazonProducts, amazonSearch, or amazonRankings, leaving the agent to infer the boundary between this tool and its very similarly named 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 cover the safety profile (readOnlyHint, openWorldHint), so the bar is lower, and the description adds genuinely non-structured context: per-product credit cost and that failed ASINs are free, which signals partial-failure tolerance. It stops short of saying how failures are reported in the response, so it is 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?

A single compact sentence, front-loaded with the batch scope, then cost, then failure semantics. Every clause carries information an agent needs; 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?

For a one-parameter read-only batch tool with full schema coverage and no output schema, the definition covers scope, cost, and partial-failure behavior adequately. The only minor gap is that 'full details' is defined only by reference to amazonProduct rather than enumerated.

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

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

Schema coverage is 100% with a single parameter whose description already states 'Up to 20 ASINs; 10 credits per product returned.' The description restates that same information rather than adding syntax, format, or normalization guidance, so 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?

Specific verb+resource with explicit scope: 'Full details for up to 20 ASINs in one call.' It also anchors itself against the sibling amazonProduct by declaring equivalence ('the same as amazonProduct for each'), so an agent can distinguish batch from single-item retrieval without opening either 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?

The description clearly implies the selection context: use this when you have multiple ASINs, versus amazonProduct for one. However, it never states an explicit exclusion or a boundary case (e.g. 'prefer this over looping amazonProduct'), leaving the choice slightly inferential.

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 safety (readOnlyHint=true) and open-world reach (openWorldHint=true), so the bar is lower. The description adds genuinely useful behavior beyond that: the result ordering (rank order), the fields returned (price and rating), and a concrete cost of 10 credits. It omits pagination behavior, but the added value is real.

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 tightly packed sentence covers the resource, the two list types, ordering, returned fields, and cost, with no filler. Front-loaded with the resource so the agent can triage it instantly.

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 correctly takes on the burden of describing returns (rank order, price, rating), and it adds cost transparency. The remaining gap is the undocumented 'page' parameter, which an agent would have to guess at from the schema alone.

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

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

Schema coverage is only 33% — only 'category' carries a description, while 'list' and 'page' are undocumented in the schema. The description partially compensates: 'Best Sellers or New Releases' maps to the 'list' enum and 'department' maps to 'category', but 'page' semantics (paging through ranked results, max 100) are not addressed anywhere.

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: retrieves Amazon Best Sellers or New Releases for a department, in rank order, with price and rating. An agent immediately knows what data comes back. It does not, however, distinguish itself from siblings like amazonProduct, amazonProducts, or amazonSearch, which also return Amazon data.

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 when-to-use guidance and never names an alternative, so an agent must infer that rankings (as opposed to keyword search or single-product lookup) is the selection criterion. The only contextual signal offered is cost ('10 credits'), which is pricing, not 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 and openWorldHint, so the safety profile is covered. The description adds real value beyond them: the returned fields (title, price, rating, Prime, photo), pagination via 'page for more', and the 10-credit cost. It omits rate limits or result caps, but for a read-only search the disclosure is solid.

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 tight and front-loaded: what it searches, what comes back, then pagination and cost. The final '10 credits' fragment is slightly abrupt but every clause carries information.

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

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

With no output schema, the description usefully enumerates returned fields and signals pagination. However, it leaves 'department' unexplained and gives no guidance on limits, so an agent can call it but not fully exploit the parameters.

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 clarifies 'query' as a keyword and 'page' as pagination ('page for more'), but 'department' is never explained and no accepted values or page range (1-100) are given.

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 ('Search') plus resource ('Amazon US products') and scope ('by keyword'), and lists returned fields. It implicitly distinguishes itself from siblings like amazonRankings or amazonSuggestions, though it never names them 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?

There is no when-to-use vs when-not guidance and no mention of alternatives such as amazonProducts (bulk lookup) or amazonSuggestions (autocomplete). The only usage hint is 'page for more', which is pagination behavior, not selection 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 openWorldHint=true, covering the safety profile. The description adds genuinely useful behavioral context by disclosing the cost ("10 credits"), but says nothing about return format, rate limits, or whether suggestions are live. The credit disclosure earns credit beyond 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?

A single front-loaded sentence plus a cost tag; every element earns its place with no padding. Slightly terse but well-structured.

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

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

For a simple read-only suggestions endpoint with annotations covering safety and no output schema, the description is adequate but thin. It omits how suggestions are returned and any hint about the sibling amazonSearch, leaving a small gap for correct tool selection.

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

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

Schema description coverage is 67%, so query and department are documented in the schema; only limit lacks a description. "What a shopper has typed so far" in the schema already conveys the query semantics, and the description adds no parameter detail. 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?

States a specific resource (Amazon's autocomplete suggestions shown as a shopper types) with the verb implicit in the phrasing. It is understandable on its own, though it does not explicitly differentiate from the sibling amazonSearch, which an agent might reasonably confuse it with.

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?

"Useful for keyword research" implies a use case but gives no explicit when-to-use, when-not-to-use, or named alternative such as amazonSearch for actual result scraping. Usage is suggested rather than prescribed.

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 openWorldHint, so safety is covered. The description adds a useful behavioral fact not in structured data: pricing (page cost plus 5 credits). It omits other traits such as timeouts, retries, or how the AI extraction behaves on failed pages.

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, front-loaded with the core action and the two key parameters, with no filler. The pricing clause is short and 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 15-parameter scraping tool with no output schema and zero schema documentation, the description is too thin. It covers the AI-extraction core but leaves most browser/proxy/render controls unexplained, which an agent would need to invoke it correctly in non-default cases.

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% across 15 parameters, so the description must carry the load. It only explains 2 of them (ai_query, ai_schema) with brief examples, leaving url, wait, cookies, timeout, wait_for, proxies, rendering flags, and screenshot undocumented in both schema and description.

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 (fetch) and resource (web page) plus the distinctive behavior (AI extracts requested fields as JSON), which separates it from a plain fetch. However, it never names or contrasts against the closest sibling, scrapeWebsite, so the agent must infer the boundary.

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 explains the two usage modes (ai_query vs ai_schema) with examples, which is genuine guidance about how to invoke it. It does not say when to prefer this over scrapeWebsite or runBrowserScenario, nor mention prerequisites or exclusions.

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 openWorldHint=false, so the safety profile is covered. The description's only added behavioral detail is 'Free' (cost context), which is genuinely useful but minimal; it says nothing about whether the job must be finished, what happens on an unknown/expired job_id, 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?

Two short sentences with zero filler; the core action and the parameter's provenance are front-loaded. Nothing 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?

Wait — reassessing: with no output schema, the description does not state what a successful lookup returns (job status vs. scraped payload), which is a meaningful gap for a job-status tool. Score should be 3.

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 schema only tells the agent job_id is a non-empty string. The description compensates partially by explaining provenance ('the job_id it returned' from an earlier scrape), which is real added meaning. It still lacks any format example or validity constraints beyond that.

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: 'Look up an earlier scrape by the job_id it returned.' An agent can tell this is a retrieval tool for a prior job. It does not explicitly contrast itself with the similarly-scoped sibling pollJobUntilDone, so it falls short of a 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?

'an earlier scrape ... it returned' implies this is a follow-up call after initiating a scrape, which gives some usage context. But there is no explicit when-to-use/when-not guidance and no mention of the obvious alternative pollJobUntilDone, leaving the agent to infer which job-lookup tool fits a given situation.

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 openWorldHint, so safety is covered; the description adds genuinely useful context beyond that, notably the 10-credit cost and the pagination mechanism. It does not describe the shape or volume of returned reviews, but with no output schema that is a minor gap.

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

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

A single dense sentence front-loads the purpose, then chains identifiers, sort options, pagination, and cost with no filler. Efficient, though the run-on form makes the cost note easy to miss.

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

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

For a 7-parameter tool with zero schema descriptions, no output schema, and no required parameters, the description covers the essential path but leaves gl/hl semantics and identifier-selection rules undefined. An agent can likely call it, but not confidently for localization or missing-identifier cases.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It explains cid/fid/placeId as alternate place identifiers, enumerates sortBy values, and covers nextPageToken, but leaves gl and hl completely undefined and never states whether an identifier is mandatory.

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

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

Names a specific verb+resource (reviews of a place from Google Maps) and identifies the accepted identifier types, which clearly distinguishes it from siblings like googleSearch or extractStructuredData. It stops short of naming a sibling to defer to, but the purpose is unambiguous.

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

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

States where the required identifiers come from ('in a googleSearch places or maps result') and how to continue results via nextPageToken, plus the valid sortBy options. There is no explicit when-not guidance or statement of which identifier to prefer when several are available.

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 openWorldHint, so the description's job is to add context. It does: output format is JSON, cost is 10 credits, and places/maps results carry a cid usable with googleReviews. It omits pagination/rate-limit behavior, but the cost and cross-tool linkage are genuinely useful additions.

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

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

A single dense sentence with the core purpose front-loaded, followed by type enumeration, localization axes, the googleReviews linkage, and cost. Nothing 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 10 parameters, no output schema, and minimal annotation detail, the description covers cost, output format, and types but leaves most parameters and pagination behaviour unexplained. Adequate for a quick call, not for invoking the advanced parameters correctly.

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

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

Schema description coverage is only 20% across 10 parameters, so the description must compensate. It explains gl, hl, and the type enum, but leaves num, page, tbs, sortBy, ll, and autocorrect entirely undocumented in both places. It adds real meaning for three params but not enough to cover the 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+resource ('Google results as JSON') and enumerates the result types the tool can return, which lets an agent distinguish it from the platform-specific siblings (amazonSearch, instagramSearch, tiktokSearch). It does not explicitly say how it differs from googleReviews, though it hints at the connection via cid.

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

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

Usage is implied by the enumerated result types (use type=images for images, type=news for news), but there is no explicit when-to-use guidance and no named alternative such as googleReviews or scrapeWebsite. The cid mention is the only routing hint.

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 openWorldHint, so safety is covered. The description adds meaningful non-annotation context: a 5-credit cost and the important caveat that very large accounts expose only ~50 recent followers, plus a mitigation. It does not describe rate limits beyond moderation or return shape.

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

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

Three tight sentences, front-loaded with purpose and required identifiers, then search/paging mechanics, then the large-account caveat and cost. No filler sentences; every clause carries actionable information.

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

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

For a two-required-parameter read tool with no output schema, the description covers purpose, search, paging, cost, and the known data limitation. It never hints at what a page of results contains, but that gap is minor given the simplicity of the 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 coverage is 75%, with query and max_id already documented in the schema. The description adds semantics for the undocumented 'direction' parameter by spelling out 'followers or following', and reinforces that query matches username or name across the whole list, going slightly beyond the bare schema text.

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

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

The description opens with a specific verb+resource: 'List or search an Instagram account's followers or following'. It also names the direction enum values and the source of user_id ('from instagramUser'), which distinguishes it from instagramUser/instagramSearch and the parallel tiktokFollowers 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 when to use query (to search the whole list, and specifically to find someone in large accounts) and what max_id does (paging). It doesn't explicitly rule out alternatives, but the routing is clear enough for an agent to pick this tool over instagramUser or tiktokFollowers.

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 openWorldHint=true, so safety and external-network behavior are covered structurally. The description adds one genuinely useful behavioral fact — the 5-credit cost — but says nothing about pagination behavior, rate limits, or whether private accounts fail.

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

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

One dense, front-loaded sentence organized by mode, followed by a cost note. Every clause maps to a mode or parameter, so little is wasted, though the mode list is packed tightly enough to require a second read.

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

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

For an 8-mode, 11-parameter tool with no output schema, the description covers mode selection well but omits pagination mechanics (end_cursor, pagination_token) and the count cap, which an agent needs to page through results correctly.

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

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

Schema description coverage is only 18%, so the description must compensate, and it does partially by binding modes to user_id, shortcode/url, comment_id, and username. However, several of the 11 parameters — count, end_cursor, pagination_token, media_id, code_or_id_or_url — get no explanation anywhere, leaving the pagination and count semantics undocumented.

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

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

Names a specific resource (Instagram content) and enumerates the exact modes it serves — posts, reels, tagged posts, single media, comments, comment replies, stories — each tied to its identifying parameter. An agent can distinguish it from instagramUser, instagramSearch, and instagramFollowers 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?

The mode-to-parameter mapping (user_id for account feeds, shortcode/url for a single post, comment_id for replies, username for stories) effectively tells the agent which mode to pick and what it requires. It stops short of naming alternatives or when-not-to-use conditions versus instagramSearch/instagramUser.

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 openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful non-structured detail, the '5 credits' cost, but omits result limits, pagination, and auth requirements.

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 front-loaded sentence with zero wasted words that covers scope, the type selector, and cost. Appropriately sized for a two-parameter search 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?

For a 2-param search tool with no output schema, the description covers the search types and cost but leaves the keyword semantics and any notion of result shape or volume unexplained. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain search_type by mapping its enum values to entity types (including 'global' = everything), but the required 'keyword' parameter is left entirely undocumented, and 'users' is referred to as 'accounts', a minor mismatch.

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 (Search) and resource (Instagram) and enumerates the entity types it covers (accounts, hashtags, places, posts, global). This clearly distinguishes it from siblings like instagramUser or instagramMedia, though it does not name them 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?

It implies when to use via the entity-type enumeration and the 'or everything at once (global)' clause, but offers no explicit when-to-use vs. when-not guidance or alternatives. Usage selection is largely 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?

Annotations cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new behavioral context: a concrete cost of '5 credits' and the fact that the numeric user id is the input other tools require, which supports tool chaining. It does not cover error behavior or rate limits, but that is a minor gap given annotation coverage.

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 returned payload first, then the input constraint and cost. Every clause carries information and 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, the description usefully enumerates the returned fields, and it states cost and the one-of input rule. What remains unstated is failure behavior for missing/invalid identifiers, but for a read-only profile lookup the definition is close to sufficient.

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% and all three parameters are optional, so the schema does not enforce any selection rule. The description supplies the critical constraint that exactly one of username, user_id or url should be passed, which the schema itself does not express. It stops short of explaining format differences between the three (e.g. URL vs handle).

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 resource and enumerates its contents (bio, follower/following/post counts, links, numeric user id), so an agent knows exactly what comes back. It does not explicitly contrast itself with close siblings like instagramFollowers or instagramMedia, leaving the boundary slightly implicit.

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

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

It gives invocation guidance ('Pass one of username, user_id or url') but no when-to-use or when-not guidance relative to alternatives such as instagramSearch or instagramMedia. Usage is implied by the resource description rather than stated.

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 openWorldHint=false, so the safety profile is covered. The description adds cost information ("Free") and states what the response contains (tools, routes, parameters), which is context beyond 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?

A single front-loaded sentence with the key information first and the cost note trailing. No wasted words.

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

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

For a parameterless, read-only discovery tool this covers what an agent needs: what is listed and that it costs nothing. With no output schema, a brief note on the shape of the returned data is helpful, though it does not describe return format or structure in detail.

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?

Zero parameters, so the baseline is 4. The description correctly implies no inputs are needed to enumerate the capabilities, and there is nothing in the schema for it 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?

Specific verb+resource: it lists every ScrapingBot tool, the API routes behind them, and their parameters. This is a meta/discovery capability that none of the sibling operation tools provide, so an agent can distinguish it immediately.

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 word "Free" implies this is a no-cost discovery call compared with the paid scraping siblings, which is useful routing context. However, there is no explicit when-to-use statement, no exclusion, and no named alternative for discovering or invoking the listed 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 openWorldHint=false, so safety is covered. The description adds the genuinely useful facts that this call blocks until completion and is 'Free,' but says nothing about timeout behavior or what happens when the poll times out.

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 blocking action, with no filler. It is tight, though the brevity is partly under-specification rather than pure economy.

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 blocking/polling tool with no output schema and zero parameter documentation, the description omits the essential polling contract: timeout behavior, retry semantics, and expected return. An agent cannot safely call it without guessing.

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 carries the full burden for job_id, timeout_ms, and poll_interval_ms, and it explains none of them. The names are fairly self-explanatory, but timeout and poll-interval semantics (units, what happens on expiry) are undocumented in both places.

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

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

States a clear verb+resource: wait for a scrape job to finish, then return it. However, it does not distinguish itself from the sibling getScrapeJob, which an agent could reasonably confuse it with.

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

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

No guidance on when to use this versus getScrapeJob or the other scrape tools. The single word 'Free' hints at a cost consideration but leaves the alternative-selection decision entirely to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world behavior are covered. The description adds one useful non-duplicated trait — 'costs the same as that API' — but says nothing about required credentials, rate limits, error behavior, or how the free-form params are applied, which matters for an open-ended proxy 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?

A single tight sentence with the purpose and provider scope front-loaded, plus a parenthetical pointer to listCapabilities. No filler; the only slight drag is the cost clause tacked on at the end.

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?

As an open-ended passthrough to four external APIs with no output schema and undocumented parameters, the description covers routing well but is thin on parameter mechanics, auth expectations, and result shape. It is adequate to start but not fully sufficient for confident 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% across 3 params, so the description must carry the load. It conveys the provider+endpoint mental model ('by path') and echoes the four provider options, but the nested free-form 'params' object — the most ambiguous parameter — is left completely unexplained, so it only partially compensates.

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 (Call) and resource (any Google/Instagram/TikTok/Amazon endpoint by path) and explicitly positions itself against siblings: it exists for 'the few the other tools do not cover.' An agent can tell instantly why it would pick providerRequest over amazonSearch or tiktokVideo.

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 a clear selection rule (only endpoints the other tools do not cover) and points to listCapabilities as the discovery mechanism for those endpoints. The exclusion is implied rather than spelled out per-provider, but the routing guidance is genuinely actionable.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds useful context such as using a real browser, returning markdown, and starting from 5 credits, but it omits operational details like step limits, timeout behavior, and proxy/stealth implications.

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 core operation, and includes a concrete js_scenario example plus cost note. It could be slightly clearer about how the example maps to required parameters, but there is little wasted 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 15-parameter tool with no output schema and very low schema description coverage, the description is too thin. It does not explain most parameters, and its statement that the tool returns markdown omits the html format option exposed by the 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 only 7% with 15 parameters, so the description must carry most of the semantic load. It provides a js_scenario example and mentions markdown output, but leaves url, cookies, timeout, wait, wait_for, block_ads, render_js, screenshot, wait_browser, proxy options, block_resources, and capture_runtime_issues essentially undocumented.

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

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

The description gives a specific verb and resource: open a page in a real browser, run click/fill/scroll/wait steps, and return the page as markdown. It distinguishes itself from static scraping siblings through the browser-interaction framing, but it does not explicitly name an alternative 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?

Usage is implied by the browser-automation scenario and the js_scenario example. However, there is no explicit guidance on when to choose this tool versus scrapeWebsite, extractStructuredData, or other siblings, and no when-not-to-use conditions.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: per-feature credit costs and the option to attach a screenshot. However, it says nothing about the many behavioral knobs (wait, wait_for, wait_browser, timeout, block_ads, block_resources, cookies, capture_runtime_issues).

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?

Compact and front-loaded: core behavior first, then costs, then the screenshot option, with zero filler sentences. It is dense rather than bloated, though the cost list is somewhat shorthand for a reader unfamiliar with the tiering.

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 14-parameter, open-world scraper with no output schema, the description omits most of the configurable behavior an agent needs to call it well. It covers the headline output and pricing but not enough of the request semantics to be self-sufficient.

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

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

Schema description coverage is only 7% across 14 parameters, so the description must carry the load and largely does not. It explains format, render_js, screenshot, premium_proxy and stealth_proxy, but leaves roughly nine parameters (wait, wait_for, wait_browser, timeout, cookies, block_ads, block_resources, capture_runtime_issues) undocumented anywhere.

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 (fetch a public web page, return content as markdown) with a precise output format. It doesn't name or contrast any sibling such as extractStructuredData or runBrowserScenario, so the agent gets a clear action but no routing signal.

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 or when-not-to-use statement and no named alternative among the 22 siblings. The credit tiers (render_js 5, premium_proxy 10, stealth_proxy 75) implicitly hint at escalating cost and therefore when each option is warranted, which is useful but indirect.

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 openWorldHint=true, so the read-only, network-facing profile is covered. The description adds a concrete cost signal ('1 credit'), which is valuable context not in the structured fields, but it says nothing about pagination via cursor or how many results a page returns.

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

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

A single dense sentence plus a short credit note. The two operating modes are front-loaded and 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?

For a read-only scraping tool with no output schema and annotations covering the safety profile, the description does enough to route the call correctly but leaves pagination behavior (cursor) and result shape unaddressed, which matters for a tool that caps count at 50.

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 60%, and the description does add real value by explaining the conditional relationship between url, video_id and comment_id (which parameters apply to which mode). It leaves 'cursor' and 'count' completely unexplained in both schema and description, so half the pagination/limit semantics remain opaque.

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 resource (comments) and the two modes it supports: top-level comments on a video, or replies to a single comment. It distinguishes itself from generic siblings like tiktokVideo and tiktokUser, though the phrasing 'Comments on a TikTok video' reads like a noun-as-verb and takes a moment to parse.

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

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

Usage is implied through the parameter combinations ('url' for comments, 'comment_id plus the video url or video_id' for replies), which is genuinely useful routing information. However, it never states when an agent should pick this over a sibling tool, nor any preconditions.

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 openWorldHint, so safety is covered. The description adds two non-obvious behavioral facts beyond the schema: a hard cap of 'Up to 50' results per call (implied pagination limit) and a cost of '1 credit' per invocation, which is genuinely useful operational context.

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 terse fragments, front-loaded with the core purpose, then the id source, limit, and cost. Almost no waste, though the fragments are somewhat telegraphic and the id-parenthetical interrupts the main clause.

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

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

No output schema exists, yet the description does not describe the return shape (e.g., a list of user objects), only the cap and cost. With low schema coverage and no output schema, an agent gets enough to invoke but not enough to interpret the response fully.

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

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

Schema description coverage is only 33% (only user_id is documented), so the description must compensate. It adds the natural-language meaning of direction ('followers or the accounts it follows'), and echoes the count cap of 50, but leaves count's semantics and the exact followers/following enum mapping only partially clarified.

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 and dual operation ('followers or the accounts it follows') for a TikTok account keyed by numeric user_id. It partially distinguishes itself by pointing at tiktokUser as the source of the id, though it doesn't contrast sharply with siblings like instagramFollowers or tiktokUser.

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

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

Usage is implied rather than stated: the description notes the id comes from tiktokUser (data.user.id), which tells the agent a prerequisite step. It never says when to choose this over alternatives or when direction=followers vs following applies.

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 openWorldHint, so safety is covered. The description adds the useful cost signal '1 credit,' but stays silent on pagination behavior despite a cursor parameter and on result limits.

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

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

Two compact sentences with the core action and the mode mapping front-loaded, and the credit cost appended. 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?

With no output schema and a cursor-based pagination parameter, an agent lacks any statement about result shape or how to page. The essentials for invocation are present, but the definition is thin for a 4-parameter search tool.

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

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

Schema description coverage is 0%, so the description must carry the load; it explains the search_type enum values, the most consequential parameter. It says nothing about query, count (max 100), or cursor semantics, so half the burden remains unmet.

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

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

Names a specific verb (Search) and resource (TikTok creators/videos) and maps both search_type values inline, so the agent knows the two operating modes. It does not distinguish itself from siblings like tiktokUser or tiktokVideo, which fetch single entities.

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 '(search_type: users) or (videos)' clarifies which mode to pick, which is the main usage decision. It gives no guidance on when to prefer this over tiktokUser/tiktokVideo or whether keyword search vs direct lookup is appropriate.

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 openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the cost ('1 credit') and the fact that the payload can be either profile metadata or a video list depending on include_posts. It does not mention rate limits, auth, or pagination for the posts mode.

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 semicolon-linked sentence that front-loads the resource and what is returned, then the mode flag, then cost. No filler; every clause adds information an agent would otherwise have to guess.

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

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

With no output schema, the description compensates by enumerating the profile fields and noting the alternate video-list return shape. For a two-parameter read tool this is close to complete, though post-mode details such as count or pagination are left unstated.

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 the parameter burden, and it largely does: unique_id is explained as a username lookup and include_posts is explained as a mode switch to latest videos. It omits formatting details for unique_id (e.g., whether the '@' prefix is accepted).

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 and retrieval mode: a TikTok profile keyed by username, enumerating the returned fields (bio, counts, verified badge, numeric user id). It also distinguishes the include_posts mode as returning videos instead. It doesn't explicitly name sibling tools like tiktokVideo or tiktokSearch, so differentiation is partial rather than crisp.

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 clause 'include_posts returns the latest videos instead' gives one concrete usage switch between two modes of this tool. However, there is no guidance on when to prefer this tool over siblings such as tiktokSearch, tiktokVideo, or tiktokFollowers, so selection context is only implied.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's main added value is the '1 credit' cost disclosure, which is real operational context. It says nothing about failure modes for private/deleted videos, rate limits, or response shape.

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

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

One sentence that leads with the resource and payload, then the input, then the cost. No filler and nothing redundant with structured fields.

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 usefully enumerates what comes back (stats, caption, author, sound, download links) and states the cost, which is enough for an agent to call it. It could still note accepted URL shapes and what happens on invalid/private videos.

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% and the single required 'url' parameter has no schema description, so the description must carry it. 'by video URL' confirms the parameter is a full video URL rather than an ID or handle, but adds no format examples (e.g. vm.tiktok.com short links) or validation guidance.

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

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

Names the exact resource (a TikTok video) and enumerates the payload fields returned: stats, caption, author, sound and download links, keyed by video URL. This distinguishes it from siblings like tiktokUser, tiktokComments and tiktokSearch, though it is phrased as a noun list rather than a verb+resource.

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?

'by video URL' implies the only invocation context: you must already have a video URL, so this is not a search/discovery tool. There is no explicit statement of when to pick it over tiktokSearch or tiktokUser, and no exclusions or prerequisites are given.

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