Influship Influencer Marketing MCP

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds behavioral context: 'cheap and fast', and clarifies it returns a short list of matching creators with IDs, platforms, and display names. 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?

Well-structured with clear sections, examples, and alternative tool references. Each sentence adds value; no redundancy or unnecessary text.

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), 100% schema coverage, and an output schema, the description covers purpose, usage, behavior, and downstream usage of results. No gaps identified.

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 contextualizing parameters through examples and use cases, and explaining how outputs (IDs) are used downstream. However, it doesn't elaborate on individual parameter details 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?

The description clearly states the tool autocompletes creator names, usernames, or display names from partial input. It uses a specific verb ('autocomplete') and resource ('creators'), and distinguishes from siblings like `get_profile`, `search_creators`, 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?

Explicit guidance on when to use this tool (partial handle/name lookup) and when to use alternatives (get_profile for exact platform+username, search_creators for similar fuzzy lookup, semantic_search_creators for discovery). Includes concrete examples.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds valuable behavioral context: blends embeddings (creator-profile, visual-style, fact), returns ranked list with scores, and mentions pagination via cursor. No contradictions 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 moderately long but well-structured with clear sections, bold emphasis, and bullet-point examples. Every sentence adds value; no fluff. Could be slightly more concise, but the detail is justified given 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 9 parameters, zero required, presence of output schema, and complexity of blending logic, the description covers purpose, usage, seeding methods, filtering, pagination, and limitations (max 100 results). It provides sufficient context for an agent to invoke correctly.

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

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

All 9 parameters have descriptions in the schema (100% coverage). Description adds extra value by explaining that usernames need resolution via autocomplete_creators, and that follower/engagement parameters can be used to constrain results. This goes beyond schema definitions.

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 'Find creators SIMILAR to one or more seed creators,' using a specific verb and resource. It distinguishes itself from siblings like semantic_search_creators and match_creators by explicitly mentioning when to use each.

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 criteria: use when the user has a known creator and wants similar ones. Clearly states when not to use (e.g., topic/niche search) and directs to alternatives. Includes concrete examples with seed_profiles and seed_creator_ids.

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 readOnlyHint and destructiveHint; description adds context on how profile data is included differently based on input, and mentions resolution through profile endpoint. No contradiction.

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 sections, but slightly verbose with multiple examples. Could be tightened slightly 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?

Covers purpose, usage scenarios, parameter behavior, alternatives, and return behavior. Output schema exists externally, so no need to describe return format. Complete for a fetch-by-ID tool.

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

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

Schema has 100% coverage with descriptions; description adds examples, pairing of platform+username, and behavior of include parameter. Provides concrete user queries mapping to parameters.

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

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

Description clearly states 'Fetch the full record for a single creator by ID or exact platform username' with specific verbs and resources, and distinguishes from siblings like search_creators and get_profile via examples.

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

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

Explicitly tells when to use this tool (when you have UUID or exact platform+username) and when not to (use get_profile for profile metrics, lookup_profiles for batch). Provides 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 annotations (readOnlyHint, etc.), the description enriches transparency by listing specific data elements included (coauthors, tagged users, etc.) and emphasizing the 'fresh raw' nature, adding significant 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?

The description is two sentences with no filler. The first sentence states the action, the second explains when to use and what it returns—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 the single parameter and existing output schema, the description covers purpose, usage, and return details comprehensively. Sibling tools provide context for alternatives.

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 parameter description. The tool description reinforces usage context but doesn't add new parameter details; however, it integrates the parameter naturally into the purpose.

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 raw Instagram post-page data by shortcode' with a specific verb and resource. It distinguishes from cached post-list endpoints, 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 explicitly says 'Use this when the user needs fresh raw Instagram post metadata that is not guaranteed on regular cached post-list endpoints yet,' providing clear usage context. It implies alternatives but doesn't name them explicitly.

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 safe read; description adds that data is raw, from the raw API, and returns per-item success/error details, providing useful behavioral context.

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

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

Two concise sentences front-load the verb and resource, then clarify return format, with no wasted 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?

Given simple parameter set, helpful annotations, and presence of output schema, the description fully covers what the tool does and how it behaves.

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 covers the single parameter completely (100%), so description adds minimal extra meaning beyond referencing the raw API and bounded list, meeting 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 it fetches raw Instagram post-page data for a bounded list of shortcodes, distinguishing it from the singular get_instagram_post sibling by specifying batch behavior and per-item response.

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?

Implicitly guides usage for multiple shortcodes via name and description, but lacks explicit when-not or alternative 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 indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: current lack of caching, future cached reads, and pricing stability. No contradictions found.

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: first sentence succinctly defines the tool's purpose, second sentence provides essential behavioral context. No fluff, efficiently front-loaded.

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

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

