Skip to main content
Glama
instagram-mcp-server

instagram-mcp-server

by qaassimq

Refresh Access Token

instagram_refresh_token

Refresh an Instagram long-lived access token for another 60 days and return the new value; save it to IG_ACCESS_TOKEN to avoid using the old token after restart.

Instructions

Extend the configured long-lived access token and return the new one.

instagram_login: refreshes an Instagram long-lived token for another 60 days. The token must be at least 24 hours old and not yet expired. facebook_login: exchanges the token for a fresh long-lived one; needs IG_APP_ID and IG_APP_SECRET.

This does NOT write the new token anywhere. Save the returned value into IG_ACCESS_TOKEN yourself, or the next restart uses the old one.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "instagram_refresh_token"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, so the agent already knows this is a non-idempotent external mutation. The description adds genuinely non-obvious context the annotations cannot convey: the new token is NOT persisted anywhere and must be written into IG_ACCESS_TOKEN by the caller, plus the 24-hour age and non-expiry preconditions. That is real added value, though it says nothing about failure modes or what happens to the previously issued token.

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

Conciseness3/5

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

The opening sentence and closing persistence warning are tight and front/back-loaded around the most important caveat. The middle three lines are formatted like descriptions of other tools rather than as guidance for this one, which creates ambiguity about whether they are alternatives, prerequisites, or a pasted toolset summary.

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?

With zero parameters and no output schema, the description carries the full burden and meets it: it states what is returned, that nothing is persisted, and the preconditions on the existing token. An agent has everything needed to call it and act on the result.

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

Parameters4/5

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies no caller-supplied input is needed by framing the token as 'configured'.

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 first sentence gives a specific verb (extend/refresh), a specific resource (the configured long-lived access token), and states the return value (the new token). An agent can immediately tell this apart from instagram_get_token_info or the publishing/comment siblings.

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

Usage Guidelines4/5

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

It names two alternative paths (instagram_login, facebook_login) and attaches the selecting conditions to each — token must be 24+ hours old and unexpired for one, IG_APP_ID/IG_APP_SECRET required for the other. It stops short of an explicit 'use this one when…' routing sentence, so the agent must infer which branch applies to its situation.

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