Influship Influencer Marketing MCP

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the burden. The description adds useful behavioral context: it is 'cheap and fast', returns a short list of matching creators with IDs/platforms/display names, and suggests downstream usage. This goes beyond the annotations without contradicting them.

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

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

The description is front-loaded with a clear purpose, followed by usage guidance and examples. Every sentence contributes: it explains when to use the tool, when not to, and what the output looks like. Despite its length, there is no redundancy or fluff.

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

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

The description covers all essential context: purpose, usage boundaries, return values, and downstream integration. With an output schema present, the description need not detail return structures. The complexity of many sibling tools is well addressed by explicit comparisons.

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 input schema already fully documents all four parameters (q, limit, scope, platform). The description adds value by explaining the query context (partial handle/name) in examples, but does not elaborate on parameter semantics beyond the schema. This aligns with the baseline for full schema coverage.

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

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

The description clearly states that the tool autocompletes creator names, usernames, or display names from partial input. It uses specific verbs ('autocomplete', 'resolve') and names the resource, while also distinguishing itself from sibling tools like search_creators, get_profile, and semantic_search_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?

The description provides explicit guidance on when to use this tool versus alternatives: prefer it over search_creators for handle-style queries, use get_profile for exact platform+username, and use semantic_search_creators for broader discovery. Concrete examples illustrate the decision boundaries.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond this: seeds are blended via multiple embeddings, results are ranked, and a seed_not_found response means the creator is unavailable and should not be retried. This gives agents actionable behavioral context.

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

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

The description is substantial but every section earns its place: summary, seed mechanics, filtering guidance, error behavior, alternatives, and examples. It is front-loaded with the core purpose and structured with clear paragraphs. There is no redundant filler or restatement of schema details.

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

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

For a tool with 9 optional parameters and several sibling tools, this description is complete. It covers when to use the tool, how to form seed inputs, how to constrain results, what error behavior to expect, and which alternatives to choose. The presence of an output schema further reduces the need to describe return values.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful value by explaining the distinction between seed_creator_ids and seed_profiles, instructing agents to resolve handles via autocomplete_creators first, and noting that limit caps results with a default of 25. It also shows a concrete seed_profiles example.

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: 'Find creators SIMILAR to one or more seed creators.' It clearly distinguishes this tool from semantic_search_creators and match_creators, and grounds the purpose with concrete user-phrase examples. An agent can immediately tell what this tool does and what it is not.

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

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

The description explicitly states when to use this tool: when the user already knows a creator and wants more like them. It also names alternatives with their selection conditions: semantic_search_creators for topic/niche queries and match_creators for scoring specific candidates. This leaves little to inference.

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

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

Beyond the readOnly annotation, the description discloses key runtime behavior: how include: ['profiles'] behaves with UUID inputs, and how platform+username inputs resolve through the profile endpoint and return both profile and creator records. This materially helps an agent predict tool behavior.

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

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

The description is well structured: purpose first, then usage conditions, parameter behavior, and concrete examples. Every section earns its place, and the bulleted examples make the two lookup modes immediately understandable.

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

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

Given the 100% schema coverage, output schema presence, and readOnly annotations, the description covers everything needed to invoke the tool correctly: lookup modes, include behavior, example intents, and sibling alternatives. No critical gap remains.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic guidance beyond the schema by explaining the id vs platform+username relationship, the effect of include with UUIDs, and the special platform+username resolution behavior.

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

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

The description opens with a specific verb and resource: 'Fetch the full record for a single creator by ID or exact platform username.' It clearly differentiates this tool from siblings like get_profile and lookup_profiles by naming them and stating the boundary.

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

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

Provides explicit 'Use this when...' guidance with concrete caller contexts: canonical creator UUID or exact platform+username pair. It also names alternatives and tells the agent when to prefer get_profile or lookup_profiles, which removes routing 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 declare readOnlyHint=true and destructiveHint=false, and the description is consistent. It adds behavioral context about freshness relative to cached endpoints and enumerates expected data fields (coauthors, paid partnership metadata, video versions, etc.), which goes beyond the annotation safety profile.

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 verb and resource, with the second sentence delivering usage context and data scope. No filler or repetition; each sentence earns its place.

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

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

For a single-parameter read-only fetch with an output schema, the description covers the purpose, when to use it, and what data to expect. The existence of an output schema removes the need to explain return shapes, and nothing important appears 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 sole parameter is fully documented in the schema with a clear description ('Instagram post shortcode from a /p/, /reel/, or /tv/ URL'). The description only says 'by shortcode' and adds no new semantic detail, so baseline 3 applies given 100% schema coverage.

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

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