With output schema present, return values need no explanation. Annotations cover safety. Description adds caching and pricing context. However, lacks details on error handling or rate limits, but overall sufficient for a tool with low complexity.

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

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

Schema coverage is 100% with both parameters described in the input schema. The description does not add new semantic information beyond the schema, warranting the baseline score of 3.

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 the action (transcribe), the resource (Instagram video post), and the input method (by shortcode). Distinguishes from sibling tools like get_instagram_post (post data) and get_instagram_post_transcripts (plural).

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 mentions current behavior (retranscribes every request) and future plans (cached reads), but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. The context of pricing and caching is helpful but not sufficient for clear usage guidance.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds that requests are retranscribed each time (no caching) and successful items include raw post data. 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?

Two sentences efficiently convey purpose and key behavioral detail without extraneous words. Front-loaded with the core action.

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 simple schema, annotations, and existence of output schema, the description is mostly complete. Mentions retranscription behavior and output content, though could clarify the exact return structure. Adequate for a low-complexity tool.

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

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

Schema descriptions cover both parameters fully (100% coverage). The description adds no additional parameter details beyond what the schema provides, so 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 transcribes Instagram video posts by shortcode, specifying 'bounded list' and 'video posts'. However, it does not explicitly differentiate from the sibling tool 'get_instagram_post_transcript' (singular), though the plural name and array input imply batch usage.

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 guidance on when to use this tool versus alternatives like the singular transcript tool or other post retrieval tools. Lacks context on ideal scenarios 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 declare readOnlyHint=true and destructiveHint=false. Description adds return fields and pagination details, meeting the bar with 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?

Efficiently front-loaded with a one-line summary, then logically structured into usage, parameters, and examples without redundant or irrelevant 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?

For a tool with 6 parameters and an output schema, the description covers all aspects: creator identification, sorting, pagination, return fields, and concrete examples, leaving 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?

With 100% schema coverage, baseline is 3, but the description adds significant value by explaining sort options, limit cap, cursor usage, and providing examples that clarify parameter usage.

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 explicitly states the verb 'fetch' and resource 'creator's posts', and differentiates from sibling tools through examples and usage context.

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 detailed when-to-use guidance, identification methods, sort options, limit/pagination info, and explicitly mentions alternative tools like get_profile and match_creators.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: case-insensitive matching, passing username without @, and that the tool returns both profile and creator record. 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 clear examples and separations. It is slightly verbose but every sentence adds value. Could be shortened slightly but remains effective.

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 (single profile lookup), the description covers all necessary aspects: purpose, usage, parameter handling, alternatives, and return value (though output schema exists). It is complete for an agent.

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

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

The schema already describes both parameters with constraints. The description adds marginal value by instructing to pass the username without @ and noting case-insensitivity. Schema coverage is 100%, so description's contribution is limited but useful.

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: fetch a single social profile by platform and username. It specifies what data is returned (bio, metrics, etc.) and distinguishes from sibling tools like search_creators and get_creator.

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 tells when to use this tool (exact handle on a specific platform) and when not to (user already has a creator UUID, use get_creator instead; for batch lookups, use lookup_profiles). It also provides concrete examples.

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

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

Annotations already mark it as readOnlyHint=true, but the description adds behavioral context: it's a low-cost preview tool, not for search or discovery, and provides post-preview instructions. This adds value 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?

The description is well-structured, front-loading purpose and usage, then providing explicit guidance. It is slightly lengthy but every sentence is meaningful and earns its place.

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

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

Given the tool has no parameters, has an output schema, and annotations, the description is complete. It covers purpose, usage context, exclusions, and post-use agent actions, leaving 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?

The input schema has no parameters, so no parameter explanations are needed. The description correctly does not add param info, and the baseline for 0 parameters is 4.

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

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

The description clearly states the tool's purpose: fetching a configured sample creator with social profile context for preview before account linking. It explicitly distinguishes itself from sibling tools like search_creators, match_creators, and find_lookalike_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 explicitly tells when to use (preview before linking) and when not to use (search, discovery, matching, lookalike requests). It provides clear context and alternatives (connecting an account for real data).

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 beyond that: response splits into data and not_found, no guaranteed order, and need for re-correlation. 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?

