Skip to main content
Glama
HasData

Instagram MCP Server

Instagram MCP Server

A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Instagram tools. Look up a public profile by handle, and walk its public post feed, as structured JSON.

It reads public data about accounts. It does not act as an account. There is nothing to connect and no account of yours involved anywhere in the flow.

https://mcp.hasdata.com/api/mcp?apis=instagram

Glama score tool contract MCP Tools npm PyPI License

Contents

Related MCP server: instagram-mcp

What you need

An MCP client that speaks streamable HTTP with custom headers. A HasData API key from the dashboard, free to create with no card, and the trial covers 100 calls. Nothing else. This is a remote server, so the simplest path is a URL and a header, with no container to run. A stdio-only client can use the @hasdata/instagram-mcp (npm) or hasdata-instagram-mcp (PyPI) launcher instead.

Quick start

URL

https://mcp.hasdata.com/api/mcp?apis=instagram

Transport

HTTP, streamable

Auth header

x-api-key: HASDATA_API_KEY

The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.

Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.

claude mcp add --transport http instagram "https://mcp.hasdata.com/api/mcp?apis=instagram" \
  --header "x-api-key: HASDATA_API_KEY"

Claude Desktop loads only local (stdio) servers from its config file, so it reaches a remote server through a stdio launcher. The @hasdata/instagram-mcp package is that launcher, and it reads the key from the environment.

claude_desktop_config.json:

