Skip to main content
Glama

InstaVision — Instagram niche discovery

Estimate credits for a run

estimate_credits
Read-only

Estimate a run's credit cost (min/max) without launching or spending anything. 1 credit = 1 profile scanned. Same input as launch_discovery, but creditsCap is optional: the answer states the cap it assumed. Works without an API key.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesPlaybook slug from list_playbooks.
inputYesAs for launch_discovery; creditsCap optional.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
slugNo
estimateNoCredits the run would likely spend, min to max.
creditsCapNoThe cap the estimate assumed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / input / description
      Added value: +"As for launch_discovery; creditsCap optional."
    • addedInput schema / properties / slug / description
      Added value: +"Playbook slug from list_playbooks."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "creditsCap": {
      +      "description": "The cap the estimate assumed.",
      +      "type": "number"
      +    },
      +    "estimate": {
      +      "additionalProperties": {},
      +      "description": "Credits the run would likely spend, min to max.",
      +      "properties": {
      +        "max": {
      +          "type": "number"
      +        },
      +        "min": {
      +          "type": "number"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "slug": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

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 and openWorldHint=false, so safety is covered; the description adds genuinely new context: no credits are spent, no API key is needed, and the response reports the cap it assumed. It does not cover result determinism or latency, but the added behavior detail is real.

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?

Three short sentences, front-loaded with the value proposition, then the cost model, then the input-equivalence caveat. No filler.

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 need not be explained. For a read-only estimator the description covers cost semantics, input equivalence with launch_discovery, the optional-cap nuance, and auth requirements (no API key) — everything needed to call it correctly.

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?

Schema coverage is 100% and the nested input object is fully documented, so baseline would be 3. The description adds meaning the schema does not: creditsCap is optional here (unlike launch_discovery) and the answer echoes the assumed cap, plus the unit definition '1 credit = 1 profile scanned'.

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 and resource ('Estimate a run's credit cost') with scope (min/max) and the key distinguishing property (without launching or spending anything). An agent can tell it apart from launch_discovery and the other siblings immediately.

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?

Strong implicit guidance: the tool exists to preview cost before spending, and 'Same input as launch_discovery' routes the agent between the two siblings. It never states an explicit when-not or names launch_discovery as the follow-up call, so it stops short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.