instagram-mcp

Overview Schema Source Related Servers Discussions Admin

Token status

instagram_token_status

Read-only

Check active Instagram credential status, including auth path, token configuration, account ID, validity, scopes, expiry, and refresh warnings.

Instructions

Report the active credential: auth path (A = ig-login / B = fb-login), whether a token is configured, the resolved account ID, and — on Path B, via debug_token — validity, granted scopes, absolute expiry and days-left (with a refresh warning as the threshold nears). Path A has no token-introspection endpoint, so its expiry is the one the login/refresh CLI recorded (IG_TOKEN_EXPIRES_AT), and unknown when none is recorded. Read-only.

Input Schema

Name	Required	Description	Default
`account`	No	Name of the configured account profile to operate as (multi-account). Omit to use the default profile (IG_ACTIVE_PROFILE).

Output Schema

Name	Required	Description
`scopes`	No	Granted scopes (Path B only).
`isValid`	No	debug_token validity (Path B only).
`profile`	Yes	Active profile name.
`warning`	No	Actionable remediation, when any applies.
`authPath`	Yes	Auth path: 'ig-login' (A) or 'fb-login' (B).
`daysLeft`	No	Whole days until expiry, when the expiry is known.
`accountId`	No	Resolved IG account ID, when known.
`expiresAt`	No	ISO 8601 absolute token expiry (Path B: debug_token; Path A: recorded expiry).
`expiryState`	Yes	Expiry state: 'unknown' \| 'never' \| 'valid' \| 'expiring_soon' \| 'expired'.
`appConfigured`	Yes	Whether Meta-app credentials (app ID) are configured.
`rateLimitBudget`	Yes	Rate-limit budget snapshot (see integration notes in the tool source).
`tokenConfigured`	Yes	Whether an access token is configured for the profile.
`dataAccessExpiresAt`	No	ISO 8601 end of the Path-B data-access window, when Meta reports one. Absent when Meta omits it or reports 0 (no data-access expiry).

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.8.0Oct 16, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / properties / dataAccessExpiresAt / description

Previous value: -"ISO 8601 end of the Path-B data-access window, when provided."New value: +"ISO 8601 end of the Path-B data-access window, when Meta reports one. Absent when Meta omits it or reports 0 (no data-access expiry)."

changedOutput schema / properties / daysLeft / description

Previous value: -"Whole days until expiry (Path B)."New value: +"Whole days until expiry, when the expiry is known."

changedOutput schema / properties / expiresAt / description

Previous value: -"ISO 8601 absolute token expiry (Path B)."New value: +"ISO 8601 absolute token expiry (Path B: debug_token; Path A: recorded expiry)."

First observedv0.7.0Aug 30, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description meaningfully adds beyond them: Path B uses debug_token for validity/scopes/expiry, while Path A has no introspection endpoint so expiry comes from the recorded IG_TOKEN_EXPIRES_AT and is 'unknown' when absent. That asymmetry is genuinely useful behavior disclosure; only permissions/rate-limit context is missing.

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

Conciseness4/5

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

It is one dense paragraph, but the core action is front-loaded and each clause (auth path, expiry source, refresh warning) carries information. The internal-mechanism detail (debug_token, IG_TOKEN_EXPIRES_AT) is slightly more than a selection decision strictly needs.

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?

An output schema exists, so return-shape explanation is not required, and annotations cover the safety profile. Combined with the explicit Path A/B distinctions and unknown-expiry caveat, an agent has everything needed to call this single-optional-parameter tool correctly.

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 100% and the single 'account' parameter is fully documented in the schema (profile name, default profile fallback). The description adds nothing about the parameter, so baseline 3 applies.

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 opens with a specific verb and resource ('Report the active credential') and enumerates exactly what is reported: auth path (A/B), token presence, account ID, validity, scopes and expiry. No sibling tool does anything comparable, so the read-token-status role is unambiguous.

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

Usage Guidelines3/5

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

Usage is only implied: the tool is clearly a diagnostic/status check, and the 'refresh warning as the threshold nears' hints at a proactive use case. However, the description never says when to call it (e.g. before publishing, or when an auth error occurs) and offers no alternatives or exclusions.

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