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; the description adds valuable behavior context: seeds are blended via embeddings, results are ranked with scores, and the flat fields can constrain results. It also mentions resolving handles via autocomplete_creators first, adding practical behavioral guidance.

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 intro, usage guidelines, alternatives, and concrete examples. Every sentence serves a purpose—no filler—and the examples clarify both the tool and when not to use it.

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, two seed types, and several alternative tools), the description fully covers when/how to use it, what it returns, and how to combine with sibling tools. The examples add completeness by showing exact parameter usage for a user request.

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?

Despite 100% schema coverage, the description adds meaning beyond the schema by explaining the difference between seed_creator_ids and seed_profiles, advising to resolve handles via autocomplete_creators, and instructing users to use follower, engagement-rate, and verified fields to constrain results. This helps agents select and populate params correctly.

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 a specific verb ('Find') and resource ('lookalike creators'), and clearly distinguishes itself from sibling tools by naming semantic_search_creators and match_creators with their different use cases. The examples further reinforce the 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?

Explicitly states when to use this tool ('when the user already knows a creator they like'), and provides exclusions with alternatives: 'Use semantic_search_creators instead when you have a topic/niche but no seed' and 'Use match_creators when you have specific candidates...'.

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

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

Annotations already declare this as a read-only, non-destructive operation, so the description's additional value is in explaining behavior not covered by annotations. It discloses that platform+username lookups resolve through the profile endpoint and return both the profile and underlying creator record, and that `include: ['profiles']` behaves differently when using a creator UUID. This is useful behavioral context beyond the generic safety 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?

The description is longer than average but tightly structured with a clear opening, bulleted input modes, and three concrete examples. Every sentence provides actionable decision-making or behavioral context, with no filler or repetition of schema descriptions.

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 multiple input modes, an output schema, and a supported `include` option, the description covers all necessary context: input requirements, behavioral differences between modes, example user requests, and sibling-tool handoffs. It enables an agent to select and invoke the tool correctly without resorting to external knowledge.

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?

Although the schema provides descriptions for all parameters, the description adds essential relational semantics: `id` and the `platform`+`username` pair are alternative lookup paths, the ID comes from specific search tools, and `include` only adds profile summaries when a creator UUID is supplied. The examples also map natural language ('Get @niickjackson on Instagram') to concrete parameter choices.

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

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