The description clearly states a specific action and resource: 'Fetch raw Instagram post-page data by shortcode.' It distinguishes from plural get_instagram_posts and transcript tools by emphasizing raw post-page data, freshness, and specific metadata fields.

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

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

It provides an explicit usage trigger: 'Use this when the user needs fresh raw Instagram post metadata that is not guaranteed on regular cached post-list endpoints yet.' This gives clear context but does not explicitly name alternatives or state when not to use it, stopping short of a full 5.

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

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

The annotations already indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds meaningful behavioral context: transient upstream recovery is auto-handled within the deadline, and per-item success/error details are returned. This goes beyond the annotations and helps the agent anticipate partial failures and retries.

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

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

The description is two sentences, each earning its place. The first sentence is front-loaded with action and resource; the second clarifies output structure. No filler or unnecessary detail, making it highly concise while remaining informative.

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

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

For a one-parameter tool with annotations, output schema, and a clear description, the context is nearly complete. The description covers return shape and recovery behavior. It could explicitly mention the relationship to get_instagram_post for single fetching, but that is a minor omission given the clear 'list' wording.

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

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

The schema covers the sole parameter 'shortcodes' with a clear description ('Instagram post shortcodes from /p/, /reel/, or /tv/ URLs') and constraints (min/max items). The description adds only the word 'bounded', which is redundant given maxItems. There is no additional semantic value 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?

The description clearly states the tool fetches raw Instagram post-page data for a bounded list of shortcodes via the raw API. The verb 'Fetch' identifies a read operation, and the resource 'Instagram post-page data' is specific. It distinguishes itself from sibling tools like get_instagram_post (singular) and get_instagram_post_transcript by explicitly targeting a list and raw post data.

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

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

The description implies batch usage with 'bounded list' and 'one item per requested shortcode', but it does not explicitly state when to use this over alternatives like get_instagram_post. There is no direct comparison or exclusion, so the guidance relies on inference from the word 'list' rather than naming alternatives.

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

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

Beyond the readOnly and non-destructive annotations, the description discloses important cache behavior: on a miss, raw post metadata is included; on a hit, the post field is omitted. This is a meaningful behavioral trait not available in annotations and helps set expectations for the response.

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

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

The description is compact and front-loaded: the first sentence conveys the core purpose, and the second adds essential behavioral nuance. There is no redundant or filler 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?

Given the output schema and annotations, the description is sufficiently complete. It covers the key non-obvious behavior (cache handling), names a clear alternative, and avoids unnecessary restatement of schema details.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Transcribe') and resource ('Instagram video post by shortcode') and clearly distinguishes the tool from siblings like get_instagram_post by explaining when metadata is or isn't included. This makes the purpose immediately clear and distinguishable.

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

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

It explicitly explains when to use this tool versus an alternative: when you need post metadata with a cached transcript, use get_instagram_post. It also clarifies cache hit versus miss behavior, providing clear context for selection.

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

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

Annotations declare readOnlyHint=true, but the description adds valuable behavioral context: cache hits/misses affect whether the nested post field is present, and successful items include transcript data. This goes beyond the annotations and prepares the agent for response variability.

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

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

The description is three sentences with no wasted words: purpose, output detail, and alternative. It is front-loaded with the primary action and each sentence contributes unique, essential 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?

The description covers the cache-dependent response shape, which is essential for interpreting output. It also names an alternative tool for a different use case. Given the simple schema and output schema, the description is complete and no further details are needed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds 'bounded list' which reinforces the maxItems constraint, but it does not explain the language parameter beyond what the schema already states. No significant new parameter semantics are provided.

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

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

The description clearly states the tool transcribes a bounded list of Instagram video posts by shortcode. It differentiates from sibling tools by mentioning the nested post field behavior and explicitly referencing get_instagram_posts as the alternative when post metadata is needed.

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

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

The description explicitly says to use get_instagram_posts when post metadata is needed for every shortcode, providing a clear when-not scenario. The batch context implies use for multiple transcriptions, distinguishing it from singular transcript tools.

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

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

Annotations already mark this as read-only and non-destructive, but the description adds substantial behavior: sort defaults and options, pagination via cursor, a limit cap of 50, cursor-sort binding (returns 400 if mismatched), and the output shape (caption, media URL, counts, timestamps, has_more, next_cursor). This goes beyond the schema and annotations.

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

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

The description is front-loaded with the main verb and then delivers usage, parameter semantics, output, and examples in a structured way. Every section earns its place; the examples are particularly useful for an agent.

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

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

Given the output schema exists and annotations declare read-only, the description effectively covers selection, invocation, pagination, and workflow context. It doesn't need to expand return fields because the output schema is present, and safety is covered by annotations.

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

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

