Remote MCP endpoint wrapping instapdown.com — 16 tools covering Instagram Reels/Story/Carousel/profile-picture downloaders, engagement audit and weighted-ER calculator, live hashtag search, Reels hook generation, Unicode fonts, best-time-to-post for 17 markets and a 2026 content calendar. Public Instagram data only, no auth.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 16 of 16 tools scored. Lowest: 3.2/5.
Most tools have clear distinct purposes; however, engagement_calculator and engagement_health_check have overlapping functionality, both dealing with engagement metrics, which could cause confusion.
Majority of tools follow a verb_noun pattern (e.g., download_photo, search_hashtags), but two tools start with nouns (engagement_calculator, engagement_health_check), breaking the consistency.
16 tools cover a wide range of Instagram-related tasks without being excessive. Each tool serves a specific purpose relevant to the toolkit's domain.
The toolkit covers downloading, engagement analysis, content generation, and hashtag research. Missing features like posting or advanced profile analytics are minor gaps for an analytical toolkit.
audit_creator_hashtagsAInspectExtract the exact hashtag set any public Instagram creator uses on their last 12 posts, ranked by frequency. Reveals someone's actual working tag stack.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Public Instagram username |
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 'public Instagram creator' indicating a prerequisite (must be public) and 'last 12 posts' specifying scope. However, it does not disclose potential errors (e.g., private account, rate limits) or authentication needs.
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?
The description is composed of two concise sentences. Every word adds value, and the most critical information (what it does and output) is front-loaded. No redundant or verbose language.
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?
Given a simple input schema (one parameter) and no output schema, the description adequately explains the tool's purpose, scope, and output format. It could mention that the result is a list of hashtags with frequency counts, but this is implied by 'ranked by frequency.' Slightly more detail about the output structure would improve completeness.
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?
With 100% schema description coverage, the schema already documents username as 'Public Instagram username.' The description adds marginal context by reinforcing 'public' in the main text, but does not provide significant additional meaning beyond the schema.
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?
The description uses a specific verb 'Extract' and clearly defines the resource: 'hashtag set any public Instagram creator uses on their last 12 posts, ranked by frequency.' It distinguishes from sibling tools like search_hashtags which are for general hashtag search, not per-creator analysis.
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?
The description implies usage for analyzing a specific creator's hashtag stack, but it does not explicitly state when to use this tool versus alternatives like search_hashtags or engagement_calculator. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_carouselAInspectDownload every slide of a public Instagram carousel post — photos and videos both. Returns an array of media URLs in the original slide order.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Instagram carousel post URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool works on public carousels only and returns media URLs in original order. No mention of error handling or rate limits, but the read-only nature is implied.
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 concise sentences: first states action and scope, second states output format. No redundant information, front-loaded and efficient.
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?
Simple tool with one parameter. The description covers purpose, input constraint (public), and output (array in order). Could mention error responses, but overall complete for expected use.
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% with a clear parameter description. The tool description adds that the URL must be a public carousel, but this is already in the schema. Minimal addition beyond schema, meeting baseline.
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?
Clearly states the tool downloads all slides of a public Instagram carousel post, including both photos and videos. Distinguishes from siblings like download_photo and download_video by specifying 'every slide' and 'carousel'.
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?
The description implies use for carousel posts, and sibling tool names (download_photo, download_video) provide context. However, it lacks an explicit when-to-use or when-not-to-use statement, though the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_photoAInspectDownload a single-image Instagram post at original full resolution. Use download_carousel instead if the post has multiple slides.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Instagram single-image post URL |
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 download action and resolution but omits key behavioral details such as output format (URL or binary), authentication requirements, rate limits, or side effects.
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?
The description is two sentences with no extraneous information. Every word contributes to clarity and purpose.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential purpose and usage. However, it could be improved by describing the output format or return value.
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?
The schema has 100% coverage for the single parameter (url), so the description adds no significant meaning beyond what is already documented. Baseline 3 is appropriate.
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?
The description explicitly states the action (download), the resource (single-image Instagram post), and the resolution (original full resolution). It also distinguishes from the sibling tool download_carousel by specifying when to use that alternative.
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?
The description clearly indicates when to use this tool (single-image posts) and when not to (use download_carousel for multiple slides). However, it does not address other potential alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_profile_pictureAInspectDownload the full-resolution profile picture for any public Instagram account. Returns the original ~1080x1080 JPG straight from the CDN.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Public Instagram username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format and resolution, but no annotations provided; lacks details on error handling for private accounts or missing pictures.
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, no wasted words, front-loaded with key information.
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?
Adequate for a simple one-parameter tool, but could mention rate limits or edge cases; no output schema to clarify return structure.
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 covers the single parameter fully; description adds minimal extra beyond 'public Instagram account' which is already in schema.
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?
Explicitly states 'download the full-resolution profile picture' and specifies resolution and format, clearly distinguishing it from sibling tools like download_photo which are for other content.
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?
Implied usage for public Instagram accounts, but no explicit guidance on when not to use or alternatives to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_reelsAInspectDownload an Instagram Reel from a public post URL. Returns the original 9:16 HD MP4 URL and audio track, with no watermark and no re-encoding. Public accounts only — private accounts return HTTP 422.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Instagram Reel URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses important behavioral traits: no watermark, no re-encoding, and error handling for private accounts. It does not mention rate limits or authentication needs, but these are less critical for a read-only download tool.
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?
The description is two sentences with no wasted words. The action is front-loaded, and every sentence adds value (purpose, output characteristics, access restriction).
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the return format and an error condition. It could mention potential size limits or the absence of re-encoding, but overall it is adequate.
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?
The description reinforces that the URL must be a public Instagram Reel URL, which is already stated in the input schema description. Schema coverage is 100%, so the description adds minimal new meaning beyond the schema.
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?
The description uses a specific verb 'Download' and resource 'Instagram Reel from a public post URL'. It clearly states the output format (HD MP4 URL and audio track, no watermark, no re-encoding), distinguishing it from other download tools like download_video or download_story.
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?
The description explicitly states 'Public accounts only — private accounts return HTTP 422', which guides the agent on when not to use it. It does not name alternative tools for private reels, but the sibling list provides options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_storyAInspectFetch every currently-active Instagram Story for a public username within the 24-hour visibility window. Returns MP4 or JPG URLs for each Story frame. Private accounts return HTTP 422.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Public Instagram username (with or without leading @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It discloses the 24-hour window and private account error, but omits crucial details like authentication requirements, rate limits, or what happens if no stories are active. Safety and side effects are not addressed.
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 clearly stating purpose and a key error case. No redundant words; front-loaded with essential information.
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?
Given low complexity (1 param, no output schema), the description covers the primary function and one error. However, it lacks details about response format (likely a list of URLs), handling of nonexistent usernames, and success/error responses beyond 422.
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% with a single 'username' parameter already described. The description adds no further detail beyond the schema's own description, so it meets the baseline without enhancing semantic clarity.
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?
The description uses specific verbs ('fetch') and resources ('Instagram Stories'), specifies a time constraint ('24-hour visibility window'), and output type ('MP4 or JPG URLs'). It clearly differentiates from sibling tools like 'download_photo' or 'download_reels' by targeting Stories and noting a private account error (HTTP 422).
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?
The description implies when to use (within 24-hour visibility window) but does not explicitly state when not to use or list alternatives. No guidance on choosing between this and other Instagram download tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
download_videoAInspectDownload an Instagram feed video (not a Reel) from a public post URL. Returns the original MP4 in whatever resolution the creator uploaded, no re-encoding.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Instagram video post URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It discloses output format (MP4, no re-encoding) but does not discuss rate limits, authentication, or whether the tool is read-only. Partial transparency.
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 purpose and key details. No unnecessary words.
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?
Given one parameter and no output schema or annotations, description is fairly complete. Could mention potential errors (e.g., private videos) but adequate for a straightforward download tool.
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%, but description adds meaning by specifying the URL must be a public Instagram video post (not a Reel), which goes beyond the schema definition.
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?
Description clearly states it downloads an Instagram feed video (not a Reel) from a public post URL, specifying output format (original MP4, no re-encoding). Distinguishes from sibling tools like download_reels.
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?
Clear context for when to use (feed videos, not Reels), but lacks explicit exclusions or mention of alternatives. Sibling list provides indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
engagement_calculatorAInspectCalculate Instagram engagement rate weighted for the 2026 Reels-ranker signals: likes, comments, saves and shares each carry different weights. Returns weighted ER, follower-tier benchmark and a performance rating.
| Name | Required | Description | Default |
|---|---|---|---|
| avg_likes | Yes | Average likes per post | |
| avg_saves | No | Average saves per post (optional, default 0) | |
| followers | Yes | Follower count of the account | |
| avg_shares | No | Average shares/sends per post (optional, default 0) | |
| avg_comments | Yes | Average comments per post |
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 describes what the tool does and returns but does not mention error handling, data freshness, or side effects. The tool is non-destructive, but more transparency on input validation or performance would be beneficial.
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?
The description is a single, efficient sentence that conveys purpose and outputs without redundancy. Every phrase contributes value.
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 adequately explains return values (weighted ER, benchmark, rating). The tool has 5 parameters, all documented. It lacks details on return types, but the description covers the essential context for an AI agent.
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% with clear parameter descriptions. The description adds context about weighting signals but does not significantly enhance semantics beyond the schema. Baseline score of 3 is appropriate.
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?
The description clearly states the tool calculates Instagram engagement rate weighted by Reels-ranker signals. It names specific signals (likes, comments, saves, shares) and outputs (weighted ER, benchmark, rating), distinguishing it from all sibling tools.
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?
The description implies when to use this tool (for weighted engagement rate calculation). No sibling tool offers the same functionality, so exclusion is not critical, but explicit guidance on when to use alternatives (e.g., engagement_health_check) is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
engagement_health_checkAInspectAudit any public Instagram profile's engagement health. Pulls the last 12 posts and returns engagement rate, save rate, comment rate, follower-tier benchmark comparison and niche-adjusted rating.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Public Instagram username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the scope (last 12 posts) and what metrics are returned. However, it does not mention any behavioral traits such as authentication requirements, rate limits, or whether the operation is read-only. There is no contradiction with annotations since none exist.
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?
The description is a single, well-structured sentence that front-loads the action and quickly conveys the tool's purpose and outputs. Every word adds value with no redundancy.
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?
Given the tool's complexity (multiple metrics, benchmarking), the description is fairly complete. It lists all key return values (engagement rate, save rate, comment rate, benchmark, rating). Without an output schema, this provides sufficient guidance. Minor omission: no mention of output format (e.g., JSON, percentages).
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% for the single parameter 'username', so baseline is 3. The description does not add extra meaning beyond the schema's description ('Public Instagram username'), but the overall context of the tool provides adequate understanding.
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?
The description uses a specific verb ('audit') and names the exact resource ('public Instagram profile's engagement health'). It distinguishes itself from sibling tools like 'engagement_calculator' or 'audit_creator_hashtags' by detailing unique outputs such as follower-tier benchmark and niche-adjusted rating.
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?
The description implies usage for auditing engagement of public Instagram profiles, but does not explicitly state when to use this tool versus alternatives like 'engagement_calculator' or 'audit_creator_hashtags'. No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extract_reel_audioAInspectExtract the audio track from a public Instagram Reel and return the direct URL to the source m4a container. Useful for trending-sound research and remix reference.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public Instagram Reel URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses output format (direct URL to m4a) but lacks details on error handling, rate limits, or whether it modifies anything. Assumes read-only extraction.
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 action and output, followed by use case. No redundant words or filler.
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 simple 1-param tool with no output schema, description is adequate: what it does, what it returns, and a use case. Lacks error handling details but not critical for basic use.
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% with 'url' described as 'Public Instagram Reel URL'. Description adds 'public' and 'Instagram Reel' context, not significantly beyond schema. Baseline 3 is appropriate.
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?
Specific verb 'extract' and clear resource 'audio track from a public Instagram Reel'. States it returns a direct URL to m4a container, distinguishing it from sibling tools that deal with photos, videos, or engagement.
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?
Mentions use for 'trending-sound research and remix reference' but no when-not-to-use or alternative tools. Implies the reel must be public but no explicit prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_instagram_fontsAInspectConvert plain text into Instagram-compatible Unicode "fonts" for bio, name field and captions. 22 styles supported. Pass one style name or omit to get every style. Available: Bold, Italic, Bold Italic, Script, Bold Script, Fraktur, Bold Fraktur, Double Struck, Sans Serif, Sans Serif Bold, Sans Serif Italic, Sans Serif Bold Italic, Monospace, Small Caps, Upside Down, Circled, Squared, Fullwidth, Strikethrough, Underline, Double Strike, Wavy Underline.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The plain text to transform | |
| style | No | Optional single style name. If omitted, all styles returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits such as whether the operation is read-only, requires authentication, has rate limits, or side effects. The description only covers the conversion process, leaving agents uninformed about safety or constraints.
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: the first states the core purpose and scope, the second covers usage guidelines including the style parameter and lists available styles. Every sentence is informative and there is no waste. The list of styles, though long, is essential and well-placed.
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 simple tool with only 2 parameters (1 required) and no output schema, the description is largely complete: it covers purpose, usage, and parameter details. However, it does not describe the output format (e.g., object with style keys), which would be useful for agents to parse results. The absence is minor given the tool's simplicity.
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% with both parameters described, but the description goes further: it explains that 'style' can be omitted for all styles, and enumerates all 22 supported style names. This adds significant actionable meaning beyond the schema's minimal description.
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?
The description clearly states the tool converts plain text to Instagram-compatible fonts, specifies it supports 22 styles, and notes usage for bio, name, and captions. This distinct verb+resource purpose is well separated from sibling tools that deal with downloading or hashtags.
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?
The description explains how to use the style parameter (pass a single style or omit for all) and lists available styles. It does not explicitly state when not to use or compare to alternatives, but no sibling tool offers similar functionality, so this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_reels_hooksAInspectGenerate first-second Instagram Reels opening hooks for a niche. Returns verified 2026 hook templates from Instapdown's 900-hook library. Country + language optional for locale-native hooks.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | BCP-47 language tag (en, tr, ar, es, fr, de, it, pt, ru, ja). Optional. | |
| niche | Yes | Content niche, e.g. "fitness", "food", "business" | |
| country | No | ISO 2-letter country code for locale-native hooks (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it uses a specific library (Instapdown's 900-hook library) and that hooks are 'verified 2026 templates'. No annotations provided, but description adds some context beyond the bare operation.
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, no fluff. Information is front-loaded: action, resource, and key differentiator (library source).
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?
No output schema, so return format is not described. Given the tool's simplicity and the presence of many siblings, the description is adequate but could mention what a 'hook template' looks like.
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%; description adds meaning by explaining that 'country' and 'lang' are for locale-native hooks, which the schema descriptions only hint at.
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?
Clearly states the verb 'generate' and resource 'first-second Instagram Reels opening hooks'. Distinguishes from sibling tools which are about downloading, hashtags, or analytics.
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?
Implies use for obtaining hooks but lacks explicit guidance on when to use vs alternatives or when not to use. No mention of prerequisites or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_best_time_to_postAInspectReturn data-driven optimal Instagram posting windows for a country. Source: Buffer 2026 verified dataset. Returns 5 prime posting slots + 7-day heatmap. Supported markets: US, GB, CA, AU, BR, MX, ES, IT, DE, FR, NL, SE, TR, JP, SA, AE, RU.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | ISO 2-letter country code. Supported: US, GB, CA, AU, BR, MX, ES, IT, DE, FR, NL, SE, TR, JP, SA, AE, RU |
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 data source (Buffer 2026), output components (5 prime slots + 7-day heatmap), and supported markets. It does not mention any destructive or side effects, which is appropriate for a read-only analytical tool.
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?
The description consists of two concise sentences. The first sentence front-loads the core action and result. Every sentence adds essential information without redundancy.
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 query tool with no output schema, the description adequately explains the return format (slots and heatmap) and the authoritative data source. It could be more detailed about the heatmap structure, but it's sufficient for an agent to understand the tool's deliverable.
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 description coverage is 100% and already includes the supported country list and ISO code format. The description largely repeats this information, adding minimal extra meaning beyond what the schema provides. Baseline 3 is appropriate.
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?
The description uses a specific verb ('Return') and identifies the resource ('data-driven optimal Instagram posting windows for a country'). It clearly distinguishes this tool from sibling tools like download_photo or engagement_calculator by its unique analytical purpose.
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?
The description implies usage for social media scheduling optimization but provides no explicit guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites beyond supported country codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_content_calendarAInspectReturn the Instagram content calendar entries for a market, filtered by an optional date range and/or niche. Each entry has a native-language Reels hook + hashtag set. Markets: US, GB, CA, AU, BR, MX, ES, IT, DE, FR, NL, SE, TR, JP, SA, AE, RU, GLOBAL. Use "GLOBAL" for cross-market dates.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO upper bound, YYYY-MM-DD (optional) | |
| from | No | ISO lower bound, YYYY-MM-DD (optional) | |
| limit | No | Max entries (default 50) | |
| niche | No | Optional niche filter | |
| market | Yes | ISO 2-letter country code, or "GLOBAL" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that entries contain a native-language Reels hook and hashtag set, and lists markets. However, it does not mention any read-only behavior, authentication needs, rate limits, or response format constraints. For a retrieval tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, no redundancy, front-loaded with the main action. Every sentence adds distinct information: purpose, output details, market list, guidance on GLOBAL.
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?
The tool has no output schema but the description adequately explains return content. The main missing elements are default limit behavior (50, mentioned in schema but not description) and pagination hints. For a straightforward retrieval tool, this is sufficient for an agent to invoke it correctly.
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 baseline is 3. The description adds value by explaining the output structure (hook + hashtags) and listing the exact market codes, which is not in the schema (which only says 'ISO 2-letter code or GLOBAL'). This helps the agent understand what each parameter means in context.
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?
The description clearly states the tool returns Instagram content calendar entries for a market, with optional date range and niche filters. It uses a specific verb ('Return') and resource ('content calendar entries'), and the scope is well-defined. The sibling tools are unrelated (downloads, audits), so no confusion with alternatives.
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?
The description explicitly lists supported market codes and advises using 'GLOBAL' for cross-market dates. It does not provide when-not-to-use or comparisons with sibling tools, but the context is clear enough for selecting this tool over unrelated siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hashtag_nicheBInspectList the 25 curated Instagram hashtag seed niches Instapdown ships. Returns each niche's slug, human label, one-line description and category grouping.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category filter: Lifestyle & Creative | Visual Arts | Business & Money | Family & Personal | Sports & Hobbies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as idempotency, rate limits, or whether it requires authentication. It only lists output fields, lacking broader 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential purpose and output, with no wasted words.
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 simple list tool with one optional parameter, the description is adequate. It explains what it returns. However, it could mention that this is a preset seed list and not user-generated, but overall it is sufficient.
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 description coverage is 100% for the single optional parameter 'category' with a clear list of values. The tool description adds no additional meaning beyond what the schema already provides.
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?
The description clearly states the tool lists 25 curated Instagram hashtag seed niches and specifies that it returns slug, human label, description, and category grouping. It distinguishes from sibling 'search_hashtags' by focusing on curated seeds.
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?
No guidance on when to use this tool vs. alternatives like 'search_hashtags'. The description only states what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hashtagsBInspectLive-search Instagram's public hashtag index for a topic and return real post counts. Not cached, not fabricated. Country + language shape the returned tag mix.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Free-form topic | |
| locale | No | BCP-47 language tag (default: en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that results are live, not cached, and influenced by country/language. However, it fails to reveal essential behavioral traits like required permissions, rate limits, error behavior (e.g., topic not found), or what happens with an invalid locale. The description is insufficiently transparent for a tool with no annotations.
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?
The description is extremely concise: two sentences with no superfluous words. Every sentence adds value: first states core action and output, second clarifies data freshness and influencing factors. It is front-loaded and easy to parse.
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?
Given no output schema, the description must explain return values, but it only mentions 'real post counts' without specifying format (e.g., integer, string, object). It also omits error handling, pagination, and overall response structure. For a tool with 2 parameters and no output schema, this is insufficient for an agent to fully understand the output.
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 description coverage is 100%, so the schema already documents both parameters. The description adds minor extra context by noting that country and language shape the tag mix, which is not in the schema for 'locale'. This adds some value beyond the schema, but does not substantially enhance understanding. Baseline 3 is appropriate.
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?
The description clearly states the tool does a live-search of Instagram's hashtag index for a topic and returns real post counts. It mentions country and language influence, which adds specificity. However, it does not distinguish itself from sibling tools like 'get_hashtag_niche' or 'audit_creator_hashtags', lacking explicit differentiation.
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?
The description implies usage for real-time, accurate post counts by stating 'Live-search' and 'Not cached, not fabricated'. But it provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The usage context is implied but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
