The Influship MCP server provides AI-native tools for influencer marketing, enabling creator discovery, profile lookup, content analysis, and campaign fit assessment.
Preview without an account: Fetch a sample creator preview to see what Influship returns before connecting an account.
Search & Discover Creators: Find creators by name, handle, niche, topic, audience, location, or engagement metrics using standard or semantic search.
Autocomplete Creator Names: Resolve partial handles or names to canonical creator IDs.
Find Lookalike Creators: Surface creators similar to one or more seed creators, with optional follower/engagement filters.
Score Creators Against a Campaign Brief: Evaluate how well specific creators fit a campaign brief, returning match scores and structured reasons.
Fetch Creator Profiles: Retrieve full records or detailed social profiles (bio, followers, engagement, growth) for individual creators or batch-fetch up to 100 profiles at once.
Analyze Creator Posts: Access a creator's posts sorted by recency or engagement metrics (likes, views, comments), with pagination.
Fetch Raw Instagram Post Data: Retrieve fresh Instagram post metadata (coauthors, tagged users, paid partnerships, music, location, etc.) individually or in batches of up to 20.
Transcribe Instagram Video Posts: Transcribe Instagram video posts by shortcode, individually or in batches of up to 10, with optional language detection.
Enables creator discovery, profile lookup, post retrieval, and Instagram post transcript analysis for influencer marketing workflows.
Provides creator search and profile resolution across TikTok for influencer marketing and prospecting.
Supports creator profile lookup and post data retrieval from YouTube for influencer marketing campaigns.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Influship MCP find beauty creators with 100k+ followers on Instagram"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI-native creator discovery for influencer marketing workflows. Influship gives ChatGPT, Claude, Cursor, Codex, VS Code, and other MCP-compatible agents typed tools for creator search, lookalikes, profile lookup, post lookup, and Instagram post transcript analysis.
Search for creators by audience, niche, location, platform, and campaign-fit criteria.
Find creator lookalikes from known winners or competitor talent lists.
Resolve creator profiles and social handles across Instagram, TikTok, and YouTube-oriented workflows.
Pull creator records, posts, and Instagram transcript data into briefs, prospecting lists, market maps, and outreach research.
Related MCP server: Instagram Complete MCP Server
Use the hosted Streamable HTTP server when your MCP client supports remote MCP:
claude mcp add influship --transport http https://mcp.influship.com/mcp --header "X-API-Key: YOUR_KEY"Use the npm package for clients that only support stdio:
INFLUSHIP_API_KEY=YOUR_KEY npx -y @influship/mcpThe package is a small stdio bridge to the hosted Influship MCP server. It keeps the data, auth, billing, and rate limits on the same production API surface as the remote server.
For local development or staging:
INFLUSHIP_API_KEY=YOUR_KEY INFLUSHIP_MCP_URL=http://localhost:8080/mcp npx -y @influship/mcp{
"mcpServers": {
"influship": {
"command": "npx",
"args": ["-y", "@influship/mcp"],
"env": {
"INFLUSHIP_API_KEY": "YOUR_KEY"
}
}
}
}search_creators
autocomplete_creators
find_lookalike_creators
match_creators
get_creator
get_profile
lookup_profiles
get_posts
Instagram post and transcript tools when enabled on the hosted MCP server
API keys: https://developers.influship.com
Hosted MCP endpoint: https://mcp.influship.com/mcp
The official MCP Registry metadata lives in server.json and advertises both
the hosted Streamable HTTP server and the npm stdio package.
pnpm install
pnpm test
pnpm build
npm publish --access publicAfter npm publish, submit server.json with the official MCP Registry publisher
and use this repository URL for directory submissions.
Autocomplete creator names, usernames, or display names from partial input.
Use this for fast lookup when the user types a partial handle or name and you need to
resolve it to canonical creator IDs (e.g., "find @cris" or "who's that fitness coach
called Jane?"). Cheap and fast — prefer over search_creators for handle-style
queries where the user already knows roughly who they want.
Use get_profile instead when the user gives an exact platform+username pair. Use
search_creators for the same fuzzy creator lookup behavior with a less typeahead-
specific name. Use semantic_search_creators only for discovery by topic, niche,
audience, geography, or content style, not for resolving a known creator.
Examples:
User: "Who is that fitness coach called Jane?" -> use this tool.
User: "Find @cris..." -> use this tool to resolve the partial handle.
User: "Pull @niickjackson on Instagram" -> use get_profile, not this tool.
Returns a short list of matching creators with their IDs, platforms, and display names.
Use the IDs returned here as input to get_creator, find_lookalike_creators, or
match_creators for downstream operations.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query (min 2 characters) | |
| limit | No | Maximum results to return | |
| scope | No | Which platforms to include in results | all_platforms |
| platform | No | Filter by platform |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate safe read operation (readOnlyHint=true, destructiveHint=false). Description adds value by stating 'Cheap and fast' and describing return format ('short list of matching creators with their IDs, platforms, and display names'). 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 core action, usage guidelines, examples, and output. Sentences are efficient and front-loaded. Some slight redundancy (e.g., examples repeat the point), but overall concise for the information provided.
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 annotations, full schema coverage, and output schema, the description covers purpose, usage, alternatives, examples, and output. It is complete for a tool with moderate 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?
Input schema has 100% coverage; every parameter has a description. Description does not add significant parameter details beyond schema, relying on schema to document parameters. 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?
Description clearly states 'Autocomplete creator names, usernames, or display names from partial input.' It distinguishes from siblings by explicitly naming alternatives (search_creators, get_profile, semantic_search_creators) and their different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('when the user types a partial handle or name'), when-not-to-use (e.g., 'Use get_profile instead when the user gives an exact platform+username pair'), and names specific alternative tools with rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find creators SIMILAR to one or more seed creators.
Use this when the user already knows a creator they like and wants more like them (e.g., "find creators like @therock", "find more creators like these three I just booked"). Seeds are blended via creator-profile + visual-style + fact embeddings to surface similar accounts.
Seeds are passed in seed_creator_ids (canonical UUIDs) and/or seed_profiles
(platform + username; resolve handles via autocomplete_creators first if needed).
Returns a ranked list of similar creators with scores. limit caps results
(default 25, max 100). Use the flat follower, engagement-rate, and verified fields
to constrain results.
Use semantic_search_creators instead when you have a topic/niche but no seed.
Use match_creators when you have specific candidates and want to score their fit
against a brief.
Examples:
User: "Find creators like @niickjackson on Instagram" -> use this tool with
seed_profiles: [{ platform: "instagram", username: "niickjackson" }].
User: "Find news creators with 1M+ followers" -> use semantic_search_creators,
not this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| cursor | No | Pagination cursor from a previous response. | |
| verified | No | When set, only return verified or unverified creators. | |
| max_followers | No | Maximum follower count. | |
| min_followers | No | Minimum follower count. | |
| seed_profiles | No | Seed creators identified by platform and username. | |
| seed_creator_ids | No | Seed creators identified by canonical Influship creator UUID. | |
| max_engagement_rate | No | Maximum engagement rate as a percentage from 0 to 100. | |
| min_engagement_rate | No | Minimum engagement rate as a percentage from 0 to 100. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, but description adds context beyond annotations: explains how seeds are blended (embeddings), returns ranked list with scores, and mentions pagination via cursor.
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 front-loaded with bold purpose, uses bullet points and examples. It is reasonably concise, with each sentence adding value. Slightly long but appropriate for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, description does not need to document return values. It covers usage context, alternatives, blending method, and pagination. Complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 is appropriate. Description adds some context for seed_profiles (resolve handles via autocomplete_creators) but does not elaborate on all parameters 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?
Description clearly states the tool finds creators similar to seed creators. It uses a specific verb and resource, and distinguishes from siblings by naming alternatives and giving 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 says when to use (user knows a creator and wants similar) and when not to use (topic/no seed -> semantic_search_creators; specific candidates -> match_creators). Provides concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full record for a single creator by ID or exact platform username.
Use this when you already have either:
a canonical creator UUID returned by search_creators,
semantic_search_creators, autocomplete_creators, or
find_lookalike_creators; or
an exact platform+username pair such as platform "instagram" and username "niickjackson".
Pass include: ['profiles'] to also receive the creator's social profile
summaries when using a creator UUID. For platform+username inputs, this tool resolves
through the profile endpoint and returns the profile record plus the underlying creator
record, so you already get the matched profile context.
Examples:
User: "Get creator 123e4567-e89b-12d3-a456-426614174000" -> call with id.
User: "Get @niickjackson on Instagram" -> call with platform "instagram" and
username "niickjackson", or use get_profile if profile metrics are the main need.
User: "Tell me about @niickjackson and include his profiles" -> use platform
"instagram" and username "niickjackson"; then use get_profile/get_posts for
platform-specific metrics and content if needed.
Use lookup_profiles for batch exact profile lookups.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Creator unique identifier | |
| include | No | Additional data to include in response | |
| platform | No | Social platform for the username. | |
| username | No | Platform username or handle without the @ sign. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and non-destructive. Description adds behavioral details: resolution through profile endpoint for platform+username, combined return, and include parameter effect. 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, but slightly longer than minimal. However, every sentence adds value and it's front-loaded with 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 output schema exists (not shown but noted), description doesn't need return details. It covers input modes, resolution, alternatives, and handling of include. 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?
Schema coverage is 100% but description adds context on parameter usage, the two input modes, and the include parameter behavior. Examples clarify real-world 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 clearly states the tool fetches the full record for a single creator by ID or exact platform+username. It distinguishes from siblings like search_creators, get_profile, and lookup_profiles 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 states when to use (have UUID or exact platform+username) and when not to use (batch lookups -> lookup_profiles; profile metrics -> get_profile). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw Instagram post-page data by shortcode.
Use this when the user needs fresh raw Instagram post metadata that is not guaranteed on regular cached post-list endpoints yet, including coauthors, tagged users, paid partnership metadata, product mentions, music attribution, location, display resources, and video versions.
| Name | Required | Description | Default |
|---|---|---|---|
| shortcode | Yes | Instagram post shortcode from a /p/, /reel/, or /tv/ URL |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and description adds behavioral context about fetching fresh data and specific data fields, complementing annotations without 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?
Two sentences, no filler, front-loaded with action and resource. Every part 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 output schema exists and annotations cover safety, description fully covers purpose, usage context, and parameter guidance.
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 parameter with description (100% coverage). The description adds context that shortcode comes from URLs like /p/, /reel/, /tv/, enhancing understanding 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 it fetches raw Instagram post-page data by shortcode and lists specific metadata types (coauthors, tagged users, etc.), distinguishing it from sibling tools like get_instagram_posts.
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 to use when fresh raw data is needed and not guaranteed on cached endpoints, providing clear usage context. Lacks explicit 'when not to use' but implies it effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw Instagram post-page data for a bounded list of shortcodes through the raw API.
Returns one item per requested shortcode with per-item success or error details.
| Name | Required | Description | Default |
|---|---|---|---|
| shortcodes | Yes | Instagram post shortcodes from /p/, /reel/, or /tv/ URLs |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. Description adds value by specifying per-item success/error details and the raw API nature, which helps the agent understand the response structure 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?
Two sentences, front-loaded with key action and resource, no redundant information. Every word contributes meaning.
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?
Adequately covers the batch nature and response structure. Could mention the bounded limit (max 20 from schema) but output schema exists so return format is not required. Overall sufficient for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context by clarifying the accepted URL patterns (/p/, /reel/, /tv/), which is not obvious from the schema alone. This enhances parameter understanding.
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 verb 'Fetch', resource 'raw Instagram post-page data', and scope 'for a bounded list of shortcodes'. Distinguishes from sibling get_instagram_post (singular) and get_posts (different scope).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies batch usage but does not explicitly compare to alternatives like get_instagram_post or state when to use this tool vs others. No exclusion criteria or usage conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe an Instagram video post by shortcode through the raw API.
For now this retranscribes every request. Cached transcript reads are planned as a follow-up, and public pricing is intended to stay the same for live and cached transcript delivery.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional transcript language code. Omit to auto-detect. | |
| shortcode | Yes | Instagram post shortcode from a /p/, /reel/, or /tv/ URL |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but description adds that it retranscribes every request (no caching yet), and mentions caching plans. Adds useful behavioral 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?
Concise, with clear first sentence. Second paragraph about caching plans is less essential but not overly verbose.
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 nature of the tool and presence of output schema, the description is fairly complete. Could mention error handling or output format, but covers key behavioral aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with good descriptions for shortcode and language. The tool description does not add much parameter-specific information, 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 it transcribes an Instagram video post by shortcode, distinguishing it from siblings like get_instagram_post (post data) and get_instagram_post_transcripts (possibly multiple 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 guidance on when to use this vs alternatives. Mentions retranscription and caching, giving some context but not clear when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe a bounded list of Instagram video posts by shortcode through the raw API.
For now this retranscribes every request. Successful items include the raw post data used for transcription.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional transcript language code. Omit to auto-detect. | |
| shortcodes | Yes | Instagram video post shortcodes from /p/, /reel/, or /tv/ URLs |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
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 'retranscribes every request' (no caching) and that successful items include raw post data. This adds useful behavioral context beyond annotations without 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?
Two sentences with no waste. First sentence states core function, second sentence adds a behavioral caveat. Perfectly front-loaded and efficient.
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 only 2 parameters, 100% schema coverage, and an output schema, the description covers the key aspects: what it does, the bounded nature, retranscribe behavior, and output content. 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?
Input schema covers both parameters with descriptions (shortcodes array, language optional). Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond 'bounded list' which aligns with the min/max constraints.
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 verb 'transcribe', the resource 'Instagram video posts by shortcode', and the scope 'bounded list'. It distinguishes from siblings like 'get_instagram_post_transcript' (singular) and 'get_instagram_post' (different 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?
No explicit when-to-use or when-not-to-use guidance. The note 'For now this retranscribes every request' hints at current behavior but doesn't clarify when to prefer this tool over the singular variant or other siblings. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a creator's posts, sorted and paginated.
Use this when the user asks to see what a creator has posted (e.g., "show me Jane's
last 20 posts", "what are this creator's top-engagement reels?", "pull recent posts
from creator-id ABC"). Identify the creator by either creator_id (UUID) OR
(platform + username).
sort defaults to "recent" (newest first); use "top_engagement" for the highest-
engagement posts, or one of "most_likes" / "most_views" / "most_comments" for a
specific metric. limit defaults to 12 and is capped at 50. Pass cursor from a
previous response's next_cursor to paginate.
Returns post records (caption, media URL, like/comment/view counts, timestamps),
plus has_more and next_cursor for pagination.
Examples:
User: "Show @niickjackson's recent Instagram posts" -> use this tool with platform "instagram" and username "niickjackson".
User: "Is @niickjackson a fit for Pixel?" -> use this after get_profile when
the fit analysis needs recent content evidence, then call match_creators.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order | recent |
| limit | No | Maximum posts to return | |
| cursor | No | Pagination cursor for next page | |
| platform | No | Platform (required with username) | |
| username | No | Username (required with platform) | |
| creator_id | No | Creator ID (use this OR platform+username) |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known to be safe. The description adds valuable behavioral details: defaults for sort and limit, cap at 50, pagination via cursor, and the return fields (caption, media URL, counts, timestamps plus has_more/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: starts with a one-sentence summary, then details usage, parameter behavior, return data, and ends with two concrete examples. Each sentence adds value, and it is not overly long. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, sorting, pagination, output schema), the description covers all essential aspects: how to identify the creator, sorting options, pagination mechanics, return fields, and even example usage scenarios. The presence of an output schema reduces the need to detail return values, but the description still mentions key 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 coverage is 100%, but the description adds meaning beyond the schema: it explains the mutual exclusivity of creator_id vs platform+username, states defaults and max for limit, describes the sort options with brief explanations, and clarifies the cursor’s source. This enhances the agent's understanding.
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 'Fetch a creator's posts, sorted and paginated' and provides concrete examples of user queries that trigger this tool. It distinguishes from sibling tools by clarifying the scope (a specific creator, with sorting/pagination) and mentions an alternative path (using after get_profile), making the purpose clear and distinct.
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 includes explicit when-to-use scenarios like 'when the user asks to see what a creator has posted' and gives example queries. It explains the two identification methods (creator_id or platform+username) and mentions a workflow after get_profile. While it does not explicitly list when not to use, the examples and context provide strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single social profile by (platform, username).
Always use this first when the user gives an exact handle on a specific platform
(for example "@niickjackson on Instagram") and you need the full profile: bio,
follower/engagement metrics, recent activity, growth, and the canonical creator ID.
Pass exactly the username they typed without the @ sign — case-insensitive matching is
handled server-side. Do not use search_creators for an exact platform+username
lookup.
Examples:
User: "Pull @niickjackson on Instagram" -> use this tool with platform "instagram" and username "niickjackson".
User: "Tell me about instagram.com/niickjackson" -> parse the platform and username, then use this tool.
User: "Is @niickjackson a fit for Pixel?" -> use this tool first, then call
get_posts and/or match_creators if the task needs content or fit analysis.
Returns the profile record plus the underlying creator record. If you already have a
creator UUID, use get_creator instead. For batch lookups by handle, use
lookup_profiles.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Social platform for the username. | |
| username | Yes | Platform username or handle without the @ sign. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
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 returns both profile and creator record, that case-insensitivity is handled server-side, and implicitly confirms read-only behavior. 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 bolded purpose, bullet-point examples, and clear usage notes. Slightly verbose but front-loaded with the critical information, every sentence is relevant.
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, the description effectively covers context: when to use, alternatives, parameter format, and error-prevention tips. No gaps for a simple 2-param 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 already covers 100% of parameters with descriptions. The description adds value by advising to omit the '@' sign and providing examples of how to parse platform and username from user input.
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 'Fetch a single social profile by (platform, username)' and lists the returned data (bio, metrics, growth, etc.), clearly distinguishing it from siblings 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?
Provides explicit guidance: use this tool for exact handle+platform, avoid search_creators for exact lookups, and consider get_creator or lookup_profiles as alternatives. Includes concrete examples for different user inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when a ChatGPT user wants to see what Influship can return before linking an account.
Fetches one configured sample creator with social profile context. This is a low-cost preview tool and should not be used for search, discovery, matching, or lookalike requests. After showing the preview, tell the user that real live creator data, search, lookalikes, matching, posts, and transcripts require connecting an Influship account. Explain that they can authorize either an Influship SaaS subscription, where usage counts against monthly bundled credits, or an Influship API account, where usage is billed pay-as-you-go under API billing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only; description adds that it's a 'low-cost preview tool' and only returns one sample creator, providing behavioral 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?
Sentences are purposeful and front-loaded, though slightly verbose; each sentence contributes clear guidance.
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?
Fully covers purpose, usage limitations, behavioral expectations, and even includes a user-facing script; no gaps given annotations and output 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?
No parameters exist; baseline score for 0-param tools is 4, and description adds no param info, which 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?
Description clearly states it fetches a sample creator for preview before account linking, and explicitly distinguishes from siblings by forbidding search, discovery, matching, or lookalike uses.
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) and when not (for search, discovery, etc.), and provides post-call instructions to explain account options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| profiles | Yes | Profiles to lookup |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint=true and destructiveHint=false indicate safe read. The description adds beyond annotations by stating response splits into data and not_found, and that profiles are returned in no particular order, requiring re-correlation for order preservation. 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?
The description is concise, front-loaded with purpose, then usage guidelines, examples, and behavioral notes. Every sentence adds value, no fluff. Appropriate length for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (one complex array parameter), the description covers purpose, usage, response structure (data/not_found), and ordering behavior. It references output schema implicitly. No gaps for agent decision or 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 descriptions for platform (enum) and username (string constraints). The description adds context about batch size limit (up to 100) but otherwise rephrases schema info. With high coverage, 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,' specifying the action, resource, and key parameters. It distinguishes from siblings like get_profile (single) and semantic_search_creators (fuzzy/topical) by emphasizing exact batch 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 given: 'Use this when the user has a list of handles...' and 'One round-trip beats 30 calls to get_profile.' When-not-to-use scenarios and alternatives are named: get_profile for single exact, search_creators/autocomplete_creators for fuzzy, semantic_search_creators for topical. Examples further clarify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score how well specific creators fit a campaign brief or search intent.
Use this when the user already has candidate creators in mind and wants to evaluate fit (e.g., "rate these 5 creators for a vegan cookbook launch", "which of these is the best match for my crypto audience?"). For each creator the API returns a match score (0-1), a good/neutral/avoid decision, and structured reasons.
Pass candidates in creator_ids (canonical UUIDs) and/or profiles
(platform + username). intent_query is the brief the LLM reasons against;
intent_context is optional extra context (target audience, brand values,
prior collabs).
Use semantic_search_creators when you don't have candidates yet and need topical
or niche discovery. Use search_creators first when you only need to resolve rough
creator names/handles into candidates.
Use find_lookalike_creators when you want creators similar to known good fits.
Examples:
User: "Is @niickjackson a fit for Pixel?" -> use this tool after resolving the
exact Instagram profile with get_profile; call get_posts first if recent
content context is needed.
User: "Rate these five creators for a vegan cookbook launch" -> use this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| profiles | No | Candidate creators identified by platform and username. | |
| creator_ids | No | Candidate creators identified by canonical Influship creator UUID. | |
| intent_query | Yes | Campaign brief or matching intent. | |
| intent_context | No | Optional extra campaign context, audience, brand values, or prior collabs. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
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 about return values (match score, decision, structured reasons) and parameter usage. It does not contradict annotations and provides useful behavioral details beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, usage guidelines, parameter details, sibling tool comparisons, and examples. Every sentence is necessary and front-loaded with the core purpose. 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?
Given the tool's complexity (4 parameters, output schema exists, annotations present, siblings distinguished), the description covers what it does, how to call it, what it returns, when to use vs alternatives, and even includes a workflow example. It is fully complete for an AI agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how to pass candidates (creator_ids and/or profiles), clarifying intent_query as 'the brief the LLM reasons against', and providing examples. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb and resource ('Score how well specific creators fit a campaign brief or search intent'), and explicitly distinguishes itself from siblings like semantic_search_creators, search_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 states when to use this tool (when candidates are already in mind) and when not to use it (e.g., use semantic_search_creators for discovery, search_creators for resolving handles, find_lookalike_creators for similar creators). It also includes examples and a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a creator by name/handle, while preserving legacy semantic creator search.
Use this as the default creator lookup tool when the user gives a creator-ish string but not a canonical creator UUID: a handle, partial handle, display name, creator name, or profile-ish text. This is cheap, fast, and backed by the creator lookup index.
If the user gives an exact handle on a specific platform (for example "@niickjackson on
Instagram"), prefer get_profile first because it returns the full platform profile.
If you need to resolve a rough creator name or partial handle first, use this tool with
query_type: "creator_lookup".
For backward compatibility, this tool still accepts the old semantic-search fields
(platforms, follower/engagement filters, creator_kinds) and routes legacy calls
to the semantic endpoint unless the query clearly contains a handle/profile URL. For
new topical/niche discovery calls such as "fitness creators in NYC" or "vegan recipe
creators with high engagement", prefer semantic_search_creators because its name is
explicit and less likely to be confused with exact creator lookup.
Examples:
User: "Find @cris" -> use this tool with query "cris" and query_type "creator_lookup".
User: "Who is that fitness coach called Jane?" -> use this tool with query "Jane" and query_type "creator_lookup".
User: "Pull @niickjackson on Instagram" -> use get_profile with platform
"instagram" and username "niickjackson".
User: "Find news creators with 1M+ followers" -> use semantic_search_creators,
not this tool.
Returns either autocomplete-style creator lookup results or legacy semantic results,
depending on routing. Use returned creator IDs with get_creator,
find_lookalike_creators, or match_creators; use returned platform usernames
with get_profile or get_posts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| query | Yes | Natural-language semantic discovery query by topic, niche, audience, geography, or content style. Do not pass exact handles or usernames here; use get_profile, lookup_profiles, or autocomplete_creators instead. | |
| scope | No | Which linked platforms to include in each lookup result. | all_platforms |
| platform | No | Optional platform to narrow username matching. | |
| verified | No | When set, only return verified or unverified creators. | |
| platforms | No | Platforms to search. Omit for all. | |
| query_type | No | Use creator_lookup for specific names/handles and semantic_discovery for topical/niche discovery. Auto routes exact handles and profile URLs to lookup, and keeps legacy semantic-search behavior otherwise. | auto |
| creator_kinds | No | Optional creator kind filter. Omit for no creator-kind filter. | |
| max_followers | No | Maximum follower count. | |
| min_followers | No | Minimum follower count. | |
| max_engagement_rate | No | Maximum engagement rate as a percentage from 0 to 100. | |
| min_engagement_rate | No | Minimum engagement rate as a percentage from 0 to 100. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds that it is 'cheap, fast' and explains legacy routing behavior without 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?
Well-structured with front-loaded purpose, clear examples, and logical flow. Slightly long but justified given complexity. No wasted 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?
Fully covers usage, alternatives, legacy behavior, and parameter guidance. With 12 parameters, 100% schema coverage, and output schema present, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining how to use query_type (creator_lookup vs semantic_discovery) and providing usage context for backward-compatible 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?
Clearly states 'Find a creator by name/handle' and 'preserving legacy semantic creator search.' Distinguishes from siblings like get_profile and semantic_search_creators by specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use vs. when-not-to-use with concrete examples, including preferred alternatives (get_profile for exact handles, semantic_search_creators for niche discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic discovery search for influencers/content creators using natural-language queries.
Use this only when the user asks to discover creators by topic, audience, geography, niche, content style, or campaign criteria (e.g., "fitness creators in NYC", "vegan recipe creators with high engagement", "tech reviewers who cover phones"). The query is matched against creator profiles, extracted facts, and visual style via hybrid vector search.
Do not use this for exact handles, usernames, or known creator names. If the user gives
a specific platform and handle (for example "@niickjackson on Instagram"), use
get_profile first. For rough name/handle lookup, use search_creators. For
multiple known handles, use lookup_profiles. Semantic search can return lookalike
or topical matches and is allowed to miss an exact username.
Examples:
User: "Find news creators with 1M+ followers" -> use this tool.
User: "Find creators in LA who make cinematic travel videos" -> use this tool.
User: "Pull @niickjackson on Instagram" -> use get_profile, not this tool.
User: "Is @niickjackson a fit for Pixel?" -> use get_profile first, optionally
get_posts, then match_creators.
Returns a ranked list of creators (id, platform, username, follower count, engagement rate, top categories, evidence facts). Use the flat follower, engagement-rate, and verified fields to constrain results when the user gives concrete numeric constraints.
Use find_lookalike_creators instead when you want creators SIMILAR to known ones.
Use match_creators when you want to SCORE specific creators against a brief.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. | |
| query | Yes | Natural-language semantic discovery query by topic, niche, audience, geography, or content style. Do not pass exact handles or usernames here; use get_profile, lookup_profiles, or autocomplete_creators instead. | |
| verified | No | When set, only return verified or unverified creators. | |
| platforms | No | Platforms to search. Omit for all. | |
| creator_kinds | No | Optional creator kind filter. Omit for no creator-kind filter. | |
| max_followers | No | Maximum follower count. | |
| min_followers | No | Minimum follower count. | |
| max_engagement_rate | No | Maximum engagement rate as a percentage from 0 to 100. | |
| min_engagement_rate | No | Minimum engagement rate as a percentage from 0 to 100. |
| Name | Required | Description |
|---|---|---|
| ok | No | |
| data | No | |
| count | No | |
| results | No | |
| has_more | No | |
| not_found | No | |
| next_cursor | No | |
| suggested_followups | No |
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 uses hybrid vector search and returns a ranked list with specific fields, which is consistent and enhances transparency.
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 with sections and examples. It is front-loaded with the purpose and every sentence adds unique value, though slight reduction could be possible.
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 9 parameters fully covered by schema, annotations present, and output schema existing, the description still adds rich behavioral context, usage guidance, and examples, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the query parameter should not contain exact handles and explains how to use follower/engagement/verified params for constraints.
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 performs 'semantic discovery search for influencers/content creators using natural-language queries,' which is specific and distinguishes it from 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 (e.g., topic, audience, geography) and when not to use (exact handles), provides alternatives like get_profile, search_creators, lookup_profiles, and includes concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0autocomplete_creatorsfind_lookalike_creatorsget_creatorget_instagram_postget_instagram_post_transcriptget_instagram_post_transcriptsget_instagram_postsget_postsget_profileget_sample_creatorlookup_profilesmatch_creatorssearch_creatorssemantic_search_creatorsTools are well-disambiguated with explicit usage guidance in each description, contrasting with others. However, some overlap between search_creators and semantic_search_creators remains due to backward compatibility.
Tool names follow a consistent verb_noun pattern (e.g., autocomplete_creators, get_creator). Instagram-specific tools use a predictable get_platform_type pattern, with minor variants for plurality.
14 tools is well-scoped for a creator discovery and data retrieval platform, covering search, profile lookup, posts, and matching without being excessive.
Covers most creator lifecycle operations (discover, retrieve, match, posts), but lacks cross-platform post retrieval beyond Instagram and advanced analytics tools.
Creator discovery & analytics across YouTube, Instagram, TikTok (30M+) + brand/sponsor intel.
Manage 230M+ influencers, track campaigns, and access real-time CIMS analytics via AI agents
AI influencer search on TikTok, Instagram, YouTube. Deinai MCP token required; credits per result.
Find viral outlier posts on TikTok, Instagram and YouTube, pull creator stats, and crawl on demand.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Influship/influship-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
