Skip to main content
Glama

knowledge_document_context

Read-onlyIdempotent

Plan document outlines and collect section evidence from project documentation and code, producing bounded, evidence-backed context with explicit gap reports.

Instructions

Document plans and section evidence.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
actionYesplan=design outline;section=collect evidence.
audienceNo
languageNo
max_pagesNo
objectiveNo
page_pathsNo
page_typesNo
diagram_modeNo
max_sectionsNo
project_nameNo
document_typeYes
section_titleNo
max_total_charsNo
max_output_charsNo
required_evidenceNo
required_sectionsNo
retrieval_profileNocoverage
max_chars_per_pageNo
preferred_evidenceNo
heuristic_token_budgetNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateYes
guidanceNo
nextActionYes
resultTextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.9.0
    • changedInput schema / properties / action / description
      Previous value: -"plan=design outline; section=collect evidence."New value: +"plan=design outline;section=collect evidence."
    • removedOutput schema / additionalProperties
      Removed value: -true
  2. First observedv2.7.0

TDQS

D1.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context beyond that. It does not disclose action modes, output behavior, or any constraints; 'Document' is also ambiguous enough to not clearly signal a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and free of padding, but it is under-specified rather than appropriately concise. A terse fragment cannot convey meaning for a 21-parameter tool, so brevity is not earning its place.

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

Completeness1/5

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

For a complex tool with 21 parameters, 2 required fields, and many siblings, this description is severely incomplete. It leaves the agent to infer the two action modes, required fields, retrieval behavior, and relationship to knowledge_document/knowledge_context from names and schema alone.

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

Parameters1/5

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

Schema description coverage is only 5%, and the description does not compensate for 21 mostly undocumented parameters. It adds no meaning to query, action, document_type, required_evidence, or any other field beyond the single schema-provided action note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Document plans and section evidence' is a noun-phrase fragment rather than a clear verb+resource statement; it does not say what the tool does with plans/evidence. It gives no differentiation from siblings such as knowledge_document, knowledge_context, or knowledge_page.

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?

No when-to-use guidance or exclusions are provided, and no alternatives are named. The only hint is the action enum in the schema ('plan=design outline;section=collect evidence'), which the description itself does not surface.

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