The description opens with a specific verb phrase 'Fetch the full record for a single creator' and clearly states the two input modes (ID or exact platform+username), which immediately distinguishes it from sibling search and batch tools. It also reinforces the purpose by naming the specific creator-lookup functions that produce the canonical ID, leaving no ambiguity about what this 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 gives explicit when-to-use guidance: 'Use this when you already have either' a canonical UUID from search/lookalike tools or an exact platform+username pair. It also contrasts with alternatives, recommending `get_profile` when profile metrics are the main need and `lookup_profiles` for batch exact profile lookups, plus follow-up tools like `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 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 declare readOnlyHint=true and destructiveHint=false, and the description adds concrete behavioral context: it returns 'the profile record plus the underlying creator record', handles case-insensitive matching server-side, and requires the username without the @ sign. These details go beyond the annotations and give the agent a clear expectation of behavior and output composition.

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 every sentence serves a purpose: defining scope, giving invocation rules, providing examples, and listing alternatives. The structure is excellent—front-loaded with the core function, followed by actionable guidance and examples, with no filler or redundant 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?

For a simple 2-parameter tool with an output schema and read-only annotations, this description is thoroughly complete. It covers the exact use case, parameter semantics, return value composition, relationship to sibling tools, and alternative invocation paths. There are no gaps that would lead an agent to misuse the 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?

While schema descriptions already explain both parameters (100% coverage), the description enriches them with practical usage instructions: exactly how to pass the username (strip the @, case-insensitivity handled), and provides concrete examples illustrating parameter values. It adds meaning beyond the raw 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 single social profile by (platform, username)', which is a specific verb+resource combination that clearly identifies the tool's function. It explicitly distinguishes itself from siblings by contrasting with search_creators, get_creator, and 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?

Provides explicit when-to-use guidance: 'Always use this first when the user gives an exact handle on a specific platform' and the negative instruction 'Do not use search_creators for an exact platform+username lookup.' It also recommends alternatives for other scenarios (get_creator for existing UUID, lookup_profiles for batch lookups), leaving no ambiguity about tool 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 already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it identifies the tool as a preview tool, notes it operates before account linking, and instructs the assistant on what to explain after showing the preview (connecting an account for live discovery). 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 well-structured and front-loaded with a direct usage directive. Every sentence serves a purpose: usage context, tool purpose, exclusions, and post-action guidance. 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?

For a zero-parameter tool with an output schema and clear annotations, the description is complete: it explains the tool's role, when to use it, what it is not for, and how to handle the post-action conversation. It leaves no gaps for an AI agent to misinterpret.

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 zero parameters, so the description has no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the schema already covers the empty input. The description doesn't need to add parameter information.

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 and explicitly distinguishes it from search, discovery, matching, and comparison requests. The verb 'fetches' with the resource 'sample creator' makes the purpose specific 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?

The description gives an explicit 'when to use' ('user wants to see what Influship can return before linking an account') and 'when not to use' ('should not be used for search, discovery, matching, or comparison requests'). This fully guides selection among siblings.

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

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

Annotations already 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?

Beyond the readOnlyHint/openWorldHint annotations, the description adds important behavioral details: returned media URLs are temporary, eligible media is captured asynchronously, and the request is metered. This gives the agent deeper expectations about side effects and latency.

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

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

Three sentences, front-loaded with the primary purpose, followed by concise behavioral notes. No redundancy or filler—every sentence 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?

The description covers purpose, URL forms, media URL behavior, and metering. The output schema exists, so return values are covered there. The only notable gap is the unexplained 'region' parameter, but overall the tool is well-contextualized.

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 partially compensates by explaining that the 'url' parameter accepts canonical and share URLs. However, the optional 'region' parameter is not mentioned at all, leaving its semantics entirely unexplained.

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', which is a specific verb + resource + output. This clearly distinguishes it from siblings like get_tiktok_video_transcript (transcript) and list_tiktok_video_comments (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 states accepted URL formats (canonical and share URLs) and notes that this is a metered live-data request, giving practical context for when to call. However, it does not directly mention alternatives or 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?

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?

Beyond the annotations (readOnly, openWorld, non-destructive), the description adds key behavioral details: media URLs are temporary, successful responses may be eligible for canonical dataset piggybacking, and this is a metered request. This gives valuable context about side effects and limitations not captured by 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 compact and well-structured. It leads with the primary action, then gives paging/ordering instructions, and follows with important behavioral notes. Every sentence adds value 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 output schema exists and annotations cover safety, the description sufficiently covers core usage: pagination, ordering, temporary URLs, and metering. It does not explain the region parameter, but this is a minor omission especially since the output schema is present. Overall, the description is complete for the tool's 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?

With 0% schema description coverage, the description compensates for cursor and sort_by by explaining their roles ('Use the returned cursor to paginate' and 'choose latest or popular ordering'), and 'for a username' clarifies the username parameter. However, it does not explain the region parameter, leaving a minor 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 clearly states the function: 'Fetch one cursor-paginated page of current TikTok videos for a username.' This is a specific verb+resource, but it does not explicitly distinguish from sibling tools like get_posts or get_tiktok_video, though the 'for a username' scope implicitly differentiates it.

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

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

Provides concrete usage guidance for pagination: 'Use the returned cursor to paginate and choose latest or popular ordering.' It also notes this is a metered live-data request, implying careful use. However, it does not specify when to choose this tool over alternatives or mention any exclusions.

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

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

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?

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.