Skip to main content
Glama

ContentIn for Agents

Write a post in the user's voice

write_post_in_my_voice

THE MAIN TOOL. Write a LinkedIn post in this user's own voice, from their own material. Use it whenever the user describes something they want to post about — a story, an opinion, a result, a lesson, a rough brief. It runs ContentIn's voice pipeline: their VoiceDNA, their real past posts as style exemplars, and their substance bank, so the output sounds like them rather than like an AI. Pass the user's idea as fully and as literally as you can — their own words, their own details, their own numbers. Do NOT tidy it up, summarise it, or replace their phrasing with your own; the pipeline preserves what they gave it and paraphrasing upstream is how a post stops sounding like them. The post is saved as a draft in their ContentIn account and the returned post_id can be passed to schedule_post or publish_post. Takes 30-90 seconds. If this tool returns needs_input: true with a question, your ONLY job that turn is to relay that question to the user (verbatim, or lightly adapted to the conversation language). Do NOT write, invent, or promise a post, and do NOT call this or any other write tool again until the user answers.

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": {
      "user_idea": "<user_idea>",
      "style": "<style>"
    },
    "name": "write_post_in_my_voice"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleYesWriting style. Infer it from the material: results / case studies / client wins = proof, educational / frameworks = authority, viral / trending / broad-resonance = growth.
user_ideaYesThe user's complete description of the post they want, in THEIR words. Include their full intent, context, specific details, names and numbers. Verbatim is better than tidy.
user_constraintsNoAny preferences the user has stated that override defaults — e.g. 'no hashtags', 'no call to action, this is a connection post', 'keep it under 800 characters'. These take priority over their usual voice defaults.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the standard hint trio, and the description adds substantial behavior the agent could not otherwise know: it saves a draft in the ContentIn account, returns a post_id usable downstream, takes 30-90 seconds, and can return needs_input:true with a question. The needs_input protocol is spelled out as an instruction with explicit prohibitions, which is exactly the kind of stateful behavior a caller must handle.

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 highest-value signal ("THE MAIN TOOL") and organized into purpose, input handling, output routing, latency, and edge-case protocol. It is dense and long, but nearly every sentence carries operational weight; the repeated emphasis on not paraphrasing borders on redundant across two sentences.

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

Completeness5/5

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

For a generative write tool with no output schema, the description covers everything a caller needs: what it produces, that it is a draft rather than a published post, the returned identifier, expected latency, downstream tools, and the needs_input branch. Nothing material is left to inference.

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?

Schema coverage is 100% and each field already documents itself, including the style enum with inference rules. The description nevertheless adds real semantic weight by insisting user_idea be passed literally and untidied, and by explaining why (paraphrasing upstream breaks voice fidelity). That is meaning beyond the schema, though the style and user_constraints fields get no additional color from the prose.

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?

Opens with a specific verb+resource ("Write a LinkedIn post in this user's own voice") and scopes it to the user's own material. "THE MAIN TOOL" plus the explicit pipeline framing (VoiceDNA, exemplars, substance bank) makes it trivially distinguishable from the read-oriented siblings like get_voice_context or list_posts.

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?

States exactly when to invoke it ("whenever the user describes something they want to post about — a story, an opinion, a result, a lesson, a rough brief"), and explicitly routes the output onward to schedule_post or publish_post via post_id. It also defines a negative-space rule: what NOT to do upstream (don't tidy, summarise, or paraphrase).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.