Skip to main content
Glama

SocialCrawl

by io.github.RidioDevelopment
OverviewDiscussionsAdmin

Make a SocialCrawl API Request

socialcrawl_request
Read-onlyIdempotent

Make an API request to any of the 575 SocialCrawl endpoints. Fetches real-time data (profiles, posts, comments, transcripts, search results, products, offers and price history, reviews, apps, places and stores, jobs and salary ranges, news, market quotes and financial statements, congressional trade disclosures, SEO audits, trends, analytics, and cross-platform Prism composites) from 65 platforms. Most endpoints are GET (pass query params in params); batch endpoints (e.g. youtube/videos, prism/profiles) are POST — pass the array/object body in body. For web scraping/crawling/browser automation use the socialcrawl_web tool instead. Requires a valid SOCIALCRAWL_API_KEY. Validates the platform, resource, required params, oneOf groups, enum values, integer ranges, parameter couplings, and CSV limits locally first, so a malformed call fails free instead of burning credits. Reports the endpoint's price (and metered rule) with every response, and on an endpoint that supports row joins it either quotes the exact hold for the include= you sent or tells you the join is available and what it costs. Pass an optional idempotencyKey to make the request retry-safe (replays return the original response and deduct 0 credits).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoJSON request body for POST batch endpoints (e.g. youtube/videos, prism/profiles). Put array/object params here — e.g. { ids: ['dQw4w9WgXcQ'] } or { items: [{ platform: 'tiktok', handle: '@scout2015' }] }. Ignored for GET endpoints. Use socialcrawl_list_endpoints to see which params belong in the body. For the web-scraping platform use the socialcrawl_web tool instead.
paramsNoQuery parameters as key-value pairs (e.g., { handle: 'charlidamelio' }). For GET endpoints these are the query string. For POST batch endpoints, put scalar query params here (e.g. { hl: 'en' }) and the array/object body in `body`.
platformYesPlatform slug (e.g., 'tiktok', 'instagram', 'youtube')
resourceYesResource path (e.g., 'profile', 'post/comments', 'search')
idempotencyKeyNoOptional Idempotency-Key header. Lets you safely retry the same request — replays return the original response and deduct 0 credits (24h TTL).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly/openWorld/idempotent/no-destructive) by disclosing local validation of platform/resource/params/oneOf/enums/CSV limits, credit pricing reported per response, join hold quoting via include=, and idempotencyKey replay semantics. These are exactly the cost/safety traits an agent needs and cannot infer from the schema.

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 core routing rule is front-loaded, but the long parenthetical enumerating data categories and the multi-clause final sentence about pricing/joins/idempotency are dense and mix several distinct behaviors into one paragraph. Useful content, but not tightly structured.

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 generic passthrough tool over 575 endpoints with no output schema, the description covers the essential contract: GET vs POST, auth requirement, local validation, cost reporting, and idempotency. It omits response shape and error format, but those are largely unknowable per-endpoint.

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 coverage is 100%, so baseline is 3. The description adds useful routing logic (scalars to params, arrays/objects to body; body ignored for GET) but restates what the schema's own property descriptions already say, so the marginal value over structured data is limited.

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+resource (make an API request to any of 575 SocialCrawl endpoints) and enumerates the data categories and 65 platforms. It explicitly distinguishes itself from socialcrawl_web for scraping/crawling/browser automation, so an agent can route correctly 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 Guidelines4/5

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

Gives clear when-to-use context (GET vs POST batch endpoints, which param goes where) and an explicit exclusion pointing to socialcrawl_web. It does not, however, direct the agent to list_endpoints/list_platforms/pricing for discovery, which would complete the routing.

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

All SocialCrawl toolsInspect
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.

Resources