The Taisly MCP server enables AI agents to publish and manage short-form video content across social media platforms (TikTok, Instagram Reels, YouTube Shorts, X, and Facebook) through a structured, confirmation-safe workflow.
Check Authentication – Verify your Taisly API key is valid and see how many social accounts are connected.
List Connected Platforms – Retrieve all social accounts available for posting under the current API key.
Get Platform Posting Schema – Fetch platform-specific constraints and requirements (e.g., caption limits, video specs) before creating a post.
Validate a Post – Run preflight validation on a local video file, destination platform IDs, caption, and optional schedule before publishing anything live.
Create/Publish a Post – Publish or schedule a video to one or more platforms; requires explicit user confirmation (confirmed: true) as a safety gate.
Check Post Status – Retrieve the status of a previously created post by its historyId.
List Post History – Browse recent posting history with optional date range filters and pagination, useful for audits.
Manage Repost Automations – List existing automations and create new ones to automatically repost content from a source account to one or more destination accounts.
Enables AI agents to publish videos to Facebook through the Taisly posting API.
Allows AI agents to post videos to Instagram (including Reels) via the Taisly Agent Kit.
Enables AI agents to publish videos to TikTok through automated posting workflows.
Provides the ability for AI agents to publish short-form videos to YouTube Shorts.
Free AI-first social media posting for short-form video. Taisly Agent Kit is a JSON-first SDK, CLI, Agent Skill, and MCP server that lets AI agents, developer tools, and automation workflows publish videos to TikTok, Instagram Reels, YouTube Shorts, X, Facebook, and other connected social platforms through Taisly.
Use it when your agent can create content, write captions, or prepare a campaign, but still needs a reliable video publishing API to put that content online. The package is free to install and designed to get an agent from idea to published video without building every platform integration yourself.
Website | Agent Kit | API Docs | npm | GitHub | MCP Registry | Glama | Guide
Read this guide in: English, Español, Deutsch, Français, Português, ไทย, 中文, Bahasa Indonesia, Русский, Nederlands, 한국어, 日本語, العربية, Türkçe, Polski.
Related MCP server: Upload-Post
Build AI agent social media posting into Codex, Claude Code, Cursor, OpenClaw, and custom automation tools.
Automate video publishing from one local file to multiple connected social accounts.
Give agents a safe JSON workflow: discover accounts, validate payloads, create posts, and check status.
Add TikTok API posting automation, Instagram Reels automation, YouTube Shorts publishing, and cross-platform social media automation without building every platform integration yourself.
Start free, then upgrade only when the publishing workflow grows.
Taisly handles the connected accounts and posting execution. Your agent handles planning, caption writing, campaign logic, or workflow orchestration.
Install the package for free.
Create or connect a Taisly account from your AI agent.
Let the agent authenticate, connect social accounts, validate videos, and publish through a JSON-first workflow.
Upgrade later when you need higher-volume publishing, larger account sets, or automatic repost workflows.
No credit card is required to get started. Paid plans are for teams and workflows that need more scale.
This package includes the Taisly Social Media Posting Skill in SKILL.md. Use it with Claude Code, Codex, Cursor, OpenClaw, and other agents when you want the agent to understand the safe posting workflow before it touches live social accounts.
Recommended skill workflow:
auth -> platforms -> validate -> confirm -> create -> statusThe skill tells agents to discover connected accounts, validate the post, ask for explicit user confirmation, create the post, and save the returned historyId for status checks.
This package includes a Codex plugin manifest in .codex-plugin/plugin.json. The plugin points Codex to the canonical SKILL.md file and the official remote MCP server:
https://app.taisly.com/mcpUse the plugin when you want Codex to discover both the posting workflow instructions and the Taisly MCP tools from one package. The root SKILL.md is the single source of truth for the agent workflow.
npm install -g @taisly/agentOr run it without a global install:
npx @taisly/agent helpStart the stdio MCP server:
npx @taisly/agent mcpFor local development inside this repository:
node packages/agent/src/cli.js helpThe easiest flow is to let your AI agent open the browser login for you. Use any short agent slug, for example claude-code, codex, cursor, windsurf, openclaw, hermes-agent, cline, or aider.
Help me set up Taisly Agent Kit.
1. Install the CLI: npm i -g @taisly/agent
2. Run taisly setup --agent <agent-slug> and send me the login URL so I can finish authentication.
3. Wait for me to finish login in the browser.
4. Run taisly checkin --agent <agent-slug>.
5. Tell me if Taisly is connected and ready. If not, tell me what failed.
If you cannot install or run the Taisly CLI in this environment, stop and tell me to open Taisly Settings instead.The setup command stores a local Taisly agent credential, so later CLI and MCP commands can run without manually copying an API key.
Manual fallback: create an API key in Taisly Settings, then set:
export TAISLY_API_KEY="taisly_..."Advanced: by default, the browser setup stores the local credential in ~/.taisly/config.json. Most users should not change this. Set TAISLY_CONFIG_HOME=/path/to/dir only for CI, tests, or isolated agent profiles that need a separate credential store.
List the connected social accounts available to the API key:
taisly auth:status
taisly platforms:listConnect a social account from an AI-agent flow:
taisly platforms:connect:start --platform instagram
# Open the returned connectUrl and finish authorization in the browser.
taisly platforms:connect:check --platform instagram
taisly platforms:listSupported connect slugs: instagram, tiktok, youtube, x, facebook.
Validate a local video before publishing:
taisly posts:validate \
--video ./launch.mp4 \
--platforms platform_id_1,platform_id_2 \
--description "Launch day"Publish now:
taisly posts:create \
--video ./launch.mp4 \
--platforms platform_id_1,platform_id_2 \
--description "Launch day"Schedule for later:
taisly posts:create \
--video ./launch.mp4 \
--platforms platform_id_1,platform_id_2 \
--description "Launch day" \
--scheduled "2026-06-14T09:00:00+07:00"Check the returned post:
taisly posts:status --id <historyId>Every command prints JSON so agents can parse results without scraping terminal text.
Taisly is published in the official MCP Registry as:
io.github.taisly/agentDisplay name: Taisly Social Media Posting
Remote MCP endpoint:
https://app.taisly.com/mcpThe remote MCP server uses streamable HTTP and OAuth. Remote MCP tools can publish only from public videoUrl values because they cannot read local files from your machine.
Codex remote MCP setup:
codex mcp add taisly --url https://app.taisly.com/mcp
codex mcp login taislyClaude Code remote MCP setup:
claude mcp add --transport http taisly https://app.taisly.com/mcpThen ask Claude Code to verify the connection. If OAuth is needed, Claude Code can guide the browser login from the session. You can also authenticate explicitly with claude mcp login taisly if you want to complete the OAuth flow from the shell before using tools.
Taisly Agent Kit also includes a local stdio MCP server in the same package. Use local MCP when your agent needs to read local video files:
{
"mcpServers": {
"taisly": {
"command": "npx",
"args": ["@taisly/agent", "mcp"]
}
}
}If you already use a manual API key, you can still pass TAISLY_API_KEY in the MCP server env block.
Codex local MCP setup:
codex mcp add taisly -- npx @taisly/agent mcpClaude Code local MCP setup:
claude mcp add taisly -- npx @taisly/agent mcpThen ask the agent:
Use the local Taisly MCP server you just added and run the Taisly agent setup start tool with agentId: "<agent-slug>".
Send me the login URL and wait for me to finish in the browser.
Then run the Taisly agent checkin tool with agentId: "<agent-slug>".
After checkin, run the Taisly auth status tool.
Tell me if Taisly is connected and ready. If not, tell me what failed.Available MCP tools:
taisly_agent_setup_start
taisly_agent_checkin
taisly_auth_status
taisly_platforms_list
taisly_platform_schema
taisly_platform_connect_start
taisly_platform_connect_check
taisly_posts_validate
taisly_posts_create
taisly_posts_status
taisly_posts_list
taisly_reposts_list
taisly_reposts_create
taisly_posts_create requires confirmed: true. Set it only after the user explicitly approves the video, destination accounts, caption, and schedule.
Agents can write a payload file and pass it to the CLI:
{
"video": "./launch.mp4",
"platforms": ["platform_id_1", "platform_id_2"],
"description": "Launch day. Short demo, big update.",
"scheduled": "2026-06-14T09:00:00+07:00"
}Then run:
taisly posts:validate --json ./campaign.json
taisly posts:create --json ./campaign.jsonThe video path must point to a real local file available to the agent. Supported local preflight extensions are .mp4, .mov, .avi, .mkv, .webm, .flv, .mpeg, and .mpg.
taisly auth:status
taisly setup --agent <agent-slug>
taisly checkin --agent <agent-slug>
taisly platforms:list
taisly integrations:list
taisly platforms:schema --platform TikTok
taisly posts:validate --video ./launch.mp4 --platforms platform_id_1 --description "Launch day"
taisly posts:create --video ./launch.mp4 --platforms platform_id_1 --description "Launch day"
taisly posts:create --json ./campaign.json
taisly posts:list --page 1
taisly posts:status --id <historyId>
taisly reposts:list
taisly reposts:create --from <platform_id> --to <platform_id_1,platform_id_2>
taisly mcpintegrations:* commands are aliases for platforms:* commands. Taisly calls connected social accounts platforms in the app, while many public APIs call them integrations.
import { Taisly } from "@taisly/agent";
const taisly = new Taisly({
apiKey: process.env.TAISLY_API_KEY,
});
const platforms = await taisly.platforms.list();
const validation = await taisly.posts.validate({
video: "./launch.mp4",
platforms: [platforms.data[0].id],
description: "Launch day",
});
const post = await taisly.posts.create({
video: "./launch.mp4",
platforms: [platforms.data[0].id],
description: "Launch day",
scheduled: "2026-06-14T09:00:00+07:00",
});
console.log(validation.success);
console.log(post.historyId);Taisly Agent Kit is designed for agentic workflows where the user gives a high-level instruction and the agent executes a safe posting path.
Codex: let a coding agent publish demo videos, launch clips, or build updates after user confirmation.
Claude Code: add social posting to local content workflows and campaign scripts.
Cursor: ship video publishing from developer tools, content apps, and internal automation.
OpenClaw and other agents: connect planning, caption writing, and posting execution through a single CLI.
Recommended agent path:
auth:status -> platforms:list -> platforms:schema -> posts:validate -> user confirmation -> posts:create -> posts:statusThe examples/ folder includes copy-paste workflows for common coding agents:
examples/codex/post-video.md
examples/claude-code/schedule-video.md
examples/cursor/post-build-demo-video.md
examples/post-video.sh
examples/schedule-video.sh
It is not a social media dashboard.
It is not a video editor.
It does not replace a Taisly account.
It requires connected social accounts and a Taisly agent credential or API key.
It does not bypass platform rules, account permissions, or media validation.
posts:create uses the existing multipart /post API.
posts:status reads recent history because a single-post status endpoint is not available yet.
posts:validate is local preflight; final validation still happens in Taisly.
Local MCP uses stdio transport. Remote MCP uses streamable HTTP at https://app.taisly.com/mcp.
Remote MCP requires public video URLs; use local MCP or the CLI for local video files.
Media upload reuse is planned later.
Taisly: https://taisly.com/en
Agent Kit page: https://taisly.com/en/ai-agent-kit
API docs: https://docs.taisly.com/en/docs
npm package: https://www.npmjs.com/package/@taisly/agent
GitHub repo: https://github.com/taisly/agent
MCP Registry: https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.taisly%2Fagent
SEO guide: https://taisly.com/en/blog/ai-agent-social-media-posting-api
Finish setup after the user approves the loginUrl in the browser. Saves the local Taisly agent credential for later CLI and MCP calls.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Short agent slug used with taisly_agent_setup_start. | |
| agentId | No | Alias for agent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutating but non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds that the tool saves credentials, which is consistent. However, it does not disclose additional behavioral traits such as side effects, idempotency, or error conditions. 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 extremely concise, using only two sentences. The first sentence front-loads the critical condition ('after user approves the loginUrl'), and every word serves a purpose.
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 (2 optional params, no output schema), the description covers the core purpose and precondition. It is missing details like expected behavior if called prematurely or what the output might be, but it is still fairly complete for its 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?
Schema coverage is 100% with both parameters ('agent' and 'agentId') described in the input schema. The description adds no extra meaning beyond what the schema already provides, so a 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: finishing setup after user approval and saving credentials. It uses a specific verb ('finish setup') and resource ('Taisly agent credential'), effectively distinguishing it from the sibling tool 'taisly_agent_setup_start' which initiates setup.
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 this tool: after the user approves the loginUrl. It implies the correct sequence relative to 'taisly_agent_setup_start' but does not mention when not to use it or provide alternatives. Still, 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.
Start browser-based Taisly authentication for an AI agent. Returns a loginUrl that the user must open and approve before checkin.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | Short agent slug, for example claude-code, codex, cursor, openclaw, or hermes-agent. | |
| agentId | No | Alias for agent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by specifying the return value (loginUrl) and user action required, but does not elaborate on internal state changes or side effects.
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 with two sentences covering purpose and output, no extraneous text.
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 simple tool (2 optional params, no output schema), the description adequately covers purpose, output, and prerequisite, though it could mention error states or default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-described. The description adds no additional meaning beyond what is in the schema, earning a baseline score.
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 initiates browser-based Taisly authentication for an AI agent and returns a loginUrl, distinguishing it from sibling tools like checkin and auth_status.
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 that the loginUrl must be opened and approved before checkin, providing context for when to use this tool, though it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether the Taisly API key is valid and count connected social accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safe, read-only, idempotent behavior. Description adds context about checking validity and counting accounts, which aligns well.
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 sentence, front-loaded, no wasted words. Ideal structure.
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 zero-parameter, read-only tool with no output schema, the description fully covers purpose and result.
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?
No parameters. Baseline 4. Description adds value by explaining what the tool does with its zero-parameter interface.
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 checks API key validity and counts social accounts. Specific verb-resource combination. Distinguishes from siblings like taisly_platform_connect_check.
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?
No guidance on when to use versus alternatives. Agent must infer context; no explicit or implicit usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a social account connection started by taisly_platform_connect_start has appeared in Taisly.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform to check. Supported: instagram, tiktok, youtube, x, facebook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that it checks for appearance but does not disclose what happens if the connection hasn't appeared or rate limiting, thus adding some value but not fully comprehensive.
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 sentence of 16 words, directly states the tool's purpose with no extraneous content.
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 one parameter fully described in schema and no output schema, the description explains the tool's role but does not indicate the return value or behavior (e.g., boolean result, polling interval). This leaves some ambiguity for a check operation.
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% with the platform parameter well-documented. The description adds no extra semantic meaning beyond referencing the start tool, 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 specifies the verb 'Check' and the resource 'social account connection', and explicitly references the companion tool taisly_platform_connect_start, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after taisly_platform_connect_start to check if the connection has appeared, providing clear context but lacking explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start browser-based connection for a social account. Returns a connectUrl that the user must open and approve in the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform to connect. Supported: instagram, tiktok, youtube, x, facebook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate openWorldHint=true and readOnlyHint=false. The description adds value by detailing that the tool returns a connectUrl that requires user browser interaction, which is essential behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, no wasted words. It front-loads the action and clearly states the return 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 (one parameter, no output schema, annotations present), the description covers the purpose, user action, and return value adequately. It could mention the effect of the connection start, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter, 'platform', with 100% schema description coverage. The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start browser-based connection' and specifies the resource as 'social account'. It mentions the return of a connectUrl, which distinguishes it from sibling tools like taisly_platform_connect_check that check status.
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 implies usage by stating the user must open and approve the URL in the browser, but it does not explicitly provide when to use this tool versus alternatives, nor does it mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get local posting constraints for a destination platform before validating or creating a post.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Platform name, for example TikTok, Instagram, YouTube, X, or Facebook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds that it returns 'local posting constraints', providing domain-specific behavioral context beyond what annotations offer.
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?
A single, front-loaded sentence with no filler words. Every part is necessary and informative.
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 tool with one parameter and no output schema, the description fully covers purpose, usage context, and what the tool returns. 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional semantics beyond the schema's parameter description, which already lists examples for the platform parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'local posting constraints for a destination platform', and clarifies the context 'before validating or creating a post'. This clearly distinguishes it from sibling tools like taisly_platforms_list (list platforms) and taisly_posts_validate (validate a 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?
The description explicitly states when to use the tool: 'before validating or creating a post'. However, it does not mention when not to use it or provide alternative tools, though the sibling context helps fill this gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connected TikTok, Instagram, YouTube, X, Facebook, and other social accounts available to this API key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context (e.g., pagination, caching). It meets the baseline but doesn't exceed 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?
Single sentence with clear verb and object. No wasted words, front-loaded with purpose.
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 parameter-less list tool with full annotations, the description is complete. It specifies the resource (social accounts) and scope (available to this API key).
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?
No parameters exist, so schema coverage is 100%. The description doesn't add parameter info, which is fine given zero parameters. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists connected social accounts (TikTok, Instagram, etc.) and distinguishes it from sibling tools like taisly_posts_list or taisly_auth_status.
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 context is clear: use this to see which social accounts are connected to the API key. No explicit exclusions or alternatives are given, but the sibling tool names imply the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish or schedule a video post through Taisly after the user explicitly confirms the media, destinations, caption, and schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| video | Yes | Local video path available to the agent. | |
| confirmed | Yes | Must be true only after explicit user confirmation. | |
| platforms | Yes | Destination platform IDs from taisly_platforms_list. | |
| scheduled | No | Optional ISO datetime or Unix timestamp in milliseconds. | |
| description | Yes | Post caption or description. | |
| previewTime | No | Optional preview timestamp used by the Taisly posting API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive. The description adds the condition of explicit confirmation but lacks details on side effects, return values, or prerequisites beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 20-word sentence that front-loads the action and condition. 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?
No output schema is provided, yet the description does not mention what the tool returns (e.g., post ID). It also omits guidance on using taisly_posts_validate first, which is a related sibling.
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 description's mention of 'media, destinations, caption, and schedule' adds no new meaning beyond what the schema provides. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publish or schedule a video post through Taisly', which is a specific verb-resource pair. It distinguishes from sibling tools like list, status, validate, and repost creation.
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 notes 'after the user explicitly confirms the media, destinations, caption, and schedule', providing a clear precondition. However, it does not explicitly exclude alternatives like validation or reposts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent Taisly post history for status checks and audits.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | History page number. Defaults to 1. | |
| endTime | No | Optional end timestamp filter. | |
| startTime | No | Optional start timestamp filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows it's a safe read operation. The description adds temporal context ('recent', 'history') but no further behavioral details like pagination or sorting. This adds some value beyond annotations but not extensive.
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?
A single sentence that is concise and front-loaded, stating the action, resource, and purpose. 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?
The description covers the basic purpose but lacks details about return values (no output schema) or pagination behavior. Given the tool's simplicity and the supportive annotations, a score of 3 is reasonable.
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 coverage is 100% with parameter descriptions for page, startTime, and endTime. The description does not add any extra meaning beyond the schema, so 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?
Description uses a specific verb ('List') and resource ('Taisly post history') and adds a usage context ('for status checks and audits'). It clearly differentiates from siblings like taisly_posts_create or taisly_posts_validate.
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 states when to use ('for status checks and audits'), providing clear context. However, it does not explicitly mention when not to use or list alternative tools among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent-history status for a Taisly post by historyId.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Taisly historyId returned by taisly_posts_create. | |
| historyId | No | Alias for id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the context of 'recent-history' but does not elaborate on behavior beyond what annotations provide. 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?
A single, clear sentence that front-loads the purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally explain what the status response contains. It only says 'recent-history status' which is vague. With only two well-documented parameters, the description is minimally adequate but lacks completeness about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (id, historyId) are described in the schema. The description mentions 'by historyId' but adds no new meaning beyond the 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?
The description uses a specific verb 'Fetch' and clearly identifies the resource: 'recent-history status for a Taisly post by historyId.' It distinguishes the tool from siblings like taisly_posts_create, taisly_posts_list, and taisly_posts_validate.
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 no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling tools such as taisly_posts_validate or taisly_posts_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a local video path, destination platform IDs, caption, and optional schedule before publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| video | Yes | Local video path available to the agent. | |
| platforms | Yes | Destination platform IDs from taisly_platforms_list. | |
| scheduled | No | Optional ISO datetime or Unix timestamp in milliseconds. | |
| description | Yes | Post caption or description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. Description adds that it validates before publishing but lacks details on return value or error handling, which is missing since no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 13 words, front-loaded with verb 'Validate'. No extraneous content.
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?
Adequate for a validation tool given annotations, but omits what the output looks like and what exactly validation checks (e.g., file format, platform compatibility). Missing output schema makes description carry more burden.
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 4 parameters. The description adds minor emphasis ('local' for video) but does not significantly expand 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 validates specific inputs (video path, platform IDs, caption, schedule) and distinguishes it from siblings like taisly_posts_create and taisly_posts_list.
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?
No explicit guidance on when to use this tool versus alternatives (e.g., taisly_posts_create). The description implies pre-publish validation but does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a repost automation from one connected account to one or more destination accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination platform IDs. | |
| from | Yes | Source platform ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (write operation) and openWorldHint=true (potential side effects). The description adds context ('automation' and 'to one or more destination accounts') but does not clarify what the automation entails, when it triggers, or any required preconditions like connection status. It adds some value beyond annotations but lacks depth.
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, well-structured sentence that front-loads the action ('Create a repost automation') and states the resource scope. No unnecessary words or 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 omits important details for a creation tool: it does not explain what happens after creation (e.g., whether it triggers immediately, expected response), does not reference sibling tools like taisly_reposts_list for follow-up, and does not mention any authentication or connection prerequisites. Given the absence of an output schema, the description should provide more guidance on the result or next steps.
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%, with both parameters already documented ('Source platform ID' and 'Destination platform IDs.'). The description's mention of 'from one connected account to one or more destination accounts' aligns with but does not add new meaning beyond the schema. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a repost automation' – a specific verb and resource (repost automation) – and distinguishes it from sibling tools like taisly_reposts_list (list reposts) and taisly_posts_create (create posts). It also defines the scope: 'from one connected account to one or more destination 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 implies usage for creating repost automations but offers no explicit guidance on when to use this tool versus alternatives such as taisly_posts_create or taisly_reposts_list. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured repost automations for connected social accounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'configured repost automations' context but does not elaborate on behavior beyond what annotations cover. 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 sentence, clear and direct. No unnecessary words. Front-loaded with the action and resource.
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 no parameters and no output schema, the description sufficiently explains what the tool returns (list of configured automations). Complete given the low 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?
No parameters exist, and schema coverage is 100%. Description mentions 'for connected social accounts,' implying auth context but no param details needed. Baseline 4 for 0 parameters 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?
Description clearly specifies the action 'List' and the resource 'configured repost automations for connected social accounts.' It distinguishes from sibling tools like taisly_reposts_create (create) and taisly_posts_list (list posts vs reposts).
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?
No explicit guidance on when to use this tool versus alternatives. While the context is simple and the tool is read-only, the description does not mention when not to use it or compare with siblings like taisly_reposts_create or taisly_posts_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.8taisly_agent_checkintaisly_agent_setup_starttaisly_platform_connect_checktaisly_platform_connect_startv0.1.0taisly_auth_statustaisly_platform_schemataisly_platforms_listtaisly_posts_createtaisly_posts_listtaisly_posts_statustaisly_posts_validatetaisly_reposts_createtaisly_reposts_listEach tool targets a distinct action: agent setup, authentication check, platform connection, schema retrieval, post validation/creation/listing, and repost configuration. No overlap in functionality.
All tools follow a consistent 'taisly_verb_noun' pattern in snake_case, making it easy to infer purpose from the name.
13 tools cover the core workflows of authentication, platform management, content posting, and reposting without being excessive or sparse.
The tool set includes setup, validation, create, list, and status check for posts, but lacks update and delete operations. Reposts have create and list but no status or delete. Minor gaps for full lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate AI short-form videos and auto-publish them to TikTok, YouTube, Instagram, Facebook and X.
Draft, schedule and publish social posts to nine platforms from any AI agent.
Create, manage, schedule, and publish short-form user-generated content through AI agents.
AI-native social media publishing to LinkedIn, Instagram, Threads, TikTok, and X.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/taisly/agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
