Skip to main content
Glama
subzeroid

HikerAPI — Instagram MCP

by subzeroid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_v2_story_by_url

Read-only

Fetch a single Instagram story using its URL to retrieve story data. For /s/ share links, resolve them first with the share resolver.

Instructions

Get one Instagram story by its link. For share links that contain /s/, call get_v1_share_by_url first to resolve them. Use get_v2_story_by_id when you have the id. Live request to Instagram, billed per call. (GET /v2/story/by/url)

Input Schema

NameRequiredDescriptionDefault
urlYes
safe_intNoConvert all big integers to strings

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.1
    • 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.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds real value beyond that: it is a live request to Instagram billed per call, which is a cost/latency signal the annotations do not carry.

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?

Four tight sentences, front-loaded with the core action, followed by routing, cost, and endpoint. Every sentence earns its place and the endpoint is a bonus for verification.

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

Completeness4/5

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

For a read-only, open-world lookup with no output schema, the description covers action, alternatives, and cost. It could say more about what a returned story contains or error/auth behavior, but it is largely sufficient for correct invocation.

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 50%: safe_int is documented in the schema but url has no description field. The description adds only that the input is a story 'link' and notes the /s/ share-link caveat, which is useful but thin relative to the undocumented url format expectations. Baseline 3 fits.

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?

States a specific verb (Get), resource (one Instagram story), and access path (by its link), and explicitly distinguishes itself from get_v2_story_by_id. An agent can tell it apart from the many sibling getters without opening the schema.

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?

Gives explicit routing: resolve /s/ share links via get_v1_share_by_url first, and use get_v2_story_by_id when an id is available. When-to-use and when-to-use-alternatives are both present.

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

Deploy Server

Other Tools