Influship

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

The description discloses that the tool is 'Cheap and fast' and returns 'a short list of matching creators with their IDs, platforms, and display names.' This adds context beyond the readOnlyHint annotation, though the output format could be more detailed. 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 concise and well-structured: purpose, usage guidelines, examples, and output details are clearly separated. Every sentence adds value, and the length is appropriate.

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 moderate complexity (4 parameters, all documented) and the presence of an output schema (not shown but referenced), the description adequately covers inputs, outputs, and downstream usage. It fully addresses what an agent needs to know.

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%, but the description adds value by providing examples and usage context (e.g., 'find @cris' for partial input). It doesn't repeat schema details, making it a helpful supplement.

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 'Autocomplete creator names, usernames, or display names from partial input,' specifying the verb and resource. It distinguishes the tool from siblings like `search_creators`, `get_profile`, and `semantic_search_creators`, 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?

Explicit when-to-use guidance for partial handle/name lookups, and when-not-to-use with specific alternative tools named (`get_profile`, `search_creators`, `semantic_search_creators`). Includes concrete examples, e.g., 'User: "Who is that fitness coach called Jane?" -> 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 show `readOnlyHint: true` and `destructiveHint: false`, so the description doesn't need to reiterate safety. It adds value by explaining the blending mechanism (creator-profile + visual-style + fact embeddings) and the returning of a ranked list with scores. However, it could briefly mention pagination or response format.

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 clear opening sentence, a usage section, parameter details, and examples. Every sentence adds value, and there is no redundancy or fluff. It is appropriately sized 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 has 9 parameters, an output schema, and a need to distinguish from 13 siblings, the description covers all key aspects: purpose, usage context, seeds, filtering, examples, and limits. It is complete and leaves no major gaps for an AI agent to misunderstand.

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 context by explaining the role of `seed_profiles` and `seed_creator_ids`, mentioning the default and max for `limit`, and noting that filter fields (follower count, engagement rate, verified) can constrain results. This helps the agent understand which parameters are central.

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 purpose: finding creators similar to seed creators. It uses specific verbs like 'Find creators SIMILAR' and distinguishes from siblings by name-dropping alternative tools. Examples 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?

Explicit guidance on when to use this tool (user has seed creators) versus alternatives (`semantic_search_creators` for topics, `match_creators` for specific candidates). Also includes concrete examples of when to use and when not to, making it easy for the agent to decide.

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 readOnlyHint=true and destructiveHint=false. Description adds context about resolution behavior for platform+username inputs and the effect of the include parameter. 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?

Well-structured with bullet points and examples. Slightly long but every sentence adds value; examples are instructive.

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 output schema and annotations, the description is comprehensive: covers purpose, usage, parameters, examples, and tool differentiation. No gaps.

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

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

Schema coverage is 100% so baseline is 3. Description adds value by explaining the two usage modes, providing examples, and clarifying the include parameter's behavior in both modes.

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?

Clearly states 'Fetch the full record for a single creator by ID or exact platform username.' Distinguishes two input modes and contrasts with sibling tools like search_creators and get_profile.

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

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