Schema coverage is 100% with detailed parameter descriptions, but the description adds the creator identification pattern (creator_id OR platform+username) and explains sort/limit/cursor interplay in plain language with examples. This elevates it beyond schema repetition, though some content (cursor binding, sort formula) is already 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 opens with 'Fetch a creator's posts, sorted and paginated,' a specific verb+resource+scope that clearly differentiates from single-post or profile tools. It reinforces with examples and workflow hints like 'use this after get_profile... then call match_creators,' distinguishing from sibling tools.

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

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

The description explicitly states when to use: 'Use this when the user asks to see what a creator has posted' with concrete examples. It also provides workflow context ('use this after get_profile... then call match_creators'), though it does not explicitly contrast with single-post siblings like get_instagram_post.

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

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

Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds meaningful behavior beyond that: case-insensitive matching is handled server-side, the @ sign should be omitted by the caller, and the tool returns both the profile record and the underlying creator record. This gives an agent useful expectations beyond the structured annotations.

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

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

The description is front-loaded with the core purpose, then gives usage conditions, input formatting rules, exclusions, and concrete examples. Although it is longer than average, every sentence earns its place by either clarifying invocation or routing the agent to the correct sibling tool.

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

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

For a two-parameter read-only tool with a full input schema and an output schema, this description covers everything an agent needs: when to use it, how to format inputs, what it returns, and which alternatives to use in related cases. There are no material gaps.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds extra meaning by explaining how to pass the username exactly as typed without the @ sign, that matching is case-insensitive, and how to parse a URL into platform and username. This is genuinely useful clarification beyond the schema descriptions.

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

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

The description opens with a specific verb and resource: 'Fetch a single social profile by (platform, username).' It clearly distinguishes itself from siblings by naming exact-use cases, the canonical creator ID, and what data is returned. This leaves no ambiguity about what the tool does.

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

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

It gives explicit when-to-use guidance ('Always use this first when the user gives an exact handle'), explicit when-not-to-use guidance ('Do not use search_creators'), and names concrete alternatives for other situations: get_creator for an already-known UUID and lookup_profiles for batch lookups. This is model-level routing guidance.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavioral traits: it is a preview-only tool, it returns a single configured sample, and it includes explicit instructions about what to say after showing the preview and what topics to avoid. This goes well beyond the structured annotations.

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

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

The description is efficiently structured: it front-loads the purpose, then states limitations, then gives the required follow-up communication. Every sentence serves a distinct purpose with no filler or repetition.

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

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

For a zero-parameter, read-only, preview tool with an output schema, the description covers the essential context: when to invoke it, what it returns, what it should not be used for, and how to follow up. Nothing necessary for correct invocation is missing.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter burden for the description to carry. The description adds context about the fixed nature of the result ('one configured sample creator'), which is sufficient for a no-parameter tool.

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

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

The description clearly states a specific verb and resource: 'Fetches one configured sample creator with social profile context.' It also explicitly labels the tool as a preview tool and contrasts it with search, discovery, matching, and comparison, distinguishing it from the many sibling tools.

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

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

The description gives an explicit trigger: 'Use this when a user wants to see what Influship can return before linking an account.' It also states when not to use it and provides follow-up guidance about explaining that live discovery requires an account, making the intended context clear.

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

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

Annotations already provide read-only and non-destructive hints. The description adds useful behavioral context: 'metered live-data request', acceptance of a leading @, and username normalization. No contradiction with annotations.

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

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

Three concise, well-structured sentences. Each sentence provides essential information: purpose/returns, normalization behavior, and metering. No fluff or repetition.

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

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

Given the tool's simplicity (1 parameter), existing output schema, and annotations that cover safety, the description covers all necessary aspects: what it does, input format, return types, normalization, and cost/metering caveat. Nothing essential is missing.

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

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

The schema only defines 'username' as a string, but the description adds meaningful semantics: it accepts a leading @ and normalizes usernames. This exceeds the bare schema definition.

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

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

Description states 'Fetch a current, normalized TikTok profile by username' with specific verb+resource+scope. It distinguishes from siblings by explicitly targeting TikTok profiles and enumerating returned data types (identity, biography, verification, audience metrics).

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?

Clear context is provided: this tool is for fetching TikTok profiles with normalization and live-data caveats. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.

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

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

Annotations already mark it read-only and non-destructive, and the description adds meaningful behavioral detail: returned media URLs are temporary, eligible media is captured asynchronously into a managed dataset, region is fixed to US, and this is a metered live-data request. This is rich context beyond the annotations.

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

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

Four concise sentences, each adding essential information. The core purpose is front-loaded, and the additional behavioral warnings are compact and no-words-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?

