Influship

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context: 'Cheap and fast', 'Returns a short list of matching creators with their IDs, platforms, and display names', and shows how results feed into downstream tools. No contradictions.

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 longer than typical but well-structured: purpose, usage guidance, examples, and downstream usage. Every section serves a distinct function and there's no fluff. Slightly verbose but highly 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?

The description covers purpose, usage context, alternatives, examples, return format, and downstream integration. Given the tool's simplicity and the presence of an output schema, this is fully 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description reinforces the meaning of q by referencing 'partial input' but doesn't add details about limit, scope, or platform beyond the schema. 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: 'Autocomplete creator names, usernames, or display names from partial input.' It explicitly differentiates from siblings by stating 'prefer over search_creators', 'Use get_profile instead', and 'Use semantic_search_creators only for discovery...'.

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: 'Use this for fast lookup when the user types a partial handle or name' and 'Cheap and fast — prefer over search_creators'. Also explicit exclusions: 'Use get_profile instead when the user gives an exact platform+username pair' and 'Use semantic_search_creators only for discovery...'.

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds behavioral context: seeds are blended via 'creator-profile + visual-style + fact embeddings', results are 'a ranked list of similar creators with scores', and handles resolution via 'autocomplete_creators first if needed'. It also notes the ability to constrain via flat fields. 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 front-loaded with a clear purpose sentence, then organized into usage, seed semantics, alternatives, and examples. It is thorough yet concise, with every sentence contributing value—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?

Given 9 optional parameters, an output schema, and annotations, the description covers all necessary context: when to use, how seeds are blended, parameter relationships, constraints, and alternatives. The output schema handles return details, so no omission is evident.

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?

Though schema coverage is 100%, the description adds significant meaning: explains seed_profiles/seed_creator_ids usage, handle resolution prerequisite, and that flat follower/engagement/verified fields can be used as filters. Examples illustrate seed_profiles structure. This goes well 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 states 'Find creators SIMILAR to one or more seed creators' with a specific verb, resource, and distinguishing scope. It explicitly contrasts with siblings: 'Use semantic_search_creators instead when you have a topic/niche but no seed' and 'Use match_creators when you have specific candidates and want to score their fit against a brief.'

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

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

The description clearly specifies when to use: 'Use this when the user already knows a creator they like and wants more like them' with concrete examples. It also provides exclusions and alternatives ('Use semantic_search_creators instead...', 'Use match_creators when...'), satisfying all guidelines for usage 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 description discloses behavioral details beyond annotations, such as the difference between UUID vs platform+username resolution, and that platform+username inputs resolve through the profile endpoint returning both profile and creator records. It also explains how `include: ['profiles']` behaves only for UUID inputs. Annotations already declare `readOnlyHint` and `destructiveHint`, so this is aligned, not contradictory.

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 moderately long but each section (purpose, when-to-use, include behavior, examples, alternatives) adds value. The examples are useful but somewhat repetitive, with the third example restating the second plus an extra step. Overall it's well-structured and front-loaded.

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

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

Given the tool's multi-mode input (UUID vs platform+username), 4 parameters, and existing output schema, the description covers input selection, include behavior, return context, and distinguishes from siblings. It also notes the batch alternative, making it complete for an AI agent to select and invoke 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 100% coverage with basic descriptions, but the description adds semantic richness: it identifies `id` as a canonical creator UUID from specific search tools, clarifies that `username` requires an exact platform+username pair, and explains the behavior of `include` with each input mode. Examples illustrate concrete parameter values.

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

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

The description opens with 'Fetch the full record for a single creator by ID or exact platform username,' which clearly identifies the verb (fetch), resource (creator record), and scope (single creator). It distinguishes from siblings by naming `get_profile` and `lookup_profiles` as alternatives for different use cases.

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 guidance: use when you already have a canonical creator UUID from specific search tools or an exact platform+username pair. It also states when not to use it, recommending `get_profile` for profile metrics and `lookup_profiles` for batch lookups.

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 clear. The description adds valuable behavioral context beyond annotations by specifying that the data is raw and fresh, and enumerating the exact content types (coauthors, tagged users, paid partnership metadata, etc.), which helps the agent set expectations about data completeness and structure.

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 states the action and resource, and the second sentence provides usage guidance and data scope. Every sentence earns its place with no filler, making it an exemplary concise description.

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), the presence of an output schema, and safe annotations, the description fully covers the necessary context: what data is returned, when to use the tool, and why it exists. Nothing critical is missing.

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

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

