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)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_id": "<user_id>"
    },
    "name": "get_v2_user_highlights"
  }
}

Input Schema

Name	Required	Description
`force`	No	Skip account privacy check
`amount`	No	Deprecated and ignored. Use page_id / next_page_id to paginate.
`page_id`	No	Use value of field `next_page_id` from response for getting next page
`user_id`	Yes
`safe_int`	No	Convert all big integers to strings

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.1Oct 5, 2026

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"
+}

First observedv1.0.2May 1, 2026

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.

Deploy Server