Explicitly says when to use ('when you already have a canonical creator UUID or exact platform+username pair') and when to use alternatives (get_profile for profile metrics, 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 indicate readOnlyHint=true and destructiveHint=false. The description adds context about data freshness and lists specific fields (coauthors, tagged users, paid partnership metadata, etc.) available only when fetched fresh, beyond what annotations convey.

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

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

Four sentences, each carrying distinct information: purpose, usage context, and list of data fields. No redundant or filler text, efficiently structured.

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

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

Given the presence of an output schema and annotations, the description covers purpose, usage, and data scope comprehensively for a single-parameter tool. It leaves no obvious 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?

With only one parameter (shortcode) and 100% schema description coverage, the schema already defines it as 'Instagram post shortcode from a /p/, /reel/, or /tv/ URL'. The description does not add further detail about the parameter beyond mentioning 'shortcode'.

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 it fetches raw Instagram post data by shortcode. It specifies the resource (Instagram post) and action (fetch), and distinguishes from sibling 'get_instagram_posts' by emphasizing freshness and raw data not in cached lists.

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 says 'Use this when the user needs fresh raw Instagram post metadata not guaranteed on regular cached post-list endpoints yet', providing clear when-to-use and implying when not to. Lists specific data categories available only via this tool, guiding 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 that it returns per-item success/error details and uses 'raw API', providing useful context beyond 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?

Two concise sentences front-loaded with the action. No wasted words, 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 one parameter fully documented, annotations covering safety, and an output schema, the description adds return structure details. Missing edge cases but adequate for basic 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% with a clear description for the parameter. The description adds minimal extra meaning ('bounded list') but is not needed; 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 action (fetch), resource (Instagram post-page data), and scope (bounded list of shortcodes). It distinguishes from siblings like get_instagram_post (singular) and get_instagram_post_transcripts (transcripts).

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

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

No explicit when-to-use or when-not-to-use guidance. While 'bounded list' implies batch usage, it doesn't contrast with singular get_instagram_post or other siblings. Missing alternatives or exclusions.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds behavioral context: 'retranscribes every request' (no caching) and future caching plans. However, it does not disclose rate limits, authentication, or error handling for invalid shortcodes.

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: first states purpose concisely, second adds a caveat about retranscription and future plans. Every sentence earns its place; no 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?

With an output schema present and good annotations, the description explains current behavior (no caching, language auto-detection). It lacks details on error cases (e.g., invalid shortcode) but is largely complete for a simple 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?

Input schema coverage is 100% with descriptions for both parameters (shortcode and language). The description does not add further meaning beyond what the schema provides, 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 clearly states 'Transcribe an Instagram video post by shortcode', specifying a clear verb and resource. It distinguishes from siblings like get_instagram_post (retrieve post metadata) and get_instagram_post_transcripts (plural, likely batch).

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 notes that 'for now this retranscribes every request' and mentions future caching, but does not explicitly guide when to use this tool versus alternatives like get_instagram_post_transcripts or how to obtain shortcodes. Usage context is implied but not definitive.

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 context beyond annotations: 'retranscribes every request' (no caching) and 'includes raw post data'. Annotations already indicate read-only, but description enriches with specific behavior.

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

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

Two sentences, no waste. Front-loaded with action and resource, second sentence adds essential caveats.

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 output schema exists, description adequately covers behavior (retranscribes, includes raw data) and boundaries (bounded list). No 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 coverage is 100%, so description adds limited value for parameters. 'Bounded list' reinforces maxItems, but no new detail about language or shortcodes beyond 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?

Clearly states it transcribes Instagram video posts by shortcode, and mentions 'bounded list' distinguishing from singular sibling 'get_instagram_post_transcript'. Differentiates from other sibling tools that retrieve posts without transcripts.

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?

Implies usage for batch transcription (bounded list, max 10), and mentions retranscribing every request, but does not explicitly compare to alternatives or state when to use singular vs batch.

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 it's non-destructive. The description adds that it returns post records with caption, media URL, counts, timestamps, plus pagination fields like has_more and next_cursor. 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 well-structured with a clear first sentence, followed by usage guidelines, parameter details, return description, and examples. It is concise (no redundant sentences) and front-loaded with the purpose.

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 complexity (6 parameters, pagination, sorting options) and the presence of an output schema, the description covers all necessary aspects: what it does, when to use, parameter semantics, return values, and pagination details. It is complete and informative.

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 significant value: it explains the two identification methods (creator_id OR platform+username), default sort ('recent'), limit cap at 50, and cursor pagination. Examples clarify usage scenarios.

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 'Fetch a creator's posts, sorted and paginated.' It specifies the verb (fetch), resource (creator's posts), and includes sorting and pagination. Examples distinguish it from sibling tools like get_instagram_posts by mentioning platform+username or creator_id.

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 when to use: when the user asks to see a creator's posts. It provides specific user query examples and mentions when to use after get_profile for fit analysis. It also hints at alternatives like calling match_creators afterward.

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 context beyond that: it specifies the return structure (profile + creator record) and notes case-insensitive matching. This adds value but does not disclose major new behavioral traits.

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 appropriately sized, starting with a clear purpose, then usage guidelines, examples, return info, and alternative tools. Every sentence contributes value without 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's simplicity (2 params, output schema exists, annotations present), the description covers all needed aspects: purpose, when to use, parameter handling, return content, and sibling differentiation. It leaves no gaps.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds extra guidance: 'Pass exactly the username they typed without the @ sign' and 'case-insensitive matching is handled server-side', plus examples of parsing platform and username. This meaningfully supplements 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 'Fetch a single social profile by (platform, username)' and details the returned fields (bio, metrics, activity, growth, creator ID). It distinguishes from siblings like 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?

Explicitly says 'Always use this first when the user gives an exact handle on a specific platform' and provides examples. It also tells when not to use it: 'Do not use search_creators for an exact platform+username lookup' and suggests alternatives like get_creator or lookup_profiles.

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. Description adds that it is a low-cost preview tool and includes detailed behavioral instructions for the agent (the script to tell user about account linking). 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?

Front-loaded with key purpose and usage. Each of the 5 sentences adds value: use case, action, exclusions, post-action script. Efficient and well-structured.

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

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

Given simple no-param tool with output schema, description provides complete context: purpose, usage boundaries, behavioral traits, and agent instructions. No 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?

No parameters. Baseline 4 as per guidelines. Description does not need to add parameter meaning.

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

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

Clearly states it fetches one configured sample creator for preview. Distinguishes from sibling tools by explicitly stating it should not be used for search, discovery, matching, or lookalike requests. Specific verb+resource.

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

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

Explicitly states when to use (preview before linking account) and when not to use (not for search, etc.). Also provides post-action instructions for the agent on what to tell the user, which further guides appropriate usage.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false. Description adds that response splits into data and not_found, and profiles are in no particular order—valuable extra context beyond 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?

