Which integrations are available for this server?

Allows programmatic control of an Instagram account, including profile management, media interaction, direct messaging, and follower management.

How do I use Instagram MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Instagram MCP Server Send a direct message to user123 saying 'Great shot!'" 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.

Instagram MCP Server

by ahmedselimmansor-ctrl

Overview Schema Related Servers Score Discussions

TypeScript

Local

Instagram MCP Server 📸

The Instagram MCP Server is a comprehensive Model Context Protocol (MCP) server that allows you to control your Instagram account programmatically and via AI agents. Built with TypeScript and the powerful instagram-private-api library, it provides a wide range of tools for profile management, interacting with media, sending direct messages, and managing followers.

🌟 Features & Available Tools

The server provides the following tools for use via MCP clients:

👤 Profile & Search

ig_get_profile: Fetch comprehensive profile data for any user by their username.
ig_search_users: Search for Instagram users using keywords.

🖼️ Feeds

ig_get_timeline: Get the recent media feed from your personal timeline.
ig_get_user_feed: Get the media feed grid for a specific user.

📸 Media Interaction

ig_publish_photo: Publish a new photo to your feed (Requires the absolute local path to the image and a text caption).
ig_like_media: Like a specific post using its Media ID.
ig_comment_media: Add a text comment to a specific post.

💬 Direct Messages

ig_get_inbox: Fetch the latest conversations and messages from your direct inbox.
ig_send_message: Send a direct message to a specific user using their User ID (PK).

👥 Relationships

ig_follow_user: Send a follow request to a user.
ig_unfollow_user: Unfollow a user.
ig_get_followers: Extract the list of followers for a specific account.
ig_get_following: Extract the list of accounts that a specific user is following.

Related MCP server: Instagram MCP Server

⚙️ Prerequisites

Node.js: Version 18 or newer.
npm or yarn for package management.
An active Instagram account (A dedicated test/bot account is highly recommended to avoid getting your primary account banned).

🚀 Installation & Setup

Access the Project Directory: Make sure you are in the root directory of the project.
Install Dependencies:
```
npm install
```
Set Up Environment Variables: Create a .env file in the root directory and add your Instagram login credentials:
```
IG_USERNAME=your_instagram_username
IG_PASSWORD=your_instagram_password
```

🏃‍♂️ Running the Server

You have multiple options to run the server depending on your environment:

1. Development Mode

Uses ts-node to run TypeScript files directly without a build step:

npm run dev

2. Production Mode

Compiles the project to JavaScript first, then runs it:

npm run build
npm start

3. Using Docker 🐳

The project includes a Dockerfile ready to build and run the container easily:

# Build the image
docker build -t instagram-mcp-server .

# Run the container with environment variables
docker run -e IG_USERNAME=your_username -e IG_PASSWORD=your_password -i instagram-mcp-server

🔌 Client Integration (MCP)

Example: Connecting to Claude Desktop

To link this server with the Claude Desktop app (or any MCP client), edit your client configuration file. (On Windows, Claude's config is usually at C:\Users\Username\AppData\Roaming\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "instagram": {
      "command": "node",
      "args": [
        "F:\\MCP_Server\\Instagram_MCP_server\\build\\index.js"
      ],
      "env": {
        "IG_USERNAME": "your_username",
        "IG_PASSWORD": "your_password"
      }
    }
  }
}

Make sure to build the project (npm run build) before referencing the build/index.js path.

⚠️ Important Warnings

Bans & Rate Limits: This project uses instagram-private-api which relies on unofficial APIs simulating the mobile app. Excessive use (e.g., rapid consecutive likes, following many accounts in a short time) will almost certainly lead to your account being restricted or permanently banned (Action Block / Shadowban).
Use With Caution: It is strongly recommended to interact gradually and implement time delays between requests if you plan to automate processes.
Two-Factor Authentication (2FA): Currently, the server supports simple login. If your account has 2FA enabled, the login process might fail. It's recommended to disable it on your test account or implement programmatic handling for 2FA challenges.

📝 License

Licensed under the ISC License.

Available Tools

13 tools

ig_comment_mediaC

Comment on a specific post using its media ID.

ParametersJSON Schema

Name	Required	Description	Default
`mediaId`	Yes
`text`	Yes

TDQS

C2.3/5.0

Behavior2/5

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

Without annotations, the description carries full responsibility for behavioral disclosure. It only states the action of commenting without revealing side effects (e.g., notification triggers, rate limits, or whether duplicate comments are allowed). The description is too brief to meet transparency needs.

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

Conciseness2/5

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

The description is a single sentence, which is concise, but it omits critical information about parameters and usage. It is under-specified rather than efficiently concise.

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

Completeness1/5

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

Given two required parameters, no output schema, and the complexity of a write operation on a social platform, the description is grossly incomplete. It does not mention authentication, error handling, or any post-conditions.

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