For a simple read-only fetch with one required parameter and an output schema present, the description covers URL acceptance, region behavior, temporary media URLs, async capture, and metering. Nothing critical is missing for an agent to invoke 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 0%, so the description must compensate. It does so by explaining accepted URL forms for the 'url' parameter and clarifying that content always resolves against the US region for the 'region' parameter. This adds real meaning beyond the bare schema.

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

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

Description uses specific verb 'Fetch' with a clear resource ('TikTok video URL') and states exact outputs ('normalized details and current engagement metrics'). This clearly distinguishes it from siblings like get_tiktok_video_transcript and list_tiktok_video_comments.

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 useful usage context: canonical and share URLs are accepted, and the request resolves against the US region. However, it does not explicitly state when to prefer this over alternatives or when not to use it, leaving selection partly 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 indicate read-only, open-world, and non-destructive behavior. The description adds valuable context beyond that: transcripts are canonical and reused, content does not expire, and the request is metered and may take longer when generation is needed. This gives the agent useful expectations about latency and resource usage, which annotations do not cover.

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

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

The description is two sentences long and front-loaded with the core purpose. Every sentence adds useful information: the first defines the action and scope, the second covers output format, caching, and performance characteristics. There is no redundant or vague wording.

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

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

Given the tool's simplicity (one parameter, output schema exists, annotations present), the description covers all essential aspects: what it returns, caching semantics, and metering/latency caveats. It does not need to detail return values since an output schema exists, and it provides enough operational context for an agent to use 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?

The input schema has a single 'url' parameter with format uri but no description (0% coverage). The tool description does not explicitly explain the parameter syntax or constraints beyond implying it is a TikTok video URL. While the name makes this inferable, the description itself adds minimal semantic value for the parameter, leaving a moderate gap.

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

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

The description opens with 'Fetch or generate a normalized TikTok video transcript', which clearly specifies the action (fetch/generate), the resource (TikTok video transcript), and distinguishes it from sibling tools like get_instagram_post_transcript. It further clarifies the output type ('plain text and timestamped segments'), making the purpose unambiguous.

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

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

The description provides clear context for when to use this tool (for TikTok video transcripts) and hints at caching behavior ('Canonical transcripts are reused'). However, it does not explicitly mention alternatives or exclusions (e.g., 'for Instagram transcripts use get_instagram_post_transcript'), so it falls short of full explicit 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 establish readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds non-obvious behavioral context: the call is 'metered' and returns 'live' data, which implies potential cost and that results reflect the current state of YouTube. This goes beyond the annotations without contradicting them.

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, purposeful sentences: what the tool fetches and how, the optional video behavior, and the metered live-data warning. The most important information is front-loaded, and there is no filler or repetition of schema details.

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

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

Given the output schema exists and annotations cover the read-only, non-destructive safety profile, the description is largely complete. The channel parameter is fully covered in the schema, and the metered live-data warning covers the key caveat. The only small gap is the undefined interaction between include_videos and video_limit, but defaults in the schema mitigate this.

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

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

Schema description coverage is only 33%, so the prose needed to compensate for the undocumented video_limit and include_videos parameters. The phrase 'Optionally includes recent videos' partially clarifies include_videos, but video_limit is never explained in the description, and its semantics are left entirely to the parameter name and constraints. This is a meaningful gap at 33% coverage.

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

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

The description uses a specific verb ('Fetch'), names the exact resource ('YouTube channel'), and lists the supported identifier forms ('handle, channel ID, or URL'). The word 'current' distinguishes this from historical or cached lookups, and the YouTube-specific resource clearly separates it from siblings like get_creator, get_profile, or get_youtube_video.

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

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

The description makes clear when to call it: to fetch a current single YouTube channel by handle/ID/URL, with optional recent videos. It also flags that it is a 'metered live-data request,' giving cost/latency context. It does not explicitly name alternatives or exclusions, but the resource and identifier criteria are enough to route an agent appropriately.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context beyond those annotations, notably that the request is metered/cost-sensitive and that output granularity depends on include_segments and video_count, making the tool's behavior more predictable.

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

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

The description is tightly structured: the first sentence states the action and resource, the second lists the primary configurable dimensions, and the final warning ('metered batch request') is useful caution with no fluff. Every sentence earns its place.

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

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

The description is adequate for a read-only batch tool with an output schema and clear annotations, covering the key decision dimensions and metering behavior. What is missing is an explicit pointer to the single-video transcript sibling tool for non-batch needs, though 'batch' in the name and description make this reasonably inferable.

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 only 20% schema description coverage, the description carries the burden for the other parameters. It maps 'video count,' 'ordering,' 'language,' and 'timestamped segments' respectively to video_limit, sort_by, language, and include_segments. It does not restate concrete values, but those are already captured by enum/default/constraint 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 states a specific verb ('Fetch'), a clear resource (YouTube channel transcripts), and narrows the scope to a 'selected batch of videos,' which distinguishes it from single-video transcript tools like get_youtube_video_transcript and channel metadata tools like get_youtube_channel.

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 batch usage with 'selected batch' and notes it is a 'metered batch request,' but it does not explicitly mention alternatives or when-not-to-use conditions. An agent can infer the intended use case from the batch wording, but the routing is not made explicit.

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

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