{
  "mcpServers": {
    "instagram": {
      "command": "npx",
      "args": ["-y", "@hasdata/instagram-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

Python instead of Node? Swap the launcher for the PyPI package, which uvx runs without a manual install:

{
  "mcpServers": {
    "instagram": {
      "command": "uvx",
      "args": ["hasdata-instagram-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

A client with OAuth support can instead add the URL as a custom connector and skip the launcher.

.cursor/mcp.json:

{
  "mcpServers": {
    "instagram": {
      "url": "https://mcp.hasdata.com/api/mcp?apis=instagram",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "instagram": {
      "serverUrl": "https://mcp.hasdata.com/api/mcp?apis=instagram",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}
{
  "mcpServers": {
    "instagram": {
      "url": "https://mcp.hasdata.com/api/mcp?apis=instagram",
      "type": "streamableHttp",
      "headers": { "x-api-key": "HASDATA_API_KEY" },
      "disabled": false
    }
  }
}

.vscode/mcp.json:

{
  "servers": {
    "instagram": {
      "type": "http",
      "url": "https://mcp.hasdata.com/api/mcp?apis=instagram",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

~/.gemini/settings.json:

{
  "mcpServers": {
    "instagram": {
      "httpUrl": "https://mcp.hasdata.com/api/mcp?apis=instagram",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

Example prompts

Each of these is one tool call unless the count says otherwise.

Pull the profile for @nasa and tell me the follower count, the category and every link in the bio.

One call, 10 credits. For a public account the profile response already carries the twelve most recent posts, so a follow-up about recent activity needs no second call.

Compare @nasa, @natgeo and @bbcearth on followers, posts published and whether each is a business account.

Three calls, 30 credits. One per handle.

Walk the last fifty posts from @nasa and list every hashtag with how often it appears.

Five calls, 50 credits. Twelve posts arrive per call, and fifty takes five pages.

For the last twelve posts on @natgeo, give me likes, comments and the accounts mentioned in each caption.

One call, 10 credits. Engagement counts and mentions come parsed in the post objects.

Two things make these work. Hashtags and mentions arrive as arrays parsed out of the caption, and an agent counts them instead of running a regex over prose. And a profile lookup returns the recent feed in the same response. That is why so many research questions land in a single call.

Tools

Two tools, both read-only, both keyed on a public account handle. Samples below are trimmed from real calls, and the numbers in them move as accounts post. Read them as shapes. Each tool name links to its endpoint reference.

The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.

Get an Instagram profile

hasdata_instagram_profile_getInstagramProfile

One public profile by handle.

Parameter

Type

Required

Notes

handle

string

yes

Username without the @, as it appears in the profile URL

Returns id, username, fullName, biography, businessCategory, verified, isBusinessAccount and isProfessionalAccount, the counters followersCount, followsCount, postsCount, highlightsCount and igtvVideoCount, both profilePicUrl and profilePicUrlHD, and the arrays latestPosts, latestIgtvVideos and relatedProfiles.

The core identity fields and the follower and following counts come back for every public account. The fields beyond that depend on what the account itself exposes, so read the optional ones with a default.

Links live in two fields that are not the same thing. bioLinks is the array of every link in the bio. externalUrls is a single string despite the plural name, and it holds the primary link, sometimes with a trailing slash the array version lacks. Read bioLinks when you want them all.

latestPosts and latestIgtvVideos do not carry identical fields. Video entries add taggedUsers, and the post objects here omit the productType that the posts tool includes. Code that walks both arrays through one parser has to treat the extra keys as optional.

{
  "id": "528817151",
  "username": "nasa",
  "fullName": "NASA",
  "biography": "Making the seemingly impossible, possible. ✨",
  "businessCategory": "Government Agencies",
  "bioLinks": [
    "https://www.nasa.gov",
    "https://science.nasa.gov/mission/roman-space-telescope/",
    "http://intern.nasa.gov"
  ],
  "externalUrls": "https://www.nasa.gov/",
  "followersCount": 104397669,
  "followsCount": 92,
  "postsCount": 4887,
  "verified": true,
  "isBusinessAccount": true,
  "latestPosts": [ "…twelve most recent posts, same shape as the posts tool…" ],
  "relatedProfiles": [
    { "id": "…", "username": "…", "fullName": "…", "profilePicUrl": "…" }
  ]
}

relatedProfiles is Instagram's own suggestion list for the account and runs to a few dozen entries. It is a cheap way to widen a competitor set without guessing handles.

Get Instagram posts

hasdata_instagram_posts_getInstagramPosts

The public post feed for one handle, page by page.

Parameter

Type

Required

Notes

handle

string

yes

Username without the @

limit

number

Approximate ceiling on posts in one response. Twelve is the real maximum, and larger values do not fetch more

nextPageToken

string

The pagination.nextPageToken from the previous response

limit is a rough cap rather than an exact count. Twelve posts is one Instagram page and the hard ceiling for a single call, and limit: 50 returns twelve. Below the ceiling the count lands near the number you asked for without always matching it, and how near depends on the account. Measured on @nasa, a limit of 2 returned 4 posts, 6 returned 6, 11 returned 10 and 13 returned 12. Treat it as "no more than roughly this many" and read the array length rather than assuming it.

The response repeats the account's identity fields alongside the posts. username, id, fullName, verified and both avatar URLs arrive on every page. Handy for labelling rows, and worth knowing before you make a separate profile call to get them.

Each post carries id, shortcode, caption, type, productType, hashtags, mentions, likesCount, commentsCount, timestamp, url, displayUrl, images, dimensionsWidth, dimensionsHeight, ownerId and ownerUsername.

{
  "username": "nasa",
  "id": "528817151",
  "fullName": "NASA",
  "verified": true,
  "latestPosts": [
    {
      "id": "3967213292204992434",
      "shortcode": "DcOX3hWFiey",
      "caption": "With your powers combined…\n\nThis colorful picture of the cosmos is the product of teamwork between our @NASAHubble, @NASAWebb, and @NASAChandraXray telescopes. […] \n\n#NASA #Universe #Nebula",
      "type": "Image",
      "hashtags": ["#NASA", "#Universe", "#Nebula"],
      "mentions": ["@NASAHubble", "@NASAWebb", "@NASAChandraXray"],
      "likesCount": 78412,
      "commentsCount": 402,
      "timestamp": "2026-08-18T16:02:11.000Z",
      "url": "https://www.instagram.com/p/DcOX3hWFiey/"
    }
  ],
  "pagination": {
    "morePostsAvailable": true,
    "nextPageToken": "3968050822236429248_528817151",
    "hasdataLink": "https://api.hasdata.com/scrape/instagram/posts?handle=nasa&nextPageToken=3968050822236429248_528817151"
  }
}

Hashtags and mentions keep their # and @ prefixes, which matters if you are joining them against a list you built yourself. morePostsAvailable is the flag to branch on when paging, and hasdataLink is the same next page expressed as a REST URL, useful when you want to reproduce an agent's call by hand.

Errors and failure paths

Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.

A wrong key surfaces as tool output, not as a failed connection. Listing tools accepts any non-empty key, and the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.

A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401.

An argument that breaks the schema is rejected before it becomes a request. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the field. Nothing is fetched and nothing is charged.

A handle that does not resolve is a clean error, not empty data. It returns isError: true with HasData API error: 400 Bad Request and requestMetadata.status set to error. This is the good case, because the failure is unambiguous. Test the flag rather than the array length.

An account whose data is not public returns no post feed. The tools cover public accounts, and there is nothing to read on one that is not. Treat a missing latestPosts as out of scope and not as an empty feed.

Results that carry data also carry a requestMetadata.id worth quoting in support, plus html and json links to the stored artifact of that exact call.

Pricing, free tier and limits

Every Instagram tool costs 10 credits per successful call. Response size does not change the price. A profile with twelve posts attached costs the same as one with none.

The free trial is 1,000 credits over 30 days with no card, or 100 Instagram calls. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.

Paid plans start at $49 a month for 200,000 credits, or 20,000 calls. The unit price falls with volume, from $2.45 per 1,000 calls on the entry plan to $0.99 on Business, $0.83 on Growth and $0.75 on the largest high-volume plans.

Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended, because an agent that fans out across handles will reach the ceiling before you do.

Paging costs a call each time. A prompt that walks a hundred posts across two accounts is eighteen calls and 180 credits. The trial goes further on profile comparisons than on deep feed crawls.

Tool selection

?apis=instagram exposes exactly these two tools. The parameter takes a list, and ?apis=instagram,tiktok,youtube gives your agent three social platforms at once. Drop the parameter and you get everything HasData exposes, which is currently 57 tools.

A narrow list is usually the better default. A model choosing between two tools picks correctly more often than one choosing between fifty-seven, and the tool descriptions themselves cost context on every turn.

Cross-platform comparison is the usual reason to widen the list. Ask the same question of an Instagram handle and a TikTok handle and it is one prompt once both are exposed.

How it compares

Almost every Instagram MCP server does something different from this one, and that makes the choice unusually clear.

The popular ones operate an account. Some wrap the Instagram Graph API to publish posts, read comments and manage the accounts you administer. Others handle direct messages. The engagement-analysis servers ask for INSTAGRAM_USERNAME and INSTAGRAM_PASSWORD in an env block, per their own setup instructions, because they sign in and browse as you. All of those are the right tool when the job is to run an account you control.

This server never signs in as anyone, which is a different job. Every question it answers is about a handle you do not own, and the call is identical whichever handle that is.

Account-operating server

This server

What it acts as

Your account, via a token or a session

Nothing, it reads public data

What you configure

Credentials or a Graph API app, per account

One API key, once

Which handles it covers

The accounts you administer

Any public handle

Publishing and messaging

Yes, that is the point

Not offered

Output

Scoped to the account you run

JSON for any public handle, hashtags and mentions parsed

What you run

A Python or Node process locally

A URL and a header

Cost

Free

10 credits a call

Two rows decide it. If you need to post, comment or reply, this server cannot help you at all. If you need the same fields across a hundred handles you have no relationship with, a server built around your own credentials cannot help you either.

The deciding axis is scope, not polish. A server built around your own login can only reach the accounts you administer, however good its output is. This one answers the same question for any public handle, and the fields come back as parsed arrays that cost nothing to aggregate.

What this server does not do. No comments, no stories, no reels beyond what the feed reports, no direct messages, no hashtag or location search, and nothing that writes. It reads two things well.

FAQ

What is an Instagram MCP server?

A server that exposes Instagram data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result and never sees a page of HTML. This one exposes two read-only tools and runs remotely. The client connects to a URL and starts no local process.

Is there an official Instagram MCP server?

Meta publishes no general-purpose one. There is an official MCP for Meta advertising, and it covers ad accounts and campaigns, not profile and post data. Everything else in this space is built by somebody else.

What data is in scope?

Public profile fields and the public post feed, for public accounts, by handle. A private account still returns its header, the follower and following counts and a private: true flag, but no biography and no posts, since there is no public feed to read. You are responsible for how you use the results, including compliance with Instagram's terms and with the law that applies to you.

Do I need to host or run anything?

No. This is a remote MCP server on streamable HTTP. Nothing to install, no Python environment, no process to restart.

Is the data live or cached?

Live. Each call fetches at request time and carries its own requestMetadata.id. Two identical calls are two separate fetches and not a replay of a stored copy. Counters like followers and likes track the account and move as it moves.

How many posts can I get?

Twelve per call, one Instagram page, and further pages come from pagination.nextPageToken. For a public account the profile lookup includes the same twelve at no extra cost, so short feed questions often need no posts call at all.

What happens when Instagram changes its markup?

Nothing on your side. We track the changes and keep the response schema stable, and field names and types stay put. A field with no value is absent from the item instead of present and null, and that is why optional fields should be read with a default.

Can I use one server for several platforms?

Yes. The apis parameter takes a list, and ?apis=instagram,tiktok,youtube gives your agent three platforms at once.

Which clients work?

Any MCP client that supports streamable HTTP with custom headers. The configs above are tested. Clients with OAuth support can add the URL as a connector instead.

Product pages and request builder

Instagram Profile API and Instagram Posts API

Server documentation

MCP server docs

All 57 tools in one server

HasData/hasdata-mcp

Client walkthroughs

MCP clients and integrations

The other platforms we parse

53 more scraper APIs

Plans and credit costs

Plans and credit costs

Keys and usage

HasData dashboard

Node launcher on npm

@hasdata/instagram-mcp

Python launcher on PyPI

hasdata-instagram-mcp

Development

This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.

It does carry a contract test. The README promises two tools with specific parameters, and the upstream tool list can change without a commit here, and that would leave this file quietly lying to you. The test asserts the promise and runs weekly in CI as well as on every push.

HASDATA_API_KEY=your_key_here npm test

On PowerShell:

$env:HASDATA_API_KEY = "your_key_here"; npm test

The last check makes a real call and costs 10 credits, which is the price of a canary that can fail for the right reason. Listing tools succeeds with any non-empty key, and a test that only lists tools stays green with a revoked one.

Contributing

Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.

License

MIT. See LICENSE.

Available Tools

2 tools
hasdata_instagram_posts_getInstagramPostsinstagram_posts: GET /AInspect

Get Instagram Posts

Fetches the latest posts of a public Instagram account by username (handle) and returns each post with caption, hashtags, mentions, likes/comments/plays counts, image and video URLs, dimensions, and timestamp, plus basic account info (full name, profile picture URL, verified/private flags). Supports token-based pagination via nextPageToken to walk older posts. Use to monitor competitor content, track engagement of creator posts, or build datasets of account content for vetting and analytics.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoThe maximum number of posts to retrieve per request. Defaults to 12.
handleYesThe Instagram username of the account whose posts you want to scrape, without the `@` symbol.
nextPageTokenNoDefines the next page token. It is used for retrieving the next page results. Use the `nextPageToken` value returned by the previous response.

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the read-only nature (fetches), the pagination mechanism via nextPageToken, and limits to public accounts, which is good. However, it does not explicitly state that it performs no mutations, nor does it mention auth requirements, rate limits, or error behavior (e.g., private account handling). These gaps are notable given the absence of annotations.

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?

The description is moderately sized but includes a redundant title phrase ('Get Instagram Posts') that repeats the tool name. It also lists fields in a long enumeration, which is informative but not strictly necessary for operation. It is front-loaded with the main action, but the structure could be tightened without losing value.

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

Completeness4/5

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

Given no output schema, the description sufficiently explains the return payload (post fields, media, account info) and pagination. It covers all parameters and provides usage context. Missing details are mostly error conditions or authentication specifics, which are not critical for a simple GET operation. Overall, it is complete enough for an agent to call it correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents each parameter clearly. The description adds marginal value by reinforcing the pagination token's purpose and the handle format (without '@'), but it does not provide semantic details beyond the schema's own descriptions. Baseline 3 is appropriate when schema handles parameter explanation.

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 resource ('Instagram Posts'), specifies the input (username/handle), and enumerates the exact return fields (caption, hashtags, mentions, counts, URLs, etc.) plus account info. This distinguishes it from the sibling tool (profile get) by resource focus, making the purpose unambiguous.

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

Usage Guidelines4/5

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

It provides explicit use cases ('monitor competitor content', 'track engagement', 'build datasets') and contextual guidance for when to use this tool. However, it does not mention any exclusions or direct alternatives (like the sibling for profile data), so it misses the full 'when-not-to-use' guidance.

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

hasdata_instagram_profile_getInstagramProfileinstagram_profile: GET /AInspect

Get Instagram Profile

Fetches a public Instagram profile by username (handle) and returns full name, biography, external link, profile picture URL, followers count, following count, posts count, verified/private flags, and category. Use to enrich CRM/lead records, verify influencer reach before outreach, monitor competitor accounts, or build datasets of creator metadata for vetting and analytics.

ParametersJSON Schema
NameRequiredDescriptionDefault
handleYesThe Instagram username of the profile you want to scrape, without the `@` symbol.

TDQS

A3.7/5.0
Behavior3/5

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

There are no annotations, so the description must carry the burden of behavioral disclosure. It states it fetches public data and lists the returned fields, which is helpful. However, it omits potential rate limits, error behavior, or whether data is live or cached. For a read operation it is adequate but not thorough.

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 concise and well-structured: it states the action, lists return fields, then adds use cases. It is front-loaded with the core purpose and each sentence earns its place. Slight trimming of use cases could tighten it, but it remains focused.

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

Completeness4/5

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

The tool is simple with one parameter and no output schema. The description covers what it returns, effectively acting as output documentation. It does not discuss failure modes, but for a basic GET that is acceptable. Overall it is complete for its complexity.

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 only parameter, handle, is fully described in the schema (username without @). The description repeats that it's a handle but adds nothing beyond the schema. With 100% schema description coverage, the baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool fetches a public Instagram profile by handle and enumerates the specific data returned (full name, bio, follower counts, flags, etc.). It is distinct from the sibling posts tool, though it does not name it. The verb and resource are explicit, making the purpose unambiguous.

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

Usage Guidelines3/5

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

The description lists concrete use cases (CRM enrichment, influencer verification, competitor monitoring, dataset building), giving context for when to use it. However, it does not explicitly compare to the sibling posts tool or state when not to use it. It provides guidance but lacks exclusion criteria.

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.

  1. 2 tool updatesv1.0.0
    • First observedhasdata_instagram_posts_getInstagramPosts
    • First observedhasdata_instagram_profile_getInstagramProfile

TDQS

A3.8/5.0
Disambiguation5/5

The two tools are completely distinct: one fetches profile metadata, the other fetches posts. There is no overlap in purpose or data returned, making misselection unlikely.

Naming Consistency5/5

Both tool names follow the same pattern: 'hasdata_instagram_<resource>_get<Resource>'. The structure and verb usage are consistent, making them predictable and easy to understand.

Tool Count3/5

With only 2 tools, this is on the thin side for an Instagram server. While they cover the core profile and posts endpoints, the count barely meets the threshold for a reasonable server scope.

Completeness2/5

The server covers only profile and posts, leaving significant gaps such as comments, stories, search, or follower interactions. For a comprehensive Instagram API surface, many common operations are missing, which could cause agent failures when those capabilities are needed.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    A
    quality
    Not graded
    maintenance
    Enables access to Instagram data through EnsembleData API, allowing retrieval of user information, posts, reels, follower counts, and search functionality for users, hashtags, and locations.
    9
    -
  • F
    license
    B
    quality
    C
    maintenance
    Provides Instagram analytics, media downloads, and search capabilities through an MCP interface for use with Claude and other MCP clients.
    43
    41
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    A remote MCP server that provides tools to query live Meta (Facebook+Instagram) and TikTok organic social data, such as follower counts, insights, recent posts, and aggregated overviews.
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    Provides unified access to social media data across nine networks (Instagram, TikTok, YouTube, etc.) through a set of MCP tools for profiles, posts, search, and comments, backed by the SocialBridge API.
    -

Latest Blog Posts

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/HasData/instagram-mcp'

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