Instagram public post search, details, comments, replies, user info, and user posts.
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 4.2/5 across 9 of 10 tools scored. Lowest: 3.6/5.
Tools are mostly distinct by resource (user info, user posts, post detail, post comments, comment replies, search, points). Two pairs differ only by lookup method (URL vs. username/ID), which is clear and acceptable. No overlapping purposes that would cause confusion.
All tools follow a consistent pattern: instagram_[action]_[resource]_by_[identifier]. For example, instagram_get_post_comments_by_post_url, instagram_search_posts, socialdatax_get_points_balance slightly deviates but remains verb_noun and clear. Overall highly consistent.
With 10 tools covering user, posts, comments, and search, the count is well-scoped for an Instagram scraping/MCP server. Each tool serves a distinct need, and the count is within the ideal range.
The tool set covers core read-only capabilities: user info, user posts, post details, comments, replies, search, and points balance. Missing operations like getting post comments by post_id (only via URL), getting replies by post URL (only by comment ID), or media downloads might be minor gaps, but most workflows are supported. Likely intentional to limit scope to public data.
instagram_get_post_comment_replies_by_comment_idA根据 Instagram 帖子的 post_id 和一级评论 comment_id 分页获取评论回复。
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Instagram 帖子 ID（数字字符串）；从一级评论结果 items[*].post_id 原样复制；也可使用同一帖子搜索或详情结果的 post_id；需与一级评论 comment_id 同时传入。 | |
| comment_id | Yes | Instagram 一级评论 ID（数字字符串）；从一级评论结果 items[*].comment_id 原样复制；不要传评论回复结果里的 items[*].comment_id。 | |
| page_token | No | Instagram 评论回复分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一帖子和一级评论的回复链路；更换 post_id 或 comment_id 时，请清空 page_token 后从第一页重新读取评论回复。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页评论回复列表；当前页可能为空数组。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| reply_count | Yes | 当前接口返回的评论回复数量；不代表一级评论下展示的全部回复数；不可用时为 null。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前评论回复续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral trait of pagination ('分页获取') beyond what annotations provide (readOnlyHint and openWorldHint). It does not contradict annotations and provides a small but relevant behavioral detail. The schema descriptions further elaborate on page_token behavior, but the description itself contributes the pagination 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, compact sentence with no superfluous words. It is front-loaded with the core action and parameters, making it easy to parse quickly. There is no repetition of schema 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 the tool's moderate complexity, the detailed schema annotations, and the presence of an output schema, the description is sufficient. It captures the essential purpose and pagination aspect, while the schema covers parameter intricacies. It does not need to explain return values or technical details since those are already in structured fields. However, a minor improvement could be explicitly mentioning it is read-only, but annotations already convey that.
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 the schema already provides exhaustive descriptions for all three parameters, including the opaque nature and usage of page_token. The tool description adds no parameter-specific meaning beyond what the schema offers, so the baseline score 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?
The description clearly states the tool's purpose: paginated retrieval of comment replies based on a post_id and a top-level comment_id. This specific verb-resource combination (get replies for a comment) distinguishes it from sibling tools like instagram_get_post_comments_by_post_url, which fetches top-level comments.
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 (when you need replies to a specific comment), but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions. There is no mention of when not to use it or references to sibling tools. Thus, guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_post_comments_by_post_urlA根据 Instagram 帖子链接分页获取公开帖子的一级评论。
| Name | Required | Description | Default |
|---|---|---|---|
| post_url | Yes | Instagram 帖子分享页链接；从搜索结果或详情结果的 share_url 原样复制；不要传 post_id、作者主页链接、评论链接、接口地址或包含链接的分享文案。 | |
| page_token | No | Instagram 评论分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一帖子评论链路；更换帖子链接时，请清空 page_token 后从第一页重新读取评论。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页一级评论列表；当前页可能为空数组。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| post_url | Yes | 可打开的 Instagram 帖子分享页链接；继续引用或展示帖子时优先使用。 |
| comment_count | Yes | 该帖子评论总数；不是当前页评论条数，也不等于当前页 items 数量；不可用时为 null。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前评论续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the bar is lower. The description adds behavioral constraints: only 'public posts' and only 'first-level comments' are included, and pagination is explicitly mentioned. This is meaningful context beyond the 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?
One concise sentence that front-loads the core purpose (paginated retrieval of first-level public post comments). No filler or redundant content.
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, the presence of a detailed input schema, output schema, and annotations, the description sufficiently covers the core functionality. It lacks some explicit edge-case guidance (e.g., behavior for non-public posts), but that is not critical given the schema and annotations already provide substantial context.
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%, with rich descriptions for both post_url and page_token. The description itself adds no additional parameter meaning, so 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?
Description clearly states the tool retrieves first-level comments from public Instagram posts using a post link, with pagination. This specific verb+resource+scope distinguishes it from sibling tools like replies or user info.
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 explicit when-to-use or alternative exclusions in the description. The 'first-level comments' phrasing implies it differs from the replies tool, but the description itself does not provide direct guidance on when to choose this over siblings. Schema parameter hints provide some context, but that is outside the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_post_detail_by_post_idA根据 Instagram 帖子 ID 获取公开帖子详情。
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Instagram 帖子 ID（数字字符串）；从搜索结果或详情结果的 post_id 原样复制；不要传 shortcode、用户名、主页链接或包含链接的分享文案。 |
| Name | Required | Description |
|---|---|---|
| music | Yes | 帖子关联音乐/配乐信息；没有可返回的音乐信息时为 null。 |
| author | Yes | 帖子作者信息；不可用时为 null。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| caption | Yes | 帖子配文；没有配文时为空字符串。 |
| post_id | Yes | Instagram 帖子 ID。 |
| location | Yes | 帖子地理标记地点/POI，不是 IP 属地；没有地点时为 null。 |
| post_type | Yes | 帖子类型；photo 表示照片帖子，video 表示视频帖子，carousel 表示轮播帖子。 |
| share_url | Yes | Instagram 帖子分享页链接；不可用时为 null。 |
| like_count | Yes | 点赞数；不可用时为 null。 |
| play_count | Yes | Instagram 播放/观看数；没有视频或不可用时为 null。 |
| topic_tags | Yes | 帖子配文中的话题标签；无话题标签时为空数组；每项只返回 name，不带 #。 |
| media_count | Yes | 帖子包含的媒体数量。 |
| media_items | Yes | 帖子包含的图片/视频媒体列表；单图/单视频通常 1 项，轮播帖按顺序返回多项。 |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳；不可用时为 null。 |
| repost_count | Yes | 转发/再分享数；不可用时为 null。 |
| tagged_users | Yes | 帖子图片或视频中标记的用户列表；无标记用户时为空数组。 |
| collaborators | Yes | 帖子共同发布者/协作者列表；无共同发布者时为空数组。 |
| comment_count | Yes | 评论数；不可用时为 null。 |
| cover_image_url | Yes | 帖子封面图链接；不可用时为 null。 |
| mentioned_users | Yes | 帖子配文中 @ 到的用户名；无 @ 时为空数组；每项只返回 username，不带 @。 |
| comments_disabled | Yes | 是否禁止发评论；true 表示已禁止，false 表示未禁止，null 表示不可用。 |
| like_and_view_counts_hidden | Yes | 平台展示层是否隐藏点赞数或播放/观看数；true 表示已隐藏，false 表示未隐藏，null 表示不可用。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description aligns with those by saying it reads public post details. However, it does not add behavioral context beyond that, such as rate limits, error behavior, or restrictions, so it stays at a baseline acceptable level.
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, front-loaded sentence in Chinese that says exactly what the tool does with no filler or redundancy. It earns its place without wasting tokens.
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 required parameter, strong schema descriptions, annotations, and the presence of an output schema, the description is nearly complete. It could improve by explicitly noting to use the URL-based sibling when only a URL is available, 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%, so the structured schema already fully documents post_id. The tool description itself only restates the concept of using an Instagram post ID and adds no parameter semantics beyond the schema; the helpful exclusions (no shortcode, username, links) live in the schema, not the 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 fetches public post details by Instagram post ID, using a specific verb ('获取') and resource ('公开帖子详情'). This distinguishes it from sibling tools like instagram_get_post_detail_by_post_url, which retrieves by URL.
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 (when you have a post ID), but it does not explicitly contrast it with the sibling URL-based tool or mention when not to use it. The schema's parameter description adds important 'don't pass shortcode/username/link' guidance, but that is parameter-level rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_post_detail_by_post_urlA根据 Instagram 帖子链接获取公开帖子详情。
| Name | Required | Description | Default |
|---|---|---|---|
| post_url | Yes | Instagram 帖子分享页链接；从搜索结果或详情结果的 share_url 原样复制，或传用户提供的 Instagram 帖子链接；不要传作者主页链接、评论链接或接口地址。 |
| Name | Required | Description |
|---|---|---|
| music | Yes | 帖子关联音乐/配乐信息；没有可返回的音乐信息时为 null。 |
| author | Yes | 帖子作者信息；不可用时为 null。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| caption | Yes | 帖子配文；没有配文时为空字符串。 |
| post_id | Yes | Instagram 帖子 ID。 |
| location | Yes | 帖子地理标记地点/POI，不是 IP 属地；没有地点时为 null。 |
| post_type | Yes | 帖子类型；photo 表示照片帖子，video 表示视频帖子，carousel 表示轮播帖子。 |
| share_url | Yes | Instagram 帖子分享页链接；不可用时为 null。 |
| like_count | Yes | 点赞数；不可用时为 null。 |
| play_count | Yes | Instagram 播放/观看数；没有视频或不可用时为 null。 |
| topic_tags | Yes | 帖子配文中的话题标签；无话题标签时为空数组；每项只返回 name，不带 #。 |
| media_count | Yes | 帖子包含的媒体数量。 |
| media_items | Yes | 帖子包含的图片/视频媒体列表；单图/单视频通常 1 项，轮播帖按顺序返回多项。 |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳；不可用时为 null。 |
| repost_count | Yes | 转发/再分享数；不可用时为 null。 |
| tagged_users | Yes | 帖子图片或视频中标记的用户列表；无标记用户时为空数组。 |
| collaborators | Yes | 帖子共同发布者/协作者列表；无共同发布者时为空数组。 |
| comment_count | Yes | 评论数；不可用时为 null。 |
| cover_image_url | Yes | 帖子封面图链接；不可用时为 null。 |
| mentioned_users | Yes | 帖子配文中 @ 到的用户名；无 @ 时为空数组；每项只返回 username，不带 @。 |
| comments_disabled | Yes | 是否禁止发评论；true 表示已禁止，false 表示未禁止，null 表示不可用。 |
| like_and_view_counts_hidden | Yes | 平台展示层是否隐藏点赞数或播放/观看数；true 表示已隐藏，false 表示未隐藏，null 表示不可用。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds the 'public post' scope restriction, which is useful, but it does not disclose additional behaviors like failure modes, rate limits, or auth requirements.
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 one concise, front-loaded sentence in Chinese that directly states the tool's purpose. There is no filler or redundant content.
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 read-only tool with one parameter, an output schema, and clear annotations, the description is mostly sufficient. It lacks explicit usage context vs. sibling tools, but the schema and annotations cover most operational needs.
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 the single post_url parameter is thoroughly documented, including what to pass and what to avoid. The tool description itself does not add parameter semantics, so 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 action and resource: get public post details via an Instagram post URL. The name and description together distinguish it from siblings like instagram_get_post_detail_by_post_id by specifying the URL-based input.
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 the tool is for retrieving post details when given a post URL, but it does not explicitly state when to prefer this over alternatives such as by_post_id or when not to use it. The param schema gives URL formatting guidance but no tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_user_info_by_profile_urlA根据 Instagram 用户主页链接获取公开用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes | Instagram 用户主页链接；从搜索、详情、评论或评论回复结果的 author.profile_url 原样复制；或传用户提供的 Instagram 用户主页链接；不要传帖子链接、评论链接、接口地址或包含链接的分享文案。 |
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户个人简介；没有简介时为空字符串。 |
| name | Yes | 用户展示名；不是 username；不可用时为空字符串。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| user_id | Yes | Instagram 用户稳定数字 ID；不可用时为空字符串。 |
| username | Yes | Instagram 用户名，不带 @；不可用时为空字符串。 |
| avatar_url | Yes | 高清头像链接；不可用时为 null。 |
| is_private | Yes | 是否私密账号；不可用时为 null。 |
| post_count | Yes | 已发布帖子数；不可用时为 null。 |
| is_verified | Yes | 是否认证；不可用时为 null。 |
| profile_url | Yes | 用户主页链接；不可用时为 null。 |
| external_url | Yes | 主页外部链接中的主链接；没有外部链接时为 null。 |
| external_links | Yes | 主页外链列表，包含可用的多个主页外部链接；无外链时为空数组。 |
| follower_count | Yes | 粉丝数；不可用时为 null。 |
| following_count | Yes | 关注数；不可用时为 null。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it retrieves public information, which aligns with the readOnlyHint annotation. It adds clarity about the data scope, though it doesn't mention potential errors or limitations for private accounts, which is acceptable given the annotations already indicate read-only behavior.
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, concise sentence that immediately conveys the tool's purpose without unnecessary detail. It is well-structured and front-loaded.
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 description is sufficient for the tool's simplicity. Given that an output schema exists, the description does not need to explain return values. It adequately covers the tool's scope and constraints, though it could mention edge cases, but that is not essential here.
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 tool description itself does not elaborate on the parameter, but the input schema provides a detailed description of profile_url, including sources and exclusions. Since schema coverage is high, the description adds no additional meaning, warranting the baseline score.
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's function: getting public user information based on an Instagram profile URL. It distinguishes from sibling tools that operate on usernames or post IDs, making the purpose specific and unambiguous.
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 and the parameter guidance provide clear instructions on what to pass (e.g., author.profile_url) and what not to pass (links to posts, comments, API endpoints). While it doesn't explicitly compare with sibling tools, the name and purpose make it obvious when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_user_info_by_usernameA根据 Instagram 用户名获取公开用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Instagram 用户名，不带 @；从搜索、详情、评论或评论回复结果的 author.username 原样复制；不要传用户主页链接、帖子链接、评论链接或分享文案。 |
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户个人简介；没有简介时为空字符串。 |
| name | Yes | 用户展示名；不是 username；不可用时为空字符串。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| user_id | Yes | Instagram 用户稳定数字 ID；不可用时为空字符串。 |
| username | Yes | Instagram 用户名，不带 @；不可用时为空字符串。 |
| avatar_url | Yes | 高清头像链接；不可用时为 null。 |
| is_private | Yes | 是否私密账号；不可用时为 null。 |
| post_count | Yes | 已发布帖子数；不可用时为 null。 |
| is_verified | Yes | 是否认证；不可用时为 null。 |
| profile_url | Yes | 用户主页链接；不可用时为 null。 |
| external_url | Yes | 主页外部链接中的主链接；没有外部链接时为 null。 |
| external_links | Yes | 主页外链列表，包含可用的多个主页外部链接；无外链时为空数组。 |
| follower_count | Yes | 粉丝数；不可用时为 null。 |
| following_count | Yes | 关注数；不可用时为 null。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. The description adds only the 'public' scope, with no extra behavior like rate limits, error cases, or data freshness. No contradiction with 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 one short, direct sentence that immediately conveys the tool's purpose. There is no filler, repetition, or unnecessary detail.
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-only lookup tool with a rich input schema and an output schema present, the description is largely complete. The main missing element is explicit guidance about when to use the username variant versus the profile-URL variant, so it is not a perfect 5.
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 covers the username parameter with 100% coverage and provides detailed guidance about stripping '@', copying from author.username, and not passing links. The tool description itself adds no parameter semantics, so the schema carries the burden; 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 action ('获取' / get) and the resource ('公开用户信息' / public user info) scoped by 'Instagram 用户名' (username). The tool name and description together distinguish it from the sibling tool that uses a profile URL.
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 gives no guidance on when to choose this tool over alternatives such as instagram_get_user_info_by_profile_url or instagram_get_user_posts_by_username. It does not state exclusions or switching conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_user_posts_by_profile_urlA根据 Instagram 用户主页链接分页获取该用户发布的公开帖子列表。
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | Instagram 用户帖子列表分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户帖子列表链路；更换 username 或 profile_url 时，请清空 page_token 后从第一页重新读取。 | |
| profile_url | Yes | Instagram 用户主页链接；从用户信息结果的 profile_url，或搜索、详情、评论、评论回复结果的 author.profile_url 原样复制；也可传用户提供的 Instagram 用户主页链接；不要传帖子链接、评论链接、接口地址或包含链接的分享文案。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页该用户发布的 Instagram 帖子列表；当前页可能为空，是否可继续翻页以 next_page_token 是否为空为准。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前用户帖子列表续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已表明 readOnlyHint=true 和 openWorldHint=true，描述进一步说明返回的是分页列表，且仅包含公开帖子，为代理提供了注解之外的行为上下文。但描述未说明分页大小、限流或其他边界情况，部分留白。
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?
主体描述高度简洁，一句完成；参数注释虽长但包含大量关键约束（如不得修改令牌），属于高密度、高价值信息，没有冗余。
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?
对于带分页的只读列表工具，描述加参数说明已覆盖绝大多数使用场景，且具有输出 schema 和良好的注解支撑；略微欠缺的是对分页大小、排序方式或可能出错情形的说明，但整体已相当完整。
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 描述覆盖率 100%，已对 profile_url 和 page_token 分别进行了详细说明，包括来源、格式要求以及使用注意点（如不得修改令牌、换页需传回等）。描述额外补充了 page_token 的不透明性和有效期上下文，信息量足。
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?
描述明确说明工具功能：“根据 Instagram 用户主页链接分页获取该用户发布的公开帖子列表”，动词（获取）+ 资源（用户公开帖子列表）+ 分页方式（按主页链接），且与兄弟工具（如按用户名获取、搜索等）区分明显。
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?
描述清楚说明何时使用：当有用户主页链接时需要分页获取公开帖子列表；同时隐含不使用本工具的条件（如不具备链接时应使用其他工具），page_token 的详细使用说明也帮助代理正确使用。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_get_user_posts_by_usernameA根据 Instagram 用户名分页获取该用户发布的公开帖子列表。
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Instagram 用户名，不带 @；从用户信息结果的 username，或搜索、详情、评论、评论回复结果的 author.username 原样复制；不要传用户主页链接、帖子链接、评论链接或分享文案。 | |
| page_token | No | Instagram 用户帖子列表分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户帖子列表链路；更换 username 或 profile_url 时，请清空 page_token 后从第一页重新读取。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页该用户发布的 Instagram 帖子列表；当前页可能为空，是否可继续翻页以 next_page_token 是否为空为准。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前用户帖子列表续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so transparency is 3 baseline. The description adds useful pagination behavior (token must be exact, reset on username change), which raises it to 4. No contradiction.
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?
Description is a single clear sentence for purpose, and parameter details are embedded in schema where they belong. No fluff, information dense and front-loaded.
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 read-only paginated list tool with output schema, annotations cover safety, and description covers invocation and pagination rules. Complete for agent selection and correct 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 covers 100% of parameters, so baseline is 3. Description adds significant value: explains username format (no @, not links) and gives explicit rules for page_token usage (opaque, must be exact, clear on user change). This goes beyond schema descriptions, hence 4.
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 specifies fetching a paginated list of public posts for a given Instagram username, clearly distinguishing it from the sibling tool that uses profile_url.
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 explicit pagination usage (page_token must be passed back unchanged, must be cleared when switching usernames) and clarifies username source (author.username from other endpoints, not links). This effectively guides when to use and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
instagram_search_postsA按搜索词搜索 Instagram 公开帖子。用户需要按搜索词查找帖子时使用；已有帖子链接时使用帖子详情或评论工具；已有 post_id 时使用按 ID 详情工具，需要评论时复用详情结果中的 share_url；已有用户主页链接或 username 时使用用户信息或用户帖子工具；支持 page_token 翻页。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Instagram 帖子搜索词，可传关键词或短语，例如品牌名、话题、人物名或内容需求；不要传帖子链接、用户主页链接、post_id、username 或 page_token。 | |
| page_token | No | Instagram 搜索分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一关键词链路。更换关键词时，请清空 page_token 后从第一页重新搜索。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页 Instagram 搜索结果列表；当前页可能为空，是否可继续翻页以 next_page_token 是否为空为准。 |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于当前搜索续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description need not repeat that. The description adds value by explaining that the search returns public posts and that pagination with page_token must be used for further pages. It also clarifies that the token must be passed back unchanged and that it's only valid for the same keyword chain. This goes beyond annotations but could be slightly more explicit about what result data contains (though output schema exists). Given annotations cover safety, a 4 is appropriate; no contradiction found.
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 dense paragraph with front-loaded purpose and usage conditions. It is efficient but a bit packed; splitting into shorter sentences could improve scannability. However, every sentence contributes value; no filler. Slightly less than perfect due to density, but well-structured overall.
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 has output schema (so return values are covered there), 2 parameters with full schema coverage, and annotations for safety, the description covers the essential usage context: when to use, how to paginate, and what not to pass as keyword. It falls short of 5 because it does not explicitly mention that search results may be time-limited or that pagination has a limit, but with the existing structured data, the description is largely complete.
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 meaning for keyword by specifying what NOT to pass (post links, user links, post_id, username, page_token) and for page_token by detailing the opaque nature, chain validity, and handling on keyword change. This goes beyond the schema's basic descriptions, so it exceeds baseline 3.
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 states a specific verb+resource: '按搜索词搜索 Instagram 公开帖子' (search Instagram public posts by search term). It clearly distinguishes from siblings by listing alternatives: use post detail for existing post links, user info tools for profile URLs or usernames, etc. This differentiates from all sibling tools effectively.
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 provides explicit when-to-use guidance: '用户需要按搜索词查找帖子时使用' (use when user needs to find posts by search term). It also gives clear exclusions: use other tools for post links, post_id, user profile links, or usernames. It further specifies pagination usage with page_token and warns against reusing tokens across different keywords, which is crucial practical guidance.
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!
socialdatax_get_points_balanceAQuery the current API Key account's SocialDataX points balance.
No parameters
Output Schema
No output parameters
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly and openWorld, and the description is fully consistent with these traits. No additional behavioral disclosure is needed for a simple query 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?
The description is a single concise sentence that directly conveys the tool's purpose without unnecessary words or complexity.
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 straightforward query tool with no parameters and an existing output schema, the description is complete. It specifies the exact subject (current API key's SocialDataX points balance) and action (query), covering all needed context.
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?
There are no parameters, so the description does not need to explain any input semantics. The empty schema is sufficient.
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 action (query) and the resource (points balance) for the current API key. It is specific and distinct from the sibling tools, which focus on Instagram data.
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?
While it does not explicitly mention alternatives, the tool is the only one for points balance, so its usage is implicitly clear. It could benefit from noting that it is the sole method to check balance, but the context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.