PingAura

Create article

create-article

Create an article on a domain from a finished Markdown body, with no AI generation. It counts toward the articles quota for the billing period and is refused once the quota is used up. The slug is made from the title unless given; a slug already used on the domain is rejected. Status is ready (default) or draft. Needs a user-tied credential. Returns the new article id, slug and status.

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": {
      "domain_id": "<domain_id>",
      "title": "<title>",
      "content_md": "<content_md>",
      "article_type": "<article_type>"
    },
    "name": "create-article"
  }
}

Input Schema

Name	Required	Description	Default
`slug`	No	URL slug: lowercase letters, numbers and hyphens. Made from the title when left out.
`title`	Yes	Article title
`status`	No	Initial status: ready (default) or draft	ready
`summary`	No	Short summary
`keywords`	No	Target keywords, up to 15
`domain_id`	Yes	Domain ID from list-domains
`content_md`	Yes	Article body in Markdown
`article_type`	Yes	Article format: ranked_list, topic_guide, comparison, how_to, alternatives, review, case_study or checklist
`meta_description`	No	Meta description

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026
- changedInput schema / properties / domain_id / description
```
Previous value: -"Domain ID"New value: +"Domain ID from list-domains"
```

Changed2 schema fields changedOct 30, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / domain_id / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

AddedOct 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (which only confirm this is a non-read-only, non-destructive, closed-world mutation), the description discloses quota consumption and refusal on exhaustion, slug auto-generation and uniqueness rejection, default status behavior, the user-tied credential requirement, and the returned fields. These are the key side effects and failure modes an agent needs before invoking a create operation.

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

Conciseness5/5

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

The description is four dense sentences with no filler, front-loading the core action and source, then prerequisites, slug rules, and return values. Every sentence contributes useful information and nothing is repeated unnecessarily.

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?

There is no output schema, and the description explicitly covers the return values (id, slug, status). For a quota-consuming mutation with uniqueness and credential requirements, it supplies the behavioral context an agent needs to call it correctly and anticipate failure modes.

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

Parameters3/5

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 all nine parameters, including slug format, status default, and article_type values. The description reinforces slug derivation and status default but adds no syntax or meaning beyond what is already structured, so the baseline of 3 is appropriate.

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?

The description states a specific verb and resource ('Create an article on a domain') and explicitly scopes the source ('from a finished Markdown body, with no AI generation'). That clause cleanly separates it from AI-generation or prompt-based siblings such as create-prompt, so an agent can identify the correct tool without inspecting the 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?

It gives a clear usage condition — use this when you already have finished Markdown and do not want AI generation — and notes the credential and quota prerequisites. It stops short of explicitly naming alternatives or stating when not to use it (e.g., to modify an existing article use update-article), so it is strong 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 PingAura 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?