The input schema provides 100% coverage of the single parameter 'shortcode' with a clear description ('Instagram post shortcode from a /p/, /reel/, or /tv/ URL'). The tool description does not add additional parameter semantics, but the schema fully documents the parameter, so a baseline 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 ('Fetch') and resource ('raw Instagram post-page data by shortcode'), clearly distinguishing it from sibling tools like get_instagram_posts (plural) and get_instagram_post_transcript. It further differentiates by enumerating the unique data fields it returns (coauthors, paid partnership metadata, video versions, etc.), making the purpose unmistakable.

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 when-to-use scenario: 'when the user needs fresh raw Instagram post metadata that is not guaranteed on regular cached post-list endpoints yet.' This implies an alternative (cached post-list endpoints) and a condition for exclusion, though it does not name a sibling tool explicitly. The guidance is clear and contextually useful.

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

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses automatic transient upstream recovery and per-item success/error details. This adds valuable information about retry behavior and partial failure handling that annotations do not cover, though it omits specifics like rate limits or lookback windows.

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 well-structured: the first sentence states the core function, and the second explains the return behavior. Every sentence contributes meaningful information without redundancy, making it highly efficient for an agent to parse.

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 a single well-documented parameter, an output schema, and annotations covering safety, the description fully addresses the tool's operational context. It adds the necessary behavioral narrative (retries, per-item errors) to round out what structured fields cannot express, leaving no critical 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?

The schema already provides a thorough description of the 'shortcodes' parameter, including source URL types and min/max constraints, giving 100% coverage. The description adds the concept of 'bounded list' but does not substantially extend beyond the schema's parameter details, maintaining the baseline for high 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 verb (fetch), resource (raw Instagram post-page data), and input scope (bounded list of shortcodes). It distinguishes itself from siblings like get_instagram_post by emphasizing the plural 'posts' and the 'raw API' nature, making its batch 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?

Usage is implied through terms like 'bounded list' and 'raw API', which suggest batch retrieval of unprocessed data. However, there is no explicit comparison with alternatives such as get_instagram_post or transcript tools, so the description relies on sibling context rather than clearly stating when not to use 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?

While annotations already indicate read-only and non-destructive behavior, the description adds valuable cache-related details: the response includes raw post metadata on a cache miss and omits the post field on a cache hit. This context is not available from annotations or the schema, enhancing transparency about 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 two succinct sentences, front-loaded with the main action and immediately providing relevant behavioral and alternative-tool guidance. Every word earns its place with no redundancy.

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

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

Given the presence of an output schema and the description's coverage of cache behavior and a sibling-tool alternative, the tool is fully contextualized. The agent has enough to select and invoke it correctly without missing critical information.

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 clear descriptions for both 'shortcode' and 'language'. The description does not add parameter-specific semantics beyond mentioning 'by shortcode', so the baseline of 3 applies where the schema carries the full load.

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

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

The description clearly states the tool's function: 'Transcribe an Instagram video post by shortcode through the raw API.' This is a specific verb (transcribe) and resource (Instagram video post), and it distinguishes from the sibling 'get_instagram_post' by noting the cache behavior and explicitly recommending that tool for metadata needs.

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 alternative: 'use `get_instagram_post` when you need post metadata with a cached transcript.' This provides a clear when-not-to-use condition and directs the agent to a sibling tool, matching the high-standard example.

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, which the description supports. The description adds valuable behavioral context: the nested post field is present on cache misses and omitted on cache hits, explaining a subtle response behavior not evident from annotations. It doesn't mention rate limits or failure modes, but given the read-only annotation, the added cache behavior detail justifies a 4.

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 and front-loaded with the primary action. Every sentence earns its place: the first states the function and scope, the second explains a nuanced cache behavior and points to an alternative. No fluff or redundancy.

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

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