Beyond the readOnly/openWorld/destructive annotations, the description adds meaningful behavioral context: 'current localized' suggests live data, and 'metered live-data request' warns about cost/usage implications. This is valuable extra 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?

Two sentences with no filler. The core operation is front-loaded, the use case is stated, and the metered/live-data warning is concise but important.

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

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

Given the output schema exists and the annotations cover safety, the description is largely complete: it states the operation, input nature, use case, and live-data/metered behavior. The only notable gap is the lack of explicit parameter mapping for optional localization fields.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: 'partial phrase' maps to q, and 'localized' hints at the country/language parameters. However, it does not explicitly explain the roles or value expectations of country_code and language_code.

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

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

The description uses a specific verb ('fetch') and resource ('YouTube query suggestions'), and clarifies it operates on a partial phrase with localization. This clearly distinguishes it from video-search siblings like search_youtube.

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

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

The description gives a clear use context: 'expanding topic seeds before search.' It does not explicitly name alternatives or state when not to use it, but the intended workflow is evident.

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

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

Annotations already indicate read-only, open-world, non-destructive behavior. The description adds valuable context by calling it a 'metered live-data request' and noting 'exact publication data when available,' which signals potential variability or cost. This goes beyond the annotations without contradicting them.

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

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

The description is remarkably concise, using two short sentences to state the purpose, list return data, and mention metering. It front-loads the main verb and resource, and every sentence adds new information without redundancy. This is appropriately sized for a tool with a single parameter.

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 return types are already covered. The description covers the core behavior, data fields, and metering, which is sufficient for a simple read-only call. It does not mention error handling or rate limits, but these are less critical given the annotations and output schema. Overall, it is quite complete for its 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?

The schema provides only the pattern for video_id with no description (0% coverage). The description clarifies that video_id is a YouTube video ID, but it does not explain the encoding, validation, or any nuances beyond the pattern. It meets the minimum requirement but does not fully compensate for the schema's lack of detail, though the parameter is straightforward.

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

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

The description clearly states the tool fetches fresh metadata and engagement for a YouTube video ID, specifying a concrete verb (fetch) and resource (video ID). It also lists the exact data fields returned (views, likes, comments, duration, tags, categories, channel identity), which distinguishes it from sibling tools like get_youtube_channel or get_youtube_video_transcript, even if not explicitly 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?

The description implies usage for retrieving current video data but does not explicitly state when to choose this tool over alternatives. There is no mention of exclusions or criteria like 'use this for metadata, use transcript for text.' The metered/live-data note hints at cost implications but no direct guidance against using other tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable non-annotation behavior: the request is metered and may take longer when captions must be resolved. This cost/latency disclosure goes beyond what the schema or annotations provide and helps the agent set expectations, without contradicting the structured fields.

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

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

Three sentences, each earning its place: the first states the core action, the second summarizes the return shape, and the third adds a critical latency/cost caveat. The most important information is front-loaded with no filler or repetition of the tool name.

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

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

An output schema exists, so return-value details need not be spelled out. The description covers the core action, output summary, and metering behavior. However, it lacks any guidance on how language selection works and does not explicitly route the agent away from sibling tools like get_youtube_channel_transcripts, leaving a noticeable gap for effective tool selection.

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

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

Schema description coverage is 0%, so the description must carry the burden of explaining parameters. It clarifies video_id as a YouTube video ID but says nothing about the language parameter—its purpose, how 'auto' behaves, or how it relates to the returned 'available caption languages.' With two parameters and only one partially explained, the description fails to compensate for the missing schema descriptions.

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

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

The description opens with a specific verb and resource: 'Fetch a normalized transcript for a YouTube video ID.' It names the exact artifact, differentiates from sibling transcript tools that operate at channel or post level, and lists the concrete return types (plain text, timestamped segments, caption languages). No ambiguity remains about what the tool does.

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

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

The description implies usage through its 'Fetch a transcript for a video ID' wording, and the singular 'video' contrasts with sibling get_youtube_channel_transcripts, but it never explicitly states when to choose this tool over alternatives or when not to use it. No exclusions or alternative routing are provided, so usage context must be inferred.

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 provide safety hints (readOnlyHint=true, destructiveHint=false), and the description adds significant behavioral context: pagination returns one page, media URLs are temporary, successful responses support dataset piggybacking, content resolves against US region, and requests are metered. This goes well beyond what 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?

