Skip to main content
Glama
subzeroid

HikerAPI — Instagram MCP

get_v2_user_highlights

Read-only

Retrieve an Instagram user's saved story highlights by user ID, one page per call, and paginate with next_page_id.

Instructions

List an Instagram user's story highlights (saved story collections) by user id, one page per call. Use get_v2_highlight_by_id to open one highlight and get_v2_user_highlights_by_username when you only have a handle. For the next page pass next_page_id from the previous response as page_id (amount is ignored). Live request to Instagram, billed as 2 requests per call. (GET /v2/user/highlights)

Input Schema

NameRequiredDescriptionDefault
forceNoSkip account privacy check
amountNoDeprecated and ignored. Use page_id / next_page_id to paginate.
page_idNoUse value of field `next_page_id` from response for getting next page
user_idYes
safe_intNoConvert all big integers to strings

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • addedInput schema / properties / amount / deprecated
      Added value: +true
    • addedInput schema / properties / amount / description
      Added value: +"Deprecated and ignored. Use page_id / next_page_id to paginate."
    • addedInput schema / properties / page_id
      Added value: +{
      +  "default": "",
      +  "description": "Use value of field `next_page_id` from response for getting next page",
      +  "title": "Page Id",
      +  "type": "string"
      +}
    • addedInput schema / properties / safe_int
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Convert all big integers to strings",
      +  "title": "Safe Int"
      +}
  2. First observedv1.0.2

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds useful context beyond that: it is a live request to Instagram, billed as 2 requests per call, and pagination works one page per call with `amount` ignored.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then efficiently covers alternatives, pagination, billing, and the endpoint. Every sentence earns its place with no wasted wording.

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

Completeness5/5

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

For a paginated list endpoint with no output schema, the description provides enough context: what is returned at a high level, how to paginate, when to use sibling tools, and the live-request billing model. Annotations cover the safety profile.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents most parameters. The description reinforces the `user_id` and `page_id`/`next_page_id` flow, but it does not add meaning beyond the schema for parameters like `force` or `safe_int`.

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

Purpose5/5

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

The description states a specific verb and resource: list an Instagram user's story highlights by user id. It distinguishes this tool from siblings by naming `get_v2_highlight_by_id` for opening a single highlight and `get_v2_user_highlights_by_username` for handle-only lookups.

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

Usage Guidelines5/5

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

It explicitly names alternatives and the conditions that select them: use `get_v2_highlight_by_id` to open one highlight and `get_v2_user_highlights_by_username` when you only have a handle. It also gives pagination instructions for continuing to the next page.

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