Given the tool has an output schema, an input schema with 100% parameter coverage, and read-only annotations, the description provides sufficient context. It covers the key edge case of cache hits/misses, directs to the sibling tool for different needs, and explains the bounded nature. No significant gaps remain for an agent to select and 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 description coverage is 100%, so the baseline is 3. The description adds extra semantics beyond the schema: it specifies 'bounded list' (aligning with maxItems 10), explains the 'nested post field' behavior in relation to shortcodes, and clarifies that language is optional for auto-detection. This adds meaningful context above the schema descriptions, warranting a 4.

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

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

The description clearly states the specific verb 'Transcribe' and resource 'Instagram video posts by shortcode through the raw API'. It distinguishes from siblings by explicitly mentioning 'bounded list' and directing users to `get_instagram_posts` for post metadata, and the sibling list includes singular/plural transcript tools, which this differentiates.

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

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

The description says when to use this tool vs alternatives: use it when you need transcripts for a bounded list of shortcodes, and use `get_instagram_posts` when you also need post metadata for every shortcode. This explicit alternative guidance 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?

Adds rich behavioral context beyond the read-only annotation: describes pagination via next_cursor/has_more, limit cap at 50, default sort behavior, and cursor-tied-to-sort error semantics. This gives an agent a clear model of how the tool behaves and what to expect.

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?

Though moderately long, the description is well-structured with a clear lead sentence, parameter guidance, return summary, and concrete examples. Every section adds value and none feels redundant with the 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?

For a list tool with pagination, multiple sort modes, and an OR identifier pattern, the description fully covers identification, sorting defaults, pagination semantics, and return fields. Output schema handles structured return details, and the description supplements with usage context and examples.

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%, but the description adds crucial meaning: the OR relationship between creator_id and (platform+username), the semantics behind each sort enum value, and how to use cursor from next_cursor. This goes beyond the schema's field-level 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 creator's posts, sorted and paginated'), making the core purpose clear. However, it does not explicitly distinguish this tool from sibling get_instagram_posts, so it misses the sibling-differentiation criterion for 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?

Provides explicit usage scenarios and examples ('Use this when the user asks to see what a creator has posted'), plus sequencing guidance with get_profile and match_creators. It lacks clear when-not-to-use or alternative-tool exclusions, so it earns 4 rather than 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 say readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds value by disclosing behavior like case-insensitive matching server-side, requiring no '@' sign, and that it returns both the profile record and the underlying creator record—useful 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?

The description is well-structured with a clear lead sentence, usage rules, examples, and alternative-tool notes. Every sentence serves a purpose—no fluff—and the examples are concise yet 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 2-parameter tool with an output schema and strong annotations, the description covers input formatting, return contents, when to use, and when not to use alternatives. It is sufficient for an agent to invoke the tool correctly without ambiguity.

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

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

Schema has 100% coverage with descriptions for both parameters, so baseline is 3. The description adds meaning beyond the schema: it instructs to pass the username without '@', notes case-insensitive matching, and provides parsing examples for URLs and handles, making parameter usage clearer.

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: 'Fetch a single social profile by (platform, username).' It distinguishes clearly from siblings by explicitly reserving search_creators, get_creator, and lookup_profiles for other use cases, and its examples reinforce the exact-match scope.

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

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

Provides explicit usage guidance: 'Always use this first when the user gives an exact handle on a specific platform,' and states negative instructions like 'Do not use search_creators for an exact platform+username lookup.' It also names alternatives for other scenarios (get_creator, lookup_profiles) and gives concrete example prompts.

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

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

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description adds important behavioral context: it is a preview tool with no live data, it must not be used for other operations, and there are specific conversational restrictions (only mention connecting an account, do not discuss plans/pricing). This fully discloses the tool's limited scope and required post-action 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 moderately sized but every sentence adds value. It is front-loaded with usage guidance, then states the purpose, exclusions, and post-preview instructions. Slightly redundant phrasing like 'Use this when' followed by 'preview tool' could be tightened, but overall it's well-structured and not 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?

Given zero parameters, rich annotations, and an output schema, the description still adds all necessary context: when to use, what it returns, exclusions from sibling tools, and post-action behavior. It is fully complete for an agent to select and invoke this tool correctly, even without seeing the output 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?

