SupaBird

Write Like Creator

write_like_creator

Rewrite the user's text into X/Twitter post drafts in the style of a SPECIFIC creator. This tool writes purely in that creator's voice — no personal style blending.

    HOW IT WORKS:
    1. You provide a creator's X/Twitter username
    2. The tool looks up the creator and loads their writing style rulebook
    3. If the creator doesn't have a style rulebook yet, this tool will return instructions to run "learn_creator_style" first — follow those instructions, then call this tool again
    4. Drafts are generated using the creator's style

    Before calling this tool, make sure you have collected ALL of the following from the user:
    1. The creator's X/Twitter username (without @)
    2. The text/topic to rewrite
    3. How many drafts (1–5)
    4. Post length (short / average / long / very_detailed)
    5. Standard or punchy formatting

    If ANY of these are missing from the user's message, ASK the user before calling this tool. Do NOT assume defaults.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "username": "<username>",
      "text": "<text>"
    },
    "name": "write_like_creator"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	The text, topic, or post content to rewrite as X/Twitter post drafts.
`length`	No	Post length. If the user didn't specify, ASK them before calling this tool. Options: - short: 80–160 chars, up to 3 lines - average: up to 240 chars, 3–5 lines - long: aim for 280 chars max (free tier max) - very_detailed: above 280 chars, detailed posts
`punchy`	No	If true, use punchy formatting with short, sharp lines. If false, use standard formatting with longer sentences. If the user didn't specify, ASK them whether they want standard format or punchy (with short lines).
`language`	No	Output language for drafts (e.g. English, French, Spanish) or "auto" to match the language of the input text. If omitted, uses the user's account language preference when set.
`username`	Yes	The X/Twitter username of the creator whose style to write in (without @). Example: 'naval', 'paulg', 'sama'
`social_set`	No	The social set (brand) this is for: its name, id or one of its handles. Omit when the user has one set.
`number_of_drafts`	No	How many draft posts to generate (1–5). If the user didn't specify, ASK them before calling this tool.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the internal pipeline: creator lookup, style-rulebook load, and a documented failure branch that returns follow-up instructions. The remaining ambiguity is whether the generated drafts are persisted to the account's drafts or returned transiently — a meaningful gap for a non-read-only, non-idempotent tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-sentence purpose, then two clearly labeled numbered blocks; each item (prerequisite list, error path) carries actionable content. Minor waste in step 1 ('You provide a creator's X/Twitter username') which restates the checklist that follows, and the headers add length for little gain.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter generative tool with no output schema, it covers prerequisites, the internal workflow, the error/retry path, and the no-defaults rule. What it does not cover is what the agent receives back — draft text format, ordering, or whether drafts land in the drafts folder — which matters most precisely because no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, but the description adds cross-parameter policy the schema only states per-field: the explicit five-item collection checklist tells the agent which values must come from the user versus which are optional conveniences (language, social_set are deliberately omitted from the checklist). The numbered 'HOW IT WORKS' also ties the username parameter to the rulebook lookup behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Rewrite the user's text into X/Twitter post drafts') plus a scope qualifier ('in the style of a SPECIFIC creator'). The clause 'no personal style blending' implicitly separates it from siblings such as write_in_my_style and write_like_my_creators, so an agent can choose between them without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite checklist (username, text, draft count, length, formatting), instructs the agent to ASK rather than default when anything is missing, and routes to a named alternative ('run learn_creator_style first — follow those instructions, then call this tool again') when no rulebook exists. When-to-use, when-not-to-use, and the recovery path are all covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SupaBird tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?