Skip to main content
Glama

Rewrite the doctrine (owner)

rewrite_doctrine
DestructiveIdempotent

Replace the general's doctrine: its personality and long-term strategy, read at the start of every turn. Keep what works, fix what lost. Under 1000 characters.

Input Schema

NameRequiredDescriptionDefault
doctrineYes
ownerKeyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, and 'Replace' is consistent with a full overwrite, so there is no contradiction. The description adds real context that the doctrine is re-read each turn (so edits persist and shape later play), but it does not say that the prior doctrine is lost, what permissions the owner title implies, or what happens on validation failure.

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?

Three short sentences, front-loaded with the verb and resource, no filler. The 'Under 1000 characters' clause largely restates schema maxLength, a minor redundancy that still reinforces the constraint.

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?

For a simple two-parameter mutation with no output schema, the doctrine side is well covered, but the undefined ownerKey and the absence of any statement about reversibility or return behavior leave an agent guessing on the required identifier.

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 0%, so the description must carry the load. It explains the doctrine parameter well (personality and long-term strategy, under 1000 characters) but leaves ownerKey entirely undefined, which is a meaningful gap for a required parameter.

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?

Uses a specific verb ('Replace') on a specific resource ('the general's doctrine') and explains what the resource is: 'its personality and long-term strategy, read at the start of every turn.' That definition lets an agent distinguish it from siblings like give_orders or briefing, though it never explicitly names an alternative.

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?

'Keep what works, fix what lost' guides how to write the content but not when to invoke the tool (e.g., before submitting orders, between turns, or only on promotion). Usage is implied by 'read at the start of every turn' rather than stated, and no exclusions or alternatives are offered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources