Let AI agents post to social media with human approval: schedule, first comments, threads.
Scored across 1 tool
With only a single tool there is no possibility of confusion between tools, and its purpose (bootstrap a workspace and obtain an API key) is unambiguous. An agent cannot misselect because there is nothing else to select.
The lone name 'signup' is clean, lowercase, and readable, so no inconsistency is possible. It scores slightly below perfect only because a single name provides no pattern to demonstrate predictability across a set.
A one-tool MCP server is borderline thin, but the description frames it deliberately as a gateway step that requires reconnecting with an API key to reach the posting tools. It is intentional rather than accidental scope, yet still minimal as a standalone server.
The apparent domain is bot-driven posting/workspace management, but this surface only handles signup with no create-post, list, update, or delete operations. The gap is explicitly deferred to a future connection, leaving the current tool set a dead end for any real work.
Create a Free Botdoor workspace for your human and get an API key (asks first: every post waits for their approval). No account needed. Returns apiKey (shown once) and next steps. Botdoor emails your human a claim link; they set a password there and connect an account. If the email already has a workspace you get no key (202): your human signs in and creates one for you. Then reconnect to this MCP server with 'Authorization: Bearer ' to get the posting tools.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Your human's email address (they own the workspace) | ||
| locale | No | Optional language of the claim email: en or ja. Default: the request's Accept-Language, else en. | |
| agentName | No | Optional name for your key, e.g. content-agent | |
| workspaceName | No | Optional, e.g. Acme |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, it discloses real side effects: Botdoor emails the human a claim link, posts wait for approval, the key is shown only once, and a pre-existing workspace yields no key (HTTP 202). That is exactly the behavioral context an agent needs for a non-idempotent, open-world write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the primary action and each sentence carries distinct information (approval behavior, claim flow, 202 edge case, reconnect step). It runs slightly dense with stacked parentheticals, but little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by describing the return ('apiKey shown once and next steps') and the failure mode (202, no key). The claim-link workflow and reconnect instruction round out the full lifecycle for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents email, locale, agentName, and workspaceName. The description adds only light framing ('for your human', 'they own the workspace'), not enough to exceed the baseline when the schema carries the load.
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: 'Create a Free Botdoor workspace for your human and get an API key.' It also names the concrete artifact produced (apiKey) and the follow-up step (reconnect with Bearer token), so an agent knows exactly what this call accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to call it (you need an API key to unlock the posting tools) and explicitly explains the post-call step: 'reconnect to this MCP server with Authorization: Bearer <apiKey>.' There are no sibling tools, so no alternative routing is needed, but it also doesn't state any prerequisites or exclusions beyond 'No account needed.'
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.
signup1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Optional language of the claim email: en or ja. Default: the request's Accept-Language, else en.",
+ "type": "string"
+}signupLets AI agents post and reply on Instagram, TikTok, Threads and more, with a human approval queue.
Draft, schedule and publish social media posts from any AI agent.
Social media scheduler for AI agents: draft posts into a human-approved queue for 15 networks.
Create, review and schedule social content from your AI agent. Approval-first.
Add one secure layer between your agents and this server.
