SocialCrawl

Estimate Credit Cost

socialcrawl_estimate

Read-onlyIdempotent

Exact credits before you spend: one call (id, platform+resource or path, plus the params you will send; calls for a job total; items for a walk) or a plan of several calls. Uses the API's estimator when available, else the bundled pricing. A platform slug gives its price table; no id gives the pricing overview. Free.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	'platform/resource'; a platform slug for its price table; none for the overview.
`body`	No	POST body, for batch endpoints.
`plan`	No	Several calls to total, instead of id.
`calls`	No	Number of such calls (an array is read as plan).
`items`	No	Rows wanted (prices a walk).
`method`	No
`params`	No	The exact params you will send.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`fix`	No
`code`	No
`plan`	No
`quote`	No	hold, min/max, calls, total_hold; valid/rejection from the API.
`reason`	No
`source`	No
`warnings`	No
`retryable`	No	Never retry a 402.
`did_you_mean`	No
`retry_after_s`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 4, 2026

changedInput schema / properties / calls / description

Previous value: -"Number of such calls."New value: +"Number of such calls (an array is read as plan)."

changedOutput schema / properties / source / enum

Previous value: -[
-  "api",
-  "local"
-]New value: +[
+  "api",
+  "api+walk",
+  "local"
+]

AddedOct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: the estimate itself is 'Free' (no credit cost), and the result comes from the API's estimator when available, falling back to bundled pricing — an accuracy/source disclosure 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.

Conciseness4/5

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

The value proposition ('Exact credits before you spend') is front-loaded, and the whole definition is a single tight sentence with no filler. The parenthetical is heavily compressed and reads as telegraphic, which slightly hurts parseability, but nothing is wasted.

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?

With an output schema present, the description need not explain return values, and it covers the key agent-relevant facts: what it costs (free), what inputs it accepts, and how the number is sourced. Given 7 optional parameters and rich annotations, it is nearly complete; only explicit routing versus the execution sibling is left implicit.

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 86%, so the schema already documents id, plan, calls, items, method, params and body. The description restates those same meanings ('calls for a job total; items for a walk', 'the params you will send') without adding format, syntax, or constraint detail, so it sits at the baseline for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource — estimating exact credit cost before spending — and the 'before you spend' framing implicitly separates it from the sibling that actually executes a request (socialcrawl_request). It is clear what the tool does, but it never explicitly names or contrasts a sibling, so it stops short of a 5.

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 gives clear usage context (pre-flight cost check, 'Exact credits before you spend'), and it lays out the supported input modes: a single call via id/calls/items, or a multi-call plan. However, it names no alternative tool and states no when-not conditions, so no exclusions are provided.

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

All SocialCrawl tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.