Influship Influencer Marketing MCP

lookup_profiles

Read-only

Batch-fetch up to 100 profiles by (platform, username) pairs.

Use this when the user has a list of handles and you need profile data for all of them at once (e.g., "give me follower counts for these 30 accounts I'm considering" or "which of @a @b @c are real accounts?"). One round-trip beats 30 calls to get_profile.

Use this for exact batch handle lookup, not semantic discovery. 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 where false-positive semantic matches are acceptable.

Examples:

User: "Compare @a, @b, and @c on Instagram" -> use this tool for the exact handle batch.
User: "Give me follower counts for these 30 accounts" -> use this tool.
User: "Find wellness creators in Austin" -> use semantic_search_creators, not this tool.

The response splits results into data (profiles found) and not_found (the (platform, username) pairs that weren't recognized). Profiles are returned in no particular order — re-correlate via the platform/username fields if you need to preserve input order.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`profiles`	Yes	Profiles to lookup

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	No
`data`	No
`count`	No
`results`	No
`has_more`	No
`not_found`	No
`next_cursor`	No
`suggested_followups`	No

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Influship Influencer Marketing MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation2/5

Several tools have overlapping boundaries: autocomplete_creators and search_creators are described as near-equivalent fuzzy lookups, get_creator and get_profile both resolve exact platform+username input, and the Instagram/TikTok post helpers overlap with generic get_posts. The descriptions work hard to disambiguate, but an agent would frequently need to choose between two or three equally plausible tools.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern, such as get_youtube_video, search_creators, match_creators, and render_creator_profile. Minor inconsistencies exist: singular/plural variants (get_instagram_post vs get_instagram_posts), list_ vs get_ for video listing, and search_creators carrying legacy semantic behavior under a lookup-sounding name.

Tool Count2/5

Twenty-eight tools places the server in the 'too many' range, and the count is inflated by near-duplicates like autocomplete_creators/search_creators, get_creator/get_profile, and singular/batch transcript variants. Even with three social platforms and rendering helpers, the surface would be more focused around 18–22 tools.

Completeness4/5

The core influencer research workflow is well covered: handle resolution, batch lookup, semantic discovery, lookalikes, posts, transcripts, YouTube search, matching, and comparison rendering. Gaps are minor—there is no creator shortlist persistence or cross-platform comment support—but the main discovery-to-match path has no dead ends.

Resources

Need Help?