Parameters1/5

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

Schema description coverage is 0%, so the description must explain parameters. It mentions 'media ID' implicitly but does not clarify the 'text' parameter's purpose (e.g., that it holds the comment content). The description fails to add meaning beyond the input schema.

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

Purpose4/5

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

The description clearly states the action (comment) and the target (a specific post via media ID). It distinctively positions this tool among siblings like 'ig_like_media' and 'ig_publish_photo'. However, it could be more precise by explicitly naming the 'text' parameter as the comment content.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., must be logged in), constraints (e.g., cannot comment on own post), or cases where commenting might fail.

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

ig_follow_userC

Follow a user using their userId (pk).

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes

TDQS

C2.9/5.0

Behavior1/5

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

No annotations exist, and the description omits behavioral details such as idempotency, rate limits, or what happens if already following.

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?

Extremely concise single sentence with no wasted words.

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

Completeness2/5

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

Lacks output schema details, success/failure info, and any behavioral context beyond the bare action.

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

Parameters2/5

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

Only clarifies that userId is the primary key, but doesn't add meaning beyond the schema (string type) and has 0% schema description coverage.

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?

Clearly states the action 'Follow a user' and specifies the required parameter 'userId (pk)', distinguishing well from sibling tools like 'ig_unfollow_user'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions provided.

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

ig_get_followersB

Get a list of followers for a user using their userId (pk).

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden to disclose behavioral traits. It does not mention pagination, rate limits, authentication needs, or that it is a read-only operation. The mention of 'pk' is minimal context.

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

Conciseness4/5

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

The description is a single short sentence with no fluff. However, it lacks structure such as front-loading key information or breaking down details for readability.

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

Completeness2/5

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

Given low schema coverage, no output schema, and no annotations, the description is incomplete. It does not mention if the result is paginated or returns a count, nor any constraints or usage notes.

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?

Despite 0% schema description coverage, the description adds meaning by clarifying 'userId (pk)' as a primary key. However, it does not explain format, length, or any constraints beyond the schema's type string.

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 the verb 'Get a list', the resource 'followers', and the required identifier 'userId (pk)'. This distinguishes it from siblings like ig_get_following (getting following list).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention limitations, prerequisites, or any context for when to prefer this over other tools.

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

ig_get_followingC

Get a list of following users for a user using their userId (pk).

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It implies a read operation but lacks details on authentication, rate limits, response format, or pagination.

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

Conciseness3/5

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

Single sentence, no waste. However, it is too brief to provide necessary context, sacrificing completeness for brevity.

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

Completeness2/5

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

With one parameter, no output schema, and sibling tools, the description should explain return value structure (e.g., list of user objects) or pagination. It does not.

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

Parameters2/5

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

Schema description coverage is 0%. The description mentions 'userId (pk)' but adds little meaning beyond the schema—no format, constraints, or example.

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

Purpose4/5

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

The description clearly states it gets a list of following users using a userId, with specific verb and resource. However, it does not explicitly differentiate from the sibling tool ig_get_followers, which is analogous but for followers.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like ig_get_followers. No exclusions or context provided.

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

ig_get_inboxB

Get recent direct messaging threads from the inbox.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only states the basic read action. It omits important traits like pagination behavior, authentication requirements, rate limits, or whether it returns only unread threads.

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

Conciseness4/5

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

The description is a single, clear sentence with no wasted words. It is front-loaded but could benefit from slightly more detail without sacrificing conciseness.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is minimal. It does not address data freshness, filtering capabilities, or how results are ordered.

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?

The input schema has no parameters (100% coverage), so the baseline is 3. The description adds no semantics beyond what the schema already indicates.

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 the action ('Get') and the specific resource ('recent direct messaging threads from the inbox'), which is distinct from sibling tools like ig_get_followers or ig_get_timeline.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. For example, it doesn't mention that ig_send_message is for sending messages or that other get tools exist for different data.

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

ig_get_profileB

Get profile information for a specific Instagram username.

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description bears full burden. It only implies a read operation ('Get') but does not disclose authentication needs, rate limits, or what specific fields are returned. The lack of output schema exacerbates the gap.

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?

A single front-loaded sentence with no waste. It efficiently communicates the core purpose.

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

Completeness3/5

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

For a simple read tool with one parameter, the description is adequate but lacks details about the return value. Given no output schema, a brief mention of what 'profile information' includes would improve completeness.

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

Parameters2/5

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

There is 1 parameter with 0% schema description coverage. The description adds no extra meaning beyond the schema, e.g., clarifying expected username format (without @). The parameter is self-explanatory but could be more explicit.

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 the verb 'Get' and the resource 'profile information for a specific Instagram username', distinguishing it from sibling tools like ig_get_followers or ig_get_user_feed.

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

