Influship

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description still adds real value by characterizing cost/latency ('cheap and fast') and by explaining that returned IDs feed downstream tools like get_creator and match_creators. Describing the return fields is somewhat redundant given an output schema exists.

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?

Content is front-loaded with the purpose, then routing guidance, then examples, so an agent can stop reading early. It runs longer than necessary, and the clause about search_creators having 'a less typeahead-specific name' is slightly muddled relative to the earlier framing.

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 annotations covering safety and an output schema covering returns, the description supplies the remaining decision-critical context: cost profile, alternatives, and ID chaining for downstream calls. Only the scope enum semantics remain undocumented anywhere in the definition.

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

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

Schema coverage is 100%, so q, limit, scope, and platform are all documented in the schema; the description adds only that q matches names, usernames, and display names via partial input. The 'scope' enum (creator_only / matched_platforms / all_platforms) is the one genuinely ambiguous parameter and is left unexplained in the 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 and resource ('Autocomplete creator names, usernames, or display names from partial input') and immediately differentiates itself from the lookalike siblings that could be confused with it. The first sentence alone lets an agent distinguish this from search_creators or get_profile.

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

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

Explicitly enumerates when to use this tool ('user types a partial handle or name', 'who's that fitness coach called Jane?') and when not to, naming concrete alternatives: get_profile for exact platform+username, search_creators for fuzzy lookup, semantic_search_creators for topic/geography/style discovery. The three worked examples reinforce the routing rules.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered; the description still adds real value by explaining the blending/ranking mechanism, that results are scored, and that a seed_not_found response means the seed is unavailable and should not be retried. It does not mention pagination behavior via cursor, which is the one behavioral 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?

Front-loaded with the core purpose, then usage, then alternatives, then examples — a logical order with no filler sentences. It is on the longer side and the examples restate guidance already given, but each section earns its place for a tool with 12 parameters and three near-siblings.

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

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

An output schema exists and annotations cover safety, so the description's job is routing and seed semantics — both handled thoroughly, including the failure mode (seed_not_found) and the handle-resolution prerequisite. Nothing an agent needs to invoke this correctly is missing beyond an optional note on cursor-based pagination.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes beyond it by explaining that seeds can be supplied via seed_creator_ids (canonical UUIDs) and/or seed_profiles (platform + username), that the two are blended, and that the flat follower/engagement-rate/verified fields constrain results. It does not cover the context, llm_model, or conversation_id parameters, but those are densely self-documented in the schema.

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

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

States a specific verb and resource ("Find creators SIMILAR to one or more seed creators") and immediately clarifies the mechanism: blended creator-profile, visual-style, and fact embeddings yielding a ranked list. This is plainly distinguishable from sibling tools like semantic_search_creators and match_creators without opening a schema.

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

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

Gives explicit when-to-use criteria ("user already knows a creator they like and wants more like them"), names two alternatives with the conditions that select them (semantic_search_creators for topic-only queries, match_creators for scoring specific candidates), and points to autocomplete_creators for handle resolution. The two worked examples, including one negative example, remove ambiguity.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavior beyond that: include:['profiles'] only augments UUID lookups, while platform+username resolves through the profile endpoint and returns both the profile record and the underlying creator record. No error or not-found behavior is discussed, keeping it short of a 5.

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

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

Front-loaded with the core statement, then a bulleted list of accepted inputs, then examples — a scannable structure. The three worked examples are somewhat repetitive and the second one mostly restates alternative routing already covered, but nothing is misleading or padded with filler.

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

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

Output schema exists, so return values need not be explained, and the description still covers the dual input modes and the differing response shape for each. For a 7-parameter read tool with formal annotations, an agent has everything needed to select and call it 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 coverage is 100%, so all seven parameters are already documented. The description does add meaning beyond the schema for the include parameter (works only with a UUID) and for how platform+username are combined, but says nothing about the analytics-only parameters context, llm_model, and conversation_id. Baseline 3 plus partial added value fits.

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

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

The first sentence names a specific verb and resource ("Fetch the full record for a single creator") and states the two accepted lookup keys (UUID or exact platform+username). This clearly separates it from search_creators, semantic_search_creators, get_profile, and lookup_profiles, which are all named.

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?

Explicit preconditions are given ("Use this when you already have either...") along with the upstream tools that produce the UUID. Alternatives are named with selection criteria: get_profile/get_posts for platform metrics, lookup_profiles for batch, and a worked example routing the "profile metrics" case away from this tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered; the description earns credit for adding the non-obvious caching/freshness trait ("raw", "not guaranteed on regular cached ... endpoints") plus an enumeration of the extra fields it can surface (coauthors, tagged users, paid partnership, product mentions, music, location, video versions). It says nothing about the conversation_id handshake or rate limits, which matters for a metered fetch.

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

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

Two sentences, front-loaded with the action, and the second sentence carries the useful disambiguation and field list. The mid-sentence line breaks are cosmetic, but the field enumeration runs slightly long given that the output schema already exists.

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

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

With an output schema present and full schema descriptions, the description needn't explain return values, and it doesn't. However, it never names the sibling it competes with (get_instagram_posts / get_posts) and says nothing about the stateful conversation_id flow the required-parameter set imposes, leaving the agent to derive routing and sequencing from schema and context 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 description coverage is 100%, so shortcode, context, llm_model, and conversation_id are all documented in the schema itself. The description only reinforces that shortcode keys the lookup; it adds no format or origin detail (e.g., that reels/tv shortcodes are equally valid) beyond the schema, so the baseline 3 applies.

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

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

"Fetch raw Instagram post-page data by shortcode" gives a specific verb (fetch), a specific resource (Instagram post-page data), and the keying input (shortcode). The phrase "not guaranteed on regular cached post-list endpoints" implicitly distinguishes it from the plural list sibling get_instagram_posts, so an agent can pick correctly without opening schemas.

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

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

"Use this when the user needs fresh raw Instagram post metadata that is not guaranteed on regular cached post-list endpoints yet" gives a clear positive trigger (need freshness/fields beyond cache). It stops short of naming get_instagram_posts or get_posts explicitly as the alternative, and gives no when-not condition, so routing depends on 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description does add genuine value by disclosing auto-retry of transient upstream failures within the request deadline and per-item success/error reporting, i.e. partial-failure semantics. It stops short of stating rate limits or whether errors consume the deadline.

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

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

Two tight sentences, front-loaded with the action and scope, then the delivery guarantee. Nothing is padded, though the second sentence could be trimmed since the output schema already describes the return shape.

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 annotations, a full-coverage schema and an output schema, the description only needs to carry the extras, which it mostly does (retry behavior, per-item errors). The remaining hole is sibling disambiguation against get_instagram_post.

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

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

Schema coverage is 100%, so all four parameters (including the analytics-only context/llm_model and conversation_id) are already documented in the schema. The description adds only the notion that shortcodes form a 'bounded list' and that one item is returned per shortcode, which is marginal beyond the schema's minItems/maxItems.

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 raw Instagram post-page data') plus scope ('for a bounded list of shortcodes through the raw API'). The plural/batch nature is clear, but it never distinguishes itself from the sibling get_instagram_post (singular) or get_posts, which is the differentiation an agent most needs here.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The agent is not told when to pick this batch tool over get_instagram_post (one post) or get_instagram_post_transcripts, nor what 'raw' excludes relative to those siblings. The 'bounded list' phrasing only vaguely implies batch usage.

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 readOnly, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely non-obvious runtime behavior: the response shape depends on cache state (miss includes raw post metadata, hit omits the post field). It doesn't mention rate limits, failure modes, or what happens for non-video 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?

Two sentences, both earning their place: the first establishes action and input, the second delivers the cache-dependent response behavior and the fallback tool. Front-loaded and free of filler.

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

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

An output schema exists, so return values need no prose, and the cache-state nuance is still explained. The only gap relative to its siblings is the lack of any reference to the batch transcript tool, leaving the reader to resolve that ambiguity from names 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 description coverage is 100%, so context, llm_model, shortcode, language, and conversation_id are already documented in the schema. The description only reinforces the shortcode parameter and adds nothing new about language auto-detection or conversation_id handling; baseline 3 applies.

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

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

States a specific verb and resource ('Transcribe an Instagram video post') plus the required identifier ('by shortcode'), and explicitly separates itself from get_instagram_post. It does not, however, distinguish itself from the near-identical sibling get_instagram_post_transcripts (batch variant), which an agent could easily 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?

Gives an explicit routing rule: use get_instagram_post when post metadata is needed alongside a cached transcript. That is a clear conditional context. It omits the other obvious alternative — the plural/batch transcript tool — so the when-to-use picture is clear but incomplete.

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

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

With readOnlyHint=true and destructiveHint=false already covering safety, the description adds real behavioral context beyond annotations: the shape of each successful item and the fact that the nested post field appears on cache misses but is absent on cache hits. That cache-dependent shape variance is exactly the kind of non-obvious trait an agent would otherwise mishandle, though it says nothing about partial failures when some shortcodes lack transcripts.

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, front-loaded with the core action, then the return-shape caveat, then the sibling routing. The only slightly wasteful element is "through the raw API," which adds little operational meaning, but nothing is padded or buried.

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

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

An output schema exists and annotations cover the safety profile, so the description need not restate return values or permissions. It covers the batch scope, the cache-dependent nesting quirk, and the sibling alternative. The remaining gap is what happens when individual shortcodes fail transcription, which is a plausible agent question for a batch 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 100%, with every parameter including `context`, `llm_model`, and `conversation_id` documented in the schema itself. The description only echoes the shortcode list and the bounded-list constraint already implied by maxItems. Baseline 3 is appropriate since the schema carries the parameter burden.

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

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

The description opens with a specific verb and resource ("Transcribe a bounded list of Instagram video posts by shortcode"), and "bounded list" plus "shortcodes" immediately separates it from the singular get_instagram_post_transcript sibling. An agent can distinguish the batch form from the single form without opening any schema.

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

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

It names a concrete alternative and the condition that should route the agent there: use `get_instagram_posts` when post metadata is needed for every shortcode. It does not explicitly address the singular `get_instagram_post_transcript`, so the when-to-use guidance is clear but not exhaustively disambiguated across 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?

Beyond the readOnly/openWorld annotations, the description discloses cost (0.5 account credits, posts included), null semantics for unavailable view counts, and that engagement rate is derived only from returned posts and is null on profile-only lookups. These are behavioral facts an agent cannot obtain from the annotations or schema and they materially affect how the tool is called.

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

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

Front-loaded with purpose and returns, then scope, then cost—no filler sentences. It is dense but a few clauses (the 1–50 posts list, leading @) restate schema facts and could be trimmed without loss.

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

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

With an output schema present, the description need not explain return shape, yet it helpfully flags null values; six parameters with three bookkeeping ones (context, llm_model, conversation_id) are covered by schema. Remaining gap is the absence of failure/precondition behavior for non-public or missing usernames in an open-world tool.

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

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

Schema coverage is 100%, so every parameter including post_limit bounds and the leading-@ rule is already documented in structured fields; the description largely repeats that. The one genuine addition is the coupling between include_posts and engagement-rate nullability, which the schema does not state.

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 ('Retrieve a live Instagram profile by exact public username') and enumerates the returned fields (biography, follower/follower counts, collection time). It explicitly distinguishes itself from the sibling that fetches stored data ('stored creator evidence is a separate lookup'), so an agent can choose between get_creator and this tool 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?

It gives the selection context (source-platform lookup vs stored creator evidence) and the optional expansion path ('Optionally include 1–50 recent posts'), which implies when to set include_posts. What it lacks is an explicit when-not statement, e.g. for private, deleted, or non-existent accounts, or guidance versus get_instagram_posts for post-only retrieval.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered and the description correctly does not repeat it. It adds nothing beyond that, however: the stateful conversation_id handshake, the prohibition on parallel calls before the first response, and the fact that this is a meta/discovery call with a non-data payload are all disclosed only in the schema, not the description.

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 an em-dash clause carrying the only caveat that matters. Nothing is wasted and the trigger precedes the qualifier.

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

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

There is no output schema, so the description carries the burden of explaining what a call yields, and it does not: an agent cannot tell whether it receives tool definitions, a yes/no answer, or instructions to re-query. The rich schema descriptions recover the procedural half of that gap, but the outcome of the call remains unstated for a three-parameter, open-world 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 100% and the parameter descriptions are unusually rich, including a full explanation of the conversation_id lifecycle and a no-guessing rule for llm_model. The description adds no parameter-level meaning at all, so the baseline 3 applies.

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

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

The description states a specific action ('Check for additional tools') and its trigger ('whenever your task might benefit from specialized capabilities'), which is enough to separate it from every sibling, all of which are concrete Instagram/TikTok/YouTube data tools. It stops short of saying what actually comes back (a set of newly available tool definitions), so the agent knows the intent but not the mechanism.

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 explicit call-condition guidance, including a deliberate anti-hesitation clause ('even if existing tools could work as a fallback'), which is the key decision an agent faces with a discovery tool. It omits any when-NOT guidance (e.g., don't call repeatedly once tools are loaded), which is the main failure mode for a tool like this.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered; the description adds the limit cap of 50 and cursor-bound-to-sort behavior, which are meaningful constraints. It does not disclose rate limits, auth requirements, or the notable fact that only Instagram is currently a valid platform despite the generic tool name.

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

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

Front-loaded with the verb and resource, then organized into usage, parameter notes, return shape and examples. Slightly redundant with the schema on defaults, caps and the cursor rule, and the return-value sentence is unnecessary given an output schema exists.

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

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

Covers identification, sorting, pagination and workflow placement well, and the output schema plus annotations carry return format and safety. The gap is the Platform enum being Instagram-only, which an agent could miss given the generic name and heading into a 400.

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

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

Schema description coverage is 100%, so all six parameters are already documented, and most of the description's parameter text (defaults of 12 and "recent", the 50 cap, cursor binding) restates the schema. The one added value is framing the identifier as creator_id OR platform+username in prose, which is a marginal gain over the schema.

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

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

States a specific verb and resource ("Fetch a creator's posts"), plus the sorted/paginated modifiers that define scope. It is clearly distinct from transcript/profile siblings, though it never explains how it relates to the platform-specific siblings like get_instagram_posts or list_tiktok_profile_videos that overlap heavily with it.

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 an explicit triggering condition ("Use this when the user asks to see what a creator has posted") plus three concrete example utterances, and even places itself in a workflow after get_profile and before match_creators. It stops short of stating when NOT to use it, e.g. when a platform-specific sibling is preferable.

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, destructiveHint false and openWorldHint false, so safety is covered; the description adds real value beyond that by disclosing the payload (bio, follower/engagement metrics, recent activity, growth, canonical creator ID), the dual profile+creator return shape, and server-side case-insensitive matching. No permissions, rate-limit, or failure behavior is mentioned, keeping it short of a 5.

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

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

Front-loaded with purpose, then usage, then examples, then routing — a logical order with each sentence carrying instruction. The three examples are slightly redundant with the prose above them and add bulk, but they resolve real parsing ambiguity.

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

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

For a 5-parameter lookup tool with an output schema, the description covers entry conditions, input formatting, return contents, and the follow-on calls (get_posts, match_creators) an agent would need. Nothing required to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by telling the agent to strip the @ and that matching is case-insensitive, and by explaining how to derive platform/username from a profile URL. It does not address context, llm_model or conversation_id, but those are fully documented in the schema.

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

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

Opens with a specific verb and resource — "Fetch a single social profile by (platform, username)" — and immediately scopes it against the near-identical siblings get_creator and lookup_profiles. An agent can pick it out of the crowded profile/video tool list without reading 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?

Explicitly states when to use it (exact handle on a specific platform), when not to ("Do not use `search_creators` for an exact platform+username lookup"), and routes to alternatives by condition (get_creator for UUIDs, lookup_profiles for batch). Three worked examples cover the URL-parsing and chained-call cases.

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

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

Annotations already declare readOnly/non-destructive/closed-world, so the added value here is that this is a single fixed sample rather than live data and that live discovery is gated behind account linking. It also constrains agent behavior post-call (no plans, pricing, credits, upgrades, purchasing). It does not describe the response shape, but an output schema exists so that burden is lower.

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

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

Four short sentences, front-loaded with the trigger, then the mechanics, then the exclusion, then the post-call constraint. It is efficient, though the final policy sentence is slightly prescriptive rather than descriptive.

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 single-record preview with annotations covering safety, a full schema, and an output schema, the description covers purpose, boundaries, and required follow-up. Only the return content itself is unaddressed, which the output schema handles.

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

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

Schema description coverage is 100%, with context, llm_model, and conversation_id all thoroughly documented in-schema, including the conversation_id handoff rule. The description adds nothing about parameters, which is acceptable but is the baseline only.

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 ('Fetches one configured sample creator with social profile context') and immediately frames it as a preview tool, which separates it from search/match/comparison siblings like search_creators and match_creators.

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 an explicit trigger ('when a user wants to see what Influship can return before linking an account') and explicit exclusions ('should not be used for search, discovery, matching, or comparison requests'), plus the required follow-up framing about needing an account.

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

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

Annotations already establish readOnly, non-destructive, open-world. The description adds behavior the annotations do not: missing fields are returned as null, audio/cover URLs are temporary and not durable, and each call is metered. That metering note is the most valuable addition for cost-aware agents, though it does not quantify the cost or state failure behavior.

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

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

Four short sentences, front-loaded with the purpose, then caveats in descending order of importance. No sentence is redundant and nothing is buried.

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

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

An output schema exists, so return-value explanation is not required, and the description fills the remaining gaps (nullability, URL expiry, metering). For a simple single-record fetch with fully documented parameters, it is nearly complete; only the relationship to the sibling listing tool is 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 coverage is 100%, so the schema already carries full parameter meaning, including the music_id vs recording/album distinction and the constraint on the other three parameters. The description only restates that music_id is the lookup key, adding no format or semantics beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource combination: 'Fetch sound clip metadata by music_id'. The lookup key is explicit, so an agent knows this is a single-sound lookup rather than a listing. It does not explicitly distinguish itself from the sibling list_tiktok_music_videos, which is the nearest source of confusion.

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

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

The description implies usage (you have a music_id, you want its metadata) but never states when to prefer this over list_tiktok_music_videos or get_tiktok_video. There are no exclusions or prerequisite call guidance; the metering note hints that calls should be deliberate but is not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are live and normalized, a leading '@' is tolerated, and the call is metered (quota-relevant). It does not mention behavior for nonexistent/private accounts, though the output schema covers the success 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 short sentences, each earning its place: identity of the operation first, then return contents, then the cost signal. No restatement of the title and no filler.

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

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

With an output schema present, the description does not need to explain the response shape, and it correctly focuses on scope, normalization, and metering. The only material gap for a live external fetch is error behavior on missing or private profiles, which neither annotations nor description address.

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

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

The schema leaves the required 'username' parameter completely undescribed (75% overall coverage), so this is where the description must compensate. It does so by stating that input is normalized and a leading '@' is accepted, which is exactly the missing semantics. The analytics parameters (context, llm_model, conversation_id) are already fully documented in the schema.

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

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

The description names a specific verb and resource ('Fetch a current, normalized TikTok profile by username') and enumerates what it returns (identity, biography, verification, audience metrics), which cleanly separates it from get_instagram_profile, get_youtube_channel, and the TikTok video/comment siblings. It stops short of naming an alternative for username resolution (e.g., search_tiktok_users), so it is clear but not fully discriminating between siblings.

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

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

Usage is implied by the 'by username' framing, and 'This is a metered live-data request' gives a real cost consideration that should make an agent prefer a cached or search tool when appropriate. However, there is no explicit when-to-use/when-not-to-use statement and no alternative tool is named for resolving an unknown handle.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value beyond them: media URLs are temporary, content always resolves to the US region, and each successful call costs 0.2 credits. It does not describe pagination, failure modes, or error behavior, which limits it to a 3.

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

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

Four short sentences, zero filler, with the core purpose front-loaded before the qualifiers about URL forms, region, and cost. Every sentence contributes a distinct operational fact.

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

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

An output schema exists, so return values needn't be explained, and the temporary-URL and region caveats cover the main surprises. Still missing is any guidance on how this differs from the many TikTok transcript, caption, comment, and list siblings, which is material given the crowded toolset.

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 only touches the url and region parameters, explaining that both canonical and share URLs work and that region is fixed to US. It says nothing about the required context, llm_model, or conversation_id parameters, so it does not compensate for the undocumented portions of the schema.

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

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

The description names a specific verb and resource ('Fetch normalized details and current engagement metrics for a TikTok video URL'), which lets an agent tell it apart from transcript/caption siblings. It stops short of explicitly contrasting with get_tiktok_videos or get_tiktok_video_transcript, so differentiation is implied rather than stated.

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

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

It usefully clarifies accepted input forms (canonical and share URLs) and notes the 0.2-credit cost, which affects whether to call it. However, there is no explicit when-to-use guidance against alternatives such as get_tiktok_video_transcripts or get_tiktok_videos, leaving routing 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 read-only, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral facts: a hard error when captions are missing and a 0.2-credit cost that applies even to cache hits — both are non-obvious and affect invocation decisions.

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

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

Three short sentences, zero filler, with the core operation stated first and the cost/error caveats following. Every sentence carries a distinct, useful fact.

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

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

With an output schema present, the description need not explain the caption payload, and the credit and error semantics are covered. It could note whether the url must be a specific video (vs. profile/short link), but overall the description is sufficient for a 4-parameter read tool.

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

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

Schema coverage is 75% with detailed prose for context, llm_model, and conversation_id; the url parameter is typed only via a TikTokVideoUrl $ref. The description adds no parameter-level meaning beyond the schema, which is acceptable at this coverage level but not additive.

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 available captions for a TikTok video) and immediately contrasts it with the sibling capability of transcript generation, so the agent can distinguish it from get_tiktok_video_transcript(s) without opening a 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?

"without generating a transcript" gives clear selection context against the transcript siblings, and the error note on missing captions tells the agent what failure looks like. It stops short of explicitly naming the alternative tool or saying what to do when captions are absent, so it is not a full when/when-not/alternative statement.

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 (readOnly, non-destructive, openWorld), yet the description adds genuinely new behavior: partial success with per-item error results, no deduplication of repeated URLs, and a concrete cost of 0.2 account credits per successful entry. It stops short of covering failure handling details such as whether failed items are billed or retried.

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

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

Three short sentences, front-loaded with the core action and count limit, followed by the two behaviors an agent could otherwise get wrong (per-item results, duplicate handling) and the cost. No redundant restatement of the name or title.

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

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

An output schema exists, so return structure need not be spelled out, and the description still sketches the per-item success/error shape and cost model. What remains unaddressed is the relationship to the single-video and search siblings and the practical limit on credits consumed per call.

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

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

Schema coverage is 75% and the context, llm_model, and conversation_id parameters are thoroughly documented in the schema itself, so the description adds little there. For the undocumented urls parameter it contributes ordering and duplicate-preservation semantics, but says nothing about accepted URL formats despite the uri format in the schema.

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

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

The description gives a specific verb and resource ('Fetch ... TikTok video URLs') plus the batch range (1–20) and ordering guarantee, which clearly separates it from the singular get_tiktok_video sibling by implication. It does not explicitly name that sibling or search_tiktok_videos, so the differentiation is inferred from the plural rather than stated.

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

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

The 1–20 item constraint implies this is the batch path and that single-video lookups belong elsewhere, but the description never states when to prefer it over get_tiktok_video or when to use search_tiktok_videos first to obtain URLs. 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.

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

Goes well beyond the annotations by disclosing a concrete billing cost (2.5 account credits per successful request, including reused results), variable latency when transcription must be generated, and an internal reuse/caching behavior. The annotations only say readOnly/openWorld/non-destructive, so the cost and latency disclosure is real added value. It stops short of stating failure/charge behavior for unsuccessful requests or any rate limits, which would have made this 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?

Four short sentences with the core action front-loaded and the cost/latency caveats grouped at the end; nothing is padded. The only redundancy is restating the return shape ('plain text and timestamped segments') when an output schema already exists, though it is brief enough not to be wasteful.

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

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

For a single-item fetch tool with an output schema and full annotations, the description covers the ingredients an agent needs to decide and to budget: what it returns, cost, and slow-path latency. The remaining gap is sibling disambiguation against get_tiktok_video_transcripts and get_tiktok_video_captions, which an agent in this 40-tool namespace would plausibly confuse.

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

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

Schema description coverage is 75%, with context, llm_model, and conversation_id documented at length in the schema itself, so the description carries no obligation to restate them. The description adds nothing about parameter meaning, including the url parameter, which has no inline description and is only typed via a $ref. Baseline 3 is appropriate when the schema does the heavy lifting.

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 or generate a normalized TikTok video transcript,' which immediately tells an agent what comes back (a transcript, not captions or video metadata). It does not explicitly distinguish itself from the near-identical siblings get_tiktok_video_transcripts (plural) or get_tiktok_video_captions, so the agent must infer the singular-vs-batch split from the name alone.

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 sentence 'A previously collected transcript can be reused' implies a caching path and hints that repeated calls are cheap in latency but not in cost, which is useful context for repeat requests. However, there is no explicit when-to-use guidance against the obvious alternatives (bulk get_tiktok_video_transcripts, or get_tiktok_video_captions for caption text), and no stated prerequisites such as a valid TikTok video URL.

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 readOnly=true, destructive=false, openWorld=true, so the safety profile is covered. The description adds genuinely non-derivable behavior: credit cost per successful entry differs by mode, captions mode never generates transcripts, results come back in input order per-item, and duplicate entries remain distinct. What it leaves out is failure handling — it costs "per successful entry," implying failed entries are free, but never says so.

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

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

Four short sentences, each carrying distinct information: scope, per-item ordering, mode costs, duplicate handling. The identifying scope is front-loaded and there is no filler or restatement of the 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?

With an output schema present, return values need not be explained, and the description still signals per-item results and input ordering. Combined with the cost model and mode semantics, an agent has what it needs to call this correctly; the only gap is whether failed entries consume credits and what happens on partial failure.

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%; context, llm_model, and conversation_id are documented in the schema itself, so the description's job is mostly the two undocumented-in-schema semantics: it explains what captions mode does versus auto (a bare enum in the schema) and it adds the count bound, ordering, and duplicate behavior for urls. That is meaningful added meaning rather than a restatement.

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?

"Fetch transcripts for 1–10 TikTok URLs in input order, with per-item results" states a specific verb (fetch), resource (TikTok transcripts), and batch scope (1–10, per-item results). That batch framing cleanly separates it from the sibling get_tiktok_video_transcript, which handles a single video, without the agent needing to open 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 mode sentences give an actionable selection rule: auto costs 2.5 credits per successful entry, captions costs 0.2 and "never generates transcripts," which tells the agent when captions mode is insufficient. It does not explicitly route to the singular transcript tool or to get_tiktok_video_captions, so the sibling differentiation is implied 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 cover the safety profile (readOnly, openWorld, non-destructive), so the description earns credit for adding that the data is 'current' (i.e., live, not cached) and that the request is 'metered', which implies cost/quota constraints an agent should ration. It also discloses that video data is optional inclusion rather than always returned. It does not quantify the metering or state failure modes, which keeps it from 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?

Three short sentences, front-loaded with the core action and input forms, with no filler. 'Current' and 'live-data' are mildly redundant, and the optional-videos clause could be one word shorter, but 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?

An output schema exists, so return values need not be explained, and the complex meta-parameters are fully documented in the schema. What is missing for a six-parameter, metered, live-data tool is anything about cost magnitude, rate limits, or when to prefer a cheaper sibling. Adequate but with clear gaps around the metering the description itself raises.

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 67% and the schema already documents channel identifier forms, video_limit, include_videos, and the meta-parameters in detail. The description's 'by handle, channel ID, or URL' restates the channel param and 'optionally includes recent videos' loosely maps to include_videos/video_limit without adding format or default details. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource (fetch a YouTube channel) and enumerates the accepted identifier forms (handle, channel ID, URL), which lets an agent distinguish it from get_youtube_video or get_youtube_channel_transcripts. It stops short of naming a sibling tool it might be confused with, such as lookup_profiles or get_creator, so it is clear but not fully differentiated.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite many overlapping siblings (get_creator, lookup_profiles, search_youtube, get_youtube_channel_transcripts). The only usage signal is the implicit cost warning in 'metered live-data request', which tells the agent to be sparing but not which tool to pick instead.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds genuinely non-obvious context by flagging the call as "metered," which implies cost/quota, but it does not say what happens to videos without captions, whether partial results are returned, or how large the payload can get for a 20-video batch.

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 verb and resource, then the tunable dimensions, then the metering caveat. Nothing is padded, though the second sentence is essentially a pass-through of schema 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?

The tool has 8 parameters, 3 required, with an output schema and annotations in place, so the description need not explain return values. It nonetheless omits partial-failure behavior for videos lacking transcripts and any sense of batch cost magnitude, which matters for a metered call with a limit of 20.

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

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

Schema coverage is only 50%, and the undocumented parameters are exactly sort_by, language, video_limit, and include_segments, all of which the description surfaces as the four knobs the caller controls. That is a meaningful supplement to the bare schema, though it does not give defaults, ranges, or accepted language formats (those live in the schema).

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

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

Names a specific verb (fetch) and resource (transcripts) scoped to a batch of videos from a channel, which implicitly separates it from the sibling get_youtube_video_transcript that handles a single video. It never explicitly names that alternative, so the differentiation is inferred rather than stated.

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

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

"Choose the video count, ordering, language, and whether timestamped segments are included" gives parameter-level guidance but no situational guidance on when to pick this over the per-video transcript tool or the channel/video lookup tools. "Metered batch request" hints that it is for bulk use, but there are no stated exclusions or prerequisites.

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 (readOnly, openWorld, non-destructive), and the description adds genuinely new context: this is a 'metered live-data request,' which tells the agent to spend calls carefully, and 'current localized' signals results vary by country/language. It does not quantify the metering or mention rate limits, so it is useful but not complete.

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 core action, and the cost caveat placed last where it still reads. No redundant restatement of the title, though the second sentence could be tightened into the first without loss.

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

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

An output schema exists, so return-value explanation is unnecessary, and the schema already spells out the awkward required params (context, llm_model, conversation_id sequencing). What the description omits is the first-call conversation_id handshake, which is the main thing that can cause a failed invocation, but the schema carries that burden adequately.

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

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

Schema coverage is 50%: context, llm_model, and conversation_id are richly documented in the schema, while q, country_code, and language_code have no descriptions there. The description partially compensates by implying q is a 'partial phrase' and that results are 'localized' (country_code/language_code), but gives no format or default hints (e.g. ISO 2-letter codes) beyond what the schema constraints show.

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 current localized YouTube query suggestions') plus the input shape ('partial phrase'), which is clearly distinct from siblings like get_youtube_video or search_youtube. It stops short of naming the closest alternative (search_youtube) explicitly, so an agent must infer the typeahead-vs-search split from the word 'suggestions'.

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 expanding topic seeds before search' implies a when-to-use context and hints at sequencing relative to search. There is no when-not guidance, no statement of what to do if no suggestions come back, and no explicit pointer to search_youtube as the follow-up tool.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false), and the description adds genuinely new context on top: the data is freshly fetched rather than cached, and the call is metered, which is a cost signal an agent should weigh before invoking. It does not quantify the metering, describe failure modes for an invalid or private video, or explain the conversation_id handshake that the schema hints at.

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

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

Three short lines, front-loaded with the core action, then the return payload, then the metering caveat — no filler. "Returns exact publication data when available" is slightly vague, but the structure is efficient.

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

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

An output schema exists, so the description need not enumerate return fields, and it still summarizes the payload for orientation. What is missing is minor: guidance on the required analytics parameters and the conversation_id sequencing is left entirely to 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 coverage is 75% and the three documented parameters (context, llm_model, conversation_id) carry long, prescriptive descriptions, so the schema does the heavy lifting. The description adds nothing about parameters — notably video_id has a strict 11-character pattern but no description, and the description never mentions the required analytics parameters.

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

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

"Fetch fresh metadata and engagement for a YouTube video ID" gives a specific verb (fetch), a specific resource (a single YouTube video by ID), and a clear scope that separates it from get_youtube_video_transcript, get_youtube_channel, and search_youtube. It stops short of naming those siblings explicitly, so it lands just under 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 word "fresh" and "metered live-data request" signal that this is a paid live lookup rather than a cached one, which nudges an agent toward it only when current data is needed. There is no explicit when-to-use / when-not-to-use statement and no routing to alternatives such as the transcript or channel 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?

Beyond the readOnly/openWorld/non-destructive annotations, the description adds that output is normalized, that it is metered (a real cost signal), and that latency increases when captions need resolving. It does not cover failure modes or rate-limit specifics, but it meaningfully exceeds what the annotations alone convey.

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 purpose, followed by the return shape and the cost/latency caveat. No redundant restatement of the title and no filler.

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

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

With an output schema present, the description need not enumerate return fields, yet it still omits the one unexplained input (`language`) and says nothing about behavior for caption-less videos. For a 5-parameter tool with an openWorld read, this is adequate but leaves an agent guessing on language 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 coverage is 60%; the undocumented parameter is `language` (default "auto", 2-20 chars), and the description never explains how to select a caption language or that this param controls it. The mention of "available caption languages" describes a return value rather than the parameter, so the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ("Fetch a normalized transcript for a YouTube video ID"), which cleanly separates it from retrieval tools for posts, profiles, or videos. It does not explicitly name the closely related sibling get_youtube_channel_transcripts, so an agent must infer the single-video vs. channel-batch 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?

The note that this is a "metered request" that "may take longer when captions must be resolved" gives useful cost/latency context for deciding whether to call it. However, there is no explicit when-to-use guidance, no mention of the channel-level transcript alternative, and no guidance for videos lacking captions.

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 readOnly/openWorld/non-destructive, so the description's job is lighter and it does add real context: per-page cost of 0.2 credits and the pagination invariant that url and parent ID must stay fixed while passing the returned cursor. It does not disclose depth limits, empty-result behavior, or rate limiting.

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

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

Three short sentences, front-loaded with the action, followed by the pagination invariant and cost. No filler, and none of the sentences are redundant.

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 paginated read tool with an output schema, the definition supplies the paging contract and the cost model — precisely the details structured fields do not convey. Nothing an agent needs to make a correct first call or a correct continuation call is missing.

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

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

Schema coverage is 50%, but the three parameters lacking schema descriptions (url, comment_id, cursor) are each addressed in the description: url must be kept unchanged, comment_id is the numeric parent, and cursor is taken from the previous response. It adds no format or default detail beyond that, which is acceptable given the ref-based schema.

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

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

Names a specific verb and resource ('Fetch one page of replies') and scopes it to a parent comment ID, which implicitly separates it from the sibling list_tiktok_video_comments (top-level comments). The sibling is never named explicitly, so an agent must infer the replies-vs-comments contrast.

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 word 'replies' signals this is the follow-up call after obtaining a parent comment ID, and the cursor sentence describes how to continue paginating. There is no explicit when-to-use vs. when-not-to-use statement and no named alternative for retrieving top-level comments.

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?

Adds substantial context beyond the read-only, open-world annotations: duplicate results are preserved, media links are temporary, and every successful page costs 0.2 credits even if empty. These are exactly the behavioral traits an agent needs to plan calls and avoid surprise costs.

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?

Five short sentences, front-loaded with the core operation, then pagination, duplication, link lifetime, and cost. Every sentence carries operational value with no filler.

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

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

Given an output schema exists, the description needn't document return values, and it covers all the caller-relevant concerns: pagination, hashtag format, duplicate handling, temporary media links, and credit cost. Nothing essential is missing for correct invocation.

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

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

With 0% schema description coverage, the description compensates by stating the hashtag must be supplied without '#', and explains cursor continuation semantics. Slight ambiguity because the parameter is named 'cursor' while the description says 'next_cursor', but the intent is clear.

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'), resource ('videos under a hashtag'), and scope ('one page'), which clearly distinguishes it from sibling list tools like list_tiktok_profile_videos or list_tiktok_music_videos. An agent can identify the operation 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?

Explains the pagination workflow ('Continue with next_cursor and the same hashtag'), which is useful usage context. However, it never names when to use this versus alternatives such as search_tiktok_videos or other list/get tools, so selection guidance 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?

Adds substantial context beyond the readOnly/openWorld annotations: credits cost (0.2 per successful page, including empty pages), duplicate preservation, temporary media links, and opaque cursors. These are non-obvious behavioral traits an agent needs before invoking.

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

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

Every sentence carries distinct, needed information – pagination, duplicates, temp links, cost – with no filler. Information is front-loaded with the primary operation first.

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

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

With an output schema present, return values needn't be described. The description covers pagination mechanics, cost, duplicate handling, and link volatility, leaving nothing essential for correct invocation 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 music_id schema description already clarifies it's a sound clip ID; the description reinforces this and explains the cursor's continuation role and opacity. One weakness: it references 'next_cursor' while the actual request parameter is named 'cursor', which could mildly confuse the agent.

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 one page of videos') and resource ('using a sound clip music_id'), making the operation and scope clear. It doesn't explicitly name sibling tools (e.g., search_tiktok_videos or list_tiktok_hashtag_videos) to differentiate itself, keeping it just below 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?

It explains how to continue pagination ('next_cursor and the same music_id') but gives no explicit guidance on when to choose this tool over related siblings like search_tiktok_videos or get_tiktok_music. Usage is implied rather than contrasted.

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 read-only/open-world/non-destructive profile, and the description adds substantial behavior beyond them: temporary media URLs, mandatory US region resolution, a per-page credit cost including empty pages, and a forbidden-error (non-empty) response for private accounts with explicit 'do not retry' instruction. This is exactly the operational context an agent cannot get from structured fields.

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

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

Five short sentences, front-loaded with the core action, then pagination/ordering, then the constraints that affect correctness (temporary URLs, region, cost, error handling). No filler and no repetition of schema content.

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

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

An output schema exists so return shape need not be described; what remains for a billed, region-locked, paginated listing tool is cost, region, error and retry policy, and pagination mechanics, all of which are present. The description is complete for correct invocation.

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

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

Schema description coverage is 43%, so the description must compensate, and it does for the undocumented parameters: cursor semantics (page continuation), sort_by semantics (latest vs popular), and region (always US). The remaining undocumented parameters, username, context, llm_model, and conversation_id, are either self-evident or fully specified inside the schema itself.

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 with scope: 'Fetch one cursor-paginated page of current TikTok videos for a username.' That distinguishes it from search_tiktok_videos and list_tiktok_hashtag_videos by implication (profile-scoped, paginated listing), but no sibling is actually named, so the differentiation is inferred rather than declared.

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 tells the agent how to continue ('use the returned cursor to paginate') and how to select ordering ('latest or popular'), which is real usage guidance. It gives no when-to-use-versus-alternative routing, e.g. nothing says to prefer get_tiktok_videos or list_tiktok_hashtag_videos under specific conditions, nor prerequisites for the account type beyond the private-account error case.

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

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

Annotations already declare readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral facts: the result is a snapshot of "current" comments, it is cursor-paginated one page at a time, and it is a metered live-data request — a cost/rate consideration not present in structured fields.

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

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

Three short sentences, each load-bearing: what is returned, how to continue, and the metering caveat. The pagination constraint is front-loaded and there is no redundant restatement of the title.

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

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

An output schema exists, so return values need no explanation, and the description covers paging and cost. It omits any hint about page size, ordering, or refresh behavior of "current" comments, which would matter for an agent reasoning about consistency across pages.

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% with the cursor and url parameters undocumented in the schema itself. The description partially compensates by explaining that cursor is a continuation token returned by the previous call and that url identifies the video, but it adds no format, limit, or ordering details before giving a baseline-3 level of added meaning.

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

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

States a specific verb and resource ("Fetch ... comments for a TikTok video URL") plus the scope of a single page, which is far more precise than the bare title. It does not explicitly distinguish itself from sibling list_tiktok_comment_replies, so the top-level-vs-reply distinction is left 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?

Gives clear pagination guidance ("Pass the returned cursor to retrieve the next page") and signals the call is metered, which implies cost-aware use. It never states when to choose this over list_tiktok_comment_replies or get_tiktok_video, so the primary selection decision remains inferred from the name.

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 read-only, closed-world, non-destructive behavior, and an output schema exists, so the bar is lower. The description still adds genuinely useful behavior: results split into `data` and `not_found` (partial-failure disclosure) and profiles return in arbitrary order requiring re-correlation. It does not mention auth or rate-limit behavior, keeping it below 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?

Purpose and the primary routing rule are front-loaded, and the return-shape caveat is placed last where an agent will look for it. It loses a point for repetition: the '30 accounts / follower counts' scenario is stated twice and the social-proof question is covered by three overlapping examples.

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

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

For a single-parameter, read-only batch lookup with an output schema, everything an agent needs is present: input shape, batch ceiling, routing to five siblings, response partitioning, and the ordering caveat. Nothing material is missing.

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

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

Schema coverage is 100% so the baseline is 3; the description nonetheless clarifies that each entry is a (platform, username) pair and that the ceiling is 100 entries. The enum restriction on platform is left to the schema, a minor residual gap.

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

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

States a specific verb and resource (batch-fetch profiles) plus the key constraints: max 100, keyed by (platform, username) pairs. An agent can immediately distinguish this from the single-record and search siblings.

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

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

Gives explicit when-to-use conditions ('a list of handles', 'one round-trip beats 30 calls'), names the alternatives and the conditions that select them (get_profile for one pair, search_creators/autocomplete_creators for fuzzy input, semantic_search_creators for topical discovery), and reinforces with worked user-utterance examples including a negative case.

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

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

Annotations already declare this a safe, closed-world read (readOnlyHint true, destructiveHint false, openWorldHint false), so the safety burden is covered. The description usefully adds the response contract (0-1 match score, good/neutral/avoid decision, structured reasons), but that is partly redundant with the existing output schema and it says nothing about latency, cost, or batching behavior for up to 100 candidates.

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?

Purpose and the when-to-use block are front-loaded and the alternative-tool routing is packed into compact sentences. The second example ('Rate these five creators for a vegan cookbook launch') largely repeats the first illustrative sentence, so a small amount of content does not earn 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 7-parameter scoring tool with full schema coverage and an output schema, the description supplies everything an agent needs: the brief-versus-context distinction, both candidate input forms, sibling routing, and prerequisite lookups. Remaining undisclosed fields are operational analytics parameters already fully specified in 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 100%, so the baseline is 3 and the schema already documents each field including the analytics-only `context` and `llm_model`. The description goes beyond that by clarifying that candidates may be supplied via `creator_ids` and/or `profiles` and by distinguishing `intent_query` (the brief reasoned against) from `intent_context` (optional auxiliary context), which is genuine added meaning but not a large lift over the schema.

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

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

The description opens with a specific verb and resource ('Score how well specific creators fit a campaign brief'), then contrasts it against the three nearest siblings (semantic_search_creators, search_creators, find_lookalike_creators). An agent can pick this tool versus discovery tools without inspecting 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?

It states the triggering condition explicitly ('when the user already has candidate creators in mind') and gives explicit routing rules for every alternative: semantic_search when you lack candidates, search_creators to resolve rough names, find_lookalike for similar-to-known-good-fits. It also sequences prerequisite calls (get_profile, get_posts) via the examples.

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=false, idempotentHint=false, and destructiveHint=false. The description adds non-annotation context that matters: the call may consume Influship account or API usage, and it performs live fetches before scoring. It doesn't mention rate limits, latency, or what a repeated call produces, so it stops short of full behavioral disclosure.

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

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

Three short sentences with zero filler: the trigger condition leads, the behavior follows, and the cost warning closes. Nothing is repeated and no sentence could be dropped without losing 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 an output schema present, return values needn't be explained, and the description covers trigger, internal pipeline, and cost. The one gap is that the conversation_id sequencing requirement and the effect of repeated/non-idempotent calls are left entirely to the schema rather than integrated into the workflow guidance.

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

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

Schema description coverage is 100%, so every parameter including the unusual llm_model and conversation_id handshake is already documented in the schema. The description only restates the creator count and the brief, adding no format, constraint, or edge-case meaning beyond the schema. Baseline 3 applies.

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

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

The description names a specific verb and resource ('renders a side-by-side comparison') and enumerates the two upstream actions (fetch current creator details, score each creator against the brief). The '2–4 canonical creator IDs and a specific campaign brief' scope makes it distinguishable from sibling renderers like render_creator_profile and render_creator_shortlist without opening a 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?

It gives a clear triggering condition: the user has 2–4 canonical creator IDs plus a campaign brief. That implicitly excludes single-creator and open-ended search cases, but it never names an alternative tool or states an explicit exclusion, so the agent must infer the routing.

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?

Adds real behavioral context beyond the annotations: the payload scope (current record plus up to six recent posts) and a cost warning that the call may consume Influship account or API usage, which also explains why readOnlyHint is false despite being a fetch-style operation. It does not cover rendering output characteristics or failure modes, but the quota disclosure is the non-obvious detail an agent needs.

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

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

Two sentences, zero filler, with the usage trigger front-loaded and the cost caveat following. Nothing is repeated from the schema or title.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description covers the data fetched and the quota cost. The remaining gap is positioning against get_creator and the other render_* siblings, which an agent must infer.

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

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

Schema description coverage is 100%, including detailed guidance for context, llm_model, and conversation_id, so the schema does the heavy lifting. The description echoes 'canonical creator ID' but adds no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific action and scope: a visual deep dive on one canonical creator ID, fetching the current creator record plus up to six recent posts. The 'visual deep dive' phrasing and 'one' creator ID indirectly separate it from render_creator_comparison and render_creator_shortlist, but no sibling is named explicitly, so the distinction from get_creator remains inferential.

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?

"Use this when the user wants a visual deep dive on one canonical creator ID" is a concrete trigger condition with an implicit scope qualifier (single creator). It gives no explicit exclusions or named alternatives such as get_creator for raw data or render_creator_comparison for multiple creators.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds real context beyond that: the call fetches stored creator details, may consume Influship account or API usage, and preserves ranking/confidence/evidence when search_id is used. It does not explain why the call is non-read-only (e.g. whether a stored render record is created), which is the one remaining 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?

Four short sentences, front-loaded with the trigger condition, followed by parameter routing, the ID-provenance guardrail, and the cost note. No sentence is redundant with the schema or the annotations, and nothing is buried 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?

With 7 parameters, full schema descriptions and an output schema in place, the description only needs to carry the selection logic and the cost/behavior note, and it does both. An agent can decide when to call it, which ID parameter to pass, and what it costs without opening another 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 100%, so the baseline is 3, and the description earns the bump by adding routing semantics the schema only gestures at: search_id is the preferred path after semantic_search_creators to preserve exact ranking and evidence, while creator_ids is reserved for name/handle lookup results. It still does not address precedence if both are supplied.

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 concrete action and output: rendering 1–8 creator cards for the user to scan, which is a specific verb plus resource. It implicitly differentiates from single-creator renderers by bounding the display at 1–8 cards, but it never names render_creator_profile or render_creator_comparison, so an agent must infer the boundary from the sibling list.

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

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

It gives an explicit trigger ('when discovery or lookup tools have returned results'), an explicit precondition ('Always call an Influship data tool first; do not invent IDs'), and routes between two modes: search_id after semantic_search_creators versus creator_ids for name/handle lookups. That is when-to-use, how-to-choose, and a negative guardrail in one place.

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

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

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. The description adds real value beyond them: it discloses cost/speed characteristics, that output shape varies by routing (autocomplete vs. legacy semantic results), and which downstream tools consume which returned identifiers. It does not mention rate limits or result ordering, keeping it short of a 5.

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

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

Front-loaded with the one-line purpose, then routing rules, then a compact example block – a good structure for a tool with 15 parameters. There is mild redundancy in restating the legacy/backward-compatibility behavior and explaining twice why semantic_search_creators is preferable for discovery, but no sentence is wasted outright.

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

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

Given 15 parameters, 3 required, existing output schema, and a non-obvious dual routing mode, the description covers what an agent needs: routing decision, return-type variability, and follow-up tools to use with returned IDs/output. It doesn't fully reconcile the handle-handling ambiguity with the schema, which is the one completeness gap.

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

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

Schema coverage is 100%, so baseline is 3, but the description genuinely adds semantics the schema lacks: it explains routing behavior for query_type, clarifies that platforms/follower/engagement/creator_kinds fields are legacy pass-throughs to the semantic endpoint, and ties query inputs to concrete examples. However, it conflicts with the schema's own `query` description, which says exact handles must NOT be passed here while the tool description instructs the agent to do exactly 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?

Opens with a concrete verb+resource ("Find a creator by name/handle") and explicitly frames itself against siblings by name (get_profile, semantic_search_creators). The dual-mode framing ("while preserving legacy semantic creator search") makes the tool's identity slightly ambiguous, since it partly overlaps with semantic_search_creators, which keeps it from 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?

Explicitly states when to use it (creator-ish string but no canonical UUID), when to prefer get_profile (exact handle on a specific platform), and when to prefer semantic_search_creators (topical/niche discovery), backed by four worked examples. Both inclusion and exclusion conditions, plus named alternatives, are covered.

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, openWorldHint=true and destructiveHint=false. The description adds genuinely non-obvious behavior beyond them: unknown profile fields come back as null, and each successful page costs 0.2 account credits, including empty pages. It says nothing about rate limits or error handling, so it falls just short of 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?

Three short sentences, each carrying a distinct fact (scope, null semantics, pagination, cost), with the core purpose front-loaded. Nothing is redundant.

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

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

An output schema exists, so the description does not need to explain the return shape. It covers pagination, cost and null fields, which are the risky parts of calling it. It is weaker on how this search relates to the other discovery tools in the family.

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 schema already documents context, llm_model and conversation_id. The description explains cursor behavior (opaque, reuse the same query), but it calls the field "next_cursor" while the schema names it "cursor", and it never says what the query string should contain. That leaves the query parameter underspecified.

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 concrete verb and resource: "Fetch one page of TikTok user search results." That distinguishes it from search_tiktok_videos and the get_* lookup tools. It never names a sibling or explains how it differs from search_creators or lookup_profiles, so it isn't 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?

It does give operating instructions: continue paging with next_cursor and the same query, and it notes that cursors are opaque. It never says when to reach for this tool instead of search_creators, lookup_profiles or autocomplete_creators, so the choice between siblings is implied 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?

Goes well beyond the annotations (which only say read-only, open-world, non-destructive): single-page semantics, relevance ordering, duplicate preservation, temporary media links, and a per-page credit cost that applies even to empty results. Cost-per-call and transient-output disclosure are exactly the traits an agent needs before calling.

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

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

Four short sentences, each carrying a distinct operational fact (page scope, pagination, dedupe, link expiry, cost), with the core purpose front-loaded. No filler.

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

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

Return format is covered by the output schema, and the description fills in the non-obvious gaps: cost, paging, duplicate retention, link lifetime. The remaining hole is the cursor parameter's naming/expiry behavior and query constraints, which no structured field or sentence resolves.

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 cursor's role in continuing a search but calls it 'next_cursor' while the schema parameter is 'cursor', and says nothing about query limits (1-100 chars, control characters rejected). Partial compensation only.

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+scope: 'Fetch one relevance-ordered page of TikTok videos.' That distinguishes it in spirit from get_tiktok_videos / list_tiktok_hashtag_videos, but it never names those siblings explicitly, so an agent must still infer the boundary between search-based and ID/list-based retrieval.

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 pagination rule ('Continue with next_cursor and the same query') is genuinely useful usage guidance. However, there is no statement of when to choose this over search_tiktok_users, search_youtube, list_tiktok_hashtag_videos, or get_tiktok_videos — usage is implied rather than scoped.

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 (readOnly, non-destructive, open-world), and the description adds genuinely non-obvious operational context: each page counts as one metered request and results are 'current' rather than historical. It does not mention authentication or quota/rate specifics beyond the metering note, so it stops short of 5.

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

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

Three short sentences, front-loaded with the core action, then filters, then pagination mechanics. Nothing is repeated from the schema and every sentence adds a distinct piece of 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 12 parameters and three required bookkeeping fields (context, llm_model, conversation_id), the description says nothing about those unusual required arguments or the sequencing constraint around conversation_id, leaving the agent dependent entirely on schema text. An output schema exists, so return values need not be described, but the description is thin relative to the tool's parameter complexity.

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

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

Schema description coverage is only 25%, so the description must carry the filter parameters, and it does name the six filter dimensions (upload window, popularity, result type, duration, country, language) that map to sort_by, upload_date, content_type, duration, country_code, and language_code. The mapping is loose — 'result type' and 'popularity' are not the literal enum names — and q/limit go unmentioned, but the next_cursor-to-cursor handoff is a useful clarification the schema alone leaves implicit.

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 ('Search current YouTube results') plus scope qualifiers (discovery filters, cursor pagination), so an agent can distinguish it from fetch-style siblings such as get_youtube_video or get_youtube_channel. It does not explicitly name any sibling, so 4 rather than 5.

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

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

Usage is implied through the listed filter dimensions and the pagination note, which tells the agent this tool is for filtered discovery rather than direct lookup. However, there is no explicit 'use this instead of X when Y' routing among the many sibling search/get tools, and no statement about when not to call it.

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