OrgLines

Blog: Create draft

blog_create_draft

Create a blog post as a DRAFT (never published by this tool) on a site of this workspace: title, text, optional excerpt, tags and category name. The draft appears in the cabinet's «Блог» section for review. Runs propose→confirm. CONFIRMATION: this tool is PROPOSED, never performed directly. You get status='confirmation_required' with an action_id and a plan_token, and the write happens only after confirm_action.

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": {
      "title": "<title>"
    },
    "name": "blog_create_draft"
  }
}

Input Schema

Name	Required	Description
`site`	No	Site id, name or subdomain. Optional when the workspace has exactly one blog-capable site.
`tags`	No
`text`	No	Article text. Paragraphs separated by a blank line; a line starting with '## ' or '### ' is a heading; lines starting with '- ' form a list. Inline bold, italic and [label](https://url) are kept.
`title`	Yes
`excerpt`	No
`category`	No	Existing category name or slug.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the tool is proposed rather than executed, that the response carries status='confirmation_required' with an action_id and plan_token, and that the write only occurs after confirm_action. The annotations only say readOnlyHint=false and destructiveHint=false; the description supplies the entire two-phase contract.

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 action and scope, then the confirmation protocol, which is the highest-risk information. The 'CONFIRMATION:' label aids scanning. It is slightly long and repeats the propose→confirm idea twice, costing a point.

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 non-destructive mutation with no output schema, the description covers what is created, where it appears, and exactly how the confirmation round-trip returns and resolves. It omits failure modes and permission requirements, but nothing essential to calling it correctly is missing.

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 schema coverage at 50%, the description compensates by naming title, text, optional excerpt, tags, category name, and the site the post targets, and it clarifies that excerpt is optional. The rich text formatting rules stay in the schema, which is appropriate. It adds useful meaning without duplicating the schema verbatim.

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 ('Create a blog post as a DRAFT') plus the scope ('on a site of this workspace') and enumerates the supported fields. The parenthetical 'never published by this tool' immediately separates it from blog_publish_post without the agent needing another schema.

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

Usage Guidelines4/5

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

Explains the outcome that selects this tool ('The draft appears in the cabinet's «Блог» section for review') and excludes publishing. It also names the follow-up confirmation step. It stops short of contrasting with sibling update tools such as blog_update_post or proc_plan_create_draft, so the guidance is clear but not exhaustive.

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

All OrgLines 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?