There are no parameters, so no parameter explanation is needed. The description does not need to compensate for schema gaps, and the tool's behavior is fully described without needing parameter context. A baseline of 4 is appropriate for a zero-parameter tool with no ambiguity.

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 configured sample creator with social profile context', which is a specific verb and resource. It distinguishes itself from siblings by explicitly saying it 'should not be used for search, discovery, matching, or comparison requests'.

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 opens with exactly when to use it: 'when a ChatGPT user wants to see what Influship can return before linking an account.' It also provides explicit exclusions (not for search, discovery, matching, or comparison) and even tells the agent what to say after showing the preview, which is clear 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?

Beyond annotations (readOnlyHint, openWorldHint), the description discloses that data is 'current' and 'normalized', that a leading @ is accepted, and that it is a 'metered live-data request'—important cost/latency context. It also lists returned categories, adding behavioral expectations without contradicting annotations.

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

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

Three sentences: purpose, return contents, and input handling/cost context. Each sentence is informative and front-loaded with the core action. No filler or redundancy.

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

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

With an output schema present (not shown), the description does not need to detail return structure. It covers key aspects: input normalization, live/metered nature, and high-level output categories. For a simple one-parameter tool, this is complete and appropriately scoped.

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 one parameter (username) with no description, so the description carries the full burden. It explains that a leading @ is accepted and usernames are normalized, giving practical meaning to the parameter. While it doesn't provide examples or edge cases, it sufficiently compensates for the 0% 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 uses specific verb 'Fetch' with resource 'TikTok profile' by username, clearly distinguishing from general profile/creator tools. It also states the scope (current, normalized) and returns high-level metrics, making the tool's purpose unambiguous.

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

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

The description indicates this is for TikTok profiles and is a live-data request, implying when to use it (when you need current TikTok data) but does not explicitly name alternatives or exclusions. It provides clear context but lacks direct comparison to sibling tools like get_creator or get_profile.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral details: media URLs are temporary, video media is captured asynchronously, and the request is metered live-data. These go beyond the annotations and help the agent anticipate response characteristics and cost implications.

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

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

The description is three sentences with no redundant phrases. It front-loads the primary purpose and packs critical operational details (URL formats, temp media, async capture, metering) into a compact form.

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 presence of an output schema covers return values, so the description doesn't need to explain them. It adequately covers accepted URL forms, data freshness (current metrics), temporary media URLs, async capture, and metering. For a single-video fetch tool, this is 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?

Schema description coverage is 0%, so the description must compensate. It explains that the url parameter accepts canonical and share URLs, adding semantic value. However, the optional region parameter is completely undocumented in both the schema and description, leaving a 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 normalized details and current engagement metrics for a TikTok video URL,' using a specific verb and resource. It clearly differentiates from siblings like get_tiktok_video_transcript and list_tiktok_video_comments by focusing on video details/metrics rather than transcripts or 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?

The description provides context on when to use the tool (for a single TikTok video URL) and mentions accepted URL formats, but does not explicitly name alternatives or exclusion scenarios. It successfully implies usage without listing sibling comparisons.

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 discloses concrete behavioral traits: transcript content does not expire and is reused, and requests are metered with potentially slower generation. This gives the agent actionable expectations not encoded in the schema.

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 brief sentences, each carrying distinct information: the primary action, the output format, caching behavior, and performance characteristics. Front-loaded with purpose and no redundant language.

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 tool with an output schema and strong annotations, the description covers operation, expected returns, caching, metering, and latency. There are no significant gaps; the description is complete for selecting and invoking this 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?

The input schema has a single url parameter with 0% description coverage. The description only implies the URL should point to a TikTok video; it does not explicitly state accepted formats or normalization expectations. This is adequate but not fully compensating for 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 'Fetch or generate a normalized TikTok video transcript,' a specific verb-object pair that precisely identifies the tool's function and scope. Mentioning 'TikTok' and 'transcript' clearly differentiates it from sibling tools like get_instagram_post_transcript.

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 clear operational context: canonical transcripts are reused on later requests and generation is metered/slow. This implies when a cached result may be available but does not explicitly name alternatives or exclusions, 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 indicate readOnly and non-destructive, but description adds significant behavioral details: media URLs are temporary, responses are eligible for canonical dataset piggybacking, and the request is metered. This goes well beyond the structured hints.

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 sentences, front-loaded with the core function. Each sentence adds essential information (pagination, ordering, temporary URLs, metering) without 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?

