Get public profiles, posts, and feeds from Instagram, X, and TikTok through ReachSocial. Connect once and get JSON your app or agent can use.
Pay for each successful request in USDC. No subscription or prepaid credit pack.
Scored across 16 tools
Each tool targets a distinct platform+resource+granularity combination (profile vs. feed vs. single post), and descriptions explicitly cross-reference siblings (e.g. 'for one specific post, use instagram_post'). The only generic tool, get_reachsocial_request, is clearly scoped as an OAuth/payment retrieval helper rather than a data fetch. No two tools appear to do the same thing.
Nearly all tools follow a predictable snake_case platform_resource pattern (instagram_post, tiktok_feed, x_profile, youtube_video). Minor deviations exist: YouTube uses 'channel' where other platforms use 'profile', and get_reachsocial_request breaks the platform-prefix convention. These are readable and logical, not confusing.
Sixteen tools sit at the upper edge of the ideal range, but the count is justified by covering five platforms with 2-3 resource types each. It is not padded with redundant variants, though the asymmetry (some platforms get one tool, others three) makes the surface feel slightly uneven rather than bloated.
Coverage is asymmetric: Facebook has only a profile tool (no feed/post), Reddit only a post tool (no profile/feed, and comments are explicitly excluded), and there is no cross-platform search or comment retrieval anywhere. Core per-platform read paths work, but these gaps will force agents to work around missing operations.
Retrieve normalized public Facebook profile metadata. Use for one account's public profile metadata. Returns normalized public profile fields. Private, gated, and unavailable profiles return an explicit terminal result. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical public Facebook profile URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: discloses the B2B key vs OAuth paths, the $0.05 USDC payment request on Base, browser approval wait, spending/rate limits, terminal-result behavior for private/gated profiles, and idempotency retry semantics. The readOnlyHint=false is consistent with a paid, side-effecting request.
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 purpose before the payment/flow details, and nearly every sentence carries operational value. The payment paragraph is dense but justified given the multi-step OAuth flow.
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 needn't be described; the description still covers terminal results, error cases, and the follow-up get_reachsocial_request call. Nothing needed to invoke the tool correctly 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 both url and idempotency_key in detail. The description's 'preserve the idempotency_key for retries; changed input needs a new key' mostly restates the schema rather than adding new syntax or format guidance, so 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 ('Retrieve'), resource ('public Facebook profile metadata') and scope ('one account's public profile'). Sibling tools are all other platforms/resources, so an agent can route to it without opening schemas.
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 a clear use condition ('Use for one account's public profile metadata') and routes the OAuth path to get_reachsocial_request with the returned request_id. It doesn't contrast against non-profile Facebook or other-platform profile siblings, but the context and exclusions are otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an OAuth request's payment state or stored social-data result.
Use after a social-data tool returns request_id, especially after browser
payment or a lost response. Requires the same OAuth wallet and client that
created it; B2B API keys cannot retrieve OAuth requests. Missing, expired
retention, or inaccessible IDs return an error. This only reads stored work:
no provider call or payment. For awaiting_approval/reconciliation_required,
retrieve this same request again; never create a new payment to recover it.
| Name | Required | Description | Default |
|---|---|---|---|
| request_id | Yes | The exact request_id returned by a social-data tool under OAuth. Preserve this ID across browser payment and retries. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses auth requirements (same OAuth wallet and client, no B2B API keys), error behavior for missing/expired/inaccessible IDs, and the important guarantee that this only reads stored work with no provider call or payment. It also gives operational recovery guidance for specific states, which is valuable behavioral context an agent would not get from annotations alone.
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 description is front-loaded with the core purpose, followed by usage context, auth constraints, and recovery rules. Every sentence adds actionable information, and there is 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?
Given that annotations cover safety, the schema fully documents the only parameter, and an output schema exists, the description is complete enough for correct invocation. It covers purpose, prerequisites, failure modes, and the critical recovery path without redundantly explaining return values.
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 coverage is 100%, and the single request_id parameter is already fully documented with pattern, min/max length, and preservation guidance. The description does not add parameter syntax or format details beyond what the schema provides, so baseline 3 is appropriate.
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 and resource: retrieve an OAuth request's payment state or stored social-data result. It distinguishes itself from the social-data sibling tools by clarifying that this only reads stored work and does not make a provider call or payment.
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 explicitly says when to use the tool: after a social-data tool returns a request_id, especially after browser payment or a lost response. It also gives when-not and recovery guidance, including that B2B API keys cannot retrieve OAuth requests and that awaiting_approval/reconciliation_required states should be retried on the same request rather than creating a new payment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the latest normalized public posts for an Instagram profile. Use for a bounded list from one account/channel. For one specific post/video URL, use instagram_post. Returns a bounded normalized profile feed and temporary media references. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Instagram profile URL. Supply a full https:// URL, not a handle or search query. | |
| max_items | No | Maximum posts to return. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare it is not read-only, is open-world and idempotent; the description adds the actual mechanics: B2B keys bill the client immediately under spend limits, OAuth creates a $0.05 USDC request on Base and blocks on browser approval, and it enumerates failure modes (private/invalid targets, access, rate, spend limits). It also spells out idempotency retry behavior, which is the kind of context annotations cannot express.
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 purpose and the sibling exclusion, then a return-value sentence, then the billing/auth flow, then error behavior — a sensible priority order. It is dense and near the upper size limit for a description, with some payment detail that could be compressed, but each sentence carries distinct operational 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?
Given an output schema exists, the description only needs a short return summary, and it supplies one ('bounded normalized profile feed and temporary media references'). Combined with the paid-execution flow, the follow-up tool handoff, and the error envelope, an agent has everything needed to call this correctly without guessing.
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 coverage is 100%, so url, max_items, and idempotency_key are already fully documented, and the description's idempotency guidance ('preserve for retries, changed input needs a new key') largely restates the schema text. The mention of 'bounded' feed and 'temporary media references' adds only marginal parameter-level meaning, so 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 and resource ('Retrieve the latest normalized public posts for an Instagram profile') with explicit scope ('bounded list from one account/channel') and names the sibling it is not (instagram_post for a single post URL). An agent can separate it from instagram_profile, instagram_highlight, and instagram_post without opening any schema.
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 an explicit when-to-use ('bounded list from one account/channel') and an explicit alternative with its selecting condition ('For one specific post/video URL, use instagram_post'). It also tells the agent what to do after a payment-gated call ('use get_reachsocial_request with the returned request_id'), so the full flow is routed, not just the entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the saved items in one public Instagram story highlight. Use for one saved highlight; current ephemeral stories are unavailable. Returns a bounded collection from one saved highlight. Current stories remain paused. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Instagram saved-highlight URL. Supply a full https:// URL, not a handle or search query. | |
| max_items | No | Maximum highlight items to return. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the annotations: it discloses the dual execution paths (entitled B2B key vs OAuth owner wallet), the concrete $0.05 USDC charge on Base, the browser-approval wait, and that invalid/private targets and rate/spend limits surface as errors. This explains why readOnlyHint is false for what looks like a read, which the annotations alone would not convey.
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 purpose and the usage constraint, and most sentences carry distinct operational information. There is minor redundancy between 'current ephemeral stories are unavailable' and 'Current stories remain paused', which repeats the same constraint twice.
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 paid, open-world retrieval tool with an output schema already documenting return values, the description covers everything an agent needs: payment/approval flow, follow-up call to get_reachsocial_request, idempotency handling, and error conditions. Nothing critical 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 coverage is 100%, so the baseline is 3, but the description adds retry semantics ('Preserve the idempotency_key for retries; changed input needs a new key') and notes the result is a bounded collection tied to max_items. It stops short of describing the URL format beyond what the schema already states.
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 and resource ('Retrieve the saved items in one public Instagram story highlight') and explicitly scopes it away from ephemeral stories, which distinguishes it from instagram_feed and instagram_post siblings. An agent can tell exactly what it fetches 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly says when to use it ('one saved highlight') and when not ('current ephemeral stories are unavailable'), and it routes the agent to get_reachsocial_request after the OAuth path. It does not name a preferred alternative for feed-style retrieval, but the exclusions are explicit enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public Instagram post or reel metadata and source media URLs. Use for one public post/video URL. For an account's list, use instagram_feed. Returns source URLs only; ReachSocial does not download or retain media bytes. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Instagram post or reel URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that only source URLs are returned and no media bytes are downloaded or retained, that OAuth triggers a $0.05 USDC payment on Base and blocks on browser approval, that B2B calls bill against client spending limits, and which failure modes (private/unavailable targets, access, rate, spend limits) surface as errors. This is consistent with readOnlyHint=false and idempotentHint=true, since the call initiates a payment request rather than a pure read.
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?
Purpose and the sibling exclusion are front-loaded, and each subsequent sentence carries operational content (billing, OAuth wait, retries, error cases). It is dense but not padded, though the payment-flow sentence is long enough to slow scanning and could be split.
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 two-parameter tool with an output schema, the description covers everything an agent needs to call it correctly: scope, auth/billing branching, async approval handling, idempotency discipline, and error behavior. Return-value detail is correctly left to the output schema.
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 coverage is 100% and both parameters are fully documented, including the idempotency key's length rules and retry semantics. The description reinforces the single-URL restriction and the 'changed input needs a new key' rule, but that largely restates the schema rather than adding new meaning, so 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 and resource: 'Retrieve normalized public Instagram post or reel metadata and source media URLs.' It immediately delimits scope ('one public post/video URL') and names the sibling it is not ('For an account's list, use instagram_feed'), so an agent can distinguish it from instagram_feed, instagram_profile, and instagram_highlight without opening a schema.
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?
Explicit when-to-use (single public post/reel URL) and when-not (account lists go to instagram_feed). It also spells out the two execution paths — entitled B2B key vs OAuth wallet approval — and the required follow-up call to get_reachsocial_request with the returned request_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public Instagram profile metadata. Use for one account's public profile metadata. For its posts/videos, use instagram_feed. Returns a provider-neutral profile object and never downloads profile media. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Instagram profile URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains the non-obvious readOnlyHint=false: a B2B key executes immediately under client billing, while OAuth creates a $0.05 USDC payment on Base and blocks on browser approval. Also discloses no media download, idempotency retry semantics, and the specific error classes (private/unavailable/rate/spend). This goes well beyond the annotations.
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?
Purpose and the sibling routing are front-loaded, and each subsequent clause carries operational weight (billing, async, retries, errors). It is dense with some run-on billing detail, but little is genuinely removable.
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 available the description needn't describe the return shape, and it doesn't. It covers the payment/approval workflow, idempotency, and failure modes — everything an agent needs to invoke this correctly in either auth mode.
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 coverage is 100% and both parameters are fully documented in the schema, so the baseline applies. The description's note on preserving idempotency_key and using a new key for changed input largely restates what the schema already says, adding workflow emphasis rather than new semantics.
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?
Specific verb + resource: 'Retrieve normalized public Instagram profile metadata' for one account. It explicitly contrasts with instagram_feed for posts/videos, so an agent can pick between the two without opening a schema.
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?
Names the alternative (instagram_feed) and the condition that selects it, and gives the follow-up path (get_reachsocial_request with the returned request_id) for the async payment flow. When-to-use and when-not-to-use are both present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public Reddit post metadata without comments. Use for one public post/video URL. Returns normalized post text, author, engagement, and available media references. Comments are excluded. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical Reddit post URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it discloses that B2B keys bill immediately against client spending limits, that OAuth requires an approved owner wallet and creates a $0.05 USDC payment request on Base that blocks on browser approval, and that access/rate/spend limits surface as errors. This explains the real cost and side-effect model behind readOnlyHint=false, which the annotations alone would not convey.
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?
Purpose and output are front-loaded, then billing/auth mechanics, then idempotency, then error behavior — a sensible order for an agent deciding whether to call. There is minor redundancy ('without comments' followed later by 'Comments are excluded'), but every other sentence carries decision-relevant 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?
Given an output schema exists, return values need not be explained, yet the description still summarizes them. It covers auth mode differences, payment amount and chain, blocking behavior, retry semantics, and failure modes — everything an agent needs before invoking a paid, open-world call.
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 coverage is 100%, so both parameters are fully documented in the schema, and the description largely restates the idempotency guidance (preserve the key across retries, new key for changed input) rather than adding to it. The URL parameter is only implicitly referenced via 'one public post/video URL'. With the schema doing the heavy lifting, 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 ('Retrieve') and resource ('normalized public Reddit post metadata'), plus an explicit scope ('one public post/video URL') and what is returned vs. excluded (comments). The platform-specific resource plus the single-post scope makes it unmistakable against siblings such as x_post, instagram_post, or the feed tools.
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 a clear when-to-use rule ('Use for one public post/video URL') and states 'Comments are excluded', which bounds the use case. It also prescribes the follow-up step ('use get_reachsocial_request with the returned request_id') and branches usage by auth mode. What's missing is explicit named alternatives for other target types, but the guidance is otherwise actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a normalized, cursor-paginated public TikTok profile feed. Use for a bounded list from one account/channel. For one specific post/video URL, use tiktok_video. Pass next_cursor back as cursor to request another page. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical TikTok profile URL. Supply a full https:// URL, not a handle or search query. | |
| cursor | No | Opaque provider-neutral pagination cursor. Omit for the first page; copy next_cursor from the prior result for a new page with a new idempotency_key. | |
| max_items | No | Maximum videos to return. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already tell the agent this is open-world, idempotent, non-destructive, and NOT read-only; the description explains why readOnlyHint is false by disclosing the B2B billing path and the OAuth $0.05 USDC payment request that blocks execution until browser approval — genuinely additive context. It also discloses the failure surface (invalid/private targets, access/rate/spend limits) and idempotency-key reuse semantics. The remaining gap is that it never says what a pending-payment response looks like versus a completed one, leaving the agent to infer the blocking behavior from the polling instruction.
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 purpose and sibling routing, then pagination, then billing/auth, then error cases — a sensible order where each sentence carries information. It reads as a dense run-on chain touching billing, pagination, idempotency, and errors in one block; a short structural break would aid scanning, but nothing is padding.
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 shape needn't be described; what the agent cannot get from structured fields — the async payment gate, the follow-up call to get_reachsocial_request, and the key-reuse rule for retries — is covered. For a dual-auth, potentially blocking tool, this is complete enough to invoke correctly.
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 all four parameters are already documented, which sets the baseline at 3. The description restates the cursor chaining and idempotency-key rules ("changed input needs a new key") in slightly less detail than the schema itself, adding emphasis rather than new meaning.
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+resource ("Retrieve a normalized, cursor-paginated public TikTok profile feed") with scope (one account/channel, bounded list) and explicitly names tiktok_video as the tool for a single post URL. An agent can distinguish it from the video and profile siblings without opening a schema.
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 explicit when-to-use (bounded list from one account) and when-not (single post/video URL → tiktok_video), plus the pagination loop (pass next_cursor as cursor) and the post-execution handoff to get_reachsocial_request with the returned request_id. Retry/idempotency rules and error conditions are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public TikTok profile metadata. Use for one account's public profile metadata. For its posts/videos, use tiktok_feed. Returns profile metadata without retaining avatars or videos. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical TikTok profile URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that avatars/videos are not retained, that a B2B key bills immediately under client spending limits, and that OAuth creates a $0.05 USDC payment request on Base requiring browser approval. It also enumerates the failure surface (private/unavailable targets, access/rate/spend limits) and the idempotency-retry contract, none of which the annotations convey.
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 purpose and the sibling alternative before the billing and error detail, and every sentence carries new information. It is dense with seven sentences, but the payment-path and idempotency sentences are load-bearing rather than 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 shape need not be explained, and the description covers the remaining complexity: dual auth/billing paths, asynchronous approval flow, follow-up call, idempotency, and error conditions. An agent has everything needed to invoke it correctly on either path.
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 both parameters are already fully documented, including the URL format and the idempotency-key reuse rule. The description only restates the idempotency retry guidance and adds nothing about syntax or key format beyond the schema, 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 and resource ('Retrieve normalized public TikTok profile metadata') and immediately scopes it to one account. It explicitly names the sibling to use instead for a different need ('For its posts/videos, use tiktok_feed'), so an agent can distinguish it from tiktok_feed and tiktok_video without opening a schema.
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 explicit routing: use this for one account's profile metadata, use tiktok_feed for posts/videos, and use get_reachsocial_request with the returned request_id after the OAuth payment path. It also tells the agent which credential path executes immediately vs. which one waits, which is the key decision an agent has to make before calling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public TikTok video metadata and source URLs. Use for one public post/video URL. For an account's list, use tiktok_feed. Returns source video and preview URLs without downloading the asset. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical TikTok video URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses billing behavior, OAuth wallet approval requirements, the $0.05 USDC payment request on Base, error conditions, and that assets are not downloaded. It also clarifies idempotency_key retry behavior, which is important for avoiding duplicate billing.
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 description is front-loaded with purpose and immediately follows with the sibling-tool distinction. Every sentence contributes operational detail about return behavior, auth/billing, retries, or errors, with 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 fully explained. Given the auth, billing, idempotency, and error-handling details included, the description is complete enough for an agent to select and invoke the tool correctly.
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 both parameters are already well documented in the input schema. The description reinforces the URL scope and idempotency-key retry semantics, but largely duplicates what the schema already states, so the baseline of 3 is appropriate.
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 uses a specific verb and resource: 'Retrieve normalized public TikTok video metadata and source URLs.' It also scopes usage to 'one public post/video URL' and explicitly distinguishes the sibling tool by saying 'For an account's list, use tiktok_feed.'
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 when-to-use guidance for a single public video URL and names the alternative tool for account lists. It also explains the B2B immediate-execution path versus the OAuth approval/payment path, and directs follow-up with get_reachsocial_request when a request_id is returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a provider-selected set of normalized public posts from an X profile. Use for a bounded list from one account/channel. For one specific post/video URL, use x_post. Returns a bounded normalized X feed and temporary media references. Provider ordering is not guaranteed to be chronological. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical X profile URL. Supply a full https:// URL, not a handle or search query. | |
| max_items | No | Maximum posts to return. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare openWorldHint, idempotentHint, and destructiveHint=false, but the description adds real behavioral context: non-chronological provider ordering, immediate B2B billing, OAuth's $0.05 USDC request on Base with browser approval wait, and an error taxonomy. This explains the otherwise surprising readOnlyHint=false (payment/billing side effect) rather than contradicting it.
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 purpose and sibling routing come first, followed by return behavior, ordering caveat, and payment flow. It is dense but nearly every sentence carries operational information; slight length is justified by the dual B2B/OAuth execution paths.
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?
Annotations, a 100%-covered schema, and an output schema mean the description needn't restate parameters or returns. It nonetheless covers ordering nondeterminism, billing/payment side effects, idempotency retry rules, and error cases, leaving no major gap for a tool with payment gating.
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 fully documents url, max_items, and idempotency_key. The description reinforces retry semantics and new-key-on-changed-input behavior, but adds little on URL format or max_items beyond the schema. Baseline 3 applies when 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?
States a specific verb and resource ('Retrieve ... normalized public posts from an X profile') with scope ('bounded list from one account/channel'). It explicitly distinguishes itself from the sibling x_post for single-post URLs, so an agent can choose without opening schemas.
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 an explicit when-to-use ('bounded list from one account/channel') and a named alternative for the other case ('For one specific post/video URL, use x_post'). It also documents the follow-up step (get_reachsocial_request) for OAuth payment, which is essential routing detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a normalized public X post and source media URLs. Use for one public post/video URL. For an account's list, use x_feed. Returns normalized text, author, engagement, and source media URLs. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical X status URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses billing/spend-limit behavior for B2B keys, the OAuth wallet-approval requirement, the $0.05 USDC payment request on Base, that execution blocks on browser approval, and the error classes (invalid/private/unavailable targets, access/rate/spend limits). This also explains why readOnlyHint is false despite the "retrieve" wording — the call can create a payment request.
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?
Scope and the sibling alternative are front-loaded in the first two sentences, and every later sentence carries distinct operational content. It is dense and the auth/billing sentence is long, but nothing is 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?
Covers the full lifecycle an agent needs: which input shape is valid, what the two auth paths cost and how they behave, where to poll the result, and how to retry safely. With an output schema present, it correctly omits return-value structure.
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 coverage is 100%, so both parameters are already documented; the description still adds operational meaning by tying idempotency_key to duplicate-billing avoidance and by framing the URL as a single canonical post target. It doesn't restate the key length/format rules, which the schema already handles.
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 and resource ("Retrieve a normalized public X post and source media URLs") and immediately scopes it to a single public post/video URL. It also names the sibling to use for the other case (x_feed), so an agent can discriminate without opening either schema.
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?
Explicitly gives the when: one public post/video URL, and the when-not: account lists belong to x_feed. It also routes the follow-up correctly ("Then use get_reachsocial_request with the returned request_id") and covers retries via the idempotency key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public X profile metadata. Use for one account's public profile metadata. For its posts/videos, use x_feed. Normalized profile metadata from the public X profile. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical X profile URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond annotations: B2B keys execute immediately under client billing/spending limits, while OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base pending browser approval. It also states error conditions for invalid/private/unavailable targets and access, rate, or spend limits, and explains request_id follow-up and idempotency 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?
The definition is front-loaded with the core purpose and then moves into execution behavior and error conditions. It has some redundancy, such as repeating 'normalized public X profile metadata' across two sentences, but is otherwise efficiently organized.
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?
The tool has an output schema, so return values need not be explained. Given that, the description is complete enough: it covers purpose, sibling routing, auth/payment flow, idempotency, follow-up request retrieval, and error behavior.
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 coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces idempotency key preservation and the need for a new key on changed input, but it does not add much parameter meaning beyond what the schema already provides.
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 uses a specific verb and resource: retrieve normalized public X profile metadata. It also distinguishes this tool from x_feed by naming x_feed as the tool for posts/videos, so the agent can select correctly among siblings.
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 explicitly says to use this for one account's public profile metadata and routes post/video retrieval to x_feed. It also explains the two execution modes: B2B API key execution versus OAuth payment approval, which is clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public YouTube channel metadata. Use for one account's public profile metadata. For its posts/videos, use youtube_feed. Returns normalized public channel metadata. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical YouTube channel URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses billing/spend limits under B2B, a $0.05 USDC payment request on Base for OAuth, that execution blocks on browser approval, that idempotency keys must be reused only for identical input, and which failure modes (invalid/private targets, access/rate/spend limits) return errors. readOnlyHint=false is consistent with the payment-request side effect described.
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 purpose and the sibling routing, but wastes a sentence re-stating "Returns normalized public channel metadata" after already saying "Retrieve normalized public YouTube channel metadata." The payment/auth mechanics are long but each carries real information, so the redundancy is the main deduction.
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, and the description covers the remaining agent-critical unknowns: auth path, payment, blocking approval, follow-up call, and idempotency/error behavior. Nothing needed to invoke it correctly 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 coverage is 100% and both parameters are fully documented there, so the description starts at the baseline. It adds only a light restatement of retry semantics ("Preserve the idempotency_key for retries; changed input needs a new key") and nothing about the url parameter beyond what the schema already says.
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 (Retrieve) and resource (normalized public YouTube channel metadata) with scope (one account's public profile). It explicitly distinguishes itself from the sibling that covers posts/videos: "For its posts/videos, use youtube_feed."
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?
Names the alternative (youtube_feed) and the condition that selects it, and also spells out the two execution paths: entitled B2B key runs immediately, OAuth requires an approved wallet connection and browser approval. It even tells the agent the follow-up call (get_reachsocial_request with returned request_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a bounded normalized list of recent public videos from a YouTube channel. Use for a bounded list from one account/channel. For one specific post/video URL, use youtube_video. Returns recent video metadata and thumbnails. It does not return downloadable YouTube video bytes. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical YouTube channel URL. Supply a full https:// URL, not a handle or search query. | |
| max_items | No | Maximum videos to return. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses the two auth paths (entitled B2B key billed under client limits vs OAuth requiring an approved owner wallet), the exact $0.05 USDC payment request on Base with browser approval gating execution, and the error surface (invalid/private/unavailable targets, access/rate/spend limits). The readOnlyHint=false is explained by the payment-request side effect rather than left contradictory.
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 purpose and the sibling exclusion before the payment detail, which is the right ordering. There is mild redundancy — 'bounded' appears in the first two sentences and the payment mechanics occupy several lines — but nearly every sentence carries operational 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?
For a paid, auth-gated, idempotent fetch with an output schema present, the description covers the auth decision, cost, approval flow, follow-up tool, retry key policy, and failure modes. Nothing an agent needs to call it safely is missing, and return values are correctly left to the output schema.
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 coverage is 100%, so url, max_items and idempotency_key are all fully documented in the schema itself. The description only restates 'bounded' (max_items) and retry/idempotency semantics that the schema already spells out ('Use a new key for a different target, item limit, or page'), adding little beyond the baseline.
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 and resource ('Retrieve a bounded normalized list of recent public videos from a YouTube channel') and immediately contrasts with the sibling that handles single items ('For one specific post/video URL, use youtube_video'). The agent can distinguish it from youtube_channel and youtube_video without opening a schema.
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?
Explicitly scopes usage ('Use for a bounded list from one account/channel') and names the alternative for the other case ('For one specific post/video URL, use youtube_video'). It also routes the follow-up step ('Then use get_reachsocial_request with the returned request_id'), so the agent knows both the entry and the continuation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve normalized public YouTube video metadata and thumbnails. Use for one public post/video URL. For an account's list, use youtube_feed. Returns video metadata and thumbnails; playback remains on the official YouTube player. An entitled B2B API key executes immediately under the client's billing and spending limits. OAuth requires an approved owner wallet connection and creates a $0.05 USDC payment request on Base; execution waits for browser approval/payment. Then use get_reachsocial_request with the returned request_id. Preserve the idempotency_key for retries; changed input needs a new key. Invalid/private/unavailable targets and access, rate, or spend limits return errors.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Canonical YouTube video URL. Supply a full https:// URL, not a handle or search query. | |
| idempotency_key | Yes | The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page. |
| Name | Required | Description |
|---|---|---|
| data | No | Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more. |
| meta | No | Direct B2B schema/normalization versions, response shape, and latency. |
| cached | No | Whether a direct B2B response reused cached normalized data. |
| result | No | Stored execution response after OAuth payment; contains normalized data or a terminal failure. |
| status | Yes | B2B success or the current OAuth payment/execution state. |
| message | No | Action or recovery guidance for the current request state. |
| service | Yes | Catalog service ID, such as instagram.profile. |
| request_id | Yes | Stored request identifier; preserve it for recovery. |
| payment_url | No | Owner browser link for USDC payment approval; present when payment is required. |
| price_cents | No | OAuth request price in USD cents. |
| transaction | No | Settled payment transaction identifier, when available. |
| payment_status | No | Stored settlement state; uncertainty requires retrieval, never a new payment. |
| payment_endpoint | No | Owner-only acceptance endpoint, present only during an explicitly enabled validation run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety hints but not billing or asynchronous approval flows; the description adds critical context about B2B immediate execution under spending limits and OAuth creating a $0.05 USDC payment request on Base that waits for browser approval. It also explains that invalid/private/unavailable targets and access/rate/spend limits produce errors. The readOnlyHint=false is consistent with billing side effects despite the read-like retrieval purpose.
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 description is front-loaded with purpose and the sibling alternative, then proceeds through return behavior and billing/async flow. It is dense but every sentence carries operational value; minor improvement would be splitting the auth/payment and retry guidance into clearer sentences.
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?
Given an output schema exists, return values need not be explained in depth. The description fully covers the unusual complexity here: payment vs B2B execution paths, async approval via get_reachsocial_request, idempotency retry semantics, and error conditions.
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 both url and idempotency_key are already well documented in the schema. The description reinforces idempotency key preservation and new-key-for-changed-input behavior, but adds little beyond the schema's own detailed parameter text.
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 and resource (retrieve normalized public YouTube video metadata and thumbnails) and explicitly scopes it to one public post/video URL. It names youtube_feed as the sibling for account-level lists, so the agent can distinguish the two without opening schemas.
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?
Explicitly says when to use this tool (one public video URL) and when to use the alternative (youtube_feed for an account's list). It also routes the OAuth follow-up to get_reachsocial_request and explains retry behavior with idempotency keys.
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.
facebook_profile1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."instagram_feed1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."instagram_highlight1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."instagram_post1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."instagram_profile1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."reddit_post1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."tiktok_feed1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."tiktok_profile1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."tiktok_video1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."x_feed1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."x_post1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."x_profile1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."youtube_channel1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."youtube_feed1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."youtube_video1 field changedInput schema / properties / idempotency_key / descriptionPrevious value: -"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."New value: +"The calling agent/client generates this key automatically; do not ask the user to invent it. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it with the exact inputs before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."facebook_profile10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical public Facebook profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"facebook_profileDictOutput"New value: +"MCPServiceResult"get_reachsocial_request9 fields changedInput schema / properties / request_id / descriptionAdded value: +"The exact request_id returned by a social-data tool under OAuth. Preserve this ID across browser payment and retries."Input schema / properties / request_id / maxLengthAdded value: +64Input schema / properties / request_id / minLengthAdded value: +64Input schema / properties / request_id / patternAdded value: +"^[0-9a-f]{64}$"Input schema / titlePrevious value: -"retrieve_requestArguments"New value: +"get_reachsocial_requestArguments"Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"retrieve_requestDictOutput"New value: +"MCPServiceResult"instagram_feed14 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / max_items / defaultPrevious value: -20New value: +12Input schema / properties / max_items / descriptionAdded value: +"Maximum posts to return."Input schema / properties / max_items / maximumAdded value: +30Input schema / properties / max_items / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical Instagram profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"instagram_feedDictOutput"New value: +"MCPServiceResult"instagram_highlight13 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / max_items / descriptionAdded value: +"Maximum highlight items to return."Input schema / properties / max_items / maximumAdded value: +50Input schema / properties / max_items / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical Instagram saved-highlight URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"instagram_highlightDictOutput"New value: +"MCPServiceResult"instagram_post10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical Instagram post or reel URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"instagram_postDictOutput"New value: +"MCPServiceResult"instagram_profile10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical Instagram profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"instagram_profileDictOutput"New value: +"MCPServiceResult"reddit_post10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical Reddit post URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"reddit_postDictOutput"New value: +"MCPServiceResult"tiktok_feed16 fields changedInput schema / properties / cursor / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maxLength": 2048,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / cursor / descriptionAdded value: +"Opaque provider-neutral pagination cursor. Omit for the first page; copy next_cursor from the prior result for a new page with a new idempotency_key."Input schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / max_items / defaultPrevious value: -20New value: +12Input schema / properties / max_items / descriptionAdded value: +"Maximum videos to return."Input schema / properties / max_items / maximumAdded value: +30Input schema / properties / max_items / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical TikTok profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"tiktok_feedDictOutput"New value: +"MCPServiceResult"tiktok_profile10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical TikTok profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"tiktok_profileDictOutput"New value: +"MCPServiceResult"tiktok_video10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical TikTok video URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"tiktok_videoDictOutput"New value: +"MCPServiceResult"x_feed14 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / max_items / defaultPrevious value: -20New value: +12Input schema / properties / max_items / descriptionAdded value: +"Maximum posts to return."Input schema / properties / max_items / maximumAdded value: +30Input schema / properties / max_items / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical X profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"x_feedDictOutput"New value: +"MCPServiceResult"x_post10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical X status URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"x_postDictOutput"New value: +"MCPServiceResult"x_profile10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical X profile URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"x_profileDictOutput"New value: +"MCPServiceResult"youtube_channel10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical YouTube channel URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"youtube_channelDictOutput"New value: +"MCPServiceResult"youtube_feed14 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / max_items / defaultPrevious value: -20New value: +12Input schema / properties / max_items / descriptionAdded value: +"Maximum videos to return."Input schema / properties / max_items / maximumAdded value: +30Input schema / properties / max_items / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical YouTube channel URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"youtube_feedDictOutput"New value: +"MCPServiceResult"youtube_video10 fields changedInput schema / properties / idempotency_key / descriptionAdded value: +"Stable key for this logical request. OAuth requires a random 32–255 character key (for example a UUID); B2B accepts 1–255 characters. Save it before calling and reuse it with identical input to recover without duplicate billing. Use a new key for a different target, item limit, or page."Input schema / properties / idempotency_key / maxLengthAdded value: +255Input schema / properties / idempotency_key / minLengthAdded value: +1Input schema / properties / url / descriptionAdded value: +"Canonical YouTube video URL. Supply a full https:// URL, not a handle or search query."Input schema / properties / url / formatAdded value: +"uri"Input schema / properties / url / maxLengthAdded value: +2048Output schema / descriptionAdded value: +"A B2B execution result or an OAuth request awaiting browser payment."Output schema / propertiesAdded value: +{
+ "cached": {
+ "description": "Whether a direct B2B response reused cached normalized data.",
+ "title": "Cached",
+ "type": "boolean"
+ },
+ "data": {
+ "additionalProperties": true,
+ "description": "Direct B2B normalized profile, item, or items; feeds may include next_cursor and has_more.",
+ "title": "Data",
+ "type": "object"
+ },
+ "message": {
+ "description": "Action or recovery guidance for the current request state.",
+ "title": "Message",
+ "type": "string"
+ },
+ "meta": {
+ "additionalProperties": true,
+ "description": "Direct B2B schema/normalization versions, response shape, and latency.",
+ "title": "Meta",
+ "type": "object"
+ },
+ "payment_endpoint": {
+ "description": "Owner-only acceptance endpoint, present only during an explicitly enabled validation run.",
+ "title": "Payment Endpoint",
+ "type": "string"
+ },
+ "payment_status": {
+ "description": "Stored settlement state; uncertainty requires retrieval, never a new payment.",
+ "title": "Payment Status",
+ "type": "string"
+ },
+ "payment_url": {
+ "description": "Owner browser link for USDC payment approval; present when payment is required.",
+ "title": "Payment Url",
+ "type": "string"
+ },
+ "price_cents": {
+ "description": "OAuth request price in USD cents.",
+ "title": "Price Cents",
+ "type": "integer"
+ },
+ "request_id": {
+ "description": "Stored request identifier; preserve it for recovery.",
+ "title": "Request Id",
+ "type": "string"
+ },
+ "result": {
+ "additionalProperties": true,
+ "description": "Stored execution response after OAuth payment; contains normalized data or a terminal failure.",
+ "title": "Result",
+ "type": "object"
+ },
+ "service": {
+ "description": "Catalog service ID, such as instagram.profile.",
+ "title": "Service",
+ "type": "string"
+ },
+ "status": {
+ "description": "B2B success or the current OAuth payment/execution state.",
+ "enum": [
+ "success",
+ "payment_required",
+ "awaiting_approval",
+ "reconciliation_required",
+ "succeeded",
+ "failed",
+ "expired"
+ ],
+ "title": "Status",
+ "type": "string"
+ },
+ "transaction": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Settled payment transaction identifier, when available.",
+ "title": "Transaction"
+ }
+}Output schema / requiredAdded value: +[
+ "request_id",
+ "service",
+ "status"
+]Output schema / titlePrevious value: -"youtube_videoDictOutput"New value: +"MCPServiceResult"facebook_profileget_reachsocial_requestinstagram_feedinstagram_highlightinstagram_postinstagram_profilereddit_posttiktok_feedtiktok_profiletiktok_videox_feedx_postx_profileyoutube_channelyoutube_feedyoutube_video
Add one secure layer between your agents and this server.