The description is compact and front-loaded, leading with the core action and then adding essential operational caveats. Every sentence adds value, and there is no redundant restating of the title or schema.

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

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

Given the output schema exists and the tool's complexity is moderate, the description covers all important operational aspects: pagination, ordering options, temporary media URLs, regional resolution, piggybacking eligibility, and metering. An agent has enough context to invoke it correctly and interpret behavior.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains username as the video target, cursor as the pagination token from the previous response, sort_by as latest or popular ordering, and region as fixed to US. This fully compensates for the absent schema descriptions.

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

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

The description clearly states the tool fetches one cursor-paginated page of TikTok videos for a given username, with explicit verbs and resource scope. It is easily distinguished from sibling tools like get_tiktok_profile or get_tiktok_video by focusing on listing profile videos.

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

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

The description provides clear operational guidance: use the returned cursor to paginate, choose latest or popular ordering, and expect metered live-data behavior. It does not explicitly name alternatives or say when not to use this tool, but the context is sufficiently clear for an agent to know when this tool applies.

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

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

The description adds valuable behavioral context beyond the annotations: it discloses cursor-based pagination, that each call returns one page only, and that the request is metered and live-data. These details inform the agent about cost and usage patterns, which the readOnlyHint and openWorldHint annotations do not cover.

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

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

The description is extremely concise and front-loaded, with two sentences that each carry important information. No filler or repetition of schema details; every phrase adds value.

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

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

Given the presence of an output schema and safety annotations, the description sufficiently covers the tool's purpose, pagination mechanics, and metered nature. No critical gaps remain for a paginated list operation.

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

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

With 0% schema description coverage, the description compensates by explaining the url parameter as a TikTok video URL and the cursor parameter as the returned value to pass for the next page. It does not explicitly name the parameters but clearly maps the concepts to the schema.

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

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

The description clearly identifies the tool as fetching one cursor-paginated page of current comments for a TikTok video URL. The verb 'Fetch' plus specific resource 'comments for a TikTok video' unambiguously distinguishes it from sibling tools like get_tiktok_video or list_tiktok_profile_videos.

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

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

The description gives clear context on how to use the tool, specifically instructing to pass the returned cursor to retrieve the next page and noting it is a metered live-data request. It does not explicitly state when not to use it or mention alternatives, but the intended use case is clearly implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: response splits into data and not_found, results are unordered, and re-correlation via platform/username is advised. No contradiction with annotations.

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

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

The description is structured into purpose, usage, alternative guidance, examples, and response caveats. Every section earns its place; there is no fluff. The front-loaded first sentence immediately communicates the tool's core function.

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 still adds crucial operational details: max batch size, not_found behavior, and lack of result ordering. It also positions the tool among multiple siblings, covering the full decision space for handle-based lookups.

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

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

Schema coverage is 100%, with the profiles parameter described as 'Profiles to lookup' and nested item fields well-defined. The description adds context like max 100 and exact pairs, but the schema already carries most parameter meaning, so 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 opens with a specific verb and resource: 'Batch-fetch up to 100 profiles by (platform, username) pairs.' It clearly differentiates from siblings like get_profile and search_creators by emphasizing exact batch lookup vs. single or fuzzy lookup.

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 when-to-use guidance is provided with concrete user phrasings, and alternatives are named: 'For one exact platform+username pair, use get_profile. For partial or fuzzy handle/name input, use search_creators or autocomplete_creators. Use semantic_search_creators only for topical/niche/audience discovery.' This is strong differentiation.

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 and destructiveHint, and the description adds useful behavioral context by disclosing the return format: 'a match score (0-1), a good/neutral/avoid decision, and structured reasons.' It also explains how candidates are passed (creator_ids and/or profiles), which goes beyond the schema. It does not mention edge cases like missing candidates, but the annotation coverage lowers the burden.

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

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

The description is front-loaded with the core purpose, then provides usage guidance, alternatives, and examples in a structured order. Every sentence serves a purpose, and the inline examples are compact yet illustrative. It is appropriately sized for a tool with this complexity and does not waste words.

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

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

The description covers when to use the tool, how to invoke it (candidate formats), what it returns, and how it relates to sibling tools. The presence of an output schema further reduces the need to explain return values. It is complete enough for an agent to correctly select and call the tool in a variety of scenarios.

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

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

The input schema already provides detailed descriptions for all parameters (100% coverage), so the baseline is 3. The description adds marginal value by clarifying that intent_query is 'the brief the LLM reasons against' and that intent_context can include target audience or brand values, but these are minor elaborations of the schema descriptions. No new syntax or format details are added beyond what the schema already documents.

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

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