Given the presence of an output schema and rich annotations, the description covers all necessary operational aspects: one-page pagination, cursor usage, ordering options, temporary media URLs, and metered nature. It is comprehensive for a tool of this complexity.

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

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

Schema coverage is 0%, so the description must compensate. It explains the purpose of 'username' (fetch videos for a username), 'cursor' (paginate with returned cursor), and 'sort_by' (latest or popular ordering). However, the 'region' parameter is not mentioned in the description, leaving a small 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?

Description uses specific verb 'Fetch' and identifies exact resource: 'one cursor-paginated page of current TikTok videos for a username.' This clearly distinguishes it from siblings like get_tiktok_video (single video) and get_tiktok_profile (profile info).

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 usage context: pagination via cursor, ordering via 'latest' or 'popular', and a warning that this is a 'metered live-data request.' It doesn't explicitly name alternatives, but the context is clear enough for selecting this tool over single-video or comment-list 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, covering the safety profile. The description adds valuable behavioral context: it is cursor-paginated (not a one-shot fetch), metered (rate/cost implications), and live-data (not cached/historical). It also explains the pagination workflow, going beyond 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 short sentences, each serving a distinct purpose: what it does, how pagination works, and the metering/live-data implication. The description is front-loaded with the primary action and contains no filler or redundant 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?

Given the tool's simplicity (two parameters, annotations present, output schema exists), the description fully covers what an agent needs: read-only behavior (via annotations), pagination handling, and the metered/live-data constraint. Return values are already defined by the output schema, so no additional detail is necessary.

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 for parameters. It identifies the URL parameter as a 'TikTok video URL' and explains the cursor parameter with 'Pass the returned cursor to retrieve the next page.' Both parameters get meaningful contextual explanation, compensating for the schema's lack of 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 'Fetch one cursor-paginated page of current comments for a TikTok video URL,' providing a specific verb (fetch), a clear resource (comments for a TikTok video), and a scoping qualifier (cursor-paginated page). This clearly differentiates from sibling tools like get_tiktok_video and list_tiktok_profile_videos, which focus on video metadata or profile feeds.

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 establishes clear context by stating it returns one page of current comments and that the returned cursor should be passed for the next page. While it does not explicitly list alternative tools, there is no other comments-related sibling tool, making the intended use unambiguous. It stops short of explicit when-not-to-use 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=true annotation, the description discloses important runtime behavior: the response splits into `data` and `not_found`, and profiles are returned in no particular order, requiring re-correlation via platform/username. It also notes the round-trip efficiency benefit. These are not inferable from the schema or 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 well-structured: a one-sentence summary, a when-to-use paragraph with examples, an explicit alternatives paragraph, and a return-behavior note. Every sentence earns its place, and the most critical information is front-loaded. Despite being a bit long, it is appropriately sized for the tool's complexity and avoids 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 is complete given the tool's complexity. It covers purpose, usage, examples, alternatives, and return behavior. The existence of an output schema means the description need not re-explain return values, but it still adds critical context like unordered results and the not_found split. Nothing important is missing.

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

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

The input schema already covers the `profiles` array with item definitions, required fields, and min/max constraints (100% coverage). The description adds meaningful context by framing these as '(platform, username) pairs' for 'exact batch handle lookup' and explaining that not_found contains unrecognized pairs. This goes slightly beyond the schema's bare 'Profiles to lookup' with extra usage 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?

The description opens with 'Batch-fetch up to 100 profiles by (platform, username) pairs' – a specific verb, resource, and constraint. It then clearly distinguishes this tool from siblings, noting that `get_profile` handles a single exact pair, `search_creators` and `autocomplete_creators` handle fuzzy input, and `semantic_search_creators` handles topical discovery.

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

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

The description gives explicit when-to-use guidance: 'when the user has a list of handles and you need profile data for all of them at once.' It also provides concrete examples of user requests that should and should not use this tool, and names alternative tools for other scenarios (e.g., semantic_search_creators for 'Find wellness creators in Austin'). No ambiguity remains.

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 valuable behavioral context: it returns a match score (0-1), a good/neutral/avoid decision, and structured reasons, and it clarifies that candidates can be passed as UUIDs and/or profiles. This goes beyond annotations, though it doesn't describe sorting, pagination, or failure behavior, so it isn't 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?