Usage Guidelines3/5

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, but the purpose is implied and distinct from siblings. Lacks when-not or exclusion criteria.

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

ig_get_timelineB

Get the authenticated user's timeline feed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits but does not mention authentication requirements, rate limits, or any side effects. It implies a read operation but offers no safety or 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.

Conciseness4/5

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

Description is a single concise sentence with no unnecessary words. However, it may be under-specified given the lack of output details, but it earns its place for a simple tool.

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

Completeness2/5

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

Despite no parameters, the description fails to clarify what the timeline feed contains or its return value (no output schema). An agent cannot predict the tool's output from this description alone.

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 has zero parameters and 100% coverage (vacuously). Description adds no extra meaning beyond the schema, which is empty. Baseline 3 applies per guidelines for high schema coverage.

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 the tool retrieves the authenticated user's timeline feed, using a specific verb and distinct resource. It distinguishes from siblings like ig_get_user_feed (specific user's feed) and ig_get_inbox (messages).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like ig_get_user_feed or ig_get_inbox. The description does not specify context or exclusions.

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

ig_get_user_feedB

Get the media feed of a specific user by username.

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It fails to disclose any behavioral traits like read-only nature, authentication requirements, rate limits, or pagination behavior.

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

Conciseness4/5

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

The description is a single concise sentence that front-loads the key action and resource. It could add more detail without sacrificing conciseness.

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

Completeness3/5

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

Given the tool's simplicity (one param, no output schema), the description is minimally adequate but lacks context about output format, limits, and when to use among siblings with many alternatives.

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?

The description adds meaning by saying 'by username', clarifying the parameter's purpose. However, with 0% schema description coverage, it does not elaborate on format or constraints beyond what is obvious.

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 the verb 'Get', the resource 'media feed', and the scope 'by username'. It distinguishes from sibling tools like ig_get_timeline and ig_get_profile.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as ig_get_timeline (for own feed) or ig_get_following (for list of followed users). The description provides no usage context.

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

ig_like_mediaB

Like a specific post using its media ID.

ParametersJSON Schema

Name	Required	Description	Default
`mediaId`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must carry the burden of behavioral disclosure. It fails to mention authentication requirements, rate limits, idempotency (e.g., effect of liking an already-liked post), or error conditions.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no wasted words. However, it is overly brief and could include more detail without harming conciseness.

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

Completeness3/5

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

For a simple tool with one parameter and no output schema, the description is minimally adequate. Yet, given no annotations, it lacks important context like prerequisites, side effects, and common usage patterns.

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

Parameters2/5

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

Schema description coverage is 0%, and the description adds no extra meaning beyond the parameter name 'mediaId'. It merely restates 'using its media ID' without clarifying format, constraints, or examples.

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 tool name and description clearly state the action (like) and resource (a specific post via media ID). It is easily distinguishable from siblings like ig_comment_media (comment) and ig_follow_user (follow).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It neither specifies when to like a post nor mentions any conditions or exclusions.

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

ig_publish_photoB

Upload a photo to the feed. Requires an absolute image path.

ParametersJSON Schema

Name	Required	Description	Default
`imagePath`	Yes	Absolute path to the image file
`caption`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions the requirement for an absolute path but does not explain any side effects, authentication needs, or rate limits.

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

Conciseness4/5

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

The description is a single, concise sentence with a clear action verb. It is front-loaded and efficient, though slightly under-informative.

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

Completeness2/5

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

Given no annotations or output schema, the description needs to be more complete. It lacks details about the caption parameter, error handling, and the overall process of publishing.

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?

The input schema has 50% description coverage (imagePath described, caption missing). The description reinforces the imagePath requirement but adds no new meaning for the caption parameter. It partially compensates for the missing schema description.

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 that the tool uploads a photo to the feed and requires an absolute image path. It distinguishes itself from sibling tools like 'ig_comment_media' or 'ig_follow_user' which perform different actions.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or restrictions. It only states a requirement without context.

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

ig_search_usersC

Search for Instagram users by query.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations; description only says 'search by query' without disclosing return format, pagination, rate limits, or other 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.

Conciseness3/5

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

Single sentence is concise but lacks necessary detail, making it under-specified.

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

Completeness2/5

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

For a simple tool with one parameter and no output schema, the description fails to cover basic usage context, output expectations, or edge cases.

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

Parameters2/5

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

Schema has 0% description coverage; description adds no meaning to the 'query' parameter beyond its name.

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

Purpose4/5

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

Description clearly states the verb 'Search' and resource 'Instagram users', but does not distinguish from sibling tools like ig_get_followers or ig_get_profile.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives, no context, no exclusions provided.

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

ig_send_messageC

Send a direct message to a user. Pass userId (pk).

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes
`text`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states the basic action without details on safety (e.g., is the message sent instantly? any rate limits?). The agent gets no insight into potential side effects or constraints beyond the action itself.

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

