Skip to main content
Glama

social_post

Publish text and optional media to a chosen social network or all supported networks, with a dry-run option to preview the post before sending.

Instructions

Post text (and optional media) to one network, or 'all'.

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": {
      "network": "<network>",
      "text": "<text>"
    },
    "name": "social_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYes
mediaNo
dry_runNo
networkYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden for a write operation. It says nothing about whether the post publishes immediately, whether it is irreversible or deletable afterward (social_delete exists but is not referenced), what permissions or connected accounts are required, or what dry_run does.

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?

The single sentence is front-loaded with the action and free of filler. Its brevity costs information, but as a structural matter there is no wasted wording or buried lead.

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

Completeness2/5

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

For a four-parameter mutation tool with no annotations, no output schema, and no schema parameter documentation, the description is too thin. Critical facts an agent needs before calling it, notably the meaning of dry_run and the immediacy/reversibility of publishing, are absent.

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

Parameters2/5

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

Schema description coverage is 0% across four parameters, so the description must compensate. It clarifies text, optional media, and the 'all' sentinel for network, but leaves dry_run entirely unexplained and gives no format or constraint detail for network values.

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

Purpose4/5

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

The description gives a specific verb and resource ("Post text (and optional media)") and names the target scope (one network, or 'all'). It does not differentiate from plausible siblings such as social_schedule or social_queue, which also appear to publish content, so an agent cannot fully rule out the alternatives from the description alone.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative is named. The only hint is the "or 'all'" scope note, which is about parameter values rather than about choosing this tool over social_schedule, social_queue, or social_recipes.

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