Skip to main content
Glama

knowledgeowl

by io.usefulapi

Create an article

create_article
Destructive

MUTATES KnowledgeOwl data: creates a new article. KnowledgeOwl API: POST /article.json (JSON). Required by the API: project_id, name, status, url_hash, visibility, and current_version (a nested object { <lang>: { title, body, ... } } — pass it via the fields passthrough). Returns the created article.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe article name/title (required).
fieldsNoAdditional documented KnowledgeOwl fields to send in the JSON write body (e.g. current_version, body) — merged OVER the typed fields above.
statusNoPublishing status, e.g. "published", "draft", "review".
url_hashNoThe article URL slug (e.g. "getting-started").
project_idYesThe knowledge base (project) id this article belongs to (required).
visibilityNoVisibility, e.g. "public" or "private".

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark destructiveHint=true, and the description reinforces this with 'MUTATES.' It adds useful behavioral context beyond annotations: the HTTP POST method, API-required fields, the nested current_version structure, and that the created article is returned. It does not discuss auth or side effects, but the annotation covers the destructive nature.

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 three sentences with no filler. It front-loads the core purpose, then adds the API endpoint, required fields, passthrough mechanism, and return value. Every sentence contributes distinct, actionable information.

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 creation tool with nested objects and no output schema, the description covers the critical operational details: the write endpoint, API-required fields, how to pass current_version, and the return value. It does not enumerate all possible subfields of current_version, but the provided structure is sufficient for an agent to construct the call correctly.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds significant meaning by stating that the API requires status, url_hash, visibility, and current_version even though the schema only marks project_id and name as required. It also explains how to pass the nested current_version object via the fields passthrough, which is essential for correct invocation.

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 opens with 'MUTATES KnowledgeOwl data: creates a new article,' identifying a specific verb and resource. It also names the exact API endpoint, POST /article.json, which clearly differentiates this creation tool from sibling tools like get_article, update_article, create_category, etc.

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

Usage Guidelines3/5

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

The description implies use when creating a new article, and 'MUTATES' distinguishes it from read-only list/get tools. However, it does not explicitly state when to choose this over update_article or provide any exclusions or alternative routing, leaving some selection guidance to inference.

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

All knowledgeowl toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose targeting a specific resource (article, category, glossary, etc.) and action (create, get, list, update). There is no ambiguity or overlap between tool names.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: create_X, get_X, list_X, update_X. The exception 'knowledgeowl_request' is a utility escape hatch, clearly marked, and does not break the overall pattern.

Tool Count4/5

At 24 tools, the set is slightly above the typical 3-15 range but still well-scoped for a knowledge base API covering many resources. Each tool serves a distinct purpose, and no tools are redundant.

Completeness2/5

The tool set lacks delete operations for all resources, and update operations are only available for articles and categories. Missing get tools for glossary terms, snippets, and other resources, though list tools are provided. This leaves significant gaps in lifecycle coverage.

Resources