Conciseness4/5

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

The description is extremely concise at one sentence, which is efficient. However, it sacrifices useful detail for brevity, earning a high but not perfect score.

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

Completeness2/5

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

Given the tool has two required parameters and no output schema, the description should at least explain both parameters and the expected outcome. It fails to describe the 'text' parameter and provides no return value information, leaving the agent guessing.

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

Parameters2/5

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

Schema coverage is 0%, so the description must compensate. It adds a hint that userId is a 'pk' (primary key) but provides no meaning for the 'text' parameter (e.g., length limits, formatting). This is insufficient for an agent to correctly invoke the tool.

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 the action ('Send a direct message') and the target ('to a user'), making the purpose unambiguous. It differentiates from sibling tools like ig_comment_media or ig_follow_user, which have distinct purposes.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description does not mention that the user must be followed or other restrictions, leaving the agent without contextual decision support.

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

ig_unfollow_userB

Unfollow a user using their userId (pk).

ParametersJSON Schema

Name	Required	Description	Default
`userId`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided; the description merely states the action without disclosing side effects, error states, or behavioral constraints.

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

Conciseness4/5

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

Single sentence, no fluff, appropriately sized for the simple action.

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

Completeness3/5

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

For a simple one-parameter tool with no output schema, the description provides minimal but adequate context, though it lacks behavioral and usage details.

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?

The description adds meaning by specifying 'userId (pk)', but does not elaborate on format, validation, or how to obtain the ID, partially compensating for 0% schema coverage.

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 the action 'Unfollow a user' and identifies the required parameter 'userId (pk)', which distinguishes it from sibling tools like ig_follow_user.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

13 tool updatesv1.0.0May 16, 2026
- First observedig_comment_media
- First observedig_follow_user
- First observedig_get_followers
- First observedig_get_following
- First observedig_get_inbox
- First observedig_get_profile
- First observedig_get_timeline
- First observedig_get_user_feed
- First observedig_like_media
- First observedig_publish_photo
- First observedig_search_users
- First observedig_send_message
- First observedig_unfollow_user

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct action (comment, follow, get data, like, publish, message, etc.) with clear boundaries. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow a consistent ig_verb_noun pattern (e.g., ig_comment_media, ig_get_profile), making the tool set predictable and easy to navigate.

Tool Count4/5

13 tools is a reasonable number for an Instagram server, covering core operations without being excessive. Slightly more could be added for stories or reels, but the current set is well-scoped.

Completeness4/5

The tool set covers essential Instagram interactions: profile viewing, following/unfollowing, liking, commenting, posting photos, and direct messaging. Missing some features like stories or saved posts, but core workflows are complete.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Instagram B
io.github.mcp-dir
Instagram for AI agents: publish, read comments and DMs, insights, and engage from your account.
Social Media
3318
Instagram Profile MCP ServerOAuth
io.github.afanasenkoa
Instagram profiles for AI agents — followers, similar accounts, keyword and location search.
Social Media Search
1
cloziqOAuth
com.cloziq
Create your offers and launch AI Instagram DM sales agents from any MCP client, over OAuth.
Social Media Autonomous Agents AI & Machine Learning
1
ChirpieOAuth
io.github.Firefloco
Post, schedule, and track social posts on X, Bluesky, LinkedIn, Instagram and more from AI agents.
Social Media App Automation
1

Related MCP Servers

Instagram MCP Server
Social Media Communication Content Management Systems
osborn1997
F
license
B
quality
Not graded
maintenance
Enables AI assistants to interact with Instagram and Facebook accounts through their APIs, supporting messaging, post management, commenting, and content creation.
Updated 9 months ago (2025-12-13 07:03 UTC)
14
-
Instagram MCP Server
Social Media App Automation Marketing
arjun1194
F
license
Not graded
quality
C
maintenance
Enables LLMs to interact with Instagram through a comprehensive toolkit for account management, content creation, messaging, social graph analysis, and content discovery.
Updated 8 months ago (2025-12-28 13:48 UTC)
10
-
Instagram MCP Server
Social Media Marketing App Automation
WebNaresh
A
license
Not graded
quality
D
maintenance
Enables AI applications to interact with Instagram Business accounts through the Graph API, supporting profile management, media publishing, insights retrieval, and direct messaging capabilities.
Updated 6 months ago (2026-03-09 09:40 UTC)
MIT
Instagram Complete MCP Server
Social Media Marketing App Automation
josephtandle
F
license
Not graded
quality
D
maintenance
Enables AI assistants to manage Instagram Business accounts by automating content publishing, scheduling posts, and analyzing performance metrics. Supports posts, stories, reels, and carousels with detailed audience insights and hashtag discovery.
Updated 5 months ago (2026-04-03 05:46 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ahmedselimmansor-ctrl/Instagram_MCP_server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server