Instagram Download MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
The tools are mostly distinct with clear purposes: highlights, posts, profile pictures, stories, and videos. However, there is some overlap between download_instagram_post and download_instagram_video, as both handle posts/reels/tv URLs, which could cause confusion about which to use for video content. The descriptions help clarify, but the boundaries are not perfectly clear.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern with 'download_instagram_' as a prefix, followed by the specific target (e.g., highlights, post, profile_pic, stories, video). This uniformity makes the tool set predictable and easy to understand, with no deviations in naming style.
Tool Count5/5With 5 tools, this server is well-scoped for its purpose of downloading various Instagram content types. Each tool serves a distinct function (highlights, posts, profile pictures, stories, videos), and the count is neither too sparse nor excessive, fitting typical expectations for a focused download utility.
Completeness4/5The tool set covers key Instagram content types for downloading: highlights, posts, profile pictures, stories, and videos, providing good coverage for the domain. A minor gap is the lack of a tool for downloading multiple posts or feeds, which might be useful for batch operations, but agents can work around this by iterating with the existing tools.
Average 3.5/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- 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 mentions authentication requirements ('requires login'), which is helpful, but doesn't disclose other behavioral traits such as rate limits, potential for account blocking, file formats downloaded, or error handling. For a tool that likely involves web scraping and authentication, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a note, and sections for Args and Returns. It's appropriately sized, though the parameter explanations are very brief. Every sentence serves a purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage and no annotations, the description is incomplete. It covers authentication needs and lists parameters but lacks details on behavior, constraints, and error cases. The presence of an output schema helps by documenting return values, but overall, it's only minimally adequate for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief explanations (e.g., 'Target Instagram username'), but these add minimal semantic value beyond what the parameter names imply. It doesn't explain format constraints (e.g., valid usernames), the effect of optional filters, or how authentication works with null defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download Instagram highlights for a target user.' It specifies the verb (download) and resource (Instagram highlights), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like download_instagram_stories, which serves a similar purpose but for different content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Note: This feature requires login,' indicating authentication is needed. It doesn't explicitly state when to use this tool versus alternatives like download_instagram_stories or download_instagram_post, leaving the agent to infer based on content type (highlights vs. stories vs. posts).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions authentication parameters are optional but doesn't explain when authentication is needed, what happens if authentication fails, whether rate limits apply, what the download directory default is, or what the JSON response contains. For a tool that downloads files and potentially requires authentication, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by organized parameter explanations and return value information. It's appropriately sized with no redundant information, though the 'Args:' and 'Returns:' formatting could be slightly more integrated with the natural language flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (1 required), no annotations, and an output schema exists, the description covers the basic purpose and parameters adequately. However, for a tool that downloads files and may require authentication, it lacks important context about authentication requirements, file naming conventions, error conditions, and what the JSON response contains, despite the output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides clear semantic explanations for all 4 parameters beyond their schema titles: 'username_target' is the target Instagram username, 'username' and 'password' are for authenticated access, and 'download_root' overrides the download directory. With 0% schema description coverage, the description fully compensates by explaining what each parameter means and their optional nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download an Instagram profile picture') and the target resource ('to the local filesystem'), distinguishing it from sibling tools that handle different Instagram content types like highlights, posts, stories, and videos. It uses precise verbs and identifies the exact resource being manipulated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. While it implicitly suggests this is for profile pictures (versus other content types), there's no explicit comparison to sibling tools, no mention of prerequisites like authentication requirements, or any context about when authentication might be necessary versus optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of behavioral disclosure. It mentions the login requirement, which is useful context, but lacks details on permissions, rate limits, error handling, or what the download process entails (e.g., file formats, storage implications). For a tool with authentication and file operations, this leaves significant gaps in understanding its 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a note, and labeled sections for Args and Returns. It is appropriately sized and front-loaded, with no wasted sentences. Minor improvements could include briefer phrasing, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (involving authentication and file downloads), no annotations, and an output schema present (which covers return values), the description is partially complete. It covers the login requirement and parameter semantics but lacks behavioral details like error cases or operational constraints, making it adequate but with clear gaps for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter's purpose: 'username_target' for the target user, 'username' and 'password' for authenticated access, and 'download_root' as an optional override for the download directory. This adds meaningful context beyond the schema's titles, though it could provide more detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download Instagram stories') and resource ('for a target user'), distinguishing it from sibling tools like download_instagram_highlights or download_instagram_post. It precisely identifies the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note that 'This feature requires login,' which provides some context for when to use it (i.e., when authentication is available). However, it does not explicitly differentiate when to use this tool versus its siblings (e.g., for stories vs. highlights or posts), nor does it specify prerequisites or exclusions beyond the login requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions authentication options and file-saving behaviors but lacks critical details: whether authentication bypasses rate limits, what happens if files already exist, error handling, or local filesystem permissions needed. 'Download to local filesystem' implies write operations but doesn't specify risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear opening sentence followed by Args/Returns sections. Every sentence adds value: the first states purpose, Args explain parameters, Returns specifies output format. Slightly verbose but efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and an output schema (which covers return values), the description is moderately complete. It explains parameters well but lacks behavioral context about authentication benefits, file conflicts, or error conditions that would be crucial for a download tool with write operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic explanations for all 6 parameters: url purpose, optional auth fields, metadata/caption saving behaviors, and download directory override. This adds substantial value beyond the bare schema with only titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download') and target resource ('Instagram video's media files') with destination ('to the local filesystem'). It distinguishes from siblings by specifying 'video' content rather than highlights, posts, profile pictures, or stories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Instagram videos via URLs (posts/reels/tv) but doesn't explicitly state when to use this vs. sibling tools like 'download_instagram_post' which might overlap. It mentions optional authentication but doesn't explain when authentication is needed or beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that files are saved to the local filesystem and mentions authentication needs via username/password parameters, but doesn't cover important behavioral aspects like rate limits, error handling, file naming conventions, or what happens when metadata/captions aren't available. It provides basic operational context but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, Args, Returns) and efficiently explains parameters. Every sentence adds value, though the 'Returns' section could be slightly more informative given the output schema exists. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters with no schema descriptions and no annotations, the description does a good job explaining parameter semantics. The existence of an output schema means the description doesn't need to detail return values. For a tool with this complexity and no annotation support, the description provides adequate context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all 7 parameters in the Args section. Each parameter gets meaningful context about its purpose and effect, adding substantial value beyond the bare schema. The only minor gap is that 'url' could specify format expectations more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Download') and resource ('Instagram post's media files'), and distinguishes it from siblings by specifying it's for posts/reels/TV rather than highlights, profile pics, stories, or videos. The first sentence is a complete, unambiguous statement of function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through parameter explanations (e.g., 'for authenticated access'), but doesn't explicitly state when to use this tool versus its siblings. It mentions what the tool does but doesn't provide guidance on when it's the appropriate choice among the Instagram download tools available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/KaiQin04/ig-download-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server