SocialGPT
Server Details
Social media analytics, video analysis, and competitor intel for any MCP-compatible AI agent.
- Status
- Healthy
- Uptime
- 57.9% over 42 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- scrollmark/socialgpt-mcp
- GitHub Stars
- 10
- Server Listing
- socialgpt-mcp
TDQS
Scored across 26 tools
Most tools map to clearly distinct resources and actions, and the descriptions are unusually explicit about boundaries. A few clusters are still easy to mis-select—growth vs. account metrics, search vs. search_videos, and fetch vs. get_video—but an agent reading the descriptions should usually pick correctly.
The surface is overwhelmingly consistent snake_case verb_noun naming: list_accounts, get_creator, analyze_post, publish_post. The main deviations are the connector-spec names `search` and `fetch`, plus `server_info` and `whoami`, which prevent a perfect score.
26 tools is slightly heavy, but the server covers a broad life cycle: creator ingestion, video analysis, metrics, semantic search, uploading, publishing, and identity/scope inspection. While a few tools overlap at the edges, most have a distinct job, so the count is justifiable rather than bloated.
The tool surface covers the main workflows well: analyze creators/posts, read results, list videos, retrieve metrics, search semantic content, publish posts, handle uploads, and poll job status. Minor gaps exist, such as no way to list all creators in the analysis library or delete/refresh analyses/uploads, but agents can usually work around them.
Available Tools
26 toolsanalyze_creatorAnalyze a creatorAInspect
Analyze a public TikTok, YouTube, or Instagram creator's recent posts — adds them to your analysis library. Async — returns a job_id; poll get_analysis_status(job_id). Results then appear via list_creator_videos / get_creator. Rate limit: 10 calls/hour.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| username | Yes | The creator's public handle, e.g. 'natgeo' (no leading @). | |
| post_limit | No | How many of the creator's recent posts to scrape + analyze (1–30, default 10; clamped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| job_id | Yes | |
| status | Yes | Always 'pending' at creation; poll the matching status tool. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutation ('adds to library'), async behavior, and rate limit, which go beyond annotations. Annotations have readOnlyHint=false, consistent with mutation. No contradictions. Could elaborate on idempotency or duplicate handling.
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?
Two sentences, front-loaded with purpose, then async and polling details. Every word earns its place. No fluff.
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 parameters, annotations, output schema existence (not shown but assumed), and sibling tools, the description covers purpose, async flow, rate limits, and result retrieval. Complete for an async analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions, so baseline is 3. Description repeats platform options and 'no leading @' already in schema, but adds 'case-insensitive' and mentions post_limit range (1–30) that is also in schema. No additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes a creator's recent posts and adds them to the analysis library. It distinguishes from siblings like analyze_post (single post) and get_creator (just info) by specifying the scope and outcome.
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 notes the asynchronous nature, how to poll with get_analysis_status, and where results appear (list_creator_videos / get_creator). Mentions rate limit (10 calls/hour). Lacks explicit 'when not to use' but provides clear next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
analyze_postAnalyze a postAInspect
Analyze a single TikTok, YouTube, or Instagram post by URL — adds it to your library and runs deep video analysis. Returns immediately with the post's platform + post_id; deep analysis runs async (~30-60s). Then call get_video_analysis(platform, post_id) to read it — while it runs you get {"status": "pending"}, so wait ~20s and retry until the full result comes back ('pending' is expected, not a failure). Only posts within the creator's recent media (roughly their last ~75 posts) can be fetched. Rate limit: 30 calls/hour.
| Name | Required | Description | Default |
|---|---|---|---|
| post_url | Yes | Full public URL of a single TikTok, YouTube, or Instagram post / reel / video. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| post | Yes | The post just queued by `analyze_post`. |
| creator_id | Yes | |
| ingest_job_id | Yes | Creator-backfill job id; null unless a new creator was created. |
| is_new_creator | Yes | |
| analysis_status | Yes | Deep-analysis job status at ingest time (e.g. 'pending'). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool mutates state (adds to library), runs async analysis with expected 'pending' status, and rate limits. Annotations already indicate non-read-only and non-destructive, and description adds significant context beyond 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?
Description is well-structured and front-loaded with key info. Every sentence adds value, though slightly verbose. Could be trimmed without losing clarity.
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 async behavior, retry logic, constraints (recent media), rate limits, and next steps. An output schema exists but description still explains immediate return and how to retrieve results, making it complete for agent use.
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 schema parameter description is already clear. The main description reiterates the URL platforms but does not add new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a single TikTok, YouTube, or Instagram post by URL, adds it to the library, and runs deep video analysis. It specifies the verb and resource, and distinguishes from siblings like analyze_creator.
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?
Provides explicit guidance: when to use (analyzing a post), what not to use (only recent ~75 posts), retry logic with get_video_analysis, and rate limit. Includes async behavior explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch a resourceARead-onlyInspect
Fetch the full content of a single resource by the id returned from search.
Returns the resource's id, title, full text, url, and metadata. This is the
deep-research "fetch" entrypoint paired with search — both names are fixed by the
ChatGPT/Claude connector spec, so they read more generic than the rest of the surface.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A resource id returned by `search` (the `id` field of a search result). |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds context about returning full content and fields. It does not contradict annotations but also does not disclose additional behavioral traits like rate limits or error states.
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 two sentences plus a brief note, all front-loaded and non-redundant. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately explains the tool's purpose and usage. It covers all necessary aspects for a simple fetch-by-id tool with good annotations.
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 parameter description already states it is an id from search. The description repeats this but adds no new semantics beyond the schema, 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 clearly states the tool fetches full content of a single resource by id from search, using specific verb and resource. It distinguishes itself as the 'fetch' entrypoint paired with 'search', differentiating from sibling 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?
The description explicitly mentions it is paired with 'search', indicating usage after search results. However, it does not provide exclusions or alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_accountGet a connected accountARead-onlyInspect
Get one of the caller's connected accounts by id (from list_accounts). 404s if the id isn't one of your connected accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | An account_id from list_accounts. |
Output Schema
| Name | Required | Description |
|---|---|---|
| platform | Yes | |
| username | Yes | |
| account_id | Yes | |
| is_verified | No | |
| display_name | No | |
| profile_link | No | |
| account_group_id | No | |
| account_group_name | No | |
| profile_picture_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=false. The description adds that the tool 404s on invalid ids, a behavioral detail not in annotations. It also specifies 'caller's connected accounts', providing context.
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?
Two sentences, no redundancy, front-loaded with key information. Highly concise.
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 the presence of an output schema, the description sufficiently covers the tool's behavior: retrieval, id source, error case, and ownership context. No gaps for a simple get tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for account_id. The description reiterates the source (from list_accounts) but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get' as the verb and specifies the resource as 'connected accounts by id'. It explicitly ties the id to list_accounts, distinguishing it from sibling tools like list_accounts.
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?
The description indicates the id should come from list_accounts, implying usage after listing. It mentions 404 for invalid ids, but does not explicitly list alternatives or when to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_metricsAccount engagement metricsARead-onlyInspect
Get per-platform engagement (views / likes / comments / shares) as a time series over the
trailing window_days (default 28, up to 365). Omit account_id to aggregate across all connected
accounts, or pass one from list_accounts; optionally filter to a single platform. post_limit
(≤100) fixes how many recent posts form the baseline. granularity buckets the series server-side
('daily' default, 'weekly', or 'raw' for every scrape). Read series (a clean per-platform list
of typed points) — metrics is the legacy column/data matrix kept for back-compat. NB: follower
counts here are latest-only; for audience growth over time use get_follower_history.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. | |
| account_id | No | A connected account_id from list_accounts. Omit to aggregate across all your accounts. | |
| post_limit | No | How many recent posts form the baseline (1–100, default 20; clamped). | |
| granularity | No | Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape). | daily |
| window_days | No | Trailing window in days (1–365, default 28; out-of-range values are clamped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when the requested account_id could not be resolved. |
| series | Yes | Per-platform typed time series. |
| metrics | Yes | Legacy per-platform {columns, data} matrix (back-compat). |
| platform | Yes | |
| platforms | Yes | |
| account_id | Yes | The account_id the caller passed (null = all accounts). |
| post_limit | Yes | |
| granularity | Yes | |
| window_days | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true. Description adds that `series` is clean output while `metrics` is legacy, and explains parameter clamping. No contradiction with annotations; adds valuable behavioral context.
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?
Description is thorough but efficiently front-loaded with main action. Every sentence serves a purpose, though slightly lengthy. Could be trimmed marginally but remains clear.
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 output schema present, description still hints at output structure. Covers all aspects: purpose, parameters, alternatives, and behavioral notes. Sufficient for informed agent decision.
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 baseline is 3. Description adds meaning by explaining 'trailing window_days', granularity options, and that post_limit forms baseline. Provides context beyond schema without redundancy.
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 clearly states the tool retrieves per-platform engagement metrics as a time series, specifying verb (get) and resource (account metrics). It distinguishes from sibling get_follower_history by noting follower counts are latest-only.
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 guidance on when to omit account_id for aggregation, filter by platform, and direct to use get_follower_history for audience growth over time. Provides clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_analysis_statusAnalysis job statusARead-onlyInspect
Check the status of an analyze_creator (or analyze_post creator-backfill) job by job_id. Note: this tracks the creator-ingest job, not a single post's video analysis. To know when one post is ready, poll get_video_analysis(platform, post_id) — it returns {"status": "pending"} until ready.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | The job_id (a UUID) returned by analyze_creator or analyze_post. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| error | Yes | |
| job_id | Yes | |
| result | No | |
| status | Yes | One of: pending, scraping, completed, failed. |
| platform | Yes | |
| progress | Yes | Completion percentage (0-100). |
| username | Yes | |
| creator_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds behavioral context by explaining that this tool tracks the creator-ingest job, not individual post analysis. It does not contradict annotations. It could mention response format or polling behavior, but the existing description is strong.
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?
Two sentences pack essential information: what the tool does, what it does not track, and the correct alternative. Every sentence is necessary and well-structured.
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 simple status-check tool with one parameter and an output schema (implied), the description covers the essential behavioral distinction against sibling tools. It is complete and requires no additional elaboration.
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% with a clear description of the job_id parameter: 'The job_id (a UUID) returned by analyze_creator or analyze_post.' The description adds minimal extra meaning beyond the schema, re-iterating the source of the job_id. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Check the status of an analyze_creator (or analyze_post creator-backfill) job by job_id', using a specific verb and resource. It clearly distinguishes from sibling tool get_video_analysis by noting it tracks the creator-ingest job, not a single post's video analysis.
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?
The description provides explicit guidance on when to use this tool vs. the alternative: 'To know when one post is ready, poll get_video_analysis(platform, post_id) — it returns {"status": "pending"} until ready.' This clearly states when not to use this tool and names the sibling tool to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_content_profileYour content profileARead-onlyInspect
Get the caller's OWN content profile / DNA (topics, pillars, voice) synthesized from their content. Scoped per account group (brand): pass a group_id from list_accounts, or omit it for the default group. There is no per-creator content-profile tool — for competitor analysis use get_creator + list_creator_videos.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | Optional account-group (brand) id from list_accounts. Omit to use the default group. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when content_profile is null — why it is null. |
| content_profile | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context about scoping and that the profile is synthesized from content. No contradictions. Some additional behavioral context beyond annotations is provided, but the core safety trait is already covered.
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?
Three sentences, each serving a distinct purpose: purpose, parameter usage, and alternatives. No unnecessary words. Highly efficient.
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 the tool's simplicity (1 optional param, no required, output schema present), the description fully covers purpose, usage, and alternatives. No gaps.
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?
The single parameter group_id is fully described in the schema (100% coverage). The description repeats the schema's guidance about omitting for default or passing from list_accounts, adding no new meaning beyond what the schema already provides. 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 'Get the caller's OWN content profile / DNA (topics, pillars, voice) synthesized from their content', providing a specific verb and resource. It distinguishes from competitor analysis tools by noting there is no per-creator tool.
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 (caller's own profile, per account group) and when not to use ('For competitor analysis use get_creator + list_creator_videos'), offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_creatorGet a public creatorARead-onlyInspect
Get a public/competitor creator's profile by platform + handle (e.g. instagram, 'natgeo').
Only returns creators already in the analysis library; it does not ingest. For a creator you haven't pulled in yet this returns reason="creator_not_in_library" (not an error) with a next_step of analyze_creator(platform, username) — call that (needs the content:ingest scope), wait for it to finish, then retry.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| username | Yes | The creator's public handle, e.g. 'natgeo' (no leading @). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true (safe read) and openWorldHint=true (unexpected results possible). The description adds behavioral details: the tool returns a specific reason when a creator is not in the library, and it does not perform ingestion. No contradiction with 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?
The description is a single efficient paragraph with two sentences. It front-loads the core purpose and immediately adds actionable usage guidance. No unnecessary words.
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 an output schema exists (so return values need not be described), the description covers all essential aspects: what the tool does, how to use it, edge cases (not in library), and next steps. It is fully complete for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds value by explaining how to use the parameters together ('platform + handle'), providing an example ('instagram, 'natgeo''), and clarifying that the username should not include a leading '@'.
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 clearly states the verb ('Get'), the resource ('public/competitor creator's profile'), and the required inputs ('platform + handle') with an example. It distinguishes itself from sibling tools like analyze_creator and search by specifying that it only retrieves existing library entries.
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?
The description explicitly tells when to use the tool (for creators already in the library) and what to do if the creator is not found: it returns a specific reason and suggests calling analyze_creator. It also notes that this tool does not ingest, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_follower_historyFollower growth historyARead-onlyInspect
Get audience growth over time — follower / following / media counts as a true per-platform time series over the trailing window_days (default 90, up to 365). This is the trend get_account_metrics flattens to a latest-only value, so use it to answer "is my audience growing?". Omit account_id to aggregate across all connected accounts, or pass one from list_accounts; optionally filter to a single platform. granularity buckets server-side ('daily' default, 'weekly', or 'raw' for every scrape).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. | |
| account_id | No | A connected account_id from list_accounts. Omit to aggregate across all your accounts. | |
| granularity | No | Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape). | daily |
| window_days | No | Trailing window in days (1–365, default 90; out-of-range values are clamped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when the requested account_id could not be resolved. |
| series | Yes | Per-platform typed time series. |
| platform | Yes | |
| platforms | Yes | |
| account_id | Yes | The account_id the caller passed (null = all accounts). |
| granularity | Yes | |
| window_days | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds trailing window behavior, granularity options, and server-side bucketing. No contradictions.
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?
Two sentences with no filler. Front-loaded with purpose and key constraints. Every sentence earns its place.
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 tool with 4 optional params, output schema present, and good annotations, the description covers aggregation, filtering, bucketing, and window. Complete.
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%, but description adds meaning: default 90 days, up to 365, clamping, aggregation when omitted, 'raw' for every scrape. All parameters explained beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'get audience growth over time' with specific metrics (follower/following/media counts) and differentiates from sibling get_account_metrics by noting that it provides a time series while the other flattens to latest-only.
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 'use it to answer 'is my audience growing?'' and explains when to omit account_id or platform. Lacks explicit when-not-to-use or alternative tools beyond the one mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_growth_summaryGrowth summaryARead-onlyInspect
Get a computed momentum summary for owned content over the trailing window_days (default 90).
For each platform returns, per metric, the start/current value, absolute + percent change over
the window, and a momentum read (recent half vs. prior half — accelerating). Audience metrics
(follower/following/media counts) come from the true growth series; engagement metrics
(views/likes/comments/shares) from recent-post activity. Higher-altitude than the raw series —
use it to lead a performance audit, then drill in with get_follower_history / get_account_metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. | |
| account_id | No | A connected account_id from list_accounts. Omit to aggregate across all your accounts. | |
| window_days | No | Trailing window in days (1–365, default 90; out-of-range values are clamped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when the requested account_id could not be resolved. |
| summary | Yes | Per-platform, per-metric window summaries. |
| platform | Yes | |
| platforms | Yes | |
| account_id | Yes | The account_id the caller passed (null = all accounts). |
| window_days | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses computational behavior: returns start/current values, absolute+percent change, momentum read ('accelerating'). Explains data source differentiation. Annotations already provide readOnlyHint=true; description adds meaningful context without contradiction.
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?
Two sentences with front-loaded purpose, detailed breakdown, and usage guidance. Every clause adds value, no redundancy or 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 purpose, data sources, usage flow, and parameter defaults. Output schema exists so return values need not be elaborated. Slightly missing mention of error cases or prerequisite (e.g., accounts must exist), but sufficient given complexity.
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%, baseline 3. Description adds value by explaining defaults (window_days=90), platform filter case-insensitivity, account_id sourced from list_accounts, and clamping behavior. Goes beyond bare schema descriptions.
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?
Description uses specific verb 'get' and resource 'computed momentum summary', clearly defining the tool's output. It distinguishes itself from sibling tools (get_follower_history, get_account_metrics) by noting it's higher-altitude and for leading audits.
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 states when to use ('lead a performance audit') and suggests when to drill in with alternatives. Provides context on data sources (true growth series vs recent-post activity) to guide appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_post_metrics_historyPost metric historyARead-onlyInspect
Get one post's metric trajectory over time — views, likes, comments, shares, saves, reach as a time series across window_days (default 90, up to 365). Use it to see how a video accelerated after posting or whether an older post is re-surging. Works for an owned post or any post you've analyzed (use the platform + post_id from list_videos / analyze_post). granularity buckets server-side ('daily' default, 'weekly', or 'raw' for every scrape).
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The post's native post_id (from list_videos / analyze_post). | |
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| granularity | No | Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape). | daily |
| window_days | No | Trailing window in days (1–365, default 90; out-of-range values are clamped). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when series is empty. |
| series | Yes | |
| post_id | Yes | |
| platform | Yes | |
| granularity | Yes | |
| window_days | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral details: granularity is bucketed server-side, window_days default and maximum, and out-of-range values are clamped. These details go beyond what annotations provide.
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 three sentences, front-loading the main purpose. It uses a compact listing of metrics and parameters without unnecessary words. Every sentence adds value.
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 the presence of an output schema, the description does not need to explain return values. It covers purpose, usage, parameters, constraints, and behavior. The tool is fully documented for an AI agent to use 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%. The description adds context: post_id source (list_videos/analyze_post), platform listing, granularity server-side behavior, and window_days clamping. This enhances understanding beyond the schema alone.
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 clearly states the tool's purpose: retrieving a single post's metric trajectory over time, listing specific metrics (views, likes, comments, shares, saves, reach). It distinguishes itself from sibling tools like get_follower_history or get_account_metrics by focusing on one post's time-series data.
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?
The description provides clear usage scenarios ('see how a video accelerated after posting or whether an older post is re-surging') and explains prerequisites (works for owned posts or posts analyzed via list_videos/analyze_post). It does not explicitly exclude alternatives but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_publish_optionsTikTok publish optionsARead-onlyInspect
Fetch live TikTok publish options for the caller's connected account — TikTok-only (Instagram and YouTube have no creator-info equivalent), REQUIRED before direct posting. Pass group_id (from list_accounts) to target a specific brand's TikTok connection. Returns the creator nickname (show it to the human), privacy_level_options (the human must pick one — never default), interaction/disclosure availability, whether posting is possible right now (can_post), and an options_token that publish_post (platform='tiktok', post_mode='direct') requires. The token expires in 15 minutes. Rate limit: 20 calls/min.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | Optional account-group (brand) id from list_accounts. Omit to use the default group. | |
| account_id | No | The account_id returned by get_publish_options. Omit to use the default connected TikTok account. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rules | Yes | |
| reason | No | |
| scopes | No | |
| can_post | Yes | |
| unaudited | No | |
| account_id | Yes | The resolved social account id — pass back to publish_post. |
| post_modes | Yes | Modes available to this account: 'draft' and/or 'direct'. |
| duet_disabled | Yes | |
| options_token | Yes | Required by publish_post(post_mode='direct'); short-lived. |
| stitch_disabled | Yes | |
| comment_disabled | Yes | |
| creator_nickname | Yes | |
| creator_avatar_url | No | |
| privacy_level_options | Yes | |
| max_video_post_duration_sec | Yes | |
| options_token_expires_in_seconds | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds token expiration (15 min), rate limit (20 calls/min), and explicit output details (creator nickname, options_token, etc.). No contradiction with 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?
The description is dense with useful information and front-loaded with the core purpose. A minor reduction could be made, but every sentence adds value, so it is efficient.
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 the rich annotations, complete schema, and presence of output schema, the description covers all necessary aspects: purpose, usage, behavioral traits, parameter semantics, and output fields. No gaps.
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 has 100% coverage with descriptions. The description adds context: group_id comes from list_accounts and account_id is from get_publish_options, and explains their roles. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches live TikTok publish options for a connected account, specifies it is TikTok-only, and notes it is required before direct posting. This distinguishes it from siblings like publish_post.
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 states it is REQUIRED before direct posting, explains how to pass group_id from list_accounts, and highlights that privacy_level_options must be chosen by the human with no default. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_publish_statusPublish job statusARead-onlyInspect
Status of a publish_post job: pending/uploading/processing/published/failed, plus the post URL when available. Drafts report 'published' when they reach the user's TikTok inbox.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | A job_id returned by publish_post. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| error | Yes | |
| job_id | Yes | |
| status | Yes | One of: pending, uploading, processing, published, failed. |
| post_id | Yes | |
| platform | Yes | |
| progress | Yes | Completion percentage (0-100). |
| platform_url | Yes | Public URL of the published post, once known. |
| platform_post_id | Yes | The platform's id for the published post, once known. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond the readOnlyHint annotation by detailing the status values, the inclusion of a post URL upon success, and the specific behavior for drafts. No contradictions found.
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 two sentences, efficiently covering the resource, possible values, and edge cases. No wasted words; key information is front-loaded.
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 simple status-checking tool with one parameter and an output schema, the description covers all essential aspects: status values, URL availability, and draft behavior. It is complete enough for an agent to understand what to expect.
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% with a clear description of the job_id parameter. The description does not add additional parameter semantics beyond what the schema already 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 clearly states the tool returns the status of a publish_post job, listing all possible statuses and noting the post URL and special behavior for drafts. This distinguishes it from sibling tools like get_publish_options and publish_post.
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 is implied that the tool should be used after calling publish_post, as it requires a job_id from that function. However, no explicit 'when-not' or alternatives are provided, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_upload_linkGet an upload linkARead-onlyInspect
Give the human a link to upload a video that lives on their device (a local file with no public URL). THIS is the answer whenever the user wants to post a file they have locally and you don't already have a public https URL for it — return this link instead of telling them you need a hosted URL. They upload on the page (already signed in), and can publish right there, or come back and ask you to publish it: call list_uploads to find the new draft, then publish_post(draft_id=...). Works for every MCP client (nothing is uploaded through the agent).
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Optional platform hint (tiktok/instagram/youtube) to pre-select the destination. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| upload_url | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant context beyond annotations: it explains that the upload happens on the page (not through the agent) and that the human can publish directly or come back later. It consistently respects the readOnlyHint annotation, as no mutation is described. No contradictions.
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 concise and well-structured: it front-loads the core purpose, then immediately gives usage guidance and workflow. No extraneous text; every sentence adds value.
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 the tool's simplicity, the description is complete. It explains the entire interaction flow, including post-upload steps, and notes that nothing is uploaded through the agent. The presence of an output schema (though not shown) complements the description for return value understanding.
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?
The input schema has 100% description coverage for its single optional parameter. The description adds no new meaning beyond the schema's own description ('Optional platform hint...'). Thus, baseline score 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 clearly states the tool's purpose: providing a link for the human to upload a local video file. It uses a specific verb ('Give'), identifies the resource ('an upload link'), and distinguishes it from sibling tools like publish_post and list_uploads by noting that this is for local files without a public URL.
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 guidance is given on when to use this tool: whenever the user wants to post a local file without a public URL. It also provides a clear workflow: return this link, later call list_uploads to find the draft, then publish_post with the draft_id. This prevents the agent from incorrectly requesting a hosted URL.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_videoGet a videoARead-onlyInspect
Get a single video by platform + native post_id — your own or a public/analyzed one. 404s if the post isn't owned by you and hasn't been analyzed yet; ingest it first with analyze_post(url).
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The platform's native post id — the `post_id` field from list_videos / search_videos (NOT the composite `id`). | |
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| include_analysis | No | Attach the video's full analysis inline. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| title | No | |
| caption | No | |
| metrics | No | |
| post_id | Yes | |
| duration | No | |
| platform | Yes | |
| post_url | No | |
| owned_by_user | No | |
| thumbnail_url | No | |
| analysis_preview | No | |
| creator_username | No | |
| post_created_time | No | |
| analysis_available | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavior: returns 404 if post not owned and not analyzed, and provides a prerequisite (use analyze_post). Complements the readOnlyHint and openWorldHint annotations with concrete details, adding significant context beyond 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?
Two sentences, no wasted words. First sentence clearly states purpose, second adds essential behavioral note. Efficient and well-structured.
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 simple retrieval tool with output schema, the description covers purpose, unique behavior, and prerequisites. No gaps; it's complete.
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 baseline is 3. The description reinforces that post_id is native and platform is case-insensitive but adds no new information beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a single video by platform and native post_id. Specifies scope ('your own or a public/analyzed one') and distinguishes from siblings by mentioning the 404 condition and the alternative analyze_post.
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 states when to use (to get a video by platform+post_id) and covers an edge case (404 for unanalyzed non-owned posts, advising use of analyze_post). Could be improved by directly referencing sibling tools like list_videos or get_video_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_video_analysisGet video analysisARead-onlyInspect
Get the full analysis (incl. scene breakdown) for a video — owned or public/competitor.
Pass platform and post_id separately (the native post_id from analyze_post or
list_videos — not the composite id field). Deep analysis runs async (~30-60s): right
after analyze_post this returns {"status": "pending", "retry_after_seconds": N} — that is
expected, not an error. Wait that long and call again until you get the full analysis. A
genuine 404 means the post was never analyzed — call analyze_post(url) first.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | The platform's native post id — the `post_id` from analyze_post / list_videos. Pass platform and post_id separately, NOT the composite `id`. | |
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotation, the description explains async behavior, the pending response shape, retry timing, and the 404 failure mode. The agent knows exactly what to expect and how to react.
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, then required parameters, then async behavior, then error handling. Each sentence adds value without redundancy.
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?
Complete for a read-only retrieval tool: covers what it returns, how to call it, what response to expect, and how to distinguish not-yet-ready from never-analyzed. An agent has everything needed to use it 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?
The schema already documents platform as allowed values and post_id as native ID, but the description adds the critical guidance to pass platform and post_id separately rather than the composite id, and clarifies that post_id comes from analyze_post/list_videos.
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: getting the full video analysis, including scene breakdown, for owned or public/competitor videos. It clearly distinguishes this retrieval tool from analyze_post, which is referenced as the trigger for analysis.
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?
Provides explicit instructions: use native post_id from analyze_post/list_videos, not the composite id; wait retry_after_seconds after a pending response; call analyze_post if a 404 means no analysis exists. This gives the agent a complete decision path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsList connected accountsARead-onlyInspect
List the caller's connected social accounts (optional platform filter). Each
account_id can be passed to get_account_metrics / list_videos to scope to that account.
Accounts are annotated with their account group (brand/workspace) and the envelope
includes the caller's groups; pass group_id to filter to one group's accounts.
When the list is empty, point the user at connect_url to link an account — newly
connected accounts then appear here automatically on the same token (no re-auth).
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | Optional account-group (brand) id from list_accounts. Omit to use the default group. | |
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| groups | No | The caller's account groups (brands/workspaces) — pass a group_id to list_accounts / get_content_profile / get_publish_options / publish_post to scope to one. |
| reason | No | Present only when accounts is empty. |
| accounts | Yes | |
| connect_url | Yes | Where the user connects (more) social accounts. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that accounts have groups, the envelope includes groups, and newly connected accounts appear automatically. It doesn't contradict 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?
The description is four sentences with the main purpose in the first sentence. It's efficiently structured without redundant 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?
The description covers the main use cases, including empty lists and filtering, but doesn't mention pagination. However, the presence of an output schema may address that.
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%, but the description adds value by explaining where to obtain group_id (from the output itself) and how platform filtering works, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the caller's connected social accounts with an optional platform filter. It distinguishes itself from siblings like get_account (singular) and list_videos (different resource) by specifying the resource and scope.
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?
The description provides usage context by explaining how account_id and group_id can be used in other tools, and advises pointing the user to connect_url when the list is empty. It doesn't explicitly exclude alternatives but the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_creator_videosList a creator's videosARead-onlyInspect
List a public/competitor creator's videos by platform + handle. Sort by 'recent' or 'top' (best-performing); optionally with analysis inline. Only returns creators already in the analysis library — for one you haven't ingested yet this returns reason="creator_not_in_library" with a next_step of analyze_creator(platform, username), not an error. When more videos exist beyond this page the response includes next_cursor — pass it back as cursor (same sort/filters) to fetch the next page; when next_cursor is absent you have everything.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ordering: 'recent' (newest first) or 'top' (best-performing). | recent |
| limit | No | Maximum number of videos per page (default 12). | |
| cursor | No | Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page. | |
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| username | Yes | The creator's public handle, e.g. 'natgeo' (no leading @). | |
| include_analysis | No | Attach each video's full analysis inline (heavier response). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds specific behavioral details: no error but a next_step response, pagination with next_cursor, and that it only works for ingested creators, all without contradiction.
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 appropriately sized (two paragraphs), front-loaded with core purpose, and every sentence adds value without redundancy.
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 the complexity (6 params, pagination, error handling) and the presence of an output schema, the description covers all necessary aspects: purpose, error message, pagination, and sorting, making it fully complete for effective tool use.
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?
Input schema covers 100% of parameters with descriptions, but the description adds significant meaning: explains 'sort' enum semantics, cursor usage, and the effect of include_analysis, improving the agent's understanding beyond the schema alone.
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 clearly states 'List a public/competitor creator's videos by platform + handle' using a specific verb and resource, and implicitly distinguishes from siblings like list_videos and analyze_creator.
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 (for creators already in the analysis library) and what to do if not (use analyze_creator). It also explains pagination and sorting alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_similar_videosFind similar videosARead-onlyInspect
Find public/competitor videos similar to a reference video, by content embedding.
Identify the reference video by platform + post_id (its native id from list_videos /
get_video). Returns {"videos": [...]}; if the reference post can't be used yet (no
embedding) or isn't found, it returns an empty list with a reason rather than erroring.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of similar videos to return (default 8). | |
| post_id | Yes | The reference post's native post_id (from list_videos / get_video). Similarity is computed from this post's content embedding. | |
| platform | Yes | Target platform — instagram, tiktok, or youtube (case-insensitive). | |
| include_analysis | No | Attach each video's full analysis inline (heavier response). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when videos is empty — why it is empty. |
| videos | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavior beyond the readOnlyHint/openWorldHint annotations: it describes the return shape and the key edge case where an unusable or missing reference post returns an empty list with a `reason` instead of erroring. This helps the agent anticipate failure semantics without contradicting 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?
The description is compact and front-loaded: the first sentence gives the core purpose and method, and the second covers identification, return shape, and edge behavior. Every clause earns its place with no wasted words.
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 the rich input schema, output schema, and annotations, the description covers everything an agent needs to invoke the tool correctly: what it finds, how the reference is identified, where IDs come from, and what happens when the reference is unavailable. No critical behavioral or input context 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%, so the baseline is 3, but the description adds meaning by explaining that post_id must be the reference post's native id from list_videos / get_video and that similarity depends on its content embedding. This prevents misuse beyond what the individual property descriptions already say.
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: 'Find public/competitor videos similar to a reference video, by content embedding.' It clearly distinguishes itself from siblings like search_videos and list_videos by focusing on embedding-based similarity and by naming the identifying inputs (platform + post_id).
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?
Provides clear context: use it to find similar videos from a reference identified by platform + post_id, with the source of those IDs explicitly given as list_videos / get_video. It stops short of explicitly naming alternatives or when-not-to-use conditions, so it is clear but not fully exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_uploadsList your uploaded draftsARead-onlyInspect
List the caller's uploaded draft videos (newest first) so you can publish one after they upload via get_upload_link. Pass a returned draft_id to publish_post(draft_id=...). The newest is usually 'the one I just uploaded'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max drafts to return (default 10). |
Output Schema
| Name | Required | Description |
|---|---|---|
| uploads | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations set readOnlyHint=true, and the description reinforces the read-only nature by saying 'list'. It adds ordering ('newest first'), which is behavioral. No contradictions.
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 two sentences with no redundancy. It front-loads the purpose and embeds guidance efficiently.
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 simple list tool with one parameter and a clear workflow context (upload then publish), the description is complete. It covers the output as draft IDs and their usage.
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% for the single parameter (limit), so the baseline is 3. The description provides usage context linking output to publish_post but does not add meaning beyond the schema's default and max description.
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 clearly states the action (list), resource (uploaded draft videos), and ordering (newest first). It distinguishes from sibling tools like list_videos and list_creator_videos by specifying 'uploaded drafts' and associating with the upload workflow.
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?
The description explains when to use: after a user uploads via get_upload_link, to obtain a draft_id for publishing with publish_post. It also notes that the newest draft is typically the one just uploaded, providing helpful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_videosList your videosARead-onlyInspect
List the caller's own videos from connected accounts.
Filter by platform and/or a free-text query, scope to one connected account_id (from list_accounts), and sort by 'recent' or 'top' (best-performing). Returns {"videos": [...]}; an empty list carries a reason — "no_connected_accounts" (with a connect_url) vs. "no_matching_videos" — so you can tell "nothing connected" from "nothing matched". When more videos exist beyond this page the response includes next_cursor — pass it back as cursor (same sort/filters) to fetch the next page; when next_cursor is absent you have everything.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ordering: 'recent' (newest first) or 'top' (best-performing). | recent |
| limit | No | Maximum number of videos per page (default 20). | |
| query | No | Optional free-text filter over your videos (caption / title). | |
| cursor | No | Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page. | |
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. | |
| account_id | No | A connected account_id from list_accounts. Omit to aggregate across all your accounts. | |
| include_analysis | No | Attach each video's full analysis inline (heavier response). |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when videos is empty — why it is empty. |
| videos | Yes | |
| connect_url | No | Where to connect an account; present only with reason='no_connected_accounts'. |
| next_cursor | No | Opaque cursor for the next page; present only when more results exist. Pass it back as `cursor` with the same filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already note readOnlyHint=true. Description adds behavioral details: pagination, empty list reasons, and consequences of 'include_analysis'. No contradictions.
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?
Single paragraph, concise yet covers purpose, parameters, output, and pagination. Could be slightly more structured but effectively front-loads key info.
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?
Handles 7 optional parameters, explains output structure and pagination. Missing info on authentication or rate limits, but annotations and context signals may cover that.
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% with descriptions for all 7 parameters. Description adds useful context (e.g., account_id from list_accounts, pagination cursor), but the schema already provides parameter 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?
The description explicitly states it lists the caller's own videos from connected accounts, with filtering options. It is specific and distinguishes from sibling tools like 'list_creator_videos' and 'search_videos'.
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?
Provides clear guidance on filtering by platform, query, account_id, and sorting. Explains pagination with cursor and the meaning of empty list reasons. Lacks explicit 'when not to use' but gives sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_postPublish a postAInspect
Publish content to the caller's connected account on the chosen platform. Async — returns job_id; poll get_publish_status(job_id). Rate limit: 10 calls/hour.
Media source — provide exactly one: media_url (a public https URL), draft_id (an already-uploaded SocialGPT draft), or carousel_id. If the user only has a LOCAL file on their device and you have no public URL, do NOT ask them to host it or paste a link — call get_upload_link, have them upload, then publish the resulting draft via draft_id (list_uploads returns the newest draft_id). The post_from_my_device prompt walks through this end to end.
TikTok: follow the rules from get_publish_options. post_mode='draft' sends to the TikTok inbox (the user finishes inside TikTok); post_mode='direct' publishes now and requires the full consent ritual (options_token + human-chosen privacy_level + previewed consent).
Instagram: publishes reels (media_url/draft_id) and carousels (carousel_id) immediately — no draft mode, no privacy, no TikTok ritual fields. Use share_to_feed / thumb_offset. The account must be set up for publishing (a connected Instagram professional account).
YouTube: publishes a video (media_url/draft_id) immediately — no carousels. caption becomes the video title (required). privacy is one of public | unlisted | private (default private).
| Name | Required | Description | Default |
|---|---|---|---|
| caption | No | Post caption (TikTok: 90 title / 4000 desc). For YouTube the caption becomes the video title (truncated to 100 chars). | |
| is_aigc | No | Direct mode, video: label as AI-generated (irreversible). | |
| privacy | No | YouTube: public | unlisted | private (default private). YouTube only. | |
| draft_id | No | post_id of an existing SocialGPT draft video — e.g. one the user just uploaded via get_upload_link (find it with list_uploads, newest first). | |
| group_id | No | Optional account-group (brand) id from list_accounts. Omit to use the default group. | |
| platform | Yes | Target platform. Required. 'tiktok' supports draft/direct + the consent ritual; 'instagram' publishes reels/carousels immediately (share_to_feed, thumb_offset); 'youtube' publishes a video immediately (caption=title, privacy). | |
| media_url | No | Public https URL of a video to post (downloaded server-side). Only when you already have a hosted URL — for a file on the user's device use get_upload_link then draft_id, never ask them to host it. | |
| post_mode | No | TikTok only — 'draft' (send to inbox) or 'direct' (publish now). Required for TikTok; omit for Instagram/YouTube. | |
| account_id | No | The account_id returned by get_publish_options. Omit to use the default connected TikTok account. | |
| carousel_id | No | Idea (hook) id with a generated carousel. | |
| disable_duet | No | Direct mode, video: disable duet. | |
| thumb_offset | No | Instagram reels: thumbnail offset in seconds. Instagram only. | |
| options_token | No | Direct mode: token from get_publish_options (15-min TTL). | |
| privacy_level | No | Direct mode: the human's choice from privacy_level_options. No default. | |
| share_to_feed | No | Instagram reels: also share to the main feed (default true). Instagram only. | |
| auto_add_music | No | Direct mode, carousel: auto-add recommended music. | |
| disable_stitch | No | Direct mode, video: disable stitch. | |
| disable_comment | No | Direct mode: disable comments. | |
| brand_content_toggle | No | Direct mode: paid partnership ('Paid partnership' label). | |
| brand_organic_toggle | No | Direct mode: promotes the creator's own brand. | |
| user_previewed_content | No | Direct mode attestation: the human previewed content + settings. | |
| user_expressly_consented | Yes | Attestation about the HUMAN: they explicitly approved sending exactly this content to the target platform. Never set true without asking them. |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| job_id | Yes | |
| status | Yes | Always 'pending' at creation; poll the matching status tool. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses async behavior (returns job_id, poll get_publish_status), rate limit (10 calls/hour), platform-specific quirks (TikTok draft vs direct, irreversible is_aigc label), and consent requirements. Annotations provide minimal behavioral cues; the description adds substantial context.
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 well-structured with paragraphs for general behavior, media source selection, and platform breakdowns. It is slightly verbose but every sentence serves a purpose. Front-loads key async and rate-limit info.
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 22 parameters (2 required), 100% schema coverage, and an existing output schema, the description is highly complete. It covers all platform variations, error states (e.g., user consent required), and practical workflows (local files, upload link).
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?
With 100% schema coverage, baseline is 3. The description adds meaningful context beyond the schema, such as the relationship between media_url, draft_id, and carousel_id, the TikTok consent ritual fields, and platform-specific parameter usage (e.g., share_to_feed only for Instagram).
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 clearly states it publishes content to the caller's connected account on the chosen platform. It specifies platforms (TikTok, Instagram, YouTube) and distinguishes behaviors per platform, making the tool's purpose unambiguous.
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 guidance on when to use media_url vs. draft_id vs. carousel_id, and a clear workflow for local files (avoid asking user to host). Platform-specific instructions (e.g., TikTok consent ritual, Instagram immediate publish) are provided, and when-not-to-use cases (local files) are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch your contentARead-onlyInspect
Search across your own connected-account content and return the best matches.
Each result has an id (pass it to fetch for the full item), a title, a url, and
a text snippet. This is the deep-research "search" entrypoint the ChatGPT/Claude
connectors call by convention; for semantic search over analyzed videos specifically use
search_videos. Returns {"results": [...]}; when you have no connected accounts it
returns reason="no_connected_accounts" plus a connect_url instead of results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default 10). | |
| query | Yes | Free-text query matched against your connected accounts' content (captions, titles, transcripts). | |
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when results is empty — why it is empty. |
| results | Yes | |
| connect_url | No | Where to connect an account; present only with reason='no_connected_accounts'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation (true), the description details the output format (results array with id/title/url/text) and edge case when no connected accounts (returns reason and connect_url). No destructive behavior is implied.
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?
Two concise sentences: first defines the tool's primary action, second explains output and key edge case. No wasted words.
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 the output schema (results array), the description adequately covers return fields and error condition. No additional details are needed for correct usage.
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 description adds meaningful context: query matches captions/titles/transcripts, platform is case-insensitive, defaults are noted. It reinforces schema but does not add entirely new info.
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 clearly states the tool searches across connected-account content and returns best matches. It specifies result fields (id, title, url, text snippet) and distinguishes from sibling search_videos for semantic video search.
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?
The description provides usage context: pass id to fetch for full item, and use search_videos for semantic video search. It does not explicitly state when not to use this tool, but the alternative is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosSearch analyzed videosARead-onlyInspect
Semantic search over your own ANALYZED videos — those with a completed deep analysis — ranked by relevance to the query. Prefer this over list_videos when you want videos matched by what's actually in them (hooks, scenes, topics) rather than by caption text. Returns {"videos": [...]}; an empty list carries a reason (no_connected_accounts → connect_url, or no_matching_videos). When more matches exist beyond this page the response includes next_cursor — pass it back as cursor (same query/filters) to fetch the next page; when next_cursor is absent you have everything.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of videos per page (default 10). | |
| query | Yes | What to look for inside your analyzed videos (themes, topics, on-screen content). | |
| cursor | No | Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page. | |
| platform | No | Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | No | Present only when videos is empty — why it is empty. |
| videos | Yes | |
| connect_url | No | Where to connect an account; present only with reason='no_connected_accounts'. |
| next_cursor | No | Opaque cursor for the next page; present only when more results exist. Pass it back as `cursor` with the same filters. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant detail beyond annotations: response structure, empty list reasons, pagination cursor semantics (next_cursor/cursor, same query/filters). No contradiction with readOnlyHint=true.
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, dense but clear. Second sentence combines multiple details (response shape, empty case, pagination) effectively. Slightly dense but no wasted words.
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 4-parameter tool with output schema, description covers empty responses and pagination thoroughly. Distinguishes from key sibling list_videos. Complete for its complexity.
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 covers all 4 parameters with descriptions. Description reinforces semantic search context and clarifies cursor usage for pagination, adding value beyond schema alone.
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?
Description clearly states it performs semantic search over analyzed videos, ranking by relevance. It explicitly distinguishes from list_videos by contrasting content-based vs caption-text matching.
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?
Provides explicit preference over list_videos for content-based matching. Describes empty response reasons (no_connected_accounts, no_matching_videos) and pagination behavior. Lacks exclusions for other siblings but sufficiently covers the primary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
server_infoServer infoARead-onlyInspect
Return this server's identity and capabilities: its name, version, the surface label (public-read-v1), and the full list of OAuth scopes it supports. Useful as a connectivity / capability check before calling scoped tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| scopes | Yes | All OAuth scopes this server supports. |
| surface | Yes | The tool-surface label, e.g. 'public-read-v1'. |
| version | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by listing the returned fields (name, version, etc.) and the purpose, going beyond 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?
Two sentences with no wasted words. The purpose and return values are front-loaded, making it easy for an AI to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, clear annotations, and the presence of an output schema, the description fully covers the tool's behavior and return value context.
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?
The tool has zero parameters, so the description does not need to add parameter meaning. Baseline 4 applies per guidelines.
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 specifies exactly what the tool returns: server name, version, surface label, and OAuth scopes. It also states it's for a connectivity/capability check, clearly distinguishing it from siblings like whoami.
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?
The description explicitly says 'Useful as a connectivity / capability check before calling scoped tools,' providing clear when-to-use context. It does not list alternatives, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whoamiWho am IARead-onlyInspect
Return the authenticated caller: the user id the token was issued for, the granted OAuth scopes, and the actor type. Use it to confirm which account the connector is signed in as and which scopes (and therefore which tools) you hold.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| scopes | Yes | Scopes granted to this token (sorted). |
| user_id | Yes | |
| actor_type | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true. The description adds value by detailing the returned fields (user id, scopes, actor type) and the purpose, which is beyond the annotations. No contradictions.
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?
Two sentences with no wasted words. The key information is front-loaded, and each sentence serves a distinct purpose (what it returns and when to use it).
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 no parameters and an output schema present, the description provides complete context: what the tool does, what it returns, and its use case. No gaps remain.
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?
There are no parameters; schema coverage is 100%. The description does not need to add parameter information, and the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the authenticated caller's user id, OAuth scopes, and actor type. It uses a specific verb ('Return') and resource ('authenticated caller'), and no sibling tool provides identity introspection, making it well-distinguished.
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?
The description explicitly says to use it to confirm which account the connector is signed in as and which scopes/tools are held. While it doesn't state when not to use, the context is clear for a simple identity check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
get_video_analysis1 field changed- changed
Output schema / anyOfPrevious value: -[ - { - "properties": { - "content_themes": { - "items": { - "type": "string" - }, - "title": "Content Themes", - "type": "array" - }, - "executive_summary": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Executive Summary" - }, - "hooks": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "title": "Hooks", - "type": "array" - }, - "note": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Note" - }, - "post": { - "properties": { - "analysis_available": { - "default": false, - "title": "Analysis Available", - "type": "boolean" - }, - "analysis_preview": { - "anyOf": [ - { - "additionalProperties": true, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Analysis Preview" - }, - "caption": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Caption" - }, - "creator_username": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Creator Username" - }, - "duration": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Duration" - }, - "id": { - "title": "Id", - "type": "string" - }, - "metrics": { - "anyOf": [ - { - "properties": { - "comments": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Comments" - }, - "engagement_rate": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Engagement Rate" - }, - "likes": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Likes" - }, - "saves": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Saves" - }, - "shares": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Shares" - }, - "views": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Views" - } - }, - "title": "McpPostMetrics", - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "owned_by_user": { - "default": false, - "title": "Owned By User", - "type": "boolean" - }, - "platform": { - "title": "Platform", - "type": "string" - }, - "post_created_time": { - "anyOf": [ - { - "format": "date-time", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Post Created Time" - }, - "post_id": { - "title": "Post Id", - "type": "string" - }, - "post_url": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Post Url" - }, - "thumbnail_url": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Thumbnail Url" - }, - "title": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Title" - } - }, - "required": [ - "id", - "platform", - "post_id" - ], - "title": "McpPostSummary", - "type": "object" - }, - "scenes": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "title": "Scenes", - "type": "array" - }, - "suggested_hooks": { - "items": { - "type": "string" - }, - "title": "Suggested Hooks", - "type": "array" - }, - "transcript": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Transcript" - }, - "transcript_segments": { - "anyOf": [ - { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Transcript Segments" - }, - "video_analysis": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null, - "title": "Video Analysis" - } - }, - "required": [ - "post" - ], - "title": "McpPostAnalysis", - "type": "object" - }, - { - "description": "Output of `get_video_analysis` while the deep analysis is not readable.\n\nDiscriminator vs. the completed variant (`McpPostAnalysis`): this shape has\na `status` field ('pending' or 'failed'); the completed analysis does not.\n'pending' is expected right after `analyze_post` — wait `retry_after_seconds`\nand call again.", - "properties": { - "message": { - "title": "Message", - "type": "string" - }, - "platform": { - "title": "Platform", - "type": "string" - }, - "post_id": { - "title": "Post Id", - "type": "string" - }, - "retry_after_seconds": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null, - "description": "Present only while status='pending' — how long to wait before retrying.", - "title": "Retry After Seconds" - }, - "status": { - "enum": [ - "pending", - "failed" - ], - "title": "Status", - "type": "string" - } - }, - "required": [ - "status", - "platform", - "post_id", - "message" - ], - "title": "McpAnalysisProgress", - "type": "object" - } -]New value: +[ + { + "properties": { + "audio_description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Audio Description" + }, + "content_themes": { + "items": { + "type": "string" + }, + "title": "Content Themes", + "type": "array" + }, + "executive_summary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Executive Summary" + }, + "hooks": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Hooks", + "type": "array" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Note" + }, + "post": { + "properties": { + "analysis_available": { + "default": false, + "title": "Analysis Available", + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Analysis Preview" + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Caption" + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Creator Username" + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Duration" + }, + "id": { + "title": "Id", + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Comments" + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Engagement Rate" + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Likes" + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Saves" + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Shares" + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Views" + } + }, + "title": "McpPostMetrics", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "title": "Owned By User", + "type": "boolean" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Created Time" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Url" + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Thumbnail Url" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "title": "McpPostSummary", + "type": "object" + }, + "scenes": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Scenes", + "type": "array" + }, + "suggested_hooks": { + "items": { + "type": "string" + }, + "title": "Suggested Hooks", + "type": "array" + }, + "transcript": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Transcript" + }, + "transcript_segments": { + "anyOf": [ + { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Transcript Segments" + }, + "video_analysis": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Video Analysis" + }, + "visual_description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Visual Description" + } + }, + "required": [ + "post" + ], + "title": "McpPostAnalysis", + "type": "object" + }, + { + "description": "Output of `get_video_analysis` while the deep analysis is not readable.\n\nDiscriminator vs. the completed variant (`McpPostAnalysis`): this shape has\na `status` field ('pending' or 'failed'); the completed analysis does not.\n'pending' is expected right after `analyze_post` — wait `retry_after_seconds`\nand call again.", + "properties": { + "message": { + "title": "Message", + "type": "string" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "retry_after_seconds": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only while status='pending' — how long to wait before retrying.", + "title": "Retry After Seconds" + }, + "status": { + "enum": [ + "pending", + "failed" + ], + "title": "Status", + "type": "string" + } + }, + "required": [ + "status", + "platform", + "post_id", + "message" + ], + "title": "McpAnalysisProgress", + "type": "object" + } +]
- Changed
list_similar_videos1 field changed- changed
Output schema / properties / videos / items / properties / analysis / anyOfPrevious value: -[ - { - "properties": { - "content_themes": { - "items": { - "type": "string" - }, - "type": "array" - }, - "executive_summary": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "hooks": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - "note": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "post": { - "properties": { - "analysis_available": { - "default": false, - "type": "boolean" - }, - "analysis_preview": { - "anyOf": [ - { - "additionalProperties": true, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "caption": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "creator_username": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "duration": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "id": { - "type": "string" - }, - "metrics": { - "anyOf": [ - { - "properties": { - "comments": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "engagement_rate": { - "anyOf": [ - { - "type": "number" - }, - { - "type": "null" - } - ], - "default": null - }, - "likes": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "saves": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "shares": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - }, - "views": { - "anyOf": [ - { - "type": "integer" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "type": "object" - }, - { - "type": "null" - } - ], - "default": null - }, - "owned_by_user": { - "default": false, - "type": "boolean" - }, - "platform": { - "type": "string" - }, - "post_created_time": { - "anyOf": [ - { - "format": "date-time", - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "post_id": { - "type": "string" - }, - "post_url": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "thumbnail_url": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "title": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "required": [ - "id", - "platform", - "post_id" - ], - "type": "object" - }, - "scenes": { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - "suggested_hooks": { - "items": { - "type": "string" - }, - "type": "array" - }, - "transcript": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - }, - "transcript_segments": { - "anyOf": [ - { - "items": { - "additionalProperties": true, - "type": "object" - }, - "type": "array" - }, - { - "type": "null" - } - ], - "default": null - }, - "video_analysis": { - "anyOf": [ - { - "type": "string" - }, - { - "type": "null" - } - ], - "default": null - } - }, - "required": [ - "post" - ], - "type": "object" - }, - { - "type": "null" - } -]New value: +[ + { + "properties": { + "audio_description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "content_themes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "executive_summary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "hooks": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post": { + "properties": { + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "type": "object" + }, + "scenes": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "suggested_hooks": { + "items": { + "type": "string" + }, + "type": "array" + }, + "transcript": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "transcript_segments": { + "anyOf": [ + { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "video_analysis": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "visual_description": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "post" + ], + "type": "object" + }, + { + "type": "null" + } +]
26 tool updates
- Changed
analyze_creator4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `analyze_creator` / `publish_post` — an async job was queued." - added
Output schema / propertiesAdded value: +{ + "job_id": { + "type": "string" + }, + "note": { + "type": "string" + }, + "status": { + "description": "Always 'pending' at creation; poll the matching status tool.", + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "job_id", + "status", + "note" +]
- Changed
analyze_post4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `analyze_post`. Deep analysis runs async — poll\n`get_video_analysis(platform, post_id)`; when `is_new_creator` is true a\nbackfill job also runs (poll `get_analysis_status(ingest_job_id)`)." - added
Output schema / propertiesAdded value: +{ + "analysis_status": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Deep-analysis job status at ingest time (e.g. 'pending')." + }, + "creator_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "ingest_job_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Creator-backfill job id; null unless a new creator was created." + }, + "is_new_creator": { + "type": "boolean" + }, + "note": { + "type": "string" + }, + "post": { + "description": "The post just queued by `analyze_post`.", + "properties": { + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "Composite resource id ('<platform>:<post_id>') usable with `fetch`." + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "post_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The platform-native post id — pass to get_video_analysis." + } + }, + "required": [ + "id", + "platform", + "post_id", + "caption", + "creator_username" + ], + "type": "object" + } +} - added
Output schema / requiredAdded value: +[ + "post", + "creator_id", + "is_new_creator", + "analysis_status", + "ingest_job_id", + "note" +]
- Changed
fetch3 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / propertiesAdded value: +{ + "id": { + "type": "string" + }, + "metadata": { + "additionalProperties": true, + "type": "object" + }, + "text": { + "type": "string" + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "id", + "title", + "text", + "url" +]
- Changed
get_account4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"One of the caller's connected social accounts. `account_id` is the handle\nother tools accept (e.g. get_account_metrics, list_videos)." - added
Output schema / propertiesAdded value: +{ + "account_group_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "account_group_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "account_id": { + "type": "string" + }, + "display_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "is_verified": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "profile_link": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile_picture_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "username": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "account_id", + "platform", + "username" +]
- Changed
get_account_metrics4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_account_metrics`. `reason`='account_not_found' appears\nonly when the requested account_id resolved to none of the caller's\naccounts (then platforms/series/metrics are empty)." - added
Output schema / propertiesAdded value: +{ + "account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The account_id the caller passed (null = all accounts)." + }, + "granularity": { + "enum": [ + "daily", + "weekly", + "raw" + ], + "type": "string" + }, + "metrics": { + "additionalProperties": true, + "description": "Legacy per-platform {columns, data} matrix (back-compat).", + "type": "object" + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "post_limit": { + "type": "integer" + }, + "reason": { + "anyOf": [ + { + "const": "account_not_found", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when the requested account_id could not be resolved." + }, + "series": { + "additionalProperties": { + "items": { + "additionalProperties": true, + "description": "One time-series point. Metric columns (views, like_count,\nfollower_count, ...) are carried as additional properties; `bucket` is\npresent only for 'daily'/'weekly' granularity.", + "properties": { + "bucket": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Bucket label (ISO date or ISO year-week); absent for granularity='raw'." + }, + "timestamp": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Snapshot time of this point." + } + }, + "type": "object" + }, + "type": "array" + }, + "description": "Per-platform typed time series.", + "type": "object" + }, + "window_days": { + "type": "integer" + } +} - added
Output schema / requiredAdded value: +[ + "account_id", + "platform", + "window_days", + "post_limit", + "granularity", + "platforms", + "series", + "metrics" +]
- Changed
get_analysis_status4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_analysis_status` — a creator-ingest job's progress." - added
Output schema / propertiesAdded value: +{ + "creator_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "error": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "job_id": { + "type": "string" + }, + "note": { + "type": "string" + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "progress": { + "description": "Completion percentage (0-100).", + "type": "integer" + }, + "result": { + "default": null, + "title": "Result" + }, + "status": { + "description": "One of: pending, scraping, completed, failed.", + "type": "string" + }, + "username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + } +} - added
Output schema / requiredAdded value: +[ + "job_id", + "status", + "progress", + "creator_id", + "platform", + "username", + "error", + "note" +]
- Changed
get_content_profile5 fields changed- added
Input schema / properties / group_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional account-group (brand) id from list_accounts. Omit to use the default group." +} - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_content_profile`. When `content_profile` is null,\n`reason` says why: 'not_connected' (no accounts/onboarding yet) or\n'not_synthesized' (connected but DNA not generated yet)." - added
Output schema / propertiesAdded value: +{ + "content_profile": { + "anyOf": [ + { + "description": "The caller's content DNA — empirical persona + prescriptive playbook.", + "properties": { + "persona": { + "default": null, + "title": "Persona" + }, + "playbook": { + "default": null, + "title": "Playbook" + } + }, + "type": "object" + }, + { + "type": "null" + } + ] + }, + "reason": { + "anyOf": [ + { + "enum": [ + "not_synthesized", + "not_connected" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when content_profile is null — why it is null." + } +} - added
Output schema / requiredAdded value: +[ + "content_profile" +]
- Changed
get_creator2 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / anyOfAdded value: +[ + { + "description": "A public/competitor creator's profile (analysis:read:public).", + "properties": { + "account_type": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Account Type" + }, + "bio": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Bio" + }, + "content_dna": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Content Dna" + }, + "creator_id": { + "title": "Creator Id", + "type": "string" + }, + "display_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Display Name" + }, + "follower_count": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Follower Count" + }, + "following_count": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Following Count" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "profile_picture_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Profile Picture Url" + }, + "username": { + "title": "Username", + "type": "string" + }, + "videos_analyzed_count": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Videos Analyzed Count" + } + }, + "required": [ + "creator_id", + "platform", + "username" + ], + "title": "McpCreatorProfile", + "type": "object" + }, + { + "description": "Soft, non-error output of `get_creator` when the creator isn't in the\nanalysis library yet. Discriminator vs. the profile variant\n(`McpCreatorProfile`): `reason` == 'creator_not_in_library'. Recover by\ncalling the tool named in `next_step`.", + "properties": { + "hint": { + "title": "Hint", + "type": "string" + }, + "next_step": { + "const": "analyze_creator", + "description": "The tool to call to ingest this creator.", + "title": "Next Step", + "type": "string" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "reason": { + "const": "creator_not_in_library", + "title": "Reason", + "type": "string" + }, + "username": { + "title": "Username", + "type": "string" + } + }, + "required": [ + "reason", + "platform", + "username", + "next_step", + "hint" + ], + "title": "McpCreatorNotInLibrary", + "type": "object" + } +]
- Changed
get_follower_history4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_follower_history`. `reason`='account_not_found' appears\nonly when the requested account_id resolved to none of the caller's\naccounts." - added
Output schema / propertiesAdded value: +{ + "account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The account_id the caller passed (null = all accounts)." + }, + "granularity": { + "enum": [ + "daily", + "weekly", + "raw" + ], + "type": "string" + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "reason": { + "anyOf": [ + { + "const": "account_not_found", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when the requested account_id could not be resolved." + }, + "series": { + "additionalProperties": { + "items": { + "additionalProperties": true, + "description": "One time-series point. Metric columns (views, like_count,\nfollower_count, ...) are carried as additional properties; `bucket` is\npresent only for 'daily'/'weekly' granularity.", + "properties": { + "bucket": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Bucket label (ISO date or ISO year-week); absent for granularity='raw'." + }, + "timestamp": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Snapshot time of this point." + } + }, + "type": "object" + }, + "type": "array" + }, + "description": "Per-platform typed time series.", + "type": "object" + }, + "window_days": { + "type": "integer" + } +} - added
Output schema / requiredAdded value: +[ + "account_id", + "platform", + "window_days", + "granularity", + "platforms", + "series" +]
- Changed
get_growth_summary4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_growth_summary`. `reason`='account_not_found' appears\nonly when the requested account_id resolved to none of the caller's\naccounts." - added
Output schema / propertiesAdded value: +{ + "account_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "description": "The account_id the caller passed (null = all accounts)." + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "platforms": { + "items": { + "type": "string" + }, + "type": "array" + }, + "reason": { + "anyOf": [ + { + "const": "account_not_found", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when the requested account_id could not be resolved." + }, + "summary": { + "additionalProperties": { + "additionalProperties": { + "description": "Window summary for one metric (see `get_growth_summary`).", + "properties": { + "accelerating": { + "anyOf": [ + { + "type": "boolean" + }, + { + "type": "null" + } + ], + "description": "True when the recent half moved more than the prior half." + }, + "change": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "number" + } + ] + }, + "current": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "number" + } + ] + }, + "pct_change": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Percent change start→current; null when start is 0." + }, + "prior_change": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Change over the prior half of the window." + }, + "recent_change": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "number" + }, + { + "type": "null" + } + ], + "description": "Change over the recent half of the window." + }, + "start": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "number" + } + ] + } + }, + "required": [ + "start", + "current", + "change", + "pct_change", + "recent_change", + "prior_change", + "accelerating" + ], + "type": "object" + }, + "type": "object" + }, + "description": "Per-platform, per-metric window summaries.", + "type": "object" + }, + "window_days": { + "type": "integer" + } +} - added
Output schema / requiredAdded value: +[ + "account_id", + "platform", + "window_days", + "platforms", + "summary" +]
- Changed
get_post_metrics_history4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `get_post_metrics_history`. `reason`='no_metrics_history'\nappears only when `series` is empty." - added
Output schema / propertiesAdded value: +{ + "granularity": { + "enum": [ + "daily", + "weekly", + "raw" + ], + "type": "string" + }, + "platform": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ] + }, + "post_id": { + "type": "string" + }, + "reason": { + "anyOf": [ + { + "const": "no_metrics_history", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when series is empty." + }, + "series": { + "items": { + "additionalProperties": true, + "description": "One time-series point. Metric columns (views, like_count,\nfollower_count, ...) are carried as additional properties; `bucket` is\npresent only for 'daily'/'weekly' granularity.", + "properties": { + "bucket": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Bucket label (ISO date or ISO year-week); absent for granularity='raw'." + }, + "timestamp": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Snapshot time of this point." + } + }, + "type": "object" + }, + "type": "array" + }, + "window_days": { + "type": "integer" + } +} - added
Output schema / requiredAdded value: +[ + "platform", + "post_id", + "window_days", + "granularity", + "series" +]
- Added
get_publish_options - Added
get_publish_status - Added
get_upload_link - Changed
get_video3 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / propertiesAdded value: +{ + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } +} - added
Output schema / requiredAdded value: +[ + "id", + "platform", + "post_id" +]
- Changed
get_video_analysis2 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / anyOfAdded value: +[ + { + "properties": { + "content_themes": { + "items": { + "type": "string" + }, + "title": "Content Themes", + "type": "array" + }, + "executive_summary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Executive Summary" + }, + "hooks": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Hooks", + "type": "array" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Note" + }, + "post": { + "properties": { + "analysis_available": { + "default": false, + "title": "Analysis Available", + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Analysis Preview" + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Caption" + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Creator Username" + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Duration" + }, + "id": { + "title": "Id", + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Comments" + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Engagement Rate" + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Likes" + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Saves" + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Shares" + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Views" + } + }, + "title": "McpPostMetrics", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "title": "Owned By User", + "type": "boolean" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Created Time" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Url" + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Thumbnail Url" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "title": "McpPostSummary", + "type": "object" + }, + "scenes": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "title": "Scenes", + "type": "array" + }, + "suggested_hooks": { + "items": { + "type": "string" + }, + "title": "Suggested Hooks", + "type": "array" + }, + "transcript": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Transcript" + }, + "transcript_segments": { + "anyOf": [ + { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Transcript Segments" + }, + "video_analysis": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Video Analysis" + } + }, + "required": [ + "post" + ], + "title": "McpPostAnalysis", + "type": "object" + }, + { + "description": "Output of `get_video_analysis` while the deep analysis is not readable.\n\nDiscriminator vs. the completed variant (`McpPostAnalysis`): this shape has\na `status` field ('pending' or 'failed'); the completed analysis does not.\n'pending' is expected right after `analyze_post` — wait `retry_after_seconds`\nand call again.", + "properties": { + "message": { + "title": "Message", + "type": "string" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "retry_after_seconds": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only while status='pending' — how long to wait before retrying.", + "title": "Retry After Seconds" + }, + "status": { + "enum": [ + "pending", + "failed" + ], + "title": "Status", + "type": "string" + } + }, + "required": [ + "status", + "platform", + "post_id", + "message" + ], + "title": "McpAnalysisProgress", + "type": "object" + } +]
- Changed
list_accounts5 fields changed- added
Input schema / properties / group_idAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Optional account-group (brand) id from list_accounts. Omit to use the default group." +} - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `list_accounts`. `reason`='no_connected_accounts' appears only\nwhen `accounts` is empty; `connect_url` is always present." - added
Output schema / propertiesAdded value: +{ + "accounts": { + "items": { + "description": "One of the caller's connected social accounts. `account_id` is the handle\nother tools accept (e.g. get_account_metrics, list_videos).", + "properties": { + "account_group_id": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "account_group_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "account_id": { + "type": "string" + }, + "display_name": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "is_verified": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "profile_link": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "profile_picture_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "username": { + "type": "string" + } + }, + "required": [ + "account_id", + "platform", + "username" + ], + "type": "object" + }, + "type": "array" + }, + "connect_url": { + "description": "Where the user connects (more) social accounts.", + "type": "string" + }, + "groups": { + "description": "The caller's account groups (brands/workspaces) — pass a group_id to list_accounts / get_content_profile / get_publish_options / publish_post to scope to one.", + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "reason": { + "anyOf": [ + { + "const": "no_connected_accounts", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when accounts is empty." + } +} - added
Output schema / requiredAdded value: +[ + "accounts", + "connect_url" +]
- Changed
list_creator_videos4 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page." +} - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of videos to return (default 12)."New value: +"Maximum number of videos per page (default 12)." - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / anyOfAdded value: +[ + { + "description": "Output of `list_creator_videos` for an ingested creator.\n`reason`='creator_has_no_indexed_videos' appears only when `videos` is\nempty. `next_cursor` appears only when the listing was truncated.", + "properties": { + "next_cursor": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque cursor for the next page; present only when more results exist. Pass it back as `cursor` with the same filters.", + "title": "Next Cursor" + }, + "reason": { + "anyOf": [ + { + "const": "creator_has_no_indexed_videos", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when videos is empty.", + "title": "Reason" + }, + "videos": { + "items": { + "properties": { + "analysis_available": { + "default": false, + "title": "Analysis Available", + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Analysis Preview" + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Caption" + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Creator Username" + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Duration" + }, + "id": { + "title": "Id", + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Comments" + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Engagement Rate" + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Likes" + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Saves" + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Shares" + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Views" + } + }, + "title": "McpPostMetrics", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "title": "Owned By User", + "type": "boolean" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Created Time" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Url" + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Thumbnail Url" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "title": "McpPostSummary", + "type": "object" + }, + "title": "Videos", + "type": "array" + } + }, + "required": [ + "videos" + ], + "title": "McpCreatorVideosEnvelope", + "type": "object" + }, + { + "description": "Output of `list_creator_videos` when the creator isn't in the analysis\nlibrary yet (same discriminator as `McpCreatorNotInLibrary`, plus an empty\n`videos` list).", + "properties": { + "hint": { + "title": "Hint", + "type": "string" + }, + "next_step": { + "const": "analyze_creator", + "description": "The tool to call to ingest this creator.", + "title": "Next Step", + "type": "string" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "reason": { + "const": "creator_not_in_library", + "title": "Reason", + "type": "string" + }, + "username": { + "title": "Username", + "type": "string" + }, + "videos": { + "default": [], + "items": { + "properties": { + "analysis_available": { + "default": false, + "title": "Analysis Available", + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Analysis Preview" + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Caption" + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Creator Username" + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Duration" + }, + "id": { + "title": "Id", + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Comments" + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Engagement Rate" + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Likes" + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Saves" + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Shares" + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Views" + } + }, + "title": "McpPostMetrics", + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "title": "Owned By User", + "type": "boolean" + }, + "platform": { + "title": "Platform", + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Created Time" + }, + "post_id": { + "title": "Post Id", + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Post Url" + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Thumbnail Url" + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Title" + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "title": "McpPostSummary", + "type": "object" + }, + "title": "Videos", + "type": "array" + } + }, + "required": [ + "reason", + "platform", + "username", + "next_step", + "hint" + ], + "title": "McpCreatorVideosNotInLibrary", + "type": "object" + } +]
- Changed
list_similar_videos4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `list_similar_videos`. `reason` appears only when `videos` is\nempty: 'source_not_analyzed' (reference post has no embedding yet) or\n'no_similar_videos'." - added
Output schema / propertiesAdded value: +{ + "reason": { + "anyOf": [ + { + "enum": [ + "source_not_analyzed", + "no_similar_videos" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when videos is empty — why it is empty." + }, + "videos": { + "items": { + "description": "A similar/competitor post; `analysis` is attached (possibly null) only\nwhen the tool was called with include_analysis=true.", + "properties": { + "analysis": { + "anyOf": [ + { + "properties": { + "content_themes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "executive_summary": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "hooks": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "note": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post": { + "properties": { + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "type": "object" + }, + "scenes": { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + "suggested_hooks": { + "items": { + "type": "string" + }, + "type": "array" + }, + "transcript": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "transcript_segments": { + "anyOf": [ + { + "items": { + "additionalProperties": true, + "type": "object" + }, + "type": "array" + }, + { + "type": "null" + } + ], + "default": null + }, + "video_analysis": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "post" + ], + "type": "object" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Full analysis; only present when include_analysis=true (null when unavailable)." + }, + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "type": "object" + }, + "type": "array" + } +} - added
Output schema / requiredAdded value: +[ + "videos" +]
- Added
list_uploads - Changed
list_videos6 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page." +} - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of videos to return (default 20)."New value: +"Maximum number of videos per page (default 20)." - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `list_videos` / `search_videos`. `reason` appears only when\n`videos` is empty: 'no_matching_videos' (accounts connected, nothing\nmatched) or 'no_connected_accounts' (then `connect_url` is also present).\n`next_cursor` appears only when the listing was truncated — its absence is\nthe \"you have everything\" signal." - added
Output schema / propertiesAdded value: +{ + "connect_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Where to connect an account; present only with reason='no_connected_accounts'." + }, + "next_cursor": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque cursor for the next page; present only when more results exist. Pass it back as `cursor` with the same filters." + }, + "reason": { + "anyOf": [ + { + "enum": [ + "no_matching_videos", + "no_connected_accounts" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when videos is empty — why it is empty." + }, + "videos": { + "items": { + "properties": { + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "type": "object" + }, + "type": "array" + } +} - added
Output schema / requiredAdded value: +[ + "videos" +]
- Added
publish_post - Changed
search4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `search`. `reason` appears only when `results` is empty:\n'no_matching_content' (accounts connected, nothing matched) or\n'no_connected_accounts' (then `connect_url` is also present)." - added
Output schema / propertiesAdded value: +{ + "connect_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Where to connect an account; present only with reason='no_connected_accounts'." + }, + "reason": { + "anyOf": [ + { + "enum": [ + "no_matching_content", + "no_connected_accounts" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when results is empty — why it is empty." + }, + "results": { + "items": { + "properties": { + "id": { + "type": "string" + }, + "metadata": { + "additionalProperties": true, + "type": "object" + }, + "text": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "type": "string" + }, + "url": { + "type": "string" + } + }, + "required": [ + "id", + "title", + "url" + ], + "type": "object" + }, + "type": "array" + } +} - added
Output schema / requiredAdded value: +[ + "results" +]
- Changed
search_videos6 fields changed- added
Input schema / properties / cursorAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque pagination cursor — pass the next_cursor from the previous page verbatim to fetch the next page (keep the same sort/filters). Omit for the first page." +} - changed
Input schema / properties / limit / descriptionPrevious value: -"Maximum number of videos to return (default 10)."New value: +"Maximum number of videos per page (default 10)." - removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `list_videos` / `search_videos`. `reason` appears only when\n`videos` is empty: 'no_matching_videos' (accounts connected, nothing\nmatched) or 'no_connected_accounts' (then `connect_url` is also present).\n`next_cursor` appears only when the listing was truncated — its absence is\nthe \"you have everything\" signal." - added
Output schema / propertiesAdded value: +{ + "connect_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Where to connect an account; present only with reason='no_connected_accounts'." + }, + "next_cursor": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Opaque cursor for the next page; present only when more results exist. Pass it back as `cursor` with the same filters." + }, + "reason": { + "anyOf": [ + { + "enum": [ + "no_matching_videos", + "no_connected_accounts" + ], + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "description": "Present only when videos is empty — why it is empty." + }, + "videos": { + "items": { + "properties": { + "analysis_available": { + "default": false, + "type": "boolean" + }, + "analysis_preview": { + "anyOf": [ + { + "additionalProperties": true, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "caption": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "creator_username": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "duration": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "id": { + "type": "string" + }, + "metrics": { + "anyOf": [ + { + "properties": { + "comments": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "engagement_rate": { + "anyOf": [ + { + "type": "number" + }, + { + "type": "null" + } + ], + "default": null + }, + "likes": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "saves": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "shares": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + }, + "views": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "type": "object" + }, + { + "type": "null" + } + ], + "default": null + }, + "owned_by_user": { + "default": false, + "type": "boolean" + }, + "platform": { + "type": "string" + }, + "post_created_time": { + "anyOf": [ + { + "format": "date-time", + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "post_id": { + "type": "string" + }, + "post_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "thumbnail_url": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + }, + "title": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null + } + }, + "required": [ + "id", + "platform", + "post_id" + ], + "type": "object" + }, + "type": "array" + } +} - added
Output schema / requiredAdded value: +[ + "videos" +]
- Changed
server_info4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `server_info`." - added
Output schema / propertiesAdded value: +{ + "name": { + "type": "string" + }, + "scopes": { + "description": "All OAuth scopes this server supports.", + "items": { + "type": "string" + }, + "type": "array" + }, + "surface": { + "description": "The tool-surface label, e.g. 'public-read-v1'.", + "type": "string" + }, + "version": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "name", + "version", + "surface", + "scopes" +]
- Changed
whoami4 fields changed- removed
Output schema / additionalPropertiesRemoved value: -true - added
Output schema / descriptionAdded value: +"Output of `whoami` — the authenticated caller." - added
Output schema / propertiesAdded value: +{ + "actor_type": { + "type": "string" + }, + "scopes": { + "description": "Scopes granted to this token (sorted).", + "items": { + "type": "string" + }, + "type": "array" + }, + "user_id": { + "type": "string" + } +} - added
Output schema / requiredAdded value: +[ + "user_id", + "scopes", + "actor_type" +]
18 tool updates
- Changed
analyze_creator3 fields changed- added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / post_limit / descriptionAdded value: +"How many of the creator's recent posts to scrape + analyze (1–30, default 10; clamped)." - added
Input schema / properties / username / descriptionAdded value: +"The creator's public handle, e.g. 'natgeo' (no leading @)."
- Changed
analyze_post1 field changed- added
Input schema / properties / post_url / descriptionAdded value: +"Full public URL of a single TikTok, YouTube, or Instagram post / reel / video."
- Changed
fetch1 field changed- added
Input schema / properties / id / descriptionAdded value: +"A resource id returned by `search` (the `id` field of a search result)."
- Changed
get_account1 field changed- added
Input schema / properties / account_id / descriptionAdded value: +"An account_id from list_accounts."
- Changed
get_account_metrics5 fields changed- added
Input schema / properties / account_id / descriptionAdded value: +"A connected account_id from list_accounts. Omit to aggregate across all your accounts." - added
Input schema / properties / granularity / descriptionAdded value: +"Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape)." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / post_limit / descriptionAdded value: +"How many recent posts form the baseline (1–100, default 20; clamped)." - added
Input schema / properties / window_days / descriptionAdded value: +"Trailing window in days (1–365, default 28; out-of-range values are clamped)."
- Changed
get_analysis_status1 field changed- added
Input schema / properties / job_id / descriptionAdded value: +"The job_id (a UUID) returned by analyze_creator or analyze_post."
- Changed
get_creator2 fields changed- added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / username / descriptionAdded value: +"The creator's public handle, e.g. 'natgeo' (no leading @)."
- Changed
get_follower_history4 fields changed- added
Input schema / properties / account_id / descriptionAdded value: +"A connected account_id from list_accounts. Omit to aggregate across all your accounts." - added
Input schema / properties / granularity / descriptionAdded value: +"Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape)." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / window_days / descriptionAdded value: +"Trailing window in days (1–365, default 90; out-of-range values are clamped)."
- Changed
get_growth_summary3 fields changed- added
Input schema / properties / account_id / descriptionAdded value: +"A connected account_id from list_accounts. Omit to aggregate across all your accounts." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / window_days / descriptionAdded value: +"Trailing window in days (1–365, default 90; out-of-range values are clamped)."
- Changed
get_post_metrics_history4 fields changed- added
Input schema / properties / granularity / descriptionAdded value: +"Time-series bucketing: 'daily' (default), 'weekly', or 'raw' (every scrape)." - added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / post_id / descriptionAdded value: +"The post's native post_id (from list_videos / analyze_post)." - added
Input schema / properties / window_days / descriptionAdded value: +"Trailing window in days (1–365, default 90; out-of-range values are clamped)."
- Changed
get_video3 fields changed- added
Input schema / properties / include_analysis / descriptionAdded value: +"Attach the video's full analysis inline." - added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / post_id / descriptionAdded value: +"The platform's native post id — the `post_id` field from list_videos / search_videos (NOT the composite `id`)."
- Changed
get_video_analysis2 fields changed- added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / post_id / descriptionAdded value: +"The platform's native post id — the `post_id` from analyze_post / list_videos. Pass platform and post_id separately, NOT the composite `id`."
- Changed
list_accounts1 field changed- added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms."
- Changed
list_creator_videos5 fields changed- added
Input schema / properties / include_analysis / descriptionAdded value: +"Attach each video's full analysis inline (heavier response)." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of videos to return (default 12)." - added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / sort / descriptionAdded value: +"Ordering: 'recent' (newest first) or 'top' (best-performing)." - added
Input schema / properties / username / descriptionAdded value: +"The creator's public handle, e.g. 'natgeo' (no leading @)."
- Changed
list_similar_videos4 fields changed- added
Input schema / properties / include_analysis / descriptionAdded value: +"Attach each video's full analysis inline (heavier response)." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of similar videos to return (default 8)." - added
Input schema / properties / platform / descriptionAdded value: +"Target platform — instagram, tiktok, or youtube (case-insensitive)." - added
Input schema / properties / post_id / descriptionAdded value: +"The reference post's native post_id (from list_videos / get_video). Similarity is computed from this post's content embedding."
- Changed
list_videos6 fields changed- added
Input schema / properties / account_id / descriptionAdded value: +"A connected account_id from list_accounts. Omit to aggregate across all your accounts." - added
Input schema / properties / include_analysis / descriptionAdded value: +"Attach each video's full analysis inline (heavier response)." - added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of videos to return (default 20)." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / query / descriptionAdded value: +"Optional free-text filter over your videos (caption / title)." - added
Input schema / properties / sort / descriptionAdded value: +"Ordering: 'recent' (newest first) or 'top' (best-performing)."
- Changed
search3 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of results to return (default 10)." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / query / descriptionAdded value: +"Free-text query matched against your connected accounts' content (captions, titles, transcripts)."
- Changed
search_videos3 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"Maximum number of videos to return (default 10)." - added
Input schema / properties / platform / descriptionAdded value: +"Optional platform filter — instagram, tiktok, or youtube (case-insensitive). Omit to span all connected platforms." - added
Input schema / properties / query / descriptionAdded value: +"What to look for inside your analyzed videos (themes, topics, on-screen content)."
4 tool updates
- Changed
get_account_metrics1 field changed- added
Input schema / properties / granularityAdded value: +{ + "default": "daily", + "enum": [ + "daily", + "weekly", + "raw" + ], + "type": "string" +}
- Added
get_follower_history - Added
get_growth_summary - Added
get_post_metrics_history
18 tool updates
- First observed
analyze_creator - First observed
analyze_post - First observed
fetch - First observed
get_account - First observed
get_account_metrics - First observed
get_analysis_status - First observed
get_content_profile - First observed
get_creator - First observed
get_video - First observed
get_video_analysis - First observed
list_accounts - First observed
list_creator_videos - First observed
list_similar_videos - First observed
list_videos - First observed
search - First observed
search_videos - First observed
server_info - First observed
whoami
Related MCP Connectors
Social media analytics, post insights, and competitor benchmarking for AI agents.
The Google for AI agents — company intel, competitor tracking, market research via MCP. JSON output
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
Connect any AI agent to 11+ social platforms: schedule, publish & track posts via hosted MCP.
Related MCP Servers
AlicenseNot gradedqualityDmaintenanceSocial media analytics, post insights, and competitor benchmarking for AI agents.6MIT- FlicenseNot gradedqualityBmaintenanceProvides social intelligence tools for AI agents to analyze competitor sentiment, trends, and brand mentions from X/Twitter data.-
- AlicenseAqualityCmaintenanceWeb intelligence MCP server for AI agents. 7 tools for SERP analysis, competitor research, market trends, content gap analysis, keyword insights, audience discovery, and citation tracking.72AGPL 3.0
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to post, schedule, thread, delete, and analyze social media posts across platforms like X, Bluesky, LinkedIn, and Instagram through a single MCP interface.2,284 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.