RunWhen Platform MCP

Create Knowledge Base Article

create_knowledge_base_article

Adds operational Knowledge Base articles to a workspace, making architecture notes, troubleshooting guides, and runbook context searchable by AI assistants.

Instructions

Create a new Knowledge Base article in a workspace.

Skill: runwhen-skill://manage-knowledge (article scoping + lifecycle).

KB articles are indexed into the Knowledge Overlay Graph and become searchable by the workspace AI assistant and other tools.

Content should be informative operational knowledge — architecture notes, troubleshooting guides, runbook context, dependency documentation, etc.

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": {
      "content": "<content>",
      "workspace_name": "<workspace_name>"
    },
    "name": "create_knowledge_base_article"
  }
}

Input Schema

Name	Required	Description
`title`	No	Human-readable article title (max 255 chars). Strongly recommended: title is the primary field for title-weighted KB search and the workspace global-note catalog. If omitted the note is stored title-less and under-performs on retrieval.
`content`	Yes	The article content (plain text or markdown, max 20000 chars).
`resource_paths`	No	Canonical resource paths (e.g. ['kubernetes/namespace/prod']).
`workspace_name`	Yes	The workspace to create in (e.g. 't-oncall').
`abstract_entities`	No	Entity tokens for indexing (e.g. ['oom-killed', 'memory-limits']).

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.4Aug 19, 2026

addedInput schema / properties / title

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Human-readable article title (max 255 chars). Strongly recommended: title is the primary field for title-weighted KB search and the workspace global-note catalog. If omitted the note is stored title-less and under-performs on retrieval."
+}

First observedv0.1.0Jul 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses a post-creation side effect: articles are indexed into the Knowledge Overlay Graph and become searchable by the workspace AI assistant and other tools. It omits permission/auth requirements, duplicate-title handling, and what happens to existing content, leaving meaningful gaps for a mutation tool.

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 purpose is front-loaded in the first sentence, followed by the skill reference, indexing behavior, and content guidance. Reasonably sized with little waste, though the inline 'Skill:' reference is slightly cryptic without further context.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, indexing effect, and content expectations for an unannotated create tool. Residual gaps are the missing permission/auth and duplicate-handling behavior, which a mutation tool would ideally state.

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 every parameter in detail (including the title recommendation and char limits), so the baseline is 3. The description adds content-topic examples but no field-level semantics beyond what the schema provides.

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?

States a specific verb and resource ('Create a new Knowledge Base article') with the scope ('in a workspace'), which is clearly distinguishable from update/delete/get siblings. It stops short of naming the alternative create/update/delete tools or when each applies, so it is clear but not fully differentiated.

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 offers content guidance ('architecture notes, troubleshooting guides, runbook context') and references a skill for scoping/lifecycle, which implies usage. However it never says when to create vs use update_knowledge_base_article or when creation is inappropriate, so the when/when-not routing is left to inference.

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

Deploy Server