Influship MCP

Official

Overview Schema Source Related Servers Discussions Admin

get_profile

Read-only

Fetch a full social profile by platform and username: bio, follower/engagement metrics, recent activity, growth, and creator ID.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`platform`	Yes	Social platform for the username.
`username`	Yes	Platform username or handle without the @ sign.

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0May 28, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context beyond that: it specifies the return structure (profile + creator record) and notes case-insensitive matching. This adds value but does not disclose major new behavioral traits.

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

Conciseness5/5

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

The description is appropriately sized, starting with a clear purpose, then usage guidelines, examples, return info, and alternative tools. Every sentence contributes value without redundancy.

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

Completeness5/5

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

Given the tool's simplicity (2 params, output schema exists, annotations present), the description covers all needed aspects: purpose, when to use, parameter handling, return content, and sibling differentiation. It leaves no gaps.

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

Parameters4/5

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

Schema coverage is 100% with descriptions for both parameters. The description adds extra guidance: 'Pass exactly the username they typed without the @ sign' and 'case-insensitive matching is handled server-side', plus examples of parsing platform and username. This meaningfully supplements the schema.

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

Purpose5/5

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

The description clearly states 'Fetch a single social profile by (platform, username)' and details the returned fields (bio, metrics, activity, growth, creator ID). It distinguishes from siblings like search_creators, get_creator, and lookup_profiles.

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

Usage Guidelines5/5

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

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

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

Deploy Server