FeatureOS

Create article

create_article

Create a new knowledge base article in a collection.

Creates a draft by default. status='published' puts the article live on the help center, so it needs the user's approval: without confirm=true nothing is created and the pending change is returned.

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

Input Schema

Name	Required	Description	Default
`title`	Yes	Title of the article (also used to generate the slug).
`locale`	No	Language code, e.g. 'en', 'es', 'fr'. Defaults to 'en'.	en
`status`	No	Article status. Defaults to 'draft'. A 'published' article is live immediately, since create writes the live description directly.	draft
`confirm`	No	Required with status='published'. Set true ONLY after the user has explicitly approved this exact change in the conversation. Without it the tool changes nothing and returns the pending change for the user to approve.
`privacy`	No	Article privacy. Defaults to 'public'.	public
`tag_ids`	No	Tag IDs to attach. Pass a JSON array of integers, e.g. [1, 2]. Do NOT pass a quoted string.
`seo_title`	No	Custom SEO title for the article.
`cover_image`	No	Cover image URL (jpeg, jpg, png, or gif; max 10 MB).
`description`	No	Article body/content. Accepts HTML.
`assignee_ids`	No	Team-member IDs to assign. Pass a JSON array of integers, e.g. [1, 2]. Do NOT pass a quoted string.
`collection_id`	Yes	ID of the collection this article belongs to (from list_collections).
`seo_description`	No	Custom SEO meta description.

Output Schema

Name	Required	Description	Default
`article`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only say this is a non-destructive write in an open-world context; the description adds real behavioral value by disclosing that publishing makes the article live on the help center, that the default is a private-ish draft, and that without confirm=true nothing is created and a pending change is returned. That is exactly the side-effect and safety context an agent needs before calling a write tool.

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?

Two short paragraphs, with the default behavior first and the approval gate second. Every sentence carries a distinct, decision-relevant fact and there is no filler.

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 12-parameter write tool with annotations and an output schema, the description covers the one genuinely dangerous decision (publishing) and the approval protocol. It does not discuss locale/privacy interactions or how collection_id is obtained, but the schema and list_collections sibling fill those gaps.

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 coverage is 100%, and the schema already documents the confirm/status dependency in the confirm field itself, so the description largely restates rather than extends parameter meaning. A baseline 3 is appropriate given the schema does the heavy lifting.

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 opens with a specific verb and resource ('Create a new knowledge base article in a collection'), which is enough to separate it from siblings like create_changelog or update_article. It stops short of explicitly naming an alternative tool, so it lands at a strong 4 rather than a 5.

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 clear conditional usage guidance: draft by default, and status='published' requires the user's approval via confirm=true. What's missing is routing guidance against alternatives such as update_article for existing content or guidance on preconditions like having a valid collection_id.

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

All FeatureOS 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.