The description opens with a specific verb+resource+context: 'Score how well specific creators fit a campaign brief or search intent.' It clearly distinguishes this tool from siblings by contrasting with semantic_search_creators, search_creators, and find_lookalike_creators, each with a different discovery or resolution purpose.

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

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

The description explicitly states when to use this tool (when the user already has candidates) and when not to, naming three alternatives: semantic_search_creators for discovery, search_creators for resolving rough names, and find_lookalike_creators for similar creators. It also provides concrete examples that chain it with get_profile and get_posts.

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

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

Annotations are all false, providing no safety hints, so the description must disclose behavior. It adds a meaningful cost warning ('may consume Influship account or API usage') and states that it fetches current creator details, implying live data retrieval. However, it does not mention potential side effects (e.g., creating reports) or error behavior, so it carries only part of the burden.

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

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

The description is three sentences, front-loaded with the usage condition, and every sentence adds value: the first gives when-to-use, the second describes the process, the third discloses resource consumption. No fluff or redundancy, making it appropriately concise for the tool's complexity.

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. The description covers the operational flow (fetch, score, render) and notes potential usage costs, which is sufficient for a moderate-complexity tool. It doesn't discuss edge cases like too many/few creators, but the schema's min/max constraints handle that, so the description is complete enough.

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% (all three parameters have descriptions), so baseline is 3. The description adds minimal extra meaning beyond the schema, such as 'canonical' and 'specific campaign brief', but these are also partly in the schema. It doesn't clarify parameter formats or relationships beyond what the schema already provides.

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

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

The description clearly states the tool's function with a specific verb ('renders'), a specific resource (creator comparison), and the process (fetches details, scores against brief). It distinguishes itself from siblings like render_creator_profile (single profile) by emphasizing comparison and scoring of 2–4 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?

The description provides an explicit 'Use this when' condition with clear inputs (2–4 canonical creator IDs and a specific campaign brief). It doesn't mention alternatives or exclusion criteria, but the condition is concrete and actionable, which is sufficient for a clear context without needing to enumerate alternatives.

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

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

Annotations provide no safety hints (all false), so the description carries the burden. It discloses that the operation may consume Influship account or API usage, and specifies the fetched scope (current record plus up to six recent posts). It does not mention rate limits or auth, but the usage warning adds material value.

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 use trigger, and no filler. Each sentence conveys either the use case or the behavioral scope.

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

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

Given a single well-documented parameter, an output schema, and a clear description, the tool definition is complete. The description sufficiently covers purpose, behavior, and cost implication without needing to elaborate return fields.

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 already fully documents creator_id with format, pattern, and description; coverage is 100%. The description's 'canonical creator ID' phrasing only reinforces the schema without adding new syntax or semantics.

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

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

Description uses specific verb 'fetches' and defines scope: visual deep dive on a single canonical creator ID, with current record plus up to six recent posts. It clearly distinguishes from sibling tools like render_creator_comparison or get_creator by emphasizing 'one canonical creator ID' and 'visual deep dive.'

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: when user wants a visual deep dive on one canonical creator ID. It does not name alternatives or exclusions, so it misses the full 5, but the trigger condition is clear and actionable.

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

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

With all annotations false, the description adds a meaningful side-effect warning: 'may consume Influship account or API usage.' It also clarifies that it fetches stored creator details, implying a read operation. However, it does not explicitly state that no data is modified, nor does it discuss error handling for invalid or conflicting IDs.

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

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

The description is three sentences, front-loaded with the primary use case, and every sentence adds actionable guidance: when to use, how to pass IDs, and a prerequisite. No fluff or repetition.

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

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

Given the output schema exists and parameters are minimal, the description covers the essential usage context, prerequisites, and side effects. It could mention what the rendered card includes or what happens if both search_id and creator_ids are provided, but these are not critical gaps with the existing 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 100% and all parameters are described, but the description elevates semantics by explaining when to use search_id vs creator_ids: search_id preserves ranking/evidence from semantic_search_creators, while creator_ids are for lookup results only. This adds decision-making value beyond the schema's property descriptions.

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

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

Description explicitly states the tool renders a shortlist of 1–8 creator cards from discovery or lookup results, and distinguishes it from siblings like render_creator_comparison and render_creator_profile. The trigger condition 'when discovery or lookup tools have returned results' makes the purpose crisp and unambiguous.

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

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

Provides explicit usage conditions: pass search_id after semantic_search_creators to preserve ranking/confidence/evidence, pass creator_ids only for name/handle lookup results, and always call an Influship data tool first. This effectively says when to use the tool and what prerequisites exist, with clear do-not-invent-IDs 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 readOnly/idempotent/non-destructive behavior, lowering the bar. The description adds significant transparency about dual routing, backward compatibility with legacy semantic fields, and conditional endpoint selection—none of which are visible from annotations or schema. There is no contradiction with the structured metadata.

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

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

