Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_manager_kb_write

Writes canonical knowledge base data by upserting, ingesting, superseding, or archiving entries with idempotency and provenance tracking.

Instructions

MANAGER WRITE: upsert, ingest, supersede, or archive canonical KB data.

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": {
      "action": "<action>",
      "key": "<key>",
      "idempotency_key": "<idempotency_key>",
      "provenance": "<provenance>"
    },
    "name": "aiworkhub_manager_kb_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYesKB entry key, non-blank, at most 256 bytes.
bodyNoEntry text, at most 32 KiB; required except for archive.
tagsNoTag string, at most 1024 bytes; default empty.
titleNoEntry title, at most 1024 bytes; required except for archive.
actionYesupsert or ingest creates or updates the entry for key, supersede stores a new entry under replacement_key and marks the old one superseded, archive retires the entry.
categoryNoCategory label, at most 128 bytes; default empty.
provenanceYesNon-blank provenance text recorded in the audit row, at most 2048 bytes.
source_refsNoSource references for the entry, at most 2048 bytes; default empty.
idempotency_keyYes8-192 characters matching ^[A-Za-z0-9][A-Za-z0-9_.:-]{7,191}$; replaying a key returns the first result instead of writing again.
replacement_keyNoKey of the new entry that supersedes key, at most 256 bytes and not already in use; required for supersede.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.12.67
    • addedInput schema / properties / action / description
      Added value: +"upsert or ingest creates or updates the entry for key, supersede stores a new entry under replacement_key and marks the old one superseded, archive retires the entry."
    • addedInput schema / properties / body / description
      Added value: +"Entry text, at most 32 KiB; required except for archive."
    • addedInput schema / properties / category / description
      Added value: +"Category label, at most 128 bytes; default empty."
    • addedInput schema / properties / idempotency_key / description
      Added value: +"8-192 characters matching ^[A-Za-z0-9][A-Za-z0-9_.:-]{7,191}$; replaying a key returns the first result instead of writing again."
    • addedInput schema / properties / key / description
      Added value: +"KB entry key, non-blank, at most 256 bytes."
    • addedInput schema / properties / provenance / description
      Added value: +"Non-blank provenance text recorded in the audit row, at most 2048 bytes."
    • addedInput schema / properties / replacement_key / description
      Added value: +"Key of the new entry that supersedes key, at most 256 bytes and not already in use; required for supersede."
    • addedInput schema / properties / source_refs / description
      Added value: +"Source references for the entry, at most 2048 bytes; default empty."
    • addedInput schema / properties / tags / description
      Added value: +"Tag string, at most 1024 bytes; default empty."
    • addedInput schema / properties / title / description
      Added value: +"Entry title, at most 1024 bytes; required except for archive."
  2. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partially covered. The description adds little beyond the action names: it does not explain that writes are canonical, that provenance is audited, that idempotency keys prevent duplicate writes, or what archive/supersede do to existing entries.

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 description is a single front-loaded sentence with no wasted words. However, it is perhaps too terse for a 10-parameter tool with four distinct write modes, leaving important structure to the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema, annotations, and output schema, the definition is minimally callable. But for a canonical KB mutation tool with archive and supersede modes, the description should at least clarify when to use this tool versus other write tools and what the modes do to existing entries.

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 10 parameters thoroughly. The description does not add any parameter semantics beyond the action list, which the schema action enum already explains in more detail.

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 names four specific write operations—upsert, ingest, supersede, archive—and the resource family: canonical KB data. It distinguishes this as a write tool, but does not explicitly differentiate it from sibling write tools such as aiworkhub_manager_ai_memory_write or context_graph_event_write.

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

Usage Guidelines2/5

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

The description offers no guidance on when to choose this tool over sibling write tools, nor when to choose each action. The action enum in the schema provides action-specific semantics, but the description itself provides no usage context or exclusions.

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

Deploy Server

Other Tools