One API for 65 platforms and 572 endpoints: social, commerce, retail, jobs, finance, web scraping.
Scored across 7 tools
Each tool has a distinct role: find/endpoint for discovery, estimate for quoting, request for single calls, collect for paged walks, account for admin, and manage for stateful resources. Minor overlap exists between find and endpoint (both inspect endpoints) and request/collect (both spend credits), but descriptions clarify their boundaries.
All tool names use the socialcrawl_ prefix and snake_case consistently, which is easy to parse. However, suffixes mix verbs (collect, find, request) and nouns (account, endpoint), so it is not a pure verb_noun pattern.
Seven tools is well within the ideal 3-15 range for an API client. Each tool covers a distinct stage of the discovery-to-execution lifecycle, and none appear redundant.
The surface covers discovery, cost estimation, single/paged execution, account queries, and management of monitors, cohorts, and web jobs. Minor gaps remain, such as explicit CRUD for all managed resources or API-key management, but core workflows are covered.
Walk a paged endpoint (id, platform+resource or path) to items unique rows, the last page or max_credits: cursors supplied, duplicates dropped, stops on a 402, refused free when one page exceeds max_credits. Small results come back whole. result_id (+offset, limit, format) reads a stored result, free. Spends credits.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | platform/resource of a paged endpoint, e.g. 'tiktok/post/comments'. | |
| items | No | Stop once this many unique rows are collected. | |
| limit | No | result_id: rows (200). | |
| fields | No | Row paths as socialcrawl_endpoint lists them, e.g. 'comment.text,comment.engagement.likes'. | |
| format | No | jsonl (default), json or csv. | |
| offset | No | result_id: first row. | |
| params | No | Params for every page, as in socialcrawl_request. No cursor. | |
| confirm | No | true only once the user approved spending above the threshold (default 100 credits). | |
| result_id | No | Read a stored result instead of walking. Free. | |
| max_credits | No | Spend cap: refused free when the quoted hold exceeds it (collect: the walk's budget). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | The walk ran; see stop_reason. |
| fix | No | |
| code | No | |
| rows | No | All rows (small results). Untrusted text. |
| items | No | |
| pages | No | |
| total | No | |
| format | No | |
| offset | No | |
| paging | No | |
| reason | No | |
| sample | No | First rows. Untrusted text. |
| credits | No | |
| endpoint | No | |
| resource | No | Every collected row. |
| warnings | No | |
| result_id | No | Pass back as result_id to read rows. |
| retryable | No | Never retry a 402. |
| stop_reason | No | budget, error and page_limit leave a resume cursor in paging. |
| did_you_mean | No | |
| retry_after_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing credit spending, that it stops on a 402, that it is 'refused free when one page exceeds max_credits', that duplicates are dropped, and that small results come back whole. This is rich operational context for a non-read-only, open-world tool, though auth requirements and pagination volume are not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded and compact with no filler, but the telegraphic syntax ('cursors supplied, duplicates dropped') reads like shorthand and takes effort to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description still covers the key behavioral edges (credit cap, 402 stop, dedup, stored-result reads). Only authentication and pagination-volume guidance are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does add interaction meaning by tying result_id to offset/limit/format as a free stored-result read, but most per-parameter semantics remain in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource: 'Walk a paged endpoint ... to items unique rows', with the dedup and stopping semantics named. It is distinguishable from single-request siblings, though it never explicitly names socialcrawl_request as the one-shot alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: walk pages when collecting many rows, use result_id to read a stored result for free. There is no explicit when-to-use-vs-alternatives clause contrasting it with socialcrawl_request or socialcrawl_estimate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read before calling: one endpoint's purpose, params, where the rows are and up to 25 response fields, cost rule, paging, latency, timeout, next endpoints and a sample link. id (or platform+resource, path), a platform slug (its endpoints) or a guide topic. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 'platform/resource' for its contract; a platform slug for its endpoint table; or a guide topic (errors, pricing, pagination, judgments, hydration, overview). | |
| page | No | Page of a long guide (default 1). | |
| method | No | Only for an id served by several methods. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| ok | Yes | |
| fix | No | |
| code | No | |
| method | No | |
| reason | No | |
| source | No | |
| contract | No | purpose, params, outputs, cost, paging, latency_ms, timeout_s, next, sample. |
| retryable | No | Never retry a 402. |
| did_you_mean | No | |
| retry_after_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral facts 'Free', 'up to 25 response fields', and it hints at latency/timeout reporting. It does not say whether results are cached or versioned, and it does not disclose error behavior. Some added value, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening clause is a comma-separated run-on list of nine return items ('purpose, params, where the rows are and up to 25 response fields, cost rule, paging, latency, timeout, next endpoints and a sample link') before any action is named. The second and third sentences are fragments with no verb ('id (or platform+resource, path), a platform slug ... Free.'). Not front-loaded and hard to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained, and annotations cover safety. The description tries to cover contract contents, cost ('Free'), paging, latency, and routing. The gaps are the missing 'when to use vs alternatives' framing and the lack of a stated behavior for guide-topic ids versus endpoint ids. Adequate, but leaves the agent to infer the primary use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents `id` (platform/resource, platform slug, or guide topic), `page`, and `method`. The description's sentence 'id (or platform+resource, path), a platform slug (its endpoints) or a guide topic' largely restates the schema's own enum of id forms. Baseline 3 applies where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns 'one endpoint's purpose, params, where the rows are and up to 25 response fields, cost rule, paging, latency, timeout, next endpoints and a sample link' – that is a detailed inventory of return contents, but it never states the core verb+resource in a first-clause way. An agent must infer from the name and the phrase 'Read before calling' that this is a documentation/contract lookup tool rather than an API caller. The sibling `socialcrawl_estimate` and `socialcrawl_collect` are not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Read before calling' gives one contextual cue (use this before invoking a real endpoint) but does not name alternatives or state when-not-to-use. There is no explicit routing against `socialcrawl_estimate` (cost) or `socialcrawl_request` (making the call). Minimal viable – a hint, not a rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
Start here: a task in plain words -> the best endpoints (3 by default) of 646, each with the params the task supplies (URLs and @handles resolved), the params still missing, the credit cost and the exact call. With no task it lists platforms, or one platform's endpoints. Free; no key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | The job in plain words; URLs and @handles in it are resolved and filled. Omit to list platforms. | |
| limit | No | Endpoints to return (default 3). | |
| platform | No | Only this platform's endpoints (slug, e.g. 'tiktok'); alone, lists them. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| fix | No | |
| code | No | |
| note | No | |
| reason | No | |
| source | No | |
| results | No | |
| resolved | No | |
| warnings | No | |
| retryable | No | Never retry a 402. |
| uncertain | No | true: guesses, not matches; confirm with socialcrawl_endpoint. |
| confidence | No | |
| did_you_mean | No | |
| match_source | No | The API's ranker, e.g. lexical. |
| retry_after_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so this adds value on other axes: free of charge, no API key required, and it discloses that URLs and @handles in the task are resolved and filled, plus that credit cost is reported. It stops short of describing result freshness, limits on the resolution step, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the essential routing instruction ('Start here'), then packs the output contract, the fallback modes, and cost/auth facts into a single dense but waste-free pair of sentences. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description usefully previews what comes back (endpoints, supplied params, missing params, credit cost, the call) and covers both input modes. Minor gaps remain around what 'the exact call' means operationally and how the resolution of URLs/@handles behaves on failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters, including that omitting 'task' lists platforms and that 'limit' defaults to 3. The description largely restates this rather than adding new parameter meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (find), resource (endpoint) and input form (a task in plain words), plus the scale of the catalog (3 of 646). The phrase 'Start here' and the fact that it returns 'the exact call' rather than results positions it clearly against executor siblings like socialcrawl_endpoint and socialcrawl_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: when you have a plain-word task, when you have no task (lists platforms), and when you supply only a platform (lists that platform's endpoints). It does not, however, explicitly name the alternative tool to call once the endpoint is identified, nor state any when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stateful work by area + action: monitors (scheduled recipes, webhooks, alerts), cohorts (mention search over your own panel of accounts), web (scrape, search, crawl and agent jobs, change monitors, browser sessions) and jobs (Prism background jobs). A wrong field is refused free with the rules. Managing is free; scrapes, jobs, queries and monitor runs bill credits. dry_run: true validates and quotes a create/update and never creates it. rows_new alerts need track (id=monitors).
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Monitor, cohort, query, web job/monitor/session or prism job id. | |
| area | Yes | What to manage. | |
| input | No | The action's fields, e.g. { recipe, cadence }, { url }, { keywords }, or the job body (max_credits, confirm allowed). Monitor alert rules, incl. rows_new: socialcrawl_endpoint id=monitors. | |
| action | Yes | monitors: create|list|get|runs|timeseries|pause|resume|delete. cohorts: create|add_members|estimate_cost|query|query_status|query_results|query_cancel|get|delete. web: scrape|search|map|extract|crawl|batch_scrape|agent|crawl_preview|job_get|job_list|job_cancel|job_errors|monitor_*|session_*. jobs: submit|list|get. | |
| dry_run | No | ||
| idempotencyKey | No | For web crawl/batch, cohort writes and job submit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is known. The description adds genuinely non-structured context: the cost model (managing free; scrapes, jobs, queries and monitor runs bill credits), the validation contract (a wrong field is refused free), and the dry-run preview semantics. It stops short of 5 because it never explains what a delete or pause actually destroys, nor idempotency-key semantics beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
It front-loads the area taxonomy before cost and dry-run details, and packs a lot of operational guidance into roughly three sentences. The trailing fragment 'rows_new alerts need track (id=monitors)' is terse and somewhat cryptic, but overall the text is dense rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex four-area dispatcher with no output schema, the description covers the area map, cost model, dry-run and validation. It omits how async actions are chained (e.g. polling query_status or job_get) and what the actions return, so it is helpful but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), so the baseline is 3, and the schema covers area/action/id/input/idempotencyKey. The description adds real value on top by defining dry_run behavior in prose (the schema leaves dry_run undescribed) and by hinting at the shape of the input payload. It does not clarify the idempotencyKey usage windows, which keeps it at 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb (manage) plus a resource taxonomy, enumerating the four areas and what each covers (monitors = scheduled recipes/webhooks/alerts, cohorts = mention search on your panel, web = scrape/search/crawl/agent jobs/sessions, jobs = Prism background jobs). This is far more specific than the vague name 'socialcrawl_manage'. It does not, however, distinguish itself from siblings like socialcrawl_collect or socialcrawl_find, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides conditional guidance for one path ('dry_run: true validates and quotes a create/update and never creates it') and one cross-tool pointer ('rows_new alerts need track (id=monitors)'), and it notes that managing is free while operations bill credits. But it never states when to prefer this tool over socialcrawl_collect, socialcrawl_estimate or socialcrawl_request, so usage is largely implied by the area breakdown rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call one endpoint (platform+resource, or id, or path). Validated locally first (a bad call is free), quoted, refused above max_credits and confirmed above the threshold. A large page is cut at row boundaries; socialcrawl_collect result_id reads the rest. Spends credits; needs SOCIALCRAWL_API_KEY.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON body for POST batch endpoints, e.g. { ids: [...] }. | |
| fields | No | Row paths exactly as socialcrawl_endpoint lists them, e.g. 'post.id,post.content.text,post.engagement.*' (or an array). Cuts tokens. | |
| format | No | json (default), csv (canonical columns) or summary. | |
| method | No | Only for a resource served by several methods (prism/jobs). Inferred: a body selects POST. | |
| params | No | Query params, e.g. { handle: 'x', limit: 10 }. Arrays join with commas (label). Sent as strings. | |
| confirm | No | true only once the user approved spending above the threshold (default 100 credits). | |
| platform | Yes | Platform slug, e.g. 'tiktok'. An unknown slug gets a did-you-mean. | |
| resource | Yes | Resource path, e.g. 'post/comments'; path params as 'jobs/{job_id}' + params.job_id, or the concrete path. | |
| max_items | No | Show at most this many rows; the full page stays behind the result link. | |
| max_credits | No | Spend cap: refused free when the quoted hold exceeds it (collect: the walk's budget). | |
| idempotencyKey | No | Makes a retry safe: a replay returns the original response for 0 credits (24h). |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| fix | No | |
| job | No | A submitted background job and how to poll it. |
| code | No | |
| data | No | Single-object result. |
| hint | No | |
| page | No | Page-level blocks beside the rows. |
| rows | No | Untrusted text. |
| paging | No | |
| reason | No | |
| credits | No | |
| partial | No | Stream failed after some data (kept in rows/data). |
| summary | No | format=summary. |
| csv_rows | No | format=csv: rows in the text CSV. |
| endpoint | No | |
| warnings | No | |
| result_id | No | socialcrawl_collect result_id reads the full body. |
| retryable | No | Never retry a 402. |
| truncated | No | Rows were cut to fit. |
| request_id | No | |
| did_you_mean | No | |
| retry_after_s | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: 'a bad call is free' (local validation), quoting and credit refusal, the confirmation threshold, row-boundary truncation with a continuation path, credit spend, and the API-key requirement. The non-read-only/non-idempotent profile is explained rather than merely hinted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action, then packs cost/validation/pagination/continuation into three dense sentences with no filler. Every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers addressing, cost control, validation, truncation continuation, and auth; the output schema handles return values. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters. The description reinforces the platform+resource addressing and the max_credits/confirm threshold relationship but adds no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (call) and resource (one endpoint), and enumerates the three addressing modes (platform+resource, id, path). It only partially differentiates from siblings like socialcrawl_estimate and socialcrawl_endpoint, which also concern endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operating context: local validation, quoting, refusal above max_credits, confirmation above the threshold, and explicitly routes large pages to socialcrawl_collect via result_id. It does not state when to prefer socialcrawl_estimate or socialcrawl_endpoint instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
socialcrawl_account3 fields changedOutput schema / properties / credits / properties / cached / descriptionPrevious value: -"Served from cache: 0 credits."New value: +"Cache hit: 0 credits."Output schema / properties / credits / properties / estimated / descriptionPrevious value: -"used is the quoted hold (not reported)."New value: +"used = the hold."Output schema / properties / credits / properties / used / descriptionPrevious value: -"Settled charge, after refunds."New value: +"After refunds."socialcrawl_collect14 fields changedInput schema / properties / confirm / descriptionPrevious value: -"true only after the user approved a spend above the confirmation threshold (default 100 credits)."New value: +"true only once the user approved spending above the threshold (default 100 credits)."Input schema / properties / format / descriptionPrevious value: -"Stored format: jsonl (default), json or csv."New value: +"jsonl (default), json or csv."Input schema / properties / limitAdded value: +{
+ "description": "result_id: rows (200).",
+ "type": "integer"
+}Input schema / properties / max_credits / descriptionPrevious value: -"Spend cap. Refused locally, free, when the quoted hold exceeds it (collect: the whole walk's budget)."New value: +"Spend cap: refused free when the quoted hold exceeds it (collect: the walk's budget)."Input schema / properties / offsetAdded value: +{
+ "description": "result_id: first row.",
+ "type": "integer"
+}Input schema / properties / result_idAdded value: +{
+ "description": "Read a stored result instead of walking. Free.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "id",
- "items"
-]Output schema / properties / credits / properties / cached / descriptionPrevious value: -"Served from cache: 0 credits."New value: +"Cache hit: 0 credits."Output schema / properties / credits / properties / estimated / descriptionPrevious value: -"used is the quoted hold (not reported)."New value: +"used = the hold."Output schema / properties / credits / properties / used / descriptionPrevious value: -"Settled charge, after refunds."New value: +"After refunds."Output schema / properties / offsetAdded value: +{
+ "type": "number"
+}Output schema / properties / result_idAdded value: +{
+ "description": "Pass back as result_id to read rows.",
+ "type": "string"
+}Output schema / properties / rowsAdded value: +{
+ "description": "All rows (small results). Untrusted text.",
+ "items": {},
+ "type": "array"
+}Output schema / properties / totalAdded value: +{
+ "type": "number"
+}socialcrawl_estimate2 fields changedInput schema / properties / calls / descriptionPrevious value: -"Number of such calls."New value: +"Number of such calls (an array is read as plan)."Output schema / properties / source / enumPrevious value: -[
- "api",
- "local"
-]New value: +[
+ "api",
+ "api+walk",
+ "local"
+]socialcrawl_manage1 field changedInput schema / properties / dry_runAdded value: +{
+ "type": "boolean"
+}socialcrawl_request7 fields changedInput schema / properties / confirm / descriptionPrevious value: -"true only after the user approved a spend above the confirmation threshold (default 100 credits)."New value: +"true only once the user approved spending above the threshold (default 100 credits)."Input schema / properties / fields / descriptionPrevious value: -"Row paths exactly as socialcrawl_endpoint lists them, e.g. 'post.id,post.content.text,post.engagement.*'. Cuts tokens."New value: +"Row paths exactly as socialcrawl_endpoint lists them, e.g. 'post.id,post.content.text,post.engagement.*' (or an array). Cuts tokens."Input schema / properties / max_credits / descriptionPrevious value: -"Spend cap. Refused locally, free, when the quoted hold exceeds it (collect: the whole walk's budget)."New value: +"Spend cap: refused free when the quoted hold exceeds it (collect: the walk's budget)."Output schema / properties / credits / properties / cached / descriptionPrevious value: -"Served from cache: 0 credits."New value: +"Cache hit: 0 credits."Output schema / properties / credits / properties / estimated / descriptionPrevious value: -"used is the quoted hold (not reported)."New value: +"used = the hold."Output schema / properties / credits / properties / used / descriptionPrevious value: -"Settled charge, after refunds."New value: +"After refunds."Output schema / properties / result_idAdded value: +{
+ "description": "socialcrawl_collect result_id reads the full body.",
+ "type": "string"
+}socialcrawl_accountsocialcrawl_check_balancesocialcrawl_cohortssocialcrawl_collectsocialcrawl_discoversocialcrawl_endpointsocialcrawl_estimatesocialcrawl_findsocialcrawl_get_docssocialcrawl_list_endpointssocialcrawl_list_platformssocialcrawl_managesocialcrawl_monitorssocialcrawl_pricingsocialcrawl_request16 fields changedInput schema / properties / body / descriptionPrevious value: -"JSON 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."New value: +"JSON body for POST batch endpoints, e.g. { ids: [...] }."Input schema / properties / confirmAdded value: +{
+ "description": "true only after the user approved a spend above the confirmation threshold (default 100 credits).",
+ "type": "boolean"
+}Input schema / properties / fieldsAdded value: +{
+ "description": "Row paths exactly as socialcrawl_endpoint lists them, e.g. 'post.id,post.content.text,post.engagement.*'. Cuts tokens.",
+ "type": "string"
+}Input schema / properties / formatAdded value: +{
+ "description": "json (default), csv (canonical columns) or summary.",
+ "enum": [
+ "json",
+ "csv",
+ "summary"
+ ],
+ "type": "string"
+}Input schema / properties / idempotencyKey / descriptionPrevious value: -"Optional Idempotency-Key header. Lets you safely retry the same request — replays return the original response and deduct 0 credits (24h TTL)."New value: +"Makes a retry safe: a replay returns the original response for 0 credits (24h)."Input schema / properties / max_creditsAdded value: +{
+ "description": "Spend cap. Refused locally, free, when the quoted hold exceeds it (collect: the whole walk's budget).",
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / max_itemsAdded value: +{
+ "description": "Show at most this many rows; the full page stays behind the result link.",
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / method / descriptionPrevious value: -"HTTP method, only needed for a resource served by more than one (e.g. prism/jobs: GET lists your jobs, POST submits one). Inferred when omitted: sending a `body` selects the POST variant when one exists, otherwise GET."New value: +"Only for a resource served by several methods (prism/jobs). Inferred: a body selects POST."Input schema / properties / params / additionalProperties / anyOfAdded value: +[
+ {
+ "type": [
+ "string",
+ "number",
+ "boolean"
+ ]
+ },
+ {
+ "items": {
+ "$ref": "#/properties/params/additionalProperties/anyOf/0"
+ },
+ "type": "array"
+ }
+]Input schema / properties / params / additionalProperties / typeRemoved value: -"string"Input schema / properties / params / descriptionPrevious value: -"Query 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`. Cross-cutting params work here too where an endpoint declares them: `label` / `relevance` / `relevant_to` / `judgments` (row judgments), `include` (row joins), `max_pages` / `seen` / `since` / `stop_at_id` (walks and incremental polling), `dry_run=1` (free judgment cost preview), `fit=goal` + `goal` (trim the page to what a goal needs), `trim`."New value: +"Query params, e.g. { handle: 'x', limit: 10 }. Arrays join with commas (label). Sent as strings."Input schema / properties / platform / descriptionPrevious value: -"Platform slug (e.g., 'tiktok', 'instagram', 'youtube')"New value: +"Platform slug, e.g. 'tiktok'. An unknown slug gets a did-you-mean."Input schema / properties / platform / enumRemoved value: -[
- "web",
- "tiktok",
- "instagram",
- "youtube",
- "twitter",
- "linkedin",
- "facebook",
- "reddit",
- "threads",
- "pinterest",
- "twitch",
- "snapchat",
- "truthsocial",
- "telegram",
- "kick",
- "kwai",
- "tiktokshop",
- "perplexity",
- "google",
- "amazon",
- "google_shopping",
- "google_news",
- "finance",
- "google_trends",
- "trustpilot",
- "g2",
- "google_play",
- "app_store",
- "tripadvisor",
- "walmart",
- "target",
- "wayfair",
- "home_depot",
- "ebay",
- "etsy",
- "sephora",
- "aliexpress",
- "hm",
- "kohls",
- "klarna",
- "gumtree",
- "yelp",
- "utility",
- "linktree",
- "linkbio",
- "linkme",
- "komi",
- "pillar",
- "polymarket",
- "hackernews",
- "quora",
- "douyin",
- "github",
- "tavily",
- "naver",
- "rumble",
- "bluesky",
- "spotify",
- "apple_music",
- "search",
- "prism",
- "content_analysis",
- "on_page",
- "jobs",
- "us_congress_trades",
- "producthunt",
- "xiaohongshu"
-]Input schema / properties / platform / minLengthAdded value: +1Input schema / properties / resource / descriptionPrevious value: -"Resource path (e.g., 'profile', 'post/comments', 'search'). A path-param endpoint takes the template plus the value in `params` (resource 'jobs/{job_id}', params { job_id: '…' }) or the concrete path ('jobs/job_abc123')."New value: +"Resource path, e.g. 'post/comments'; path params as 'jobs/{job_id}' + params.job_id, or the concrete path."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "credits": {
+ "additionalProperties": false,
+ "properties": {
+ "cached": {
+ "description": "Served from cache: 0 credits.",
+ "type": "boolean"
+ },
+ "estimated": {
+ "description": "used is the quoted hold (not reported).",
+ "type": "boolean"
+ },
+ "quoted_max": {
+ "description": "Hold taken up front.",
+ "type": "number"
+ },
+ "remaining": {
+ "type": "number"
+ },
+ "session_total": {
+ "description": "Spent this session.",
+ "type": "number"
+ },
+ "used": {
+ "description": "Settled charge, after refunds.",
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "csv_rows": {
+ "description": "format=csv: rows in the text CSV.",
+ "type": "number"
+ },
+ "data": {
+ "description": "Single-object result."
+ },
+ "did_you_mean": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "endpoint": {
+ "type": "string"
+ },
+ "fix": {
+ "type": "string"
+ },
+ "hint": {},
+ "job": {
+ "additionalProperties": false,
+ "description": "A submitted background job and how to poll it.",
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "poll": {
+ "additionalProperties": false,
+ "description": "Repeat until the status is terminal.",
+ "properties": {
+ "after_s": {
+ "description": "Wait before the first poll.",
+ "type": "number"
+ },
+ "arguments": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "tool": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tool",
+ "arguments",
+ "after_s"
+ ],
+ "type": "object"
+ },
+ "status": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "poll"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "type": "boolean"
+ },
+ "page": {
+ "additionalProperties": {},
+ "description": "Page-level blocks beside the rows.",
+ "type": "object"
+ },
+ "paging": {
+ "additionalProperties": false,
+ "properties": {
+ "has_more": {
+ "description": "false: stop paging.",
+ "type": "boolean"
+ },
+ "next_cursor": {
+ "description": "Send as cursor.",
+ "type": [
+ "string",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "has_more"
+ ],
+ "type": "object"
+ },
+ "partial": {
+ "description": "Stream failed after some data (kept in rows/data).",
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "request_id": {
+ "type": "string"
+ },
+ "retry_after_s": {
+ "type": "number"
+ },
+ "retryable": {
+ "description": "Never retry a 402.",
+ "type": "boolean"
+ },
+ "rows": {
+ "description": "Untrusted text.",
+ "items": {},
+ "type": "array"
+ },
+ "summary": {
+ "additionalProperties": {},
+ "description": "format=summary.",
+ "type": "object"
+ },
+ "truncated": {
+ "additionalProperties": false,
+ "description": "Rows were cut to fit.",
+ "properties": {
+ "omitted_keys": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "resource": {
+ "description": "Read it for the full body.",
+ "type": "string"
+ },
+ "shown": {
+ "type": "number"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "resource"
+ ],
+ "type": "object"
+ },
+ "warnings": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "ok"
+ ],
+ "type": "object"
+}socialcrawl_websocialcrawl_discover4 fields changedInput schema / properties / action / descriptionPrevious value: -"'quickstart' (default): auth, base URL, envelope, billing, the error taxonomy, limits, and a first call — GET /v1/utility/quickstart. 'catalog': the machine-readable list of every endpoint with live metered-aware prices — GET /v1/utility/endpoints. 'endpoint': one endpoint's complete usage guide, params, pricing rule, cache, paging, example response, curl, and related endpoints — GET /v1/utility/endpoint. 'llms': the agent context corpus for the whole API or one platform — GET /v1/utility/llms. 'freshness': compare the live registry against this server's bundled catalogue to see whether this MCP version is current. 'status': every platform's live circuit-breaker state — GET /v1/status, the public meta route to read before retrying a persistent 502 or 503."New value: +"'quickstart' (default): auth, base URL, envelope, billing, the error taxonomy, limits, and a first call — GET /v1/utility/quickstart. 'capabilities': every cross-cutting parameter once (label presets per row family, relevance, judgments, include, since/stop_at_id, seen, max_pages, row filters, trim, fit, download_media) with what it does, what it costs and every endpoint that supports it — GET /v1/utility/capabilities (filter with `param`). 'plan': turn a job in plain words (`query`, e.g. 'track mentions of Acme on TikTok and Reddit') into the exact priced calls to make, in order — GET /v1/utility/plan (needs an API key; free). 'catalog': the machine-readable list of every endpoint with live metered-aware prices — GET /v1/utility/endpoints. 'endpoint': one endpoint's complete usage guide, params, pricing rule, cache, paging, example response, curl, and related endpoints — GET /v1/utility/endpoint. 'llms': the agent context corpus for the whole API or one platform — GET /v1/utility/llms. 'freshness': compare the live registry against this server's bundled catalogue to see whether this MCP version is current. 'status': every platform's live circuit-breaker state — GET /v1/status, the public meta route to read before retrying a persistent 502 or 503."Input schema / properties / action / enumPrevious value: -[
- "quickstart",
- "catalog",
- "endpoint",
- "llms",
- "freshness",
- "status"
-]New value: +[
+ "quickstart",
+ "catalog",
+ "endpoint",
+ "capabilities",
+ "plan",
+ "llms",
+ "freshness",
+ "status"
+]Input schema / properties / paramAdded value: +{
+ "description": "capabilities: return one capability only, by parameter name (e.g. 'label', 'relevance', 'seen').",
+ "type": "string"
+}Input schema / properties / queryAdded value: +{
+ "description": "plan (required): the job in plain words, e.g. 'a creator's profile, posts and comments'.",
+ "maxLength": 500,
+ "type": "string"
+}socialcrawl_get_docs1 field changedInput schema / properties / topic / descriptionPrevious value: -"Documentation topic: 'overview', 'full', 'authentication', 'credits', 'pricing' (per-endpoint costs), 'errors', 'idempotency', 'pagination', 'caching', 'hydration' (opt-in `include=` row joins), 'response-schema', 'limits', 'monitors', 'discovery', or a platform slug (e.g., 'tiktok', or 'web' for the scraping/browser surface)."New value: +"Documentation topic: 'overview', 'full', 'authentication', 'credits', 'pricing' (per-endpoint costs), 'errors', 'idempotency', 'pagination', 'caching', 'hydration' (opt-in `include=` row joins), 'judgments' (free default labels/relevance and the metered presets), 'batch-jobs' (batches and background jobs), 'response-schema', 'limits', 'monitors', 'discovery', or a platform slug (e.g., 'tiktok', or 'web' for the scraping/browser surface)."socialcrawl_list_endpoints1 field changedInput schema / properties / platform / enumPrevious value: -[
- "web",
- "tiktok",
- "instagram",
- "youtube",
- "twitter",
- "linkedin",
- "facebook",
- "reddit",
- "threads",
- "pinterest",
- "twitch",
- "snapchat",
- "truthsocial",
- "telegram",
- "kick",
- "kwai",
- "tiktokshop",
- "perplexity",
- "google",
- "amazon",
- "google_shopping",
- "google_news",
- "finance",
- "google_trends",
- "trustpilot",
- "g2",
- "google_play",
- "app_store",
- "tripadvisor",
- "walmart",
- "target",
- "wayfair",
- "home_depot",
- "ebay",
- "etsy",
- "sephora",
- "aliexpress",
- "hm",
- "kohls",
- "klarna",
- "gumtree",
- "yelp",
- "utility",
- "linktree",
- "linkbio",
- "linkme",
- "komi",
- "pillar",
- "polymarket",
- "hackernews",
- "quora",
- "douyin",
- "github",
- "tavily",
- "naver",
- "rumble",
- "bluesky",
- "spotify",
- "apple_music",
- "search",
- "prism",
- "content_analysis",
- "on_page",
- "jobs",
- "us_congress_trades"
-]New value: +[
+ "web",
+ "tiktok",
+ "instagram",
+ "youtube",
+ "twitter",
+ "linkedin",
+ "facebook",
+ "reddit",
+ "threads",
+ "pinterest",
+ "twitch",
+ "snapchat",
+ "truthsocial",
+ "telegram",
+ "kick",
+ "kwai",
+ "tiktokshop",
+ "perplexity",
+ "google",
+ "amazon",
+ "google_shopping",
+ "google_news",
+ "finance",
+ "google_trends",
+ "trustpilot",
+ "g2",
+ "google_play",
+ "app_store",
+ "tripadvisor",
+ "walmart",
+ "target",
+ "wayfair",
+ "home_depot",
+ "ebay",
+ "etsy",
+ "sephora",
+ "aliexpress",
+ "hm",
+ "kohls",
+ "klarna",
+ "gumtree",
+ "yelp",
+ "utility",
+ "linktree",
+ "linkbio",
+ "linkme",
+ "komi",
+ "pillar",
+ "polymarket",
+ "hackernews",
+ "quora",
+ "douyin",
+ "github",
+ "tavily",
+ "naver",
+ "rumble",
+ "bluesky",
+ "spotify",
+ "apple_music",
+ "search",
+ "prism",
+ "content_analysis",
+ "on_page",
+ "jobs",
+ "us_congress_trades",
+ "producthunt",
+ "xiaohongshu"
+]socialcrawl_pricing5 fields changedInput schema / properties / action / descriptionPrevious value: -"'overview' (default): the tier ladder, every free endpoint, every flat override, every metered band with its rule, cache TTLs, and the refund matrix. 'endpoint': one endpoint's exact price, metered rule, price-driving params, row joins, and worst case (needs platform + resource) — add `include`/`rows` for an exact quote instead of a band. 'platform': the cost table for one platform (needs platform). 'list': rank/filter endpoints by price across platforms. 'hydration': every `include=` row join in the API, what each one fills, what it costs per row and what a fully-joined page holds (optionally scoped with `platform`)."New value: +"'overview' (default): the tier ladder, every free endpoint, every flat override, every metered band with its rule, judgments, cache TTLs, and the refund matrix. 'endpoint': one endpoint's exact price, metered rule, price-driving params, row joins, judgments, cost levers and worst case (needs platform + resource) — add `params` (the exact query you will send) and `calls` for an itemised hold and a whole-job budget. 'platform': the cost table for one platform (needs platform). 'list': rank/filter endpoints by price across platforms. 'hydration': every `include=` row join, what each fills, its per-row rate and what a fully-joined page holds. 'judgments': every endpoint with free default labels/relevance, which presets are metered, and the hold each opt-in takes (optionally scoped with `platform`)."Input schema / properties / action / enumPrevious value: -[
- "overview",
- "endpoint",
- "platform",
- "list",
- "hydration"
-]New value: +[
+ "overview",
+ "endpoint",
+ "platform",
+ "list",
+ "hydration",
+ "judgments"
+]Input schema / properties / callsAdded value: +{
+ "description": "endpoint: how many such calls you plan (e.g. 200 profiles), for a whole-job budget.",
+ "maximum": 1000000,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / paramsAdded value: +{
+ "additionalProperties": {
+ "type": "string"
+ },
+ "description": "endpoint: the exact query params you intend to send (e.g. { include: 'engagement', label: 'mention', brand: 'Acme', max_pages: '3' }). Returns an itemised hold — the page, each join, each metered judgment — multiplied by `max_pages`. Costs nothing to ask.",
+ "type": "object"
+}Input schema / properties / platform / enumPrevious value: -[
- "web",
- "tiktok",
- "instagram",
- "youtube",
- "twitter",
- "linkedin",
- "facebook",
- "reddit",
- "threads",
- "pinterest",
- "twitch",
- "snapchat",
- "truthsocial",
- "telegram",
- "kick",
- "kwai",
- "tiktokshop",
- "perplexity",
- "google",
- "amazon",
- "google_shopping",
- "google_news",
- "finance",
- "google_trends",
- "trustpilot",
- "g2",
- "google_play",
- "app_store",
- "tripadvisor",
- "walmart",
- "target",
- "wayfair",
- "home_depot",
- "ebay",
- "etsy",
- "sephora",
- "aliexpress",
- "hm",
- "kohls",
- "klarna",
- "gumtree",
- "yelp",
- "utility",
- "linktree",
- "linkbio",
- "linkme",
- "komi",
- "pillar",
- "polymarket",
- "hackernews",
- "quora",
- "douyin",
- "github",
- "tavily",
- "naver",
- "rumble",
- "bluesky",
- "spotify",
- "apple_music",
- "search",
- "prism",
- "content_analysis",
- "on_page",
- "jobs",
- "us_congress_trades"
-]New value: +[
+ "web",
+ "tiktok",
+ "instagram",
+ "youtube",
+ "twitter",
+ "linkedin",
+ "facebook",
+ "reddit",
+ "threads",
+ "pinterest",
+ "twitch",
+ "snapchat",
+ "truthsocial",
+ "telegram",
+ "kick",
+ "kwai",
+ "tiktokshop",
+ "perplexity",
+ "google",
+ "amazon",
+ "google_shopping",
+ "google_news",
+ "finance",
+ "google_trends",
+ "trustpilot",
+ "g2",
+ "google_play",
+ "app_store",
+ "tripadvisor",
+ "walmart",
+ "target",
+ "wayfair",
+ "home_depot",
+ "ebay",
+ "etsy",
+ "sephora",
+ "aliexpress",
+ "hm",
+ "kohls",
+ "klarna",
+ "gumtree",
+ "yelp",
+ "utility",
+ "linktree",
+ "linkbio",
+ "linkme",
+ "komi",
+ "pillar",
+ "polymarket",
+ "hackernews",
+ "quora",
+ "douyin",
+ "github",
+ "tavily",
+ "naver",
+ "rumble",
+ "bluesky",
+ "spotify",
+ "apple_music",
+ "search",
+ "prism",
+ "content_analysis",
+ "on_page",
+ "jobs",
+ "us_congress_trades",
+ "producthunt",
+ "xiaohongshu"
+]socialcrawl_request4 fields changedInput schema / properties / methodAdded value: +{
+ "description": "HTTP method, only needed for a resource served by more than one (e.g. prism/jobs: GET lists your jobs, POST submits one). Inferred when omitted: sending a `body` selects the POST variant when one exists, otherwise GET.",
+ "enum": [
+ "GET",
+ "POST",
+ "PATCH",
+ "DELETE"
+ ],
+ "type": "string"
+}Input schema / properties / params / descriptionPrevious value: -"Query 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`."New value: +"Query 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`. Cross-cutting params work here too where an endpoint declares them: `label` / `relevance` / `relevant_to` / `judgments` (row judgments), `include` (row joins), `max_pages` / `seen` / `since` / `stop_at_id` (walks and incremental polling), `dry_run=1` (free judgment cost preview), `fit=goal` + `goal` (trim the page to what a goal needs), `trim`."Input schema / properties / platform / enumPrevious value: -[
- "web",
- "tiktok",
- "instagram",
- "youtube",
- "twitter",
- "linkedin",
- "facebook",
- "reddit",
- "threads",
- "pinterest",
- "twitch",
- "snapchat",
- "truthsocial",
- "telegram",
- "kick",
- "kwai",
- "tiktokshop",
- "perplexity",
- "google",
- "amazon",
- "google_shopping",
- "google_news",
- "finance",
- "google_trends",
- "trustpilot",
- "g2",
- "google_play",
- "app_store",
- "tripadvisor",
- "walmart",
- "target",
- "wayfair",
- "home_depot",
- "ebay",
- "etsy",
- "sephora",
- "aliexpress",
- "hm",
- "kohls",
- "klarna",
- "gumtree",
- "yelp",
- "utility",
- "linktree",
- "linkbio",
- "linkme",
- "komi",
- "pillar",
- "polymarket",
- "hackernews",
- "quora",
- "douyin",
- "github",
- "tavily",
- "naver",
- "rumble",
- "bluesky",
- "spotify",
- "apple_music",
- "search",
- "prism",
- "content_analysis",
- "on_page",
- "jobs",
- "us_congress_trades"
-]New value: +[
+ "web",
+ "tiktok",
+ "instagram",
+ "youtube",
+ "twitter",
+ "linkedin",
+ "facebook",
+ "reddit",
+ "threads",
+ "pinterest",
+ "twitch",
+ "snapchat",
+ "truthsocial",
+ "telegram",
+ "kick",
+ "kwai",
+ "tiktokshop",
+ "perplexity",
+ "google",
+ "amazon",
+ "google_shopping",
+ "google_news",
+ "finance",
+ "google_trends",
+ "trustpilot",
+ "g2",
+ "google_play",
+ "app_store",
+ "tripadvisor",
+ "walmart",
+ "target",
+ "wayfair",
+ "home_depot",
+ "ebay",
+ "etsy",
+ "sephora",
+ "aliexpress",
+ "hm",
+ "kohls",
+ "klarna",
+ "gumtree",
+ "yelp",
+ "utility",
+ "linktree",
+ "linkbio",
+ "linkme",
+ "komi",
+ "pillar",
+ "polymarket",
+ "hackernews",
+ "quora",
+ "douyin",
+ "github",
+ "tavily",
+ "naver",
+ "rumble",
+ "bluesky",
+ "spotify",
+ "apple_music",
+ "search",
+ "prism",
+ "content_analysis",
+ "on_page",
+ "jobs",
+ "us_congress_trades",
+ "producthunt",
+ "xiaohongshu"
+]Input schema / properties / resource / descriptionPrevious value: -"Resource path (e.g., 'profile', 'post/comments', 'search')"New value: +"Resource path (e.g., 'profile', 'post/comments', 'search'). A path-param endpoint takes the template plus the value in `params` (resource 'jobs/{job_id}', params { job_id: '…' }) or the concrete path ('jobs/job_abc123')."socialcrawl_get_docs1 field changedInput schema / properties / topic / descriptionPrevious value: -"Documentation topic: 'overview', 'full', 'authentication', 'credits', 'pricing' (per-endpoint costs), 'errors', 'idempotency', 'pagination', 'caching', 'response-schema', 'limits', 'monitors', 'discovery', or a platform slug (e.g., 'tiktok', or 'web' for the scraping/browser surface)."New value: +"Documentation topic: 'overview', 'full', 'authentication', 'credits', 'pricing' (per-endpoint costs), 'errors', 'idempotency', 'pagination', 'caching', 'hydration' (opt-in `include=` row joins), 'response-schema', 'limits', 'monitors', 'discovery', or a platform slug (e.g., 'tiktok', or 'web' for the scraping/browser surface)."socialcrawl_list_endpoints1 field changedInput schema / properties / hydratingAdded value: +{
+ "description": "Only show endpoints that can fill their own rows in the same call via an `include=` row join (e.g. a search page that can carry engagement counts). Use it to find the one call that answers a question instead of a page plus one lookup per row.",
+ "type": "boolean"
+}socialcrawl_pricing4 fields changedInput schema / properties / action / descriptionPrevious value: -"'overview' (default): the tier ladder, every free endpoint, every flat override, every metered band with its rule, cache TTLs, and the refund matrix. 'endpoint': one endpoint's exact price, metered rule, price-driving params, and worst case (needs platform + resource). 'platform': the cost table for one platform (needs platform). 'list': rank/filter endpoints by price across platforms."New value: +"'overview' (default): the tier ladder, every free endpoint, every flat override, every metered band with its rule, cache TTLs, and the refund matrix. 'endpoint': one endpoint's exact price, metered rule, price-driving params, row joins, and worst case (needs platform + resource) — add `include`/`rows` for an exact quote instead of a band. 'platform': the cost table for one platform (needs platform). 'list': rank/filter endpoints by price across platforms. 'hydration': every `include=` row join in the API, what each one fills, what it costs per row and what a fully-joined page holds (optionally scoped with `platform`)."Input schema / properties / action / enumPrevious value: -[
- "overview",
- "endpoint",
- "platform",
- "list"
-]New value: +[
+ "overview",
+ "endpoint",
+ "platform",
+ "list",
+ "hydration"
+]Input schema / properties / includeAdded value: +{
+ "description": "endpoint: the `include=` row-join tokens you intend to send (comma-separated, e.g. 'engagement' or 'engagement,channel'). Turns the quoted band into the exact hold for that call, itemised per join. Costs nothing to ask.",
+ "type": "string"
+}Input schema / properties / rowsAdded value: +{
+ "description": "endpoint: the row cap you intend to send alongside `include` (the endpoint's own `limit`). A row join holds per row, so capping the rows caps the credits — quote it before you spend it.",
+ "minimum": 1,
+ "type": "integer"
+}socialcrawl_check_balancesocialcrawl_cohortssocialcrawl_discoversocialcrawl_get_docssocialcrawl_list_endpointssocialcrawl_list_platformssocialcrawl_monitorssocialcrawl_pricingsocialcrawl_requestsocialcrawl_webSearch, extract, crawl, map, research, scrape 16 platforms, browser automation, proxy — one API key.
One API for public web data across social, directories and real estate, as clean JSON.
Hundreds of scraping & data APIs through one key. USD pay-per-request, normalized schemas, failover.
Scraping API for Google Search, Maps, Flights, Jobs, YouTube, LinkedIn, Trustpilot and more.
Add one secure layer between your agents and this server.
socialcrawl_accountAccount and Service StatusARead-onlyIdempotent Inspect
Free checks: balance (with this session's spend), transactions (itemised ledger; the receipts for one request_id), status (platform health; read it before retrying a 502/503) and freshness (whether this server's bundled catalogue is behind the API).
Output Schema
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds non-obvious traits: all four views are free (no spend), balance is scoped to this session, and status is the prerequisite for retry after 502/503. That is genuine context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the 'Free checks' hook, with each view's purpose in a compact parenthetical. Dense but organized; the parenthetical for transactions is slightly overloaded but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shapes need not be explained, and annotations cover safety. The description supplies the missing pieces an agent needs: that these calls are free, that balance is session-scoped, and that status should precede a retry. Complete enough for a zero-required-param read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already documents its view and meaning (limit = page size, cursor = next_cursor, request_id = receipts for one request). The description largely restates the view enum rather than adding syntax or format detail, so the schema does the heavy lifting and baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names four concrete read views (balance, transactions, status, freshness) and their scope, which is far more than the bare name 'socialcrawl_account' conveys. It is distinguishable from siblings like estimate/request/collect, which are about running work rather than reading state. It stops short of a single crisp verb+resource framing, but the enumeration is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit actionable guidance for one view: read status before retrying a 502/503, which is a real when-to-use rule. It also labels all checks as free, implicitly steering the agent here rather than to paid siblings. It does not state when-not-to-use or contrast against sibling tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.