Description is well-structured with front-loaded key info, examples, and clear separation of use cases. A few sentences could be tightened, but overall efficient and easy 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?

Given the tool's simplicity, full schema coverage, annotations, and presence of output schema, the description covers all needed context: use case, alternatives, response format, and ordering. No gaps.

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

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

Schema coverage is 100% and well-documented. Description repeats the purpose (batch-fetch) but doesn't add significant new meaning to the parameter structure beyond what the schema already provides. 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 clearly states it batch-fetches profiles by (platform, username) pairs, up to 100. It differentiates from siblings like get_profile (single), search_creators (fuzzy), and semantic_search_creators (topical), 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?

Explicitly states when to use (exact batch handle lookup) and when not (fuzzy/partial input). Provides specific examples and names alternatives (get_profile, search_creators, autocomplete_creators, semantic_search_creators), giving clear 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 declare readOnlyHint=true and destructiveHint=false, and the description adds important behavioral context: returns a match score (0-1), a good/neutral/avoid decision, and structured reasons. There is no contradiction; the description enriches the behavioral model 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 concise yet rich, using about 10 lines. It front-loads the core purpose, then provides usage guidelines, alternatives, and examples without redundancy. 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?

Given 4 parameters (1 required), high schema coverage, and an existing output schema (implied by return description), the description provides complete guidance. It covers parameter relationships, workflow integration with get_profile and get_posts, and disambiguation from sibling tools.

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 baseline is 3. The description adds meaningful context: explains that intent_query is the brief the LLM reasons against, intent_context is optional extra context, and clarifies the relationship between profiles and creator_ids. This adds value 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 uses a specific verb ('score', 'evaluate fit') and clearly identifies the resource ('specific creators', 'campaign brief'). It explicitly distinguishes from sibling tools by naming semantic_search_creators, search_creators, and find_lookalike_creators, making it easy for an agent to select correctly.

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 candidate creators are already known) and when to use alternatives (for discovery or rough name resolution). It provides concrete examples and names the alternative tools, offering clear guidelines for correct invocation.

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, idempotentHint, destructiveHint false. Description adds value by noting the tool is 'cheap, fast, and backed by the creator lookup index' and explains automatic routing between legacy and new behavior. 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?

Front-loaded with purpose and usage guidelines, followed by examples and return info. Well-organized sections, but slightly verbose with repeated 'use this for X' and legacy details. Could tighten 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 12 parameters (1 required) and an output schema, the description covers all necessary aspects: use cases, sibling differentiation, routing logic, parameter guidance, and post-return actions. Output schema exists, so return handling is appropriately brief.

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%, baseline 3. Description adds significant context beyond parameter descriptions, e.g., explaining the query_type parameter's routing logic and the legacy field handling. This helps the agent choose the right variant of the tool, compensating beyond basic 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?

Clearly states it finds a creator by name/handle while preserving legacy semantic search. Distinguishes from siblings like get_profile and semantic_search_creators by specifying its role as default lookup for non-canonical identifiers.

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 instructs when to use this tool (default lookup for creator-ish strings) vs. alternatives: prefer get_profile for exact handles on a platform, and semantic_search_creators for topical discovery. Includes concrete examples with query_type recommendations.

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, indicating no destructive actions. The description adds behavioral context beyond this, such as mentioning hybrid vector search, the ability to return lookalike or topical matches, and that it 'is allowed to miss an exact username.' It does not contradict annotations. A slight deduction because the description could further detail rate limits or pagination, but it is solid overall.

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 the core purpose. It uses bullet-like formatting (via line breaks and dashes) and provides examples in an organized manner. Every sentence adds necessary information, with no redundancy. It is concise given the complexity of the tool and sibling relationships.

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, many siblings, and an output schema), the description is highly complete. It explains the return format ('ranked list of creators with id, platform, username, follower count, engagement rate, top categories, evidence facts'), provides usage examples, and distinguishes from all relevant siblings. The presence of an output schema reduces the need to detail return values, and the description covers all other critical aspects.

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 baseline is 3. The description adds value by explaining how to use specific parameters (e.g., 'Use the flat follower, engagement-rate, and verified fields to constrain results') and clarifying the query parameter should not receive handles. This extra context raises the score above baseline.

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 performs 'semantic discovery search for influencers/content creators using natural-language queries.' It specifies the verb (discovery search), resource (creators), and input type (natural-language queries). It distinguishes from siblings by explicitly listing when to use alternatives like get_profile, search_creators, lookup_profiles, find_lookalike_creators, and match_creators, providing clear differentiation.

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 (e.g., 'discover creators by topic, audience, geography, niche, content style, or campaign criteria') and when not to use it (e.g., 'exact handles, usernames, or known creator names'). It directs to specific alternatives with concrete examples, such as using get_profile for a specific platform and handle. This fully equips an AI agent to decide correctly.

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