Description is concise and well-structured: purpose first, then usage guidance, examples, and response details. Every sentence adds value, 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 output schema exists, description still explains response structure (data/not_found) and order behavior. Covers purpose, usage, and response completely.

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 already defines ProfileLookupItem fields. Description does not add additional parameter-level details beyond what schema 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 'Batch-fetch up to 100 profiles by (platform, username) pairs.' It distinguishes from siblings by specifying alternatives like get_profile for single exact pairs and search_creators for fuzzy input.

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 provides when-to-use (e.g., 'list of handles', 'profile data for all of them at once') and when-not-to-use ('semantic discovery', 'partial/fuzzy input'). Includes concrete examples and names alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the return type (match score, decision, structured reasons). However, it does not mention any additional behavioral aspects like rate limits or idempotency, which are not critical given annotations.

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

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

The description is well-structured with clear sections: purpose, usage guidelines, parameter explanation, and examples. It is concise (about 150 words) with no redundant sentences.

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

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

Given the tool has 4 parameters (1 required), an output schema, and sibling tools, the description covers all necessary context: when to use, what to expect, and how to configure parameters. Examples further clarify usage 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?

Schema coverage is 100%, baseline 3. The description adds semantic meaning by explaining the role of each parameter: candidates in creator_ids/profiles, intent_query as the brief, intent_context as extra context. This goes beyond the schema's field descriptions.

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

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

The description clearly defines the tool as scoring specific creators against a campaign brief, using strong verb 'Score' and resource 'creators'. It explicitly distinguishes from sibling tools like semantic_search_creators, search_creators, and find_lookalike_creators by stating when to use each.

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 (when candidates are known) and when-not-to-use (for discovery, resolution, lookalikes) with alternative tool names. Includes concrete examples like rating creators for a vegan cookbook launch.

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

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds context: it is 'cheap, fast, backed by the creator lookup index', explains routing behavior (legacy semantic vs modern lookup), and the return types. No contradictions 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?

Well-structured with a clear opening sentence, bullet-point examples, and logical sections. Slightly verbose but every sentence serves a purpose. Front-loaded with key information.

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

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

Given 12 parameters, multiple sibling tools, and presence of an output schema, the description covers when to use, behavioral nuances, routing logic, and how to use results (e.g., with get_creator, get_profile). No significant 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 description coverage is 100%, so baseline is 3. The description adds limited parameter-specific detail beyond the schema, though it clarifies usage of query_type. Mainly reinforces schema content without deep additional 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?

The description states the primary purpose as 'Find a creator by name/handle' and distinguishes it from siblings like get_profile and semantic_search_creators with specific use cases. The verb 'find' and resource 'creator' are precise, and the preservation of legacy semantic search is clearly noted.

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 is provided on when to use this tool ('default creator lookup tool'), when not to use it (exact handles → get_profile, topical discovery → semantic_search_creators), and includes concrete examples with user queries and tool 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 (safe read) and destructiveHint=false. The description adds valuable behavioral context: the tool uses 'hybrid vector search', matches against 'creator profiles, extracted facts, and visual style', and 'can return lookalike or topical matches' with 'evidence facts'. It also notes that it 'is allowed to miss an exact username', which helps set expectations. While annotations cover safety, the description enriches understanding of how results are generated.

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 relatively long but well-structured: opens with purpose, then usage guidelines, examples, return format, and finally sibling differentiation. Each section serves a clear goal, and the examples are particularly helpful. While it could be slightly more concise, the length is justified by the complexity of the tool and the number of sibling alternatives. It earns its place.

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

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

Given the tool's complexity (9 parameters, 1 required, output schema exists, 13 sibling tools), the description covers all necessary aspects: when/why to use, when not to, how results are returned, and clear sibling distinctions. The presence of an output schema means the description doesn't need to detail return values, but it still mentions the return structure (ranked list with specific fields). The description is comprehensive for an AI agent to make an informed decision.

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 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by explaining how to use certain parameters: 'Use the flat follower, engagement-rate, and verified fields to constrain results when the user gives concrete numeric constraints.' It also reiterates not to pass exact handles in the query parameter, reinforcing the schema's hint. This contextual guidance improves parameter usage without repeating schema 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 defines the tool as a semantic discovery search for influencers using natural-language queries, with a specific verb 'semantic discovery search' and resource 'creators'. It effectively distinguishes from sibling tools like get_profile (exact handle lookup), search_creators (rough name search), and lookup_profiles (multiple known handles), ensuring the agent understands its unique role.

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

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

The description provides explicit when-to-use scenarios (e.g., 'fitness creators in NYC') and when-not-to-use cases (exact handles/usernames), with concrete examples for each. It names specific alternatives (get_profile, search_creators, lookup_profiles, find_lookalike_creators, match_creators) and gives a rationale for why semantic search is not for exact lookups, making the decision boundary crystal clear.

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