PCD (Portable Context Deck)

Manage Knowledge

manage_knowledge

Initialise or maintain the knowledge corpus: manifest, domains, indexes, verification and template audits. Use write_knowledge to author record content.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Domain name — required for add_domain / remove_domain.
`action`	Yes	describe: read manifest · ages: per-record days since verified_at — a pure date delta, no threshold or verdict; apply your own cadence on top · refresh_index: rebuild knowledge-index · refresh_manual_index: rebuild manual-index · add_domain / remove_domain: manage declared domains · verify: batch-refresh verified_at on record_ids · audit_templates: check records against their category's template; emits a signal per finding (deduped) and returns them. · initialise: idempotently initialize the corpus; accepts only container_id.
`category`	No	Category filter — optional for audit_templates and ages (e.g. "manual" to scope to manual records).
`contract`	No	Help mode — return the complete contract with no operation performed.
`record_ids`	No	Array of record UUIDs — required for verify.
`description`	No	Domain description — optional for add_domain.
`container_id`	Yes	Container ID — required. Scopes all operations.
`include_drafts`	No	Include draft records — optional for audit_templates (default false: live records only).
`include_superseded`	No	Include superseded records — optional for audit_templates (default false: current records only; superseded ids retired by a newer record are excluded).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 7, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / action / description

Previous value: -"describe: read manifest · ages: per-record days since verified_at — a pure date delta, no threshold or verdict; apply your own cadence on top · refresh_index: rebuild knowledge-index · refresh_manual_index: rebuild manual-index · add_domain / remove_domain: manage declared domains · verify: batch-refresh verified_at on record_ids · audit_templates: check records against their category's template; emits a signal per finding (deduped) and returns them."New value: +"describe: read manifest · ages: per-record days since verified_at — a pure date delta, no threshold or verdict; apply your own cadence on top · refresh_index: rebuild knowledge-index · refresh_manual_index: rebuild manual-index · add_domain / remove_domain: manage declared domains · verify: batch-refresh verified_at on record_ids · audit_templates: check records against their category's template; emits a signal per finding (deduped) and returns them. · initialise: idempotently initialize the corpus; accepts only container_id."

changedInput schema / properties / action / enum

Previous value: -[
-  "describe",
-  "ages",
-  "refresh_index",
-  "refresh_manual_index",
-  "add_domain",
-  "remove_domain",
-  "verify",
-  "audit_templates"
-]New value: +[
+  "describe",
+  "ages",
+  "refresh_index",
+  "refresh_manual_index",
+  "add_domain",
+  "remove_domain",
+  "verify",
+  "audit_templates",
+  "initialise"
+]

changedInput schema / properties / contract / description

Previous value: -"Help mode — pass true to receive this tool's full _meta.contract (all variants) with NO operation performed."New value: +"Help mode — return the complete contract with no operation performed."

First observedSep 7, 2026

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=false), so the description is only expected to add side-effect context. 'Initialise or maintain' signals mutation but does not disclose what refresh_index, verify, add_domain, or remove_domain actually change or require, and no such details are supplied.

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 sentences, no filler, with the primary purpose front-loaded and the sibling routing placed second. Every word contributes to orienting the agent.

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

Completeness2/5

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

This is a high-complexity dispatcher with nine actions, nine parameters, and no output schema, yet the description offers only an umbrella statement and one sibling rule. An agent still needs to infer when to run initialise vs refresh_index vs verify and what each action accomplishes, which the schema does not fully compensate for.

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 baseline is 3 and the description need not repeat parameter docs. The description's list (manifest, domains, indexes, verification, template audits) loosely maps to the action enum values, but it adds no parameter-level meaning beyond the schema.

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 a concrete resource ('knowledge corpus') and verbs ('Initialise or maintain'), and lists the operational areas: manifest, domains, indexes, verification, template audits. It also distinguishes itself from the sibling write_knowledge by routing content authoring to that tool, though it does not explicitly contrast with read_knowledge or find_knowledge.

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?

It provides one clear alternative: 'Use write_knowledge to author record content.' However, it does not state when to prefer manage_knowledge over read_knowledge/find_knowledge, nor does it give selection context for the nine action variants, so an agent must infer when to call the tool.

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

All PCD (Portable Context Deck) 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?