Public Instagram profiles and post feeds by handle, with hashtags and mentions parsed.
Scored across 3 tools
Each tool targets a distinct Instagram resource: comments on a specific post, posts of an account, and a profile. Inputs (URL vs username) and outputs differ clearly, so an agent can easily select the right tool.
All tool names follow the same pattern: hasdata_instagram_<resource>_getInstagram<Resource>, using consistent snake_case with a camelCase action. Minor redundancy does not hurt predictability.
Three tools is well within the 3-15 sweet spot and each covers a core Instagram data retrieval function. No tool feels extraneous or missing at this scope.
The surface covers profile, posts, and comments, which are core read endpoints. However, there's no dedicated tool to fetch a single post's details (the comments tool does this as a side effect), a minor gap for agents wanting post metadata without comments.
Get Instagram Comments
Fetches the comments on a public Instagram post or reel from its URL (/p/, /reel/ or /tv/ links, with or without the username segment). The first page returns the post (id, shortcode, caption, hashtags, mentions, likes and comments counts, owner, display image, images, video URL, DASH manifest, hasAudio flag, tagged location, and every carousel item as childPosts) plus the first comments; with includeMusic=true the post also carries music (audioId, artistName, songName) for the reel's licensed track or original sound; later pages return comments only. Each comment has text, timestamp, like count, reply count, and owner (username, verified flag, profile picture, hasdataLink to the profile endpoint). Supports token-based pagination via nextPageToken. Instagram sizes pages server-side (about 10 to 15 comments). Use for sentiment analysis, engagement research, or building comment datasets from posts discovered via the posts API, whose items carry a hasdataLink to this endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the Instagram post or reel, for example `https://www.instagram.com/p/Ddjis3vETcP/` or `https://www.instagram.com/instagram/reel/DcymgItMFao/`. | |
| includeMusic | No | Also return the reel's sound (audio ID, artist and song title) in `post.music`, for both licensed tracks and original audio. This takes an extra request to Instagram on the first page and is ignored when `nextPageToken` is set. Default is false. | |
| nextPageToken | No | Defines the next page token. Use the `nextPageToken` value returned by the previous response. Omit it to fetch the first page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations by disclosing pagination mechanics: the first page returns the full post plus initial comments while later pages return comments only, server-side page sizing of ~10-15 comments, and nextPageToken handling. It also notes includeMusic triggers an extra upstream request and is ignored when nextPageToken is set.
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?
Front-loads the purpose in the first sentence, then layers pagination and return-shape detail. It is dense, and the long parenthetical enumerating every post field is heavy, but that content earns its place because there is no output schema.
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 no output schema, the description carries the full burden of describing return values and does so thoroughly: post fields, carousel childPosts, comment fields (text, timestamp, likes, replies, owner with hasdataLink), and music fields. Nothing an agent needs to call it correctly is missing.
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 the baseline is 3, but the description adds beyond it by enumerating accepted URL forms (/p/, /reel/, /tv/, with or without the username segment) and clarifying the interaction between includeMusic and nextPageToken. Most other parameter detail is already in the schema, so it is not fully additive.
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?
States a specific verb and resource ('Fetches the comments on a public Instagram post or reel from its URL'), and its scope clearly separates it from sibling tools like getInstagramPosts and profile endpoints. An agent can immediately tell this returns comments rather than posts or profiles.
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 concrete use cases (sentiment analysis, engagement research, comment datasets) and explicitly routes the agent from the posts API, whose items carry a hasdataLink to this endpoint. It does not state when to avoid the tool or name a competing comments source, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Instagram Posts
Fetches the latest posts of a public Instagram account by username (handle) and returns each post with caption, hashtags, mentions, like and comment counts, play counts on videos and Reels, image and video URLs, and timestamp. Supports token-based pagination via nextPageToken to walk older posts. Private accounts and handles that do not exist or are hidden from logged-out viewers return an error field instead of posts. Use to monitor competitor content, track engagement of creator posts, or build datasets of account content for vetting and analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The maximum number of posts to retrieve per request. Defaults to 12. | |
| handle | Yes | The Instagram username of the account whose posts you want to scrape, without the `@` symbol. | |
| nextPageToken | No | Defines the next page token. It is used for retrieving the next page results. Use the `nextPageToken` value returned by the previous response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description still adds meaningful behavior: token-based pagination via nextPageToken to walk older posts, and that private/nonexistent/hidden handles return an error field instead of posts. No rate limits or result-cap behavior are mentioned, keeping it short of a 5.
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?
Front-loaded with the purpose, then return fields, then pagination, then error behavior, then use cases — a sensible ordering with little waste. The field enumeration is long but justified given there is no output schema.
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 no output schema, the description carries the return-value burden and does so by listing caption, hashtags, mentions, engagement counts, video/Reels play counts, media URLs, and timestamps. Combined with pagination semantics and error behavior for private accounts, nothing an agent needs to call this correctly is missing.
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 each of the three parameters is already documented with its own description. The description adds only a light gloss on pagination ('walk older posts'); it adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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?
States a specific verb and resource ('Fetches the latest posts of a public Instagram account by username') and enumerates the returned fields, which cleanly separates it from sibling tools like instagram_profile and instagram_comments. An agent can tell what this returns without opening the schema.
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?
Gives concrete use cases ('monitor competitor content, track engagement of creator posts, or build datasets... for vetting and analytics'), which is clear when-to-use context. It does not, however, name alternative tools or state when not to use it (e.g., profile metadata or comments go to sibling tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, and verified/private flags. Use to enrich CRM/lead records, verify influencer reach before outreach, monitor competitor accounts, or build datasets of creator metadata for vetting and analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The Instagram username of the profile you want to scrape, without the `@` symbol. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the low-level safety profile is covered. The description adds the meaningful constraint that only *public* profiles are fetched and enumerates the returned fields, which goes beyond the annotations, but it says nothing about rate limits, failures on missing/private handles, or freshness.
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 the operation and its return payload, followed by use cases. The use-case list is somewhat expansive but each item is a plausible agent routing cue, so little is wasted.
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?
For a single-parameter read tool with rich annotations but no output schema, the description covers purpose, scope, and return shape, which is most of what an agent needs. Minor gaps (behavior on invalid/private handles) are tolerable given the simplicity and annotation coverage.
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% and the single handle parameter is already documented in the schema, including the no-@-symbol requirement. The description only restates 'by username (handle)' and adds no new syntax or format meaning, so the baseline of 3 applies.
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?
States a specific verb (Fetches) and resource (public Instagram profile by username) and lists exactly what the response contains (full name, bio, link, picture, follower/following counts, verified/private flags). This clearly separates it from content-oriented siblings like instagram_posts and instagram_comments, though no sibling is named explicitly.
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 concrete usage contexts (CRM enrichment, influencer vetting, competitor monitoring, dataset building) that tell the agent when this tool is appropriate. It offers no exclusions or named alternatives (e.g. TikTok/Facebook profile tools), so it stops short of full routing guidance.
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.
hasdata_instagram_comments_getInstagramCommentshasdata_instagram_posts_getInstagramPostshasdata_instagram_profile_getInstagramProfileInstagram profiles, follower/following snapshots and changes, with budgeted public lookups.
Instagram profiles, follower/following snapshots and changes, with budgeted public lookups.
Read-only public Instagram data: profiles, posts, reels, stories, comments, top-accounts ranking.
Public Instagram and TikTok data: profiles, posts, reels, stories, comments, hashtags and places.
Add one secure layer between your agents and this server.