The description is longer than average but well-organized: core purpose first, followed by parameter guidance, sibling disambiguation, and concrete examples. Each sentence adds value, though the example section is somewhat verbose and could be tightened without losing 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?

Given the tool has 4 parameters, full schema coverage, an output schema, and 13 sibling tools, the description provides sufficient context: it explains what the tool does, when to use it, how to handle different input forms, how it relates to siblings, and includes both brief and full user-intent examples. There are no significant gaps 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 description coverage is 100%, so the baseline is 3. The description adds practical parameter semantics by stating that creator_ids and profiles can be used 'and/or', that intent_query is 'the brief the LLM reasons against', and that intent_context is optional extra context (target audience, brand values, prior collabs). This helps an agent compose valid inputs beyond what the schema alone conveys.

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: 'Score how well specific creators fit a campaign brief or search intent.' It clearly distinguishes this from sibling tools by noting the tool evaluates existing candidates, whereas semantic_search_creators is for discovery and search_creators for resolving handles.

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 guidance: use when the user already has candidate creators in mind and wants fit evaluation. It also names alternatives with explicit conditions ('Use semantic_search_creators when you don't have candidates yet', 'Use search_creators first when you only need to resolve rough creator names/handles', 'Use find_lookalike_creators when you want creators similar to known good fits'). Realistic user-phrasing examples reinforce 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?

The description warns that the tool 'may consume Influship account or API usage,' which is useful cost-related context. However, annotations do not include readOnlyHint, leaving the possibility of side effects unclear; the description does not clarify whether any persistent state changes occur or how the rendering process behaves in detail.

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

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

The description is two sentences, front-loaded with the usage trigger, and contains no filler. Every clause earns its place.

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

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

Given the output schema exists, the description adequately covers the input requirements, process, and a cost caveat. It could be more thorough by noting when not to use this tool or how the output relates to other render tools, but it remains sufficient 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 coverage is 100%, so the schema already documents all parameters. The description adds the qualifiers 'canonical' and 'specific' but does not meaningfully enrich understanding beyond the schema.

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

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

The description clearly states the tool fetches current creator details, scores each against a campaign brief, and renders a side-by-side comparison. This distinguishes it from sibling tools like render_creator_profile (single profile) and search_creators (discovery).

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 opens with 'Use this when the user has 2–4 canonical creator IDs and a specific campaign brief,' providing clear usage context. It does not mention alternatives or when not to use it, but the trigger conditions are well-defined.

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 annotation hints false, the description carries the burden and discloses key behavior: it fetches the current creator record and up to six recent posts, and it 'may consume Influship account or API usage.' This cost/resource warning is valuable beyond what annotations provide. It does not describe side effects or reversibility, but the operation is presented as a fetch/read, and the consumption warning is sufficient.

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 usage trigger ('Use this when...'). Every phrase adds value: the scope ('one canonical creator ID'), the data retrieved, and the cost warning. 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?

For a tool with one parameter and an existing output schema, the description explains the data scope (record + up to six posts) and the usage cost caveat. It gives enough context for an agent to decide appropriately. It could have mentioned how this differs from get_creator/get_profile, but the 'visual deep dive' phrasing and cost warning provide sufficient differentiation.

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 100% coverage with a clear description for creator_id ('Canonical Influship creator ID.'). The tool description merely repeats 'canonical creator ID' without adding format details or constraints. Since the schema does the heavy lifting, a baseline 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 clearly states a specific action: 'visual deep dive on one canonical creator ID' and describes what it fetches ('current creator record plus up to six recent posts'). It distinguishes itself from siblings like render_creator_comparison and render_creator_shortlist by focusing on a single creator and a visual/deep-dive format.

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 a clear when-to-use directive: 'Use this when the user wants a visual deep dive on one canonical creator ID.' It also implicitly differentiates from simpler lookup tools by flagging that it 'may consume Influship account or API usage,' suggesting it's for heavier, explicit requests. It does not name alternative tools or exclusions, but the context is 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 are all false, so the description carries the burden. It discloses that the tool fetches stored creator details, preserves ranking/confidence/evidence, and 'may consume Influship account or API usage.' This adds valuable behavior context beyond the annotations, though it doesn't elaborate on output format (covered by output schema).

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 sentences, none wasted. It front-loads the primary use case, then gives parameter routing, a prerequisite, and a cost warning. The structure is clear and scannable.

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 usage context, parameter selection, prerequisites, and side effects. It doesn't explicitly state whether search_id and creator_ids are mutually exclusive, which is a minor gap given neither is required in the schema. Overall it is highly complete for a rendering 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 baseline is 3. The description adds important parameter semantics: search_id preserves exact ranking/confidence/evidence, creator_ids are only for lookup results, and the 'do not invent IDs' warning. This goes beyond the schema's field descriptions and clarifies parameter selection rules.

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 renders a shortlist of 1–8 creator cards for scanning, and distinguishes it from siblings like render_creator_profile and render_creator_comparison by specifying the discovery/lookup context. It also specifies the exact resource (creator cards) and the action (render/shortlist).

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 the tool ('when discovery or lookup tools have returned results'), and provides conditional guidance for parameters: use search_id after semantic_search_creators, or creator_ids for name/handle lookup results. It also says 'Always call an Influship data tool first; do not invent IDs', which gives a clear prerequisite and an alternative direction.

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, and non-destructive behavior, so the description adds valuable context about dual routing: it can return either autocomplete-style lookup results or legacy semantic results depending on the query, and it preserves backward compatibility with legacy fields. This goes beyond what annotations provide.

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 longer than average but well-structured with a clear purpose, usage guidance, examples, and return-value notes. Every section carries useful information for a tool with dual behavior; minor redundancy could be tightened but complexity justifies the 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 12 parameters, dual routing, existing output schema, and rich annotations, the description is highly complete. It explains return types, downstream tool chaining, and the legacy fallback behavior, giving an agent all context needed to select and 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?

The input schema covers all 12 parameters (100% coverage), so the baseline is 3. The description adds meaningful semantics by explaining when to use query_type 'creator_lookup' versus 'semantic_discovery' and showing examples with exact query strings. However, the schema's query description contradicts the tool's purpose by saying 'do not pass exact handles or usernames here', which the description does not explicitly correct, creating some ambiguity.

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 this tool finds a creator by name/handle while also preserving legacy semantic search. It distinguishes from siblings by explicitly naming get_profile for exact handles on specific platforms and semantic_search_creators for topical discovery, and it provides illustrative examples.

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

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

The description gives explicit when-to-use guidance: use as the default creator lookup for creator-ish strings, prefer get_profile for exact handles on a specific platform, and prefer semantic_search_creators for new topical/niche discovery. Concrete examples map user requests to the correct tool and query_type.

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 known. The description adds meaningful behavioral context beyond annotations: it explains the hybrid vector search mechanism, states that results may be lookalike/topical matches, and acknowledges that exact usernames may be missed. It also advises using flat numeric fields to constrain results, which clarifies expected 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 long but well-structured and every sentence earns its place. It opens with a clear purpose, gives concrete usage rules, includes illustrative examples with user queries, and differentiates from siblings. The examples are compact and highly informative, making the length appropriate 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?

Given the tool's complexity, its 9 parameters, and a rich sibling landscape, the description is complete. It covers the query semantics, return value summary, filtering approach, and exclusions, and it complements the existing output schema and annotations. No critical usage context 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 adds value beyond the schema by explaining the nature of the query parameter (natural-language, topic-based) and by explicitly instructing to use the flat follower, engagement-rate, and verified fields for numeric constraints. This enriches parameter understanding, though the schema already documents each parameter well.

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

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

The description states a specific verb and resource: 'Semantic discovery search for influencers/content creators using natural-language queries.' It clearly distinguishes itself from sibling tools by explicitly naming alternatives like get_profile, search_creators, lookup_profiles, find_lookalike_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?

The description provides explicit when-to-use guidance: 'Use this only when the user asks to discover creators by topic, audience, geography, niche, content style, or campaign criteria.' It also gives explicit when-not-to-use instructions and names alternative tools for exact handle lookup, similar-creator search, and scoring creators against a brief.

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