The description is comprehensive and front-loaded with purpose, but it is somewhat verbose—the 'cheap, fast, and backed by the creator lookup index' phrase adds little functional value. The example block is useful, though it could be tightened without sacrificing clarity.

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 dual-mode tool with 12 parameters, the description covers primary use cases, routing behavior, return-value chaining, and sibling-tool boundaries. It thoroughly compensates for any schema ambiguity and gives the agent enough context to select and invoke the tool correctly, especially given the output schema exists.

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

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

The tool description adds rich context for query usage (e.g., 'query "cris" with query_type "creator_lookup"') and explains how legacy fields are routed. However, the input schema's query description explicitly says 'Do not pass exact handles or usernames here,' which directly conflicts with the tool's primary purpose and creates contradictory parameter guidance for 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?

The description opens with a specific verb and resource—'Find a creator by name/handle'—and explicitly frames it as the default creator lookup tool. It distinguishes itself from siblings like get_profile (exact handle lookup) and semantic_search_creators (topical/niche discovery), making its role unambiguous.

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

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

It provides explicit when-to-use and when-not-to-use guidance: prefer get_profile for exact handles/platforms, use this tool for rough names or partial handles, and prefer semantic_search_creators for niche discovery. Concrete examples for each scenario reinforce the guidance, leaving little room for misinterpretation.

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

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

Annotations already declare readOnlyHint and destructiveHint, giving a baseline safety profile. The description adds useful behavioral context: it returns 'current' live results, uses cursor-based pagination, and explicitly states that 'Each page is one metered request.' This goes beyond the annotations and helps agents anticipate cost.

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

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

The description is compact and front-loaded: one summary sentence, one sentence listing applicable filter dimensions, and one sentence describing pagination and metering. Every sentence the main purpose, the main options, and the key usage constraint without wasted prose.

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

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

For a read-only search tool with an output schema, this description covers the primary query intent, filter semantics, and cursor cycle. It still leaves small gaps such as the meaning of limit/newline and what terminates pagination, but these are partially inferable from schema defaults and the output schema, so the description is close to complete.

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

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

The schema has zero description coverage, so the description is the main provider of meaning. It maps many parameters thematically — upload window, popularity, result type, duration, country, language — and explains ‘pass next_cursor back as cursor for the next page.’ However, it does not clarify the `q`, `limit`, or `cursor` values beyond terms already in the schema, leaving some parameter semantics to be inferred from names and enums.

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

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

The description clearly states a specific verb and resource: 'Search current YouTube results' with filters and pagination. It distinguishes the tool generically from sibling search tools like search_creators and get_youtube_video, but does not explicitly name those alternatives or narrow the resource to videos.

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

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

The description gives clear context for when to use this tool: searching YouTube results with discovery filters and pagination. However, it provides no explicit guidance on when not to use it or how it compares to sibling tools such as search_creators, get_youtube_video, or semantic_search_creators, so the agent must infer the appropriate selection.

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

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses that results come from hybrid vector search matching against profiles, facts, and visual style, and that it 'can return lookalike or topical matches' and 'is allowed to miss an exact username.' It also states the return shape (ranked list with specific fields) and that flat follower/engagement/verified fields should be used to constrain numeric criteria, adding genuine behavioral insight.

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?

Although substantial, every section earns its place: a clear first-line summary, explicit usage boundaries, named alternative tools, illustrative examples, return-value summary, and filter guidance. The structure with short paragraphs and examples makes it easy to scan despite its length.

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

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

Given the tool's complexity (9 parameters, multiple modes, rich sibling context), the description is remarkably complete. It covers purpose, usage timing, exclusions, alternatives, behavioral caveats, return semantics, and parameter usage—all while relying on the output schema for exact return format details.

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

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

The input schema already has 100% description coverage for parameters, so the baseline is 3. The description adds value by warning that exact handles/usernames should not be passed in the query and by advising to use the flat follower, engagement-rate, and verified fields for numeric constraints—semantics not fully obvious from the schema alone.

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 'Semantic discovery search for influencers/content creators using natural-language queries,' which names the specific verb, resource, and mechanism. It clearly differentiates from siblings by explicitly stating this is not for exact handles/usernames and directs those cases to get_profile, search_creators, or lookup_profiles.

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

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

It provides explicit when-to-use ('only when the user asks to discover creators by topic, audience, geography, niche, content style, or campaign criteria') and when-not-to-use scenarios, with concrete examples for both. It names specific alternative tools (get_profile, search_creators, lookup_profiles, find_lookalike_creators, match_creators) and explains when each alternative is appropriate.

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