Engram

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.0-beta.12
Disambiguation4/5
Most tools have distinct purposes, such as 'mcp_engram_remember' vs 'mcp_engram_remember_solution' and 'mcp_engram_recall' variants. However, some overlap exists—e.g., 'mcp_engram_context_for_edit', 'mcp_engram_context_for_file', and 'mcp_engram_evolution_at_locus' all provide contextual memory but with different scopes, which could confuse an agent.
Naming Consistency4/5
All tools follow a consistent 'mcp_engram_<descriptive_name>' pattern, with occasional structural variations like 'mcp_engram_quick_trace' (adjective+noun) or 'mcp_engram_context_for_file' (noun+preposition+noun). The overall pattern is predictable, but not strictly verb_noun throughout.
Tool Count2/5
With 79 tools, the server is extremely bloated for a memory management system. While some complexity is expected, this count is excessive and likely overwhelming for agents. Fewer, more versatile tools would improve usability.
Completeness5/5
The tool set covers the full lifecycle of memory management: creation, retrieval, update, deletion, search, visualization, export/import, goal tracking, spatial context, verification, and user modeling. No obvious gaps are apparent for the intended domain.
Average 4/5 across 79 of 79 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 370 commits in the last 12 weeks
- Last stable release on August 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It fails to specify important details such as ordering of results, how 'active' vs 'recent' are defined, or the effect of combining parameters. The tool appears non-destructive, but the description provides minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main action. However, the inclusion of an inaccurate filter ('parent') detracts from its efficiency and reliability.
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?
Given the tool has two optional parameters, no output schema, and no annotations, the description should provide more context about the returned goal objects (e.g., fields, ordering). It fails to define 'active' or 'recent' and does not mention pagination or limits, leaving the agent without sufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 100% coverage with descriptions, the tool description adds misleading information by mentioning a 'parent' filter that does not exist in the schema. This harms rather than helps parameter understanding. The existing schema descriptions are sufficient, but the description's inaccuracy reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List active or recent goals' with optional filters, which clearly indicates the tool's purpose. However, it inaccurately mentions filtering by 'parent' which is not present in the input schema, reducing clarity and potentially misleading the agent.
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 notes that the tool is 'useful for the engram-goal skill and for surfacing current intent in ki_hijacker / wake-up,' providing some context. But it does not differentiate from sibling tools like mcp_engram_goal_search or mcp_engram_goal_get_children, leaving the agent to infer when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions returning metadata and previews but does not disclose behavioral traits like side effects, permissions, or constraints. The jargon ('provlog', 'geometry_ref') adds ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but uses domain-specific jargon ('LinguisticDiscourseBundle', 'context_bundle_v1') that may confuse agents. Adequate brevity but at the cost of clarity.
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?
With 7 parameters, no output schema, and zero annotations, the description is insufficient. It provides a high-level purpose but omits details on parameters, return values, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only 'name' and 'prefixes' have descriptions). The description adds no detail about parameters like 'concepts', 'limit', 'min_crs', or 'preview_chars'. It fails to compensate for the low coverage.
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?
Description states a specific verb ('Declare') and resource ('context variable handle'), and mentions the tool binds concepts and returns metadata. However, it does not clearly differentiate this from sibling tools like mcp_engram_var_project or mcp_engram_var_query.
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 guidance on when to use this tool versus alternatives. Among 60+ sibling tools, there is no indication of its specific role or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It mentions 'Phase 3' and the computation method (VSA geometric/cosine) but omits side effects, authorization needs, rate limits, or whether it modifies state. The description is too abstract for an agent to understand operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loads the core purpose. However, it relies heavily on jargon ('Fibered', 'Linguistic*', 'CRS-scored', 'VSA'), reducing accessibility for a general AI 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?
The tool involves complex domain concepts and nested object parameters, but the description does not explain what a LinguisticDiscourseBundle is, how to prepare it, or interpret the output. No output schema exists to fill the gap. Incomplete for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions provide minimal labels ('First LinguisticDiscourseBundle'), and the description adds no further explanation of what constitutes a valid bundle or how to obtain one. With 100% schema coverage but shallow descriptions, the description fails to compensate for the lack of semantic depth.
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 states a specific action: 'fibered equivalence check' and identifies the resources ('two Linguistic* presentations'). It mentions the output ('CRS-scored equivalence block'), providing a clear purpose for domain-aware agents.
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 guidance on when to use this tool versus alternatives like mcp_linguistic_calculus or other engram tools. No prerequisites or context for invocation are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It mentions producing wildcards and graph edges but does not state if the operation is read-only, has side effects, requires permissions, or any rate limits. This is insufficient for the AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, but it uses domain jargon ('WS-3', 'sheaf TOML', 'wildcards + realized_by graph edges') that may be opaque. While not verbose, it sacrifices clarity for brevity.
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?
With one parameter, no output schema, and no annotations, the description is incomplete. It does not explain the return format, pagination, or any additional context needed to use the tool effectively.
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%, so baseline is 3. The description adds minimal value beyond the schema's definition of process_key as a process:engram.* key. The mention of 'per-process fulfillment metrics' slightly reinforces the parameter's role, but no additional meaning.
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 identifies the tool's purpose: per-process fulfillment metrics from sheaf TOML, producing wildcards and realized_by graph edges. It distinguishes from sibling tools which are mostly other engram operations (recall, forget, stats). However, 'WS-3' is cryptic and 'sheaf TOML' may be unclear, reducing clarity.
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 guidance on when to use this tool versus alternatives like mcp_engram_stats or other metrics-related tools. No exclusions or context is provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits fully. It states that a new var is minted (except to_linguistic_bundle returns a bundle), which implies creation behavior. However, it does not mention side effects like whether existing vars are modified, authorization needs, error conditions, or rate limits. The behavioral picture is incomplete.
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 very concise—two sentences—and front-loaded with the core verb and resource. It lists operations efficiently. However, the structure could be improved by separating the operation list and output behavior more clearly, but for the length it accomplishes its goal without waste.
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?
Given the tool's complexity (8 parameters, 5 operations, no output schema), the description is incomplete. It does not explain return formats (bundle vs. var) in detail, provide parameter dependencies, or error scenarios. The agent would need to guess many details about how to correctly invoke the tool.
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?
The description adds meaning for the 'operation' parameter by listing valid values, and for 'target_name' via schema description. However, schema coverage is only 13%, and the description does not explain 7 out of 8 parameters (e.g., k, min_crs, prefix, seed, vars, source_var). It compensates slightly by clarifying output type per operation, but overall parameter semantics are lacking.
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 clearly states it projects/transforms a context var and lists five specific operations (filter_crs, filter_prefix, etc.). It also distinguishes output types: mints a new var unless to_linguistic_bundle which returns a bundle. This provides a specific verb+resource and some distinction from sibling tools like mcp_engram_var_declare, though it could be more explicit about overall scope.
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 explicit guidance on when to use this tool versus alternatives (e.g., other var tools or sibling tools). The description lists operations but does not explain selection criteria, prerequisites (like source_var must exist), or when not to use. The agent is left to infer context from operation names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone bears responsibility for behavioral disclosure. It states 'Additive, CRS homotopy preserving,' which implies non-destructive behavior, but lacks details on safety, idempotency, permissions, or side effects. Some useful context is given but not comprehensive.
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 concise with two sentences, front-loading the main action and outputs. However, dense jargon ('functor-style', 'VSA', 'mint_linguistic', 'CRS homotopy') reduces clarity. It earns points for brevity but loses some for accessibility.
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 no output schema, the description should explain return values in more detail. It mentions 'crs + compressed preview' but does not define these terms or their structure. For a specialized tool aimed at domain experts, it may suffice, but for a general AI agent it is incomplete.
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 describes both parameters adequately. The description adds minimal extra meaning beyond mentioning 'word/context/discourse,' which is partially redundant. Thus baseline 3 is appropriate.
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 clearly states it compresses a LinguisticDiscourseBundle into a phase/payload block and returns a CRS and compressed preview. The verb 'compress' and differentiation from the sibling 'mcp_decompress_linguistic' are evident, though jargon like 'functor-style' and 'CRS homotopy' may obscure meaning for unfamiliar agents.
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 explicit guidance on when to use this tool versus alternatives. It mentions 'Phase 3' implying a sequence, but no prerequisites, caveats, or conditions are provided. The description does not tell the agent when not to use it or what to use instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It notes that the tool performs a reverse functor with a CRS check on roundtrip and returns crs + preview. However, it does not disclose what happens if CRS fails, permissions needed, or other side effects. This provides some transparency but is incomplete.
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 sentence and fragment, which is concise and front-loads the purpose. However, the heavy use of jargon ('functor', 'homotopy', 'CRS') may reduce clarity for less specialized agents, but it is not overly verbose.
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 complexity of a decompression tool and the lack of an output schema, the description provides some return information ('crs + result bundle preview') but lacks details on error handling, expected behavior on roundtrip failure, or prerequisite conditions. It is adequate but not fully complete for a complex operation.
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%, with both parameters described in the schema. The description adds the context 'reverse functor' and 'homotopy', but these are already implied by the parameter descriptions. The description does not significantly add meaning beyond the schema, so a baseline score of 3 is appropriate.
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 clearly states it decompresses a phase block back to a LinguisticDiscourseBundle, using technical terms like 'reverse functor' and 'homotopy'. It implies a relationship with compression but does not explicitly distinguish it from the sibling tool 'mcp_compress_linguistic', though the inverse nature is clear.
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 mentions 'Phase 3' and 'roundtrip' suggesting it's part of a pipeline, but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. The context is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses key side effects like auto-relating to primary and optional hot promotion, but omits details on idempotency, conflict behavior, permissions, or error conditions. Some transparency is present but incomplete.
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 relatively concise at three sentences and front-loads the core purpose. However, the jargon reduces clarity per word. Could benefit from plainer language but achieves efficiency.
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?
The description covers the main operations (create/update, bonds, automatic namespace), but lacks explanation of the geometric model, the meaning of '8192D unit q + momentum p', and how bonds and auto-relate interact. Without an output schema, an agent may face uncertainties. Adequate for an MVP but not fully complete.
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 description's parameter details mirror the schema exactly (e.g., 'Self-contained text encoded into geometric block' for 'text'). No additional meaning is added beyond the schema, so the baseline score of 3 is appropriate.
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 clearly states that the tool creates or updates a persistent geometric entry with optional dynamic bonds, which distinguishes it from sibling tools like mcp_engram_remember or mcp_engram_relate. However, heavy jargon (e.g., '8192D unit q + momentum p in .leg3', 'OP_BIND ZEDOS_RELATION edges') reduces accessibility.
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 does not provide any guidance on when to use this tool versus alternatives like mcp_engram_remember or mcp_engram_relate. No conditions, prerequisites, or exclusions are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses idempotency ('skips existing concepts') and the output format (.leg3), which are helpful behavioral traits. However, it omits side effects, required permissions, or failure modes, leaving gaps.
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 brief with three short sentences covering purpose, relation, and idempotency. No redundant or filler content. Slight jargon (WS5, .leg3) may obscure meaning, but overall it is efficiently front-loaded.
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 no annotations, output schema, or parameters, the description provides core purpose and idempotency. However, it lacks context to differentiate from numerous sibling ingest/creation tools (e.g., mcp_engram_import, mcp_engram_remember). An agent may need more context to select correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema description coverage is 100%. According to the rubric, baseline is 4. The description does not need to add param info, but the existing content (mentions of core components) aligns with the tool's action, justifying the score.
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 specifies a concrete action ('Mint formal_spec:linguistic_reference_frame_v1 + genesis pillar blocks into local .leg3'), which clearly identifies the tool's purpose. However, heavy jargon and absence of a title reduce accessibility, so it scores 4 instead of 5.
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 explicit guidance on when to use this tool versus alternatives. It mentions idempotency and a relationship to a patent spec, but does not state prerequisites, exclusions, or relative advantages over sibling tools like mcp_engram_import.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses core mechanics (phase q, momentum, sheaf gluing), operation types, return bundle, and side effects (mints training block, trace integration). However, missing details on error conditions, permissions, or state changes beyond described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph of ~80 words, front-loaded with purpose and operations. Information-dense but uses specialized jargon that could be simplified. Could benefit from bullet points or clearer sectioning, but overall not overly verbose.
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?
No output schema, yet return description is vague ('crs + result bundle/phase preview'). Missing details on return structure, error handling, prerequisites, or typical usage. Assumes significant domain knowledge without concrete examples or clarifications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions. Description adds useful context: operation enum values, morphological structure of bundle, role of path_bundles for integrate/operadic. This supplements the schema without redundancy, justifying above baseline 3.
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?
Clearly states it performs synthetic differential/integral/operadic calculus on LinguisticDiscourseBundle, listing three operations and return types. Distinguishes from sibling engram tools. However, dense jargon may obscure purpose for agents unfamiliar with the domain.
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?
Implies usage for linguistic calculus operations and mentions post-calc actions (ZEDOS_TRAINING, NREM), but does not explicitly specify when to use this tool vs alternatives or provide exclusion criteria. No direct sibling tools, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns daemon-extracted AABB AST items with line ranges and CRS first, then higher-level context, and mentions it is faster than free-text recall. Since no annotations are provided, the description carries full burden and does so adequately, though it omits details about potential side effects or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and includes enthusiastic flair ('TRIGGER', 'geometric Pre-Edit impact recon tool') that could be trimmed for conciseness. It contains multiple sentences with some redundancy, making it less efficient than ideal.
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?
The tool has no output schema, so the description should clarify the return value structure. It mentions 'AABB AST items with line ranges + CRS' and 'higher-level context' but does not detail the format or types of these items. Aspects like error handling or prerequisites are not covered.
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% with a single 'path' parameter described. The description adds no additional details about the parameter beyond what the schema provides, meeting the baseline.
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 clearly states this is a pre-edit context retrieval tool that returns spatially-prioritized AST items with line ranges. It distinguishes itself by emphasizing its geometric, spatial nature, but does not explicitly differentiate from the similar sibling 'mcp_engram_context_for_edit'.
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 says 'Call before editing any file' which implies usage context but does not provide explicit guidance on when not to use or alternatives. The sibling list includes similar tools like mcp_engram_context_for_edit and mcp_engram_recall_in_file, but no differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions goals being surfaced by engram-goal skill and ki_hijacker, but does not disclose side effects, permissions, or safety considerations for a creation tool.
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, front-loaded with key purpose, no wasted words.
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 7 parameters and no output schema, the description covers the creation intent and linking behavior but lacks return value info or examples. Adequate but with gaps.
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% with parameter descriptions. The tool description adds context about A/D/R triad and linking to traces, but does not elaborate beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new goal block as part of the agent's explicit goal stack' and distinguishes it from sibling goal tools (e.g., goal_decompose, goal_list) by emphasizing creation and linking to traces.
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 says 'primary entry point for declaring intent' and mentions linking to traces, but does not explicitly state when to avoid this tool or provide alternatives among the many sibling goal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool creates a marker for automatic linking, indicating a safe write operation. However, it does not describe what happens if a primary goal already exists or any side effects.
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?
The description is two sentences, front-loading the primary action and result, then adding a value statement. No redundant information.
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 one-parameter tool without an output schema, the description is adequate but does not specify the return value or confirmation of success.
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?
The schema already provides a description for the single parameter 'goal' (100% coverage). The description adds no additional semantic context beyond what the schema offers.
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 clearly states the action ('Mark a goal as the agent's current primary intent') and the mechanism ('creates a lightweight primary_goal marker'). This purpose is distinct from sibling tools like goal_create or goal_list, though it doesn't explicitly contrast them.
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 implies usage context ('reducing friction during focused work') but does not explicitly state when to use or avoid this tool, nor does it mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return of CRS and content snippet, but no annotations exist. Does not explicitly state read-only nature or side effects. Describes behavioral context but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but first is dense with jargon (e.g., 'Spatial recall (enhanced for ritual)', 'AABB coordinates', 'CRS') reducing clarity despite brevity.
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?
Provides return info (CRS, snippet) and use case hint, but lacks explanation of CRS, coordinate system, or how impact analysis works. Adequate for domain experts but not fully self-contained.
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% with descriptions for all 4 parameters. Description adds no new semantic value beyond the schema, maintaining baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes specific verb 'find', resource 'AST concepts', and scope 'in a line range with AABB coordinates'. Distinguishes from siblings like 'mcp_engram_recall' and 'mcp_engram_recall_recent' by specifying file and line range.
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?
Implied usage via 'spatial discipline' and 'low-friction Pre-Edit/Post-Delta impact analysis', but no explicit when-to-use vs alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It mentions edits and returns, but fails to explicitly state that the tool modifies files on disk or disclose any side effects, authorization needs, or safety guarantees beyond the vague 'SAFE' label.
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?
Front-loaded with key purpose and suboperation list. Examples are useful but lengthy; could be more concise. Overall structure is logical: purpose, usage, returns, examples.
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?
Covers purpose, usage, returns, and examples. Missing explicit statement about side effects (file modification) and prerequisites (file must exist). For a composite tool with no output schema, additional clarity on behavioral outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with two detailed few-shot examples showing real parameter combinations and usage context (e.g., arc_delta, goal_context, run_verify). This helps an agent understand how params relate in practice.
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?
Description clearly states it is a 'SAFE composite for code edits' and lists suboperations. It distinguishes from sibling mcp_engram_context_for_edit by advising preference when changing crates/, docs/, or processes/. Tool name and description align, but jargon (e.g., 'tensor edit_pattern bond') may reduce clarity for some agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preference over 'ad-hoc context_for_edit' for specific file types, providing useful context. However, it does not enumerate other alternatives (e.g., individual sub-tools like quick_trace) or state when NOT to use this composite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions modes and context extension, but does not disclose if the tool is read-only, any security or rate limit implications, or whether modifications are possible. Some behavioral context is given but incomplete.
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 with no wasted words. The key information (purpose, modes, benefit) is front-loaded and efficient.
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 no output schema and three parameters, the description covers the core purpose but lacks details on return values, error conditions, or how modes differ in output. It is adequate but not thorough for a query tool.
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?
The description adds meaning to the 'mode' parameter by listing its options and hints at the purpose of the tool (context extension), but does not explain 'preview_chars' beyond its default. Schema coverage is low (33%), and the description partially compensates but not fully.
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 clearly states the tool queries var:* handles with multiple modes (metadata, preview, relations, slots). It distinguishes from read_concept by noting it extends context window without reading every bound concept. However, it could more precisely define what a var handle is.
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 implies usage for querying var handles efficiently ('extends context window without read_concept on every bound concept'), but it lacks explicit guidance on when not to use it or comparisons to sibling tools like mcp_engram_read_concept.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses auto-ingest as a side effect (modifying the store) and notes safety via bounded stem prefix. However, it does not explicitly state that auto-ingest is a write operation, nor does it mention potential costs or irreversibility.
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, focused paragraph that front-loads the purpose and return fields. It is concise without being terse, though it could be slightly more structured (e.g., bullets) for easier parsing. No wasted sentences.
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?
The description explains return fields (no output schema) and auto-ingest behavior. With 6 parameters, it covers the key functionality: spatial filtering (implied by 'in range'), trace depth, preview chars. The mention of 'bounded evolution bundle' gives context. Lacks detailed explanation of spatial filter interplay, but overall complete.
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 parameters are already documented. The description adds no extra details about parameters themselves (e.g., how line_start/line_end affect spatial filtering), but it does describe output fields that depend on parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an 'evolution bundle at a file locus' and enumerates specific return fields (loci, arcs, trace_chain, etc.). It distinguishes itself from siblings like context_for_edit by mentioning auto-ingest behavior and same resolution, making its purpose specific and unique.
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 implies usage when needing spatial evolution data at a file locus and auto-ingests when no loci exist. It mentions safety on large stores, but does not explicitly state when to use this tool versus alternatives like context_for_edit or force_spatial_ingest. More explicit guidance would improve this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool forces ingestion without requiring file system save events, but it does not describe potential side effects (e.g., whether it overwrites existing data, performance impact, or required permissions). For a force operation, more behavioral context is needed.
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 effectively convey identity, purpose, and added value without any redundant information. The description is front-loaded with the tool's role.
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 tool's complexity as a bootstrap force operation and the absence of an output schema or annotations, the description is moderately complete. It explains what the tool does but lacks details on return values, error handling, or success/failure indications.
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%, so baseline is 3. The description adds minimal meaning beyond the schema, just summarizing that paths can be files or directories. No additional constraints or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Force the daemon to perform tree-sitter AST extraction and ingestion' and the resource 'a list of files or an entire directory'. It distinguishes the tool from manual operations and implies a different use case from the sibling 'incremental_spatial_ingest' by emphasizing bootstrapping without save events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by labeling it as an 'Item 1.5 bootstrap tool' and explaining it enables 'agent-driven historical spatial bootstrap instead of manual open+save'. However, it does not explicitly state when not to use this tool or mention alternatives like 'mcp_engram_incremental_spatial_ingest'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states the basic function and does not mention side effects, rate limits, pagination, or whether the operation is read-only. This lack of transparency hinders safe usage.
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?
The description is very concise: two sentences that front-load the action and purpose. Every sentence earns its place with no unnecessary words.
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?
The tool is simple with no output schema, so the description should at least outline return format. It says 'basic metadata' which is vague. Missing details on pagination, ordering, or how status filter works. Adequate but could be more informative.
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. The description does not add meaning beyond what the schema provides; it merely echoes that search is by text or status. No extra details on parameter formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for goals by statement text or status, returns matching goals with basic metadata, and specifies when it's useful (finding goals without exact IDs). This distinguishes it from sibling tools like mcp_engram_goal_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('when the agent wants to find existing goals without knowing exact IDs'). However, it does not explicitly exclude situations or mention alternatives, which could be helpful given the many sibling goal tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains that the tool builds, verifies, or samples corpus batches, and mentions data sources and verification steps. However, it does not disclose side effects, idempotency, permissions, or rate limits, which are important for safe invocation of a training corpus builder.
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?
The description is two sentences long, front-loading the main purpose and then listing actions. Every sentence adds value without redundancy. It is concise and well-structured for quick parsing.
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 8 parameters, no output schema, and no annotations, the description covers the core workflow but lacks details on return values, error states, or the meaning of 'homotopy verify'. It is adequate for a technical user but not fully comprehensive for an AI agent.
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 low (13%), but the description adds meaning by explaining the action enum and the min_crs filtering. It does not explain parameters like coherence_min, limit, or persist_manifest in detail. The description partially compensates for low schema coverage but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: building a .leg training corpus as leg_block_pack_v1 batches. It specifies three actions (build, verify, sample) and mentions the selection criteria (CRS>=min_crs) and additional steps (scrub_export + homotopy verify). This is specific and distinct from sibling tools.
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 outlines three actions and their functions, but does not provide explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or comparisons to sibling tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden and does well: it reveals encryption algorithm (XChaCha20-Poly1305), return constraints ('bounded snippet'), and an audit concept. It also surfaces environment dependencies. It does not mention side effects or failure modes, but for a read-like provisioning tool, this is solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with labeled sections (purpose, returns, ritual, env, few-shot), but it is dense with jargon and acronyms. The main idea is front-loaded, though the Ritual line and environment variable list may be necessary for operation. It is not as concise as it could be but is organized.
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?
Given no output schema and no annotations, the description covers the core needs: what it does, what it returns (snippet, integrity pointer, audit concept), environment prerequisites, and a few-shot example. It lacks failure modes and explicit alternative comparisons, but for a 3-parameter tool, this is reasonably complete.
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% for all three parameters, so the schema does the heavy lifting. The description adds a few-shot example with concrete values ('concept':'lexicon:word:sovereignty','query':'encrypted','max_chars':512) which aids usage, but it does not explain parameters beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'open an encrypted-at-rest ProvLog... for need-to-know only' with a defined output of 'bounded snippet + Merkle-related integrity pointer + audit concept'. The verb 'open' and resource 'ProvLog' are specific, and the encryption/need-to-know framing distinguishes it from sibling tools like mcp_engram_read_concept or mcp_engram_recall.
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 implies usage for secure, need-to-know selective disclosure and lists required environment variables (ENGRAM_ENCRYPT_AT_REST, etc.), which are prerequisites. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions dual-write and verified tensor update for propose_improvement but does not disclose whether the operation is destructive, idempotent, or any side effects. Lacks clarity on safety and permissions.
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 concise and front-loaded with the main purpose. However, it could be better structured by separating the primary functionality from detailed parameter notes. Still efficient with no wasted sentences.
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?
All 7 parameters are described adequately. However, with no output schema, the description does not explain what the tool returns (e.g., tile ID or confirmation). For a creation tool, this is a notable gap. The dual-write and bond creation are mentioned but not the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value by explaining tile_type options with examples, goal_context auto-linking logic, spatial_references creating compresses_path relations, and process_context emitting realized_by edge. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new Thought Tile' and explains its functionality: dual-writes with bonds, supports multiple tile types, auto-links to Primary Intent. It distinguishes from sibling 'thought_tile_create_visualization' as a companion for human-viewable output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to pair with visualization tool and notes that 'agent_response' tile type should instead use mcp_engram_turn_record for turn envelope. This provides usage context but does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Describes reseeding as 'repair' but does not disclose potential data loss or mutation side effects. Incomplete transparency for a re-initialization operation.
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?
Two front-loaded sentences with 'BEHAVIOR' and 'USAGE' labels. Concise, but structure could be improved with clearer separation of actions. No unnecessary words.
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?
For one-parameter tool with no output schema, description covers purpose, actions, and usage. Lacks details on output format but sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with enum descriptions. Description adds context: status for 'verify ethical/operational anchors', reseed for 'repair the manifold'. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Inspects or re-initializes' with specific resource 'core alignment genesis blocks'. Uniquely identifies foundational PRAXIS-tagged memories, differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use 'status' (verify anchors exist) and 'reseed' (repair missing/corrupted). Lacks explicit non-usage scenarios, but actions are well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the effects: LegView, backend hot cache, and explicit hot_set. Also mentions same mechanism as ki_hijacker promote_tile_to_high_priority. Could mention idempotency or side effects, but still good.
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. First states action and target, second states when to use and cross-reference. Every word earns its place.
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?
For a simple single-parameter tool with no output schema, description adequately covers purpose, usage, and parameter semantics. Missing mention of response or verification, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with examples (tile:..., helper:...). Description adds context by linking to usage timing (e.g., Thought Tiles, helpers), reinforcing parameter meaning.
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?
Clearly states verb (promote) and resource (concept to high-priority hot path), with specific LegView/backend cache/hot_set targets. Gives use cases but does not explicitly differentiate from sibling 'mcp_engram_promote_hot_batch' or 'mcp_engram_pin'.
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?
Provides explicit when-to-use scenarios (after creating high-value Thought Tiles, ritual anchors, helpers, before session_end/compression). However, no information on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states it returns content, implying a read operation, but does not explicitly confirm non-destructiveness or any side effects. Adequate but could be more explicit.
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?
The description is two sentences with no extraneous words. The key information is front-loaded with the tool's identity, making it highly efficient.
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?
Given the tool is simple (no parameters, no output schema), the description covers its purpose and usage sufficiently. It could mention the format of the state block, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% vacuously). The description adds no parameter info, which is acceptable because none exist. Baseline of 4 for zero parameters is appropriate.
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 clearly states the tool returns the current content of a specific state block, using a verb ('Returns') and specifying the resource. It implies a read-only status function but does not explicitly differentiate from siblings like mcp_engram_get_backend_readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool for quick checks on coverage, gaps, and readiness before heavy work, providing clear usage context. It does not specify exclusions but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what is captured (user utterance, assistant output, auto-aggregated traces). However, no annotations are provided, and the description does not mention auth requirements, side effects, or behavior on repeated calls, leaving gaps.
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 wasted words. Front-loaded with core action and key details. Highly efficient.
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 tool with 15 parameters and no output schema, the description provides a high-level overview but lacks detail on return values, prerequisites, or error conditions. Adequate but not comprehensive.
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 80%, and the schema already describes parameters well. The description adds no extra parameter detail, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it mints an RPT v3 agent_response turn tile, specifying the schema version. Differentiates from sibling tools by focusing on recording turn interactions, extending prior convention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use at end of each assistant turn (lean default)', providing clear context. Does not list alternatives or when not to use, but the instruction is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions applying 'thermodynamic CRS gating' (some internal behavior) and describes output as confirmation of committed concepts. Lacks details on potential partial failures or error handling.
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?
Three focused sentences, each serving a clear purpose: behavior, usage, output. No fluff, efficient communication.
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?
Covers purpose, usage, behavior, and output. Lacks details on batch size limits or error scenarios, but given simplicity of the tool (one parameter, no output schema), it is reasonably complete.
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 fully describes the 'entries' parameter (array of {concept, text}). Description adds context about 'distinct texts' and 'separate blocks' but does not significantly supplement the schema for parameter usage. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool encodes and stores multiple distinct texts as separate HolographicBlock memories, which distinguishes it from the sibling tool mcp_engram_remember that handles single entries. The verb 'batch remember' is well explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use for several unrelated facts/snippets and highlights performance gain over sequential calls. No explicit when-not-to-use, but the context implies it's not for single items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the automatic creation of 'decomposes_into' relations, which is a useful side effect. However, it does not discuss idempotency, error handling (e.g., parent not existing), permissions, or whether existing children are affected. A score of 3 reflects adequate but incomplete transparency.
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?
The description is two sentences long, front-loads the main action, and includes only essential information. Every sentence earns its place without redundancy or filler.
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?
Given no output schema, a relatively simple set of parameters, and multiple sibling tools, the description adequately covers the tool's purpose and side effect. It could mention constraints like requiring an existing parent, but overall it is sufficiently complete for an agent to understand when and how to use it.
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?
Both parameters are described in the input schema (100% coverage), so the description does not need to add much. The description does not elaborate on parameter values beyond what the schema provides. Therefore, a baseline score of 3 is appropriate, as the description adds no extra semantic value for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates child goals under an existing parent goal, and it positions itself as 'the primary mechanism for breaking down complex intent'. This specific verb+resource combination distinguishes it from siblings like mcp_engram_goal_create (root goals) and mcp_engram_goal_get_children (reading).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is 'the primary mechanism for breaking down complex intent', which implies when to use it for decomposition. However, it does not explicitly mention when not to use it or provide comparisons with other goal-related tools such as mcp_engram_goal_create or mcp_engram_goal_update_status. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Accurately states tool returns children and supports traversal. Lacks details on error handling or empty results, but overall honest and complete for a simple read operation.
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 short sentences pack essential information without filler. Efficient and front-loaded.
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?
Given no output schema and simplicity, description is adequate: explains input, output (children), and purpose (traversal). Minor omission: behavior when parent not found or no children.
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 already describes 'parent' with 'Parent goal concept name'. Description adds no new semantic value beyond implying hierarchical context. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly uses specific verb 'return all direct child goals' and resource 'parent goal'. Distinguishes from siblings like goal_list, goal_search, and goal_decompose by focusing on hierarchical traversal.
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?
Implies usage for traversing goal decomposition tree but does not explicitly state when to use vs alternatives like goal_list or goal_decompose. Missing guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists what the tool returns (traces, momentum signals, relationships) but does not explicitly state that it is a read-only, safe operation. While the purpose implies idempotence, the description could be more transparent about behavioral traits like lack of side effects.
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?
The description is two short sentences that efficiently convey the tool's purpose, what it returns, and its context in commands. Every word adds value, with no redundancy or fluff.
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?
Given the tool has one parameter and no output schema, the description adequately explains the return content (traces, momentum signals, relationships). It is nearly complete for a simple retrieval tool, though it could mention if any prerequisites or permissions are required.
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?
The schema description coverage is 100% for the single parameter 'goal', and the tool description adds no additional meaning beyond 'The goal concept name' already in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed status for a single goal, listing specific components (recent linked traces, momentum signals, parent/child relationships). It distinguishes itself from siblings like mcp_engram_goal_list and mcp_engram_goal_search by indicating it's for a specific goal and used in 'goal show' and 'goal status <id>'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by linking to commands 'goal show' and 'goal status <id>', implying when to use this tool. It does not explicitly exclude alternatives, but the sibling tool names make the differentiation clear. A score of 4 reflects clear usage context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is bounded and outputs a truncated list with notes, but does not explicitly declare it as read-only or discuss any side effects, permissions, or error conditions. The description adds moderate context beyond the bare minimum.
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 plus an output note, front-loading the purpose and providing essential guidance. No filler words, every sentence earns its place.
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?
For a simple list tool with no output schema, the description covers purpose, usage guidance, and output format (newline-separated, with total/truncation notes). It lacks explicit read-only declaration but is otherwise complete for its complexity.
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 baseline is 3. The description adds emphasis on using the prefix and provides examples, which adds modest value beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('lists'), the resource ('concept names in the memory manifold'), and the bounded nature. It distinguishes from sibling list tools by specifying concepts and including a warning about unfiltered dumps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to always pass a prefix and warns against unfiltered full dumps. It does not cross-reference alternative sibling tools, but the context of listing concepts is clear and the warning is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that each concept is promoted individually but in one call, but lacks details on permissions, side effects, or failure modes.
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, front-loaded with purpose, no fluff. Every sentence serves a clear role.
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?
For a batch variant with one parameter and no output schema, the description adequately covers the use case and efficiency benefit. Could mention return value or error behavior, but not essential.
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?
The description repeats the schema's description for the only parameter 'concepts', adding no additional meaning. With 100% schema coverage, the baseline is 3, and no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it batch promotes multiple concepts to the hot path, specifying the target (LegView, backend hot cache, hot_set). It effectively distinguishes from sibling mcp_engram_promote_hot by noting it reduces round-trips vs repeated single calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Used in optimized wake-up after rehydrate to batch hot anchors/tiles/traces.' This guides when to use. Lacks explicit when-not-to-use guidance, but the context implies it's for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral transparency. It does disclose the ranking algorithm (80/20 blend and α re-weight) and mentions filter behavior, which is useful. However, it does not explicitly state that this is a read-only operation, what the return format is, or any side effects. For a query tool, this is a gap, though less severe than for a mutating 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 description is a single paragraph with the core idea front-loaded and a distinct 'WHEN TO USE' section that improves scannability. However, it contains unexplained internal references like 'RSI Cycle 24' and 'goal-edge α' that an agent may not parse, and the phrasing could be tightened. Overall, it is efficient and well-structured, not overly verbose.
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?
There is no output schema, so the description should clarify what the tool returns. It implies it returns memory results (indicated by 'recall' and the k parameter), but does not explicitly state the return format or any additional behavior like pagination or sorting. Given the moderate complexity (4 parameters, no annotations), the description is adequate but leaves room for more completeness.
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%, with each parameter already having a clear description. The description's explanation of alpha_weighted and zedos_filter largely repeats schema information or introduces opaque jargon (e.g., 'edge_volatility_scale', 'RSI Cycle 24') that adds little clarity. It does add context about the 80/20 blending, but not enough to elevate the score beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Momentum-assisted recall' and specifies its core function: blending semantic similarity (q tensor, 80%) with conceptual trajectory (p tensor, 20%). It also distinguishes itself from the sibling tool mcp_engram_recall by explicitly stating 'WHEN TO USE INSTEAD OF recall', making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'WHEN TO USE INSTEAD OF recall: When you want concepts that are actively changing or evolving. Use regular recall for stable crystallized knowledge.' This clearly states when to use this tool versus the alternative. It also notes zedos_filter support including 'training', adding practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'crystallized' and 'CRS=1.0' without explanation, and does not describe side effects, whether it overwrites, or any error handling. The examples are domain-specific jargon. The agent is left without understanding key behaviors like idempotency or success/failure outcomes.
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 relatively concise with a clear structure: purpose, usage guidelines, then examples. It is front-loaded. However, the examples are lengthy and embedded, slightly reducing conciseness. Overall well-organized.
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?
With no output schema and 3 parameters (100% schema coverage), the description covers when to use the tool and provides examples, but it lacks details about the tool's return value, idempotency, or behavior on duplicate entries. The jargon (ZEDOS_PRAXIS, CRS) is unexplained. It is adequate but leaves gaps for an agent to fully understand the tool's contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing few-shot examples that demonstrate realistic parameter values, and it explains that the optional 'process_context' parameter emits a 'realized_by' edge (WS-3), which goes beyond the schema description. This clarifies the meaning and usage of parameters beyond mere field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for storing 'crystallized error→solution pair' with a defined framework (ZEDOS_PRAXIS, CRS=1.0). It distinguishes itself from sibling tools like mcp_engram_update by specifying it is for verified fixes, not routine deltas. The few-shot examples further solidify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use after verified fixes, not for routine deltas (use update).' This tells the agent exactly when to use this tool and provides an alternative (update) for other cases. The examples also illustrate appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the immediate effect and the core behavior of each mode (bounded recall vs. full BVH build). However, it omits potential side effects such as performance impact, persistence across sessions, or whether mode switching is destructive to existing data.
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?
The description consists of exactly two sentences with no extraneous information. The key action and mode distinctions are front-loaded, making it immediately scannable for an AI agent.
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?
Given the tool's simplicity—one required enum parameter, no output schema—the description is largely complete. It explains the modes and the immediate effect. Minor omissions like persistence or cross-process scope are acceptable but prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with an enum and a description for the only parameter. The description enriches this by explaining what each mode does operationally ('bounded recall' vs. 'auto-spawns full BVH build'), adding significant contextual value beyond the schema's simple labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Switch agent memory mode'), identifies the resource ('agent memory mode'), and distinguishes between two specific modes ('lean' and 'deep') with concise behavioral summaries. This differentiates it from sibling tools like mcp_engram_recall or mcp_engram_rebuild_bvh.
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 implies usage by listing the two modes and their characteristics but does not explicitly state when to choose one over the other or provide guidance on alternatives. The acknowledgment that the change affects the current process helps, but lacks proactive selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses automatic namespace creation and a success message output, but does not explain side effects on existing memories or permission requirements. For a simple switch tool, this is adequate but minimal.
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?
The description is three concise lines with labeled sections (BEHAVIOR, USAGE, OUTPUT). It is front-loaded and every sentence adds value, with no wasted words.
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?
Given the tool's simplicity (1 parameter, no output schema), the description covers purpose, usage timing, and output. It does not explain jargon like 'geometric context' or 'stalk', but this is likely domain-specific. Overall, it is sufficiently complete for correct invocation.
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?
The sole parameter 'namespace' has a clear schema description with examples. The description adds context that the namespace is project-specific and created if missing, but does not provide additional format or constraints beyond the schema. With 100% schema coverage, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool switches the active geometric context to a project-specific namespace and automatically creates it if missing. This distinguishes it from sibling tools like list_namespaces (listing) and remember (adding memories without switching context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this at the start of a session or when switching contexts, providing a clear use case. It does not mention when not to use it or alternative tools, but the guidance is sufficient for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses non-minting behavior but lacks details on side effects, permissions, or state modifications beyond 'build draft payload from trace chain'.
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?
Two concise sentences front-load the action, though 'WS-2' is cryptic; no fluff, but clarity could be slightly improved without the prefix.
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?
Lacks description of output payload structure or error conditions; with 2 parameters and no output schema, the description is adequate but not fully comprehensive.
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% with clear explanations for both parameters; description does not add further meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool builds a verified_sequence_v0 draft payload from a trace chain without minting a tile, distinguishing it from the sibling thought_tile_create which mints a tile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when condensation_hint fires or before thought_tile_create', providing clear context and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses side effects ('Triggers momentum + ki_hijacker refresh'), but does not cover error conditions, idempotency, or permission requirements. Adequate but not highly transparent.
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?
Three sentences, each adding value. No fluff, action-oriented first sentence, and a suggestion for additional use. Perfectly concise.
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?
For a write tool with no output schema, the description covers the core behavior and side effects. It lacks info on return value (e.g., success/failure indication) but is otherwise sufficient for an AI to understand usage.
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%, so baseline is 3. The description adds no extra meaning beyond the parameter descriptions in the schema. It does not elaborate on formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write result/update data') and the resource ('existing Thought Tile'). It distinguishes from siblings like create and create_visualization tools by specifying it's an update operation on existing tiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by mentioning it's useful after state changes in specific tile types (Research Offload, State Machine, Tabular). However, it does not explicitly state when not to use it or name direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool samples high-CRS blocks, reports gross issues, and is cheap—implying read-only behavior. However, it does not explicitly state it has no side effects, what happens on failure, or that it is safe and non-destructive. Lacks explicit safety profile.
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?
Three sentences, no fluff. First sentence states purpose, second explains method, third gives use cases. Excellent front-loading and efficient use of words.
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?
For a simple verification tool with two optional parameters and no output schema, the description covers purpose, method, use cases, and cost implications. It does not describe the return format or error conditions, but given the simplicity, this is a minor gap. Almost complete.
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% with clear parameter descriptions for 'min_crs' and 'sample_size.' The description reaffirms 'Samples high-CRS blocks' but does not add significant new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as a high-level integrity check of the memory manifold, explicitly contrasting with sibling tools (e.g., mcp_engram_verify_behavior, mcp_engram_verify_block_lawfulness). The description uses specific verb 'verify' and resource 'manifold integrity' with practical context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Designed to be reasonably cheap even on large manifolds' and 'Critical for trustworthy long-sleep / cold-boot scenarios.' This helps the agent decide when to call it, but does not explicitly exclude cases or mention alternative tools for more detailed checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the operation is non-deletive ('residency demote only'), lists protected path prefixes, and recommends dry-run first. It does not discuss reversibility or post-run effects, but this is strong transparency for the given context.
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 information-dense and front-loaded with the purpose. Each sentence adds relevant detail: trigger conditions, behavior, protections, and defaults. The protected-prefix list is long but necessary for safety, and there is no filler.
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?
For a 2-parameter tool with a detailed schema and no output schema, the description provides trigger conditions, behavioral guarantees, protected namespaces, and defaults. It does not specify the normal return value for non-dry-run calls, but overall it gives enough context for an agent to use it appropriately.
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?
The input schema already provides rich descriptions for both parameters, including defaults and clamping ('default 64, clamped 1..500') and dry_run behavior. The tool description mostly repeats this information, adding only the HOT_SET_SOFT target and the dry-run preference, so it adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation ('unmark non-protected hot residency toward HOT_SET_SOFT (1k)') and identifies it as a capacity/NREM/hot compress path. It distinguishes from deletion by stating 'Does NOT delete blocks — residency demote only' and lists protected prefixes, making it clear what this tool does versus related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger conditions are provided ('when soft_elevated_hot_set or elevated_hot_set'), along with practical guidance to 'Prefer dry_run=true first' and references to 'compress_path.suggested + nrem_candidate_count' as signals for when to call. However, it does not name alternative tools or explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Returns' and implies a read-only operation, but it does not explicitly confirm no side effects or permissions requirements. It does add useful context about the 'after wake' timing and interpretation of the fields, but the lack of explicit safety disclosure keeps it at a 3.
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 long sentence, but it front-loads the core purpose ('Returns backend readiness') and then efficiently lists all returned fields. It is dense but not wasteful; every element contributes meaning. Slightly long due to the exhaustive field list, but appropriate for a status tool with no output schema.
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?
Given no output schema, the description compensates by enumerating all returned fields and includes usage timing ('Use after wake'). It explains what to check ('whether recall is full GPU/BVH and whether RoMem α speed-gate is active'). It could further explain field meanings, but for a zero-param status tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so by the rubric baseline is 4. The description naturally needs no parameter details and adds no irrelevant param information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Returns backend readiness' and enumerates specific fields (fully_initialized, bvh_ready, recall_mode, etc.), making the purpose concrete and distinguishable from sibling tools like mcp_engram_stats or mcp_engram_spatial_status by its unique focus on backend readiness and alpha policy surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use after wake to see whether recall is full GPU/BVH and whether RoMem α speed-gate is active.' This tells the agent when to invoke it, but it does not explicitly mention alternatives or when not to use it, which would be needed for a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the requirement for creating a trace on specific status transitions, but lacks details on side effects, reversibility, or required permissions. With no annotations, the description only partially meets the need for behavioral transparency.
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 tight sentences: first states core action and allowed values, second adds critical behavioral note. No filler, front-loaded, every sentence serves a purpose.
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?
Missing explanation of return values (no output schema) and semantics of each status. Does not address constraints like status transition ordering. Adequate for a simple mutation, but could be more complete given the system complexity and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides clear descriptions for all three parameters (100% coverage). The description adds value by reinforcing valid statuses and noting the expected action for completed/demoted, going beyond the schema's enum listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'update' and resource 'status of an existing goal', lists allowed statuses, and distinguishes from sibling tools like mcp_engram_goal_create (creates new goal) and mcp_engram_goal_status (likely reads status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs caller to create a Goal Completion/Demotion Trace when moving to completed or demoted, providing key usage guidance. Does not explicitly say when not to use this tool or mention alternatives for status changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses creating 'VSA OP_BIND edges as ZEDOS_RELATION' and mentions batch behavior, but lacks details on side effects, idempotency, error handling, or permissions.
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 front-load the core purpose ('Batch create...') followed by usage examples. No wasted words.
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?
The description covers function and use cases but omits output behavior (e.g., return values, success/failure indicators). Given the single parameter and no output schema, completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all properties. The description adds value by specifying the VSA OP_BIND and ZEDOS_RELATION context, going beyond the schema's 'List of {concept_a, concept_b, label} to relate a->b with label'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch create multiple directional relations', specifying the verb (create), resource (relations), and batch nature. It distinguishes from the sibling 'mcp_engram_relate' by emphasizing batch operation and reduced round-trips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use: 'Reduces round-trips for gluing many at once (e.g. process requires, handoff lineage). Used in loader and lean wake batching.' It implies use for batch creation but does not explicitly state when not to use or mention the singular alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact contents of the wake bundle (primary_goal, suggested_actions, trace_chain head, slim ego_snapshot, presentation_stratum previews, trust_residual), notes a verification step (local CRS verify), and instructs the agent on sequencing. This is substantive behavioral disclosure, though it omits details about idempotency or error handling.
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 dense but front-loaded with the mandatory nature. It packs a lot of operational detail into four sentences, and every sentence serves a purpose. However, heavy use of acronyms and domain-specific terms (CRS, presentation_stratum, trace_chain) may reduce readability.
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?
For a session-start tool with no output schema, the description lists the bundle contents which serves as the expected output, and references documentation for deeper details. It covers the agent's immediate needs: what to expect, what to do, and what to avoid. It could mention the return value explicitly, but the bundle list suffices.
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?
All three parameters have schema descriptions, so the baseline for parameter semantics is 3. The description adds marginal context by linking 'primary_goal' to the intent parameter and confirming the default bundle, but it does not elaborate on include_spatial or spatial_max_files 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 identifies this as the 'MANDATORY first MCP call every session,' which clearly establishes its role as session initialization. It distinguishes itself from siblings by describing the default slim wake bundle and pointing to mcp_engram_get_continuation_bundle for the full harness. However, it does not explicitly state 'this tool starts a session' as a direct verb-object phrase, relying on the mandatory-first-call framing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('MANDATORY first MCP call every session'), what to do after ('Execute suggested_actions BEFORE edits; ack with mcp_engram_ack_wake_queue'), and what not to do ('do NOT call watch_workspace at wake'). It also names the alternative for full harness, making usage context crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the composite flow (recall-first, update, bond, optional scar), return types, and the scar_on_mismatch behavior. However, it does not explain failure modes (e.g., what if recall fails), auth requirements, or rate limits. The behavioral description is good but not exhaustive.
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 front-loaded with the core purpose and negative guideline, followed by two concrete examples. It is somewhat lengthy due to the examples, but each sentence adds value. The structure is clear and easy to parse, though it could be trimmed slightly without losing meaning.
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?
Given no output schema, the description covers return values (crs_delta, tensor_pattern, lineage). It explains the composite operation flow and optional scar behavior. However, it omits error conditions (e.g., concept not found), prerequisites, and side effects beyond the update. The examples compensate partially but not fully.
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%, so the schema already documents all 6 parameters. The description adds contextual flow meaning (recall-first, update, bond) but does not elaborate on individual parameter semantics beyond what the schema provides. The examples illustrate parameter usage but do not add new semantic detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'SAFE composite for memory updates' combining recall-first, update, tensor bond, and optional scar. It explicitly lists return values (crs_delta, tensor_pattern, lineage) and distinguishes from using forget+remember. The verb and resources are specific and unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear negative guideline ('NEVER use forget+remember to mutate') and includes two detailed few-shot examples showing concrete when-to-use scenarios. It implies this tool is for composite updates with tensor bonding, but it does not explicitly list alternatives or state prerequisites (e.g., concept must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a side effect: 'Advances frame_step for audit trail.' This adds transparency beyond the basic clearing action, though it doesn't detail permissions or reversibility.
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?
The description is very concise, consisting of a single sentence and a clause, with no fluff. It is front-loaded with the core purpose.
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?
Given zero parameters and no output schema, the description is largely complete for such a simple tool. It explains the action and a side effect, but could briefly mention whether the operation is synchronous or if it affects other state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds no parameter info, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Clear the current Geosphere lens' with an explanation of the effect ('return all queries to native coordinate / identity transform'). The verb+resource is specific and distinguishes from sibling tools like get/set_geosphere_frame.
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?
No explicit guidance on when to use vs alternatives. The purpose implies usage when resetting the lens, but no exclusions or comparisons to sibling tools like set_geosphere_frame are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description must carry behavioral weight. It discloses score range, input dependencies, and alternate emission points, but does not explicitly state whether the call is read-only, modifies state, or requires certain backend readiness, leaving some burden unmet.
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, front-loaded with the core action and output range; the second sentence adds useful alternative emission and ritual context without repetition. Jargon is dense but not bloated.
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?
For a computation with no parameters and no output schema, the description covers purpose, output range, inputs, and alternative sources of the value. Some terms ('mean hub CRS', 'BVH/NVMe') are unexplained, but the essential invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is trivially 100%. Description adds value by naming the implicit inputs (live continuation, readiness components) even though no formal parameters exist, aligning with the 0-param baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute') and names the resource ('cold-start fidelity score'), including the output range and input components. This clearly distinguishes it from sibling tools like process_metrics or verify_manifold_integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for direct computation of the cold-start fidelity score and notes the same value is emitted on session_start / get_continuation_bundle, giving agents alternative pathways. However, it does not explicitly state when to prefer this tool over those alternatives or exclude other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must supply all behavioral info. It states the tool is read-only ('without starting a session'), returns specific data, and mentions a wake-up optimization. It does not contradict any annotations (none exist) and gives a clear picture of what happens.
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 sentences, each serving a distinct purpose: what the tool returns, when to use it, and an optimization note. Could be slightly more concise but remains focused and front-loaded.
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?
No output schema is provided, and while the description mentions what the bundle contains (primary goal, active tiles/helpers, handoff lineage), it lacks details on the structure or format of the returned data. For a tool with no output schema, more explicit description of the return value shape would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so the description need not add parameter details. Baseline 4 applies since there is nothing to explain, and the description does not mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the 'live continuation bundle' with specific components (primary goal, active tiles/helpers, handoff lineage) and explicitly says it does so 'without starting a session', distinguishing it from session-start tools like mcp_engram_session_start.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage timing: 'at TUI 63-65% before context compression' and 'the VERY FIRST step in lean ritual for instant hot/legominism rehydration'. It implies alternative usage (don't use if you want to start a session) but does not explicitly list sibling tools except implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of disclosing behavior. It reveals upsert semantics, required fields (definition + etymology), internal operations (ProvLog, VSA OP_BIND, CRS ≥ 0.74), and the return value (action mint|update). Some ambiguity remains about the precise side effects of updates, but the description is notably transparent for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with domain-specific jargon and packs multiple ideas into a single unstructured paragraph. While every sentence earns its place, the lack of organization (no explicit sections) and heavy terminology make it less concise than ideal. A structured format would improve readability and clarity.
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?
For a tool without an output schema, the description covers the key contextual elements: return value, required inputs, internal processing, and an example. It does not address error cases or permissions, but given the complexity and the presence of a rich example, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema provides 100% parameter coverage, the description adds valuable context through the few-shot example and clarifies that etymology is expected even though it is not marked as required. This goes beyond the schema's descriptions, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a lexicon seed/upsert operation with explicit mention of minting new words and updating existing ones. It specifies the resource (lexicon:word:*) and the intended action, distinguishing it from sibling tools focused on recall, visualization, or process management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (lexicon seeding) and references a 'Ritual' process, but it does not explicitly state when to avoid it or name alternative tools for similar tasks. Since the context is evident from the name and description, it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses behavior (retrieval, chronological sorting) and output structure (concept name, CRS score, tags, snippet). Read-only operation is implied but not explicitly stated.
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?
Three well-structured labeled sections (BEHAVIOR, USAGE, OUTPUT) with no redundant words. Every sentence adds value, and key information is front-loaded.
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?
Given one parameter, no output schema, and no annotations, the description covers core purpose, usage scenario, and output fields. Lacks potential info like maximum N or performance notes, but sufficient for basic use.
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 has 100% coverage for the single parameter 'n' with description and default. Tool description merely restates 'N most recently accessed memories' without adding new semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the N most recently accessed memories from the manifold, sorted chronologically. It is distinct from siblings like mcp_engram_recall (likely by name) and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Call this for session rehydration when you lack exact concept names.' Provides context for when to use, though does not explicitly mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the export process: PII scrub, semantic coherence check with threshold, optional derivative minting. It also describes output fields (packs, denied, failed_coherence, minted_derivatives). This is quite transparent for a complex tool.
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?
The description is highly concise and structured with BEHAVIOR, USAGE, OUTPUT sections. Every sentence serves a purpose, and the critical information is front-loaded. No redundant text.
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?
Given complexity, no output schema, and no annotations, the description covers behavior, usage, and output well. It mentions sovereignty-gating but doesn't detail authentication. However, for a specialized tool, it is largely complete.
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 baseline is 3. The description does not add much detail beyond the schema for individual parameters (e.g., explaining coherence_min or prefixes), but it gives overall process context. No significant added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a sovereignty-gated three-channel export for training corpus/central contribution, and explicitly distinguishes it from raw mcp_engram_export by warning never to use that tool in agent profile. The verb 'export' and resource 'leg_block_pack_v1' are specific, and the use case is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The USAGE label explicitly says 'Training corpus / central contribution' and provides a strong exclusion: 'never use raw mcp_engram_export in agent profile'. While it doesn't cover all alternative scenarios, this is clear guidance for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by revealing that results include 'RoMem semantic-speed-gate α per edge' and are 'ranked by prefer_static (default true: static edges first),' which explains ordering and output content. It also warns about potentially large outputs on high-relation hubs. It stops short of stating read-only status or full result structure, but for a search tool this is adequate.
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?
The description is three sentences long, front-loaded with the core purpose, and every sentence earns its place. The all-caps scoping warning is a concise, actionable addition that improves usability without verbose explanation.
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?
Given the lack of an output schema, the description partially explains return content by mentioning α per edge and ranking behavior. The scoping warning addresses a real edge case. It could be more complete by explicitly stating traversal depth or full result fields, but the description covers the essential selection and invocation details for a relation search tool with well-documented parameters.
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 descriptive baseline is 3. The description mostly repeats what the schema already states: filtering by label/direction, k for scoping, and prefer_static ranking. It adds no significant parameter semantics beyond the schema, though the scoping warning reinforces k's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a knowledge graph traversal operation: 'Traverse the knowledge graph. Find concepts related to a seed, filtered by optional label and direction.' This specific verb+resource combination distinguishes it from sibling recall/query tools, which focus on content retrieval rather than relation-based graph traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('Find concepts related to a seed') and adds practical guidance with 'IMPORTANT FOR SCOPING: use label, direction, and k to keep results small on high-relation hubs.' It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description richly discloses behaviors: commits the session, extracts reasoning traces, refreshes caches, hot-promotes artifacts, mints manifests, and warns of data loss. It also notes that flat summaries are accepted but discouraged. Some jargon (e.g., '0x10 functor minting') is opaque but does not detract from overall transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information but could be more concise. It front-loads the mandatory call and reasoning trace support, but includes cryptic version-specific notes (e.g., '2026-06 Ritual Evolution') that may be unnecessary. Every sentence adds value, but some jargon reduces clarity.
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?
Given no output schema and no annotations, the description covers purpose, usage, behavioral traits, and parameter semantics thoroughly. It explains side effects and consequences of skipping. However, it assumes domain knowledge of terms like 'ZEDOS_EPISODIC' and does not describe the return value, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds value by explaining the purpose of 'minimal' (thin closure vs full compression), the 'prepare_compression' behavior, and detailed guidance for the 'summary' field content beyond the schema. This helps the agent choose appropriate parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Call at end of every conversation/task. Commits the session as ZEDOS_EPISODIC and extracts key reasoning traces...' It specifies the resource (session) and action (end/commit), and distinguishes from siblings by emphasizing its mandatory nature and reasoning trace extraction, contrasting with other engram tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'MANDATORY... Call at end of every conversation/task.' Provides content guidelines for the summary field and warns of consequences of skipping. Does not explicitly mention alternatives or when not to use, but the mandatory framing and discouragement of flat summaries indirectly guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavior: two modes, caps (12 entries/32 edges with truncation flag), 1-hop bond expansion limited to tensor:/design:, and the prerequisite for semantic mode. It does not mention authentication, rate limits, or side effects, but as a recall tool it is likely read-only.
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 compact paragraph that front-loads the core purpose and then systematically details modes, caps, and deprecated parameters. It is not overly verbose, but could benefit from bullet points or clearer separation of concepts for faster scanning.
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 tool's complexity (two modes, caps, bond expansion) and absence of an output schema, the description covers core behavior but omits return format, error handling, and precise behavior when truncated. This leaves gaps for an agent to fully understand the call's outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have schema descriptions (100% coverage), but the description adds significant value: it explains how 'query' behaves in pin vs semantic mode, that 'seed_concept' forces inclusion, and that 'scope' and 'include_presentation' are deprecated and ignored. This goes beyond the schema to clarify semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Solid-State Tensor — addressable working memory for agents' and distinguishes between pin mode (direct fetch by name) and semantic mode (BVH over tensor:/design:). It uniquely differentiates from sibling tools like mcp_engram_recall by specifying tensor-specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly defines when to use pin mode (query with tensor:/design: name) vs semantic mode (natural language, requires nvme_recall_ready via get_backend_readiness). However, it does not provide explicit exclusion criteria like 'do not use for non-tensor recall' or compare directly to other recall tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, description implies heavy resource usage ('power tier') and selective use, but lacks explicit details on side effects, lifecycle, or output behavior.
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?
Three concise sentences with no redundancy; first sentence conveys purpose, second gives alternative, third gives usage 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?
Adequately covers purpose, usage, and alternatives given the tool's simplicity; could clarify 'power tier' and 'deep mode' but not essential.
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?
Parameter is already fully described in schema (100% coverage); description adds no extra semantics about the path parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'binds' and resource 'full-repo OS file-watcher', clearly distinguishing from sibling tools like mcp_engram_context_for_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to avoid ('lean-avoid at wake') and when to use ('deep mode when passive daemon ingest is required'), and names alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes incremental behavior, respecting engramignore, updating item1.5 state, and fallback logic. It does not explicitly mention read-only or destructive nature, but the state update is implied.
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 slightly jargon-heavy but packs essential information concisely. It front-loads the key purpose and behavioral details without unnecessary words.
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?
Given no output schema and three optional parameters, the description covers default behavior, fallback, file selection mechanism, and respects configuration. It is sufficiently complete for an incremental ingest tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds context: max_files default of 10, and paths bypass auto delta, providing meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs incremental force ingest of only changed files, using specific mechanisms (mtime, timestamps, watcher events). It distinguishes from the full force ingest sibling by specifying it's incremental and defaults to fewer files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is called from a 'lean wake-up contract' and defaults to a small number of files, contrasting with the previous full 81-item force. It notes fallback behavior to full force if no last_end or explicit paths, implying when to use this tool over the sibling force_spatial_ingest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses internal behavior: synthesizes a deterministic normalized 8192D lens vector, installs it into SymplecticState register, and that it is reproducible for same inputs. No annotations provided, but description is detailed. Lacks mention of potential side effects or idempotency.
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?
Concise but comprehensive; front-loads purpose, then explains process and effect. Could be slightly more compact, but every sentence adds value.
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?
Covers purpose, inputs, internal process, effect on future queries, and return type (confirmation with frame_step). No output schema, so return info is adequate. Missing details on frame_step format, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: provides examples for origin ('giza_sacred_cubit', etc.) and time_offset ('sowing_moon', '1776-07-04'). Schema coverage is 100%, so description complements schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Set' and resource 'Geosphere frame (5th coordinate)'. Distinguishes from sibling tools like mcp_engram_get_geosphere_frame and mcp_engram_clear_geosphere_frame by specifying it is for setting a frame for subsequent queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states effect on 'all subsequent queries' and mentions that 'recall/query_with_momentum' will use this lens. Could be more explicit about when not to use or prerequisites, but provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes deserialization and injection behavior, and specifies output (success message with count). However, it does not disclose whether the operation is destructive or idempotent, or any side effects beyond writing to disk.
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?
Three sentences efficiently cover behavior, usage, and output. No redundancy; front-loaded with key action verb. Every sentence adds value.
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?
Given the simple input schema and no output schema, the description covers purpose, usage, and output format. It could mention error handling or idempotency, but is largely sufficient for an import tool.
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% with clear parameter description. The tool description adds context about backup restoration but does not add substantial new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deserializes a JSON array and injects concepts/texts as HolographicBlocks into the active manifold, with a specific verb and resource. It distinguishes from sibling mcp_engram_export (backup) and mcp_engram_remember (single memory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states two use cases: restoring backups from mcp_engram_export and ingesting bulk data. Implicitly excludes single-memory use, suggesting mcp_engram_remember as alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it fetches the complete original document and bypasses search, and explains the truncation behavior of recall. However, no mention of error handling or output format, and no annotations to supplement.
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 redundant information, front-loaded with purpose and trigger. Every sentence adds value.
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?
Given low complexity, one parameter, and no output schema, the description adequately covers when and why to use the tool. However, it fails to describe the return value or potential errors, which would be helpful.
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 already provides a good description for the single parameter 'concept'. The tool description adds minimal extra meaning beyond stating it's for a 'specific memory block', meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the full text of a memory block, distinguishes it from 'recall' which only provides a 512-character snippet, and specifies the trigger condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (after recall, when full text is needed) and indicates when not (when snippet is sufficient), and references the alternative tool (recall).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that the tool produces well-named trace:* blocks, links to other mechanisms (ki_hijacker, session_end), and mentions the A/D/R triad. Without annotations, it provides good behavioral context, though it could elaborate on side effects like persistence.
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?
Description is concise yet complete, with the key purpose front-loaded. Every sentence adds value, no redundancy.
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?
Provides rich context about the engram system and trace usage. However, it lacks information about the return value or output, which would improve completeness.
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 covers all 12 parameters with descriptions. The tool description does not significantly add parameter-level meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a structured reasoning trace segment as first-class serial memory. It distinguishes from free-form notes and sibling tools like mcp_engram_quick_trace by emphasizing its role for automatic capture of decision points and justifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: at major forks, pre-edit justifications, and post-delta decisions. Also notes it is preferred over free-form notes for anything affecting future continuation, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auto goal linking and creation of 'compresses_path' relations, adding value. However, it does not mention permissions, side effects, or return format, leaving some gaps.
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 plus a key phrase, all front-loaded and each sentence adds value. No wasted words.
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?
Given no output schema and no annotations, the description covers main behaviors, usage context, and parameter functions. Lacks detailed output or error info but is adequate for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema: 'auto goal linking' for goal_context, 'creates compresses_path relations' for spatial_references, and clarification of payload format. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'create' and resource 'rich HTML/compound Visualization Thought Tile'. Distinguishes itself as a companion to thought_tile_create, making its role distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using it as a companion to the main thought_tile_create tool. Provides context on input types (raw HTML or structured payload) but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses that the tool returns 'Merkle chain state, allowed_transforms contract, CRS, and detected issues.' It also states it is local-only with no external servers required. However, it does not explicitly state whether the operation is read-only or if it has side effects, though the name 'verify' suggests non-destructive behavior.
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?
The description is front-loaded with a clear label and consists of two informative sentences plus a note. Every sentence adds value: purpose, usage, return content, and locality. No redundancy.
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?
Given the tool's complexity (2 parameters, no output schema, no annotations), the description covers purpose, usage, return values, and constraints. It lacks details on output structure or examples, but for a verification tool, the provided information is sufficient for an agent to decide when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing context for the 'concept' parameter, emphasizing high-value blocks like PRAXIS or GENESIS. It does not elaborate on 'check_merkle_chain' but the schema already includes a default and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to audit tamper-evidence and contractual integrity of high-value memory blocks (especially PRAXIS or GENESIS). It uses specific verbs ('Audit', 'Returns') and distinguishes from sibling verification tools like 'mcp_engram_verify_behavior' and 'mcp_engram_verify_manifold_integrity' by focusing on block lawfulness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this on cold boot after long sleep or before acting on critical operational protocols.' It also notes that verification is local-only, which guides the agent on when to invoke. However, it does not specify when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the edge cost formula (1+volatility), how high-α paths burn depth budget faster, and the master switch behavior. This provides substantial transparency into the algorithm's behavior beyond what a schema could convey.
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?
The description is extremely concise, consisting of two sentences: the first states the core purpose, the second explains the key behavioral modifier. Every sentence adds value without repetition or fluff.
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?
Given no output schema, the description adequately indicates the output is a Mermaid diagram and clarifies the depth parameter's dual meaning. It could mention edge cases or prerequisites (e.g., nonexistent concept), but the essential operational context is present for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already provides descriptions for all three parameters (100% coverage), the description adds nuance by explaining the continuous α-budget cost model for depth and the master switch override for alpha_weighted. This enriches the static parameter definitions with behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a BFS subgraph from a seed concept as a Mermaid diagram, using a specific verb ('Render') and resource ('BFS subgraph', 'seed concept', 'Mermaid diagram'). It distinguishes itself from sibling tools by focusing on visualization and the specialized α-weighted BFS behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the default α-weighted mode and how to switch to classic unit-hop BFS via the alpha_weighted parameter or environment variable, which is helpful operational guidance. However, it does not explicitly name alternative tools or exclusion cases, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that calling this tool unblocks context_for_edit (conditional on ENGRAM_WAKE_QUEUE_GATE=hard) and clears soft warnings. It also explains auto-ack behavior at session start. This is good, though further detail on 'soft warnings' would strengthen transparency.
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?
Three sentences, each adding essential information. Front-loaded with the core purpose, followed by usage and special cases. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (acknowledgment action with 3 optional parameters and no output schema), the description covers everything: when to call, what it does, conditions, side effects, and edge cases (empty queue). Complete for its role.
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 baseline is 3. The description does not add extra meaning to parameters beyond what is in the schema. It provides usage context but no new parameter-level information, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Acknowledge' and the resource 'wake queue execution', and distinguishes itself from sibling tools like context_for_edit by specifying that it unblocks that tool under certain conditions. It also mentions clearing soft warnings, making the purpose explicit and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call once after running harness_injection.suggested_actions (or honestly note skip)'. It also specifies an automatic behavior for empty queues, providing clear context for when the tool is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return structure (JSON with fields like spatial_items, traces_at_locus) and the wake queue requirement. However, it does not explicitly state whether the tool is read-only or if it has side effects, though the context suggests it is a read-only context retrieval. Overall, it is transparent enough for safe invocation.
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 concise (four sentences plus examples) and front-loaded with the key idea 'pre-edit situated memory.' It packs essential information but could be slightly more structured (e.g., separating the wake queue note). Still, every sentence serves a purpose.
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?
Given no output schema, the description properly explains the return JSON fields. It also mentions the wake queue gate requirement. However, it does not elaborate on the meaning of each returned field (e.g., scars_at_locus) or their typical use, which could be helpful for agents unfamiliar with the 'Code atlas' system. Overall, it is sufficiently complete for a focused context tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that 'line_start' and 'line_end' are optional for a spatial AABB filter, and 'auto_ingest' defaults to true to force ingestion when no items exist. The examples further illustrate parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'pre-edit situated memory' and lists the specific JSON fields it returns (spatial_items, traces, scars, post_edit_palette). It distinguishes itself from the sibling tool 'mcp_engram_safe_edit_and_verify' by advising to use that tool for substantive edits, indicating a lighter context retrieval role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Requires wake queue ack when ENGRAM_WAKE_QUEUE_GATE=hard' and 'Prefer mcp_engram_safe_edit_and_verify for substantive edits.' Includes two concrete examples showing standard pre-edit and line-bounded locus usage, clarifying when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the behavior as serialization (likely non-destructive) and mentions profile restrictions and degraded geometry. It does not explicitly confirm read-only or disclose any side effects, but the word 'serializes' implies no mutation. Some missing details on concurrency or resource impact, but adequate for the given context.
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?
The description is concise, uses clear labels (BEHAVIOR, USAGE, OUTPUT), and front-loads the main action. Every sentence adds value, and the structure aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly states the output format (JSON array with concept, text, crs and degraded geometry). It also covers profile restrictions and filtering. For a simple export tool with one optional parameter, this is complete.
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?
The only parameter, min_crs, is fully described in the input schema with default and meaning. The description merely echoes 'filtered by minimum CRS' without adding new semantics. Since schema coverage is 100%, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool serializes the active memory manifold into a portable JSON array, with optional filtering by minimum CRS. It distinguishes itself from the sibling mcp_engram_scrub_export by noting the export is block-isomorphic and training-safe for that sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says the tool is blocked in ENGRAM_PROFILE=agent and recommends using mcp_engram_scrub_export instead. It also limits usage to backup/migrate in deep|dev|ui profiles, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses permanent destruction and details what is lost (CRS, Merkle chain, ADR state). Mentions that pinned blocks are deletable. Lacks description of return value or confirmation, but the warning is strong.
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?
Very concise: 3 sentences. First sentence states purpose, second warns, third provides usage guidelines and exception for pinned blocks. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema and no annotations, the description covers purpose, usage boundary, behavioral consequences, and distinguishes from an alternative. The agent can confidently decide when to invoke and what to expect.
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?
Only one parameter 'concept' with full schema coverage (100%). The description does not add additional meaning beyond the schema's 'The concept name to delete'. As per guidelines, baseline 3 is appropriate since schema already documents the param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Permanently delete a memory block from the manifold', clearly identifying the action and resource. Distinguishes from sibling mcp_engram_update by noting that update preserves history, whereas this tool destroys it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Only when a concept is completely obsolete or was stored in error.' Tells when not to use: 'If you need to change what a memory says, use mcp_engram_update instead.' Also clarifies that pinned blocks can still be deleted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns the current frame state including a lens active flag, implying no side effects. It does not detail authorization needs or rate limits, but for a read-only getter, this is adequate.
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 concise sentences with no wasted words. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description fully explains what the tool returns and its purpose. It is complete for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. Baseline is 4. The description adds no param details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the currently active Geosphere frame state with specific fields (origin, frame_step counter, active_location summary) and mentions use cases like audit and verification. It distinguishes from siblings like mcp_engram_set_geosphere_frame and mcp_engram_clear_geosphere_frame by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states usage for audit, reproducibility checks, and lawfulness verification. It does not explicitly list when not to use it or alternatives, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: setting CRS to 1.0, locking to prevent manual forget_old eviction, and that pinned blocks still support relate/update. However, it does not mention reversibility (e.g., how to unpin) or behavior on non-existent concepts, leaving minor gaps.
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?
The description is concise and well-structured. It front-loads the primary action, then provides usage guidance in a clear section. Every sentence adds value without fluff, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the operation, usage context, exclusions, and relationships to other tools. It is complete for the tool's complexity.
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 fully documents the 'concept' parameter. The description adds usage context but does not enhance parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set a concept's CRS to 1.0 and lock it.' It clearly distinguishes the tool from siblings by explaining the locking behavior and referencing forget_old. This is a unique and well-defined purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'WHEN TO USE' section explicitly lists use cases (foundational knowledge, architecture decisions) and provides exclusions ('Do NOT pin everything'). It also references an alternative tool (mcp_engram_forget_old) for cleanup, giving clear guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses that the tool creates a structured trace:* block with a prev_in_trace chain, implying it is a write operation that modifies state. It also suggests follow-up actions. However, it does not explicitly state side effects, permissions, or whether it is destructive, which could be clarified. Still, the core behavior is transparent enough for an agent.
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 front-loaded with the core purpose and usage, followed by few-shot examples. While somewhat lengthy due to examples, every sentence serves a purpose (guidance, illustration). It could be slightly more compact, but the structure effectively communicates when and how to use the tool.
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?
Given the complexity (12 parameters, no output schema), the description adequately covers purpose, usage, parameter interaction, and follow-up workflow. It explains the output format (structured trace:* block with prev_in_trace chain) without an explicit output schema. The inclusion of few-shot examples further completes the context for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 12 parameters with descriptions (100% coverage). The description adds operational context beyond the schema, such as the chaining usage for 'prev' ('chain prev from trace_chain.head') and practical meaning of 'spatial_context' and 'goal_context' via examples. This extra context helps an agent select and fill parameters correctly, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Low-friction trace capture' and specifies usage 'at every fork' with chaining from 'trace_chain.head'. It clearly distinguishes from siblings by focusing on quick capture and chaining, and the verb 'trace' combined with 'structured trace:* block' precisely conveys the action and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use instructions ('Use at every fork'), how to chain ('chain prev from trace_chain.head'), and post-edit steps ('run reflection loop or mcp_engram_safe_edit_and_verify'). Few-shot examples illustrate concrete scenarios (e.g., edit fork, post-edit delta), providing clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the storage mechanism ('ZEDOS_RELATION block'), the directional linking format ('concept_a →[label]→ concept_b'), and the semantics of the volatility parameter (α as a 'RoMem semantic speed gate' with static≈0.1 and dynamic≈0.85). It also explicitly notes the precondition that both concepts must exist. It does not cover return values or error behavior, but for a creation tool this is substantial transparency.
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?
The description is concise, with two sentences plus a clearly labeled 'WHEN TO USE' callout. Every sentence adds unique information: the core action, the storage format, the optional parameter semantics, and the usage context. There is no wasted wording, and the structure front-loads the primary purpose.
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?
Given the tool's complexity (a simple edge creation with 4 parameters), the description covers the core elements: purpose, parameter semantics, usage context, and a critical precondition. It does not specify return values or behavior on failure, but since there is no output schema, a brief statement about the response would improve completeness. Still, it is adequate for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the baseline is 3. The description adds significant value by explaining the volatility parameter with concrete examples ('static≈0.1, dynamic≈0.85') and the behavior when omitted ('auto-infer from label'). It also clarifies the orientation of concept_a and concept_b through the arrow notation, providing meaning beyond the schema's simple 'Source' and 'Target' descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a directional knowledge graph edge between two concepts using VSA OP_BIND.' This specifies the verb (create), the resource (knowledge graph edge), and the directional nature. It distinguishes itself from siblings like mcp_engram_relate_batch by focusing on a single edge, and from mcp_engram_remember which likely stores concepts rather than relations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'WHEN TO USE' section: 'When you discover a meaningful relationship — depends_on, implements, contradicts, supersedes, etc.' It also provides a clear precondition: 'Both concepts must already exist in memory before relating them.' However, it does not mention alternatives such as mcp_engram_relate_batch for batch operations, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses persistence, file format (.leg3), and CRS tiers. It doesn't mention error conditions or side effects but is sufficiently transparent for a 'remember' operation.
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 front-loaded with purpose, followed by usage guidelines, CRS tiers, and examples. It is slightly long but every sentence adds value, so it remains efficient.
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?
Given no output schema and many sibling tools, the description provides sufficient context with examples, usage rules, and thresholds. It lacks return value details but is complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, baseline is 3. The description adds meaningful guidance: 'Be specific and self-contained' for text and snake_case naming with namespacing for concept, which enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Encode NEW facts only' and contrasts it with the sibling tool mcp_engram_update based on recall match threshold. The examples further clarify the intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: only for new facts, and provides an alternative (mcp_engram_update) when recall match > 0.85. It also includes CRS tier thresholds for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the burden. It discloses effects: creates a geometric repeller, demotes via op_suspend, mints receipts, and notes that magnitude is ignored for research/uncertainty paths. It does not discuss reversibility or permissions, but for an action tool with no annotations, this is strong.
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 long but structured with a TRIGGER prefix and conditional branches. Every sentence adds necessary information for a complex multi-mode tool. It is dense and requires careful reading, but there is no fluff or redundancy.
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?
For a tool with multiple modes and no output schema, the description covers triggers, parameter routing, and default behavior. It lacks error/return information, but that is less critical for a side-effect tool. References domain concepts (CRS penalty, M-NOL) that are unexplained but likely part of the system's vocabulary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds crucial routing semantics: which parameter combinations trigger which paths (ruled_out+why, uncertainty_status) and when magnitude is ignored. This is meaningful behavioral context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: creates a geometric repeller to prevent repeating bad solutions. It clearly distinguishes from sibling tools like remember and forget by describing the unique mechanism and routing paths (research scar, uncertainty receipt, default demotion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Begins with an explicit TRIGGER condition: call after a failed code fix or dead end. Provides detailed guidance for research dead-ends (pass ruled_out+why via mint_research_scar) and insufficient memory anchors (use uncertainty_status), and explicitly prefers structured scar over free-form remember. It covers when to use which parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but description fully details the pipeline: DuckDuckGo search (no API key), synthesis via Gemma 4B, storage as ZEDOS_DECLARATIVE block (CRS=0.9). Config are given. No surprises.
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?
Concise yet comprehensive: Phase identifier, pipeline summary, usage instruction, example, and config. Front-loaded with purpose. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description covers the full flow, return value, configuration, and use case. No missing critical information.
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 covers both parameters fully. Description adds no new semantics beyond what the schema already provides (e.g., default and max for max_results are already in schema). Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches the web, synthesizes results, and stores them. It is distinct from sibling tools which are about memory/engram operations, not web search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use case: 'ground a hypothesis in real-world web data before storing it.' Example further clarifies. Does not specify when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it calculates and returns a formatted text block with specific metrics. It implies a non-mutating, read-only operation by describing a report generation. It could explicitly state 'no side effects' but the description is otherwise transparent about what happens.
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?
The description is structured with clear labels (BEHAVIOR, USAGE, OUTPUT) and only three sentences. Every sentence earns its place, providing key information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully explains what the tool returns (total memories, pinned count, CRS distributions, active namespace, disk usage) and when to use it. It also connects to the related forget_old tool, making it complete in the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline 4 applies. The description adds no parameter details because none exist, but it compensates by describing the output contents in detail, which is more relevant for a no-argument stats tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculates and returns a comprehensive health report of the geometric manifold.' It specifies the main outputs (scale, disk usage, active namespace, thermodynamic health) and distinguishes it from other tools by focusing on overall stats rather than specific operations like recall or cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Useful before deciding on explicit bulk cleanup (forget_old).' This gives clear context for when to call the tool. It does not mention exclusions or alternatives, but the specific scenario is sufficient for a stats/reading tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully details the behavior: recording interaction, applying an EMA algorithm, and outputting a confirmation. It could mention side effects (e.g., whether it updates a cumulative model) but the core mechanism is transparent.
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?
The description is well-structured with clear 'BEHAVIOR', 'USAGE', and 'OUTPUT' sections. Every sentence adds essential information without redundancy, making it concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one simple parameter and no output schema, the description covers all necessary aspects: what it does, when to use, how it behaves, and what to expect as output. It is complete for the agent to select and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 'interaction' as 'The interaction text to track', and the description adds semantic context: 'significant preference, intent, or constraint', and 'user interaction'. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Tracks and records a user interaction' into a specific model. It distinguishes from siblings by emphasizing it targets the 'User Model manifold' and uses '90/10 EMA superposition', which is unique among related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('whenever the user expresses a significant preference, intent, or constraint'), providing clear context. It does not mention alternatives or when not to use, but the guidance is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses key behaviors: append-only history preservation, 'Superposes q + p-momentum + ProvLog splice', and bi-temporal succession via supersedes_of. It also warns that forget+remember 'destroys history,' which is critical safety information.
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 front-loaded with the critical warning and purpose in the first sentences. The few-shot examples are useful but add length. Some jargon ('q + p-momentum') is cryptic but not redundant. Overall, every sentence earns its place.
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?
Given no annotations and no output schema, the description covers purpose, usage, alternatives, behavioral details, and parameter examples. It lacks explicit return-value information, but for this complex update tool with rich schema and examples, it is sufficiently complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds significant value by showing concrete example values for concept and new_text, explicitly explaining provlog_mode's default inference ('append for __arc/trace:*; replace for AST __fn__/*'), and adding ritual context for supersedes_of.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing memory with a specific verb+resource and scope ('Use whenever you change an existing memory'). It distinguishes from siblings by explicitly warning against the forget+remember pattern and referencing mcp_engram_update_with_tensor_bond as the alternative for agent edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('whenever you change an existing memory'), when-not ('NEVER forget+remember'), and direct alternative ('Prefer mcp_engram_update_with_tensor_bond for agent edits'). Few-shot examples give concrete usage contexts, making selection unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that the tool unblocks repeat context_for_edit on the same path when gate is hard, and explains the two modes (skip vs acknowledge). The few-shot examples illustrate behavior. However, it does not detail side effects, authorization needs, or what the acknowledgment entails beyond unblocking.
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 well-structured with purpose first, then guidance, then examples. It is front-loaded but includes several examples which, while helpful, add length. Could be slightly more concise, but the structure supports comprehension.
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?
Given no output schema and 5 parameters (none required), the description covers the tool's purpose, triggers, and parameter usage via examples. It lacks return value information but is otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. The description adds significant value by explaining the semantic roles (skip vs ack, lineage_check usage) and providing concrete examples that show parameter combinations, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool acknowledges or skips pending edit-arc debt, unblocking repeat context_for_edit. It distinguishes from sibling mcp_engram_update by directing to prefer it for __arc updates, providing clear purpose and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (post-edit for acknowledging arc debt) and when not to (prefer mcp_engram_update on __arc after edits, use skip only for read-only passes). It provides alternative and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly details what gets evicted (non-pinned, below threshold), what is exempt (pinned blocks at CRS=1.0), the Langevin ranking formula, batching via max_evict, and a safety recommendation to preview with stats first. This goes well beyond a minimal description.
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 moderately long but each sentence contributes valuable information, including usage guidance, exceptions, algorithm details, and a caution to preview first. It is well-structured with a clear 'WHEN TO USE' section, though it could be slightly tightened without losing critical content.
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?
The description covers the tool's purpose, usage, parameters, and core behavior, which is substantial especially since there is no output schema. However, it does not explicitly mention what the tool returns (e.g., count of evicted blocks) or whether eviction is reversible, which would be valuable for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes each parameter (100% coverage), the description adds substantial semantic value: it explains the default threshold (0.2) and suggests starting at 0.3, clarifies that older_than_days targets stale memories while preserving recent ones, and details the Langevin ranking formula for langevin_rank. This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool evicts non-pinned memories below a CRS threshold, with a specific verb ('evict'), resource ('non-pinned memories'), and scope ('below CRS threshold'). It explicitly distinguishes itself from automatic garbage collection and from mcp_engram_stats (for preview), providing a unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'WHEN TO USE' section with concrete scenarios (end of project phase, after distill runs, manifold growing too large) and offers practical advice (start with threshold 0.3, preview with mcp_engram_stats). However, it does not explicitly state when NOT to use this tool or compare directly to the sibling mcp_engram_forget.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is an experimental vertical slice and does NOT execute real protocol side effects yet, which is crucial for a tool that might otherwise look like a real invocation. It also warns about dry_run preference, but does not detail other behaviors such as return format or error handling.
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 with no wasted words. The first sentence immediately communicates the experimental state and the pipeline, and the second sentence provides key cautions and alternatives. Information is front-loaded and scannable.
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?
Given the tool's experimental nature, the description covers purpose, safety (no real side effects), and alternatives (verify tools). However, with no output schema, it does not describe what the tool returns, which is a notable gap for a pipeline-style tool. Still, for a stub/experimental tool, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented. The description adds value by recommending dry_run=true, which gives practical guidance beyond the schema's default value description. This extra hint elevates it above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a 7-point gate (tag, CRS, contract, lawfulness summary) and then stub_dispatch, giving a specific verb and resource. It distinguishes itself from siblings by explicitly noting it is not a product automation surface and pointing to verify tools for audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to prefer dry_run=true, which is a clear usage directive. It also states 'Not a product automation surface; use verify tools for audits,' providing both an exclusion and an alternative tool category, which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses behavior: lists namespaces on disk and marks active one. It does not mention authorization, side effects, or performance, but for a simple read-only listing, this is adequate. Could be slightly more detailed.
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?
The description is three short sentences, each with a clear label (BEHAVIOR, USAGE, OUTPUT). It is front-loaded with the essential purpose, no unnecessary words.
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?
Given zero parameters and no output schema, the description explains the output format adequately. It does not mention error handling or edge cases, but for this simple tool it is sufficient. The description helps differentiate from sibling tools well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100% by default. The baseline for 0 parameters is 4. The description does not need to add param information; it correctly focuses on output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers and lists all available memory namespaces on disk and indicates the active one. It uses specific verbs and resource, and differentiates from the sibling tool mcp_engram_set_namespace which switches namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this when you need to know what project contexts exist before attempting to switch namespaces,' providing clear context for use. It implies when not to use (if you want to switch, use the sibling).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses that geometry and recall remain intact, that an archival trace is minted, and which edges are wired/removed, providing thorough behavioral understanding.
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?
Three concise sentences front-loaded with the main action, followed by side effects and usage guidance, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, constraints, and use cases comprehensively despite no output schema; an agent has enough information to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions; the description adds behavioral context (e.g., concept cannot be primary_goal implicitly reinforced) and explains the purpose of the note and reviewer parameters in the demotion process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool demotes a concept from the active serving stack without deleting geometry, specifying the exact actions (archival trace, edge wiring) and differentiates from siblings like goal_update_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions use cases: hygiene demotion, LEG Mark complete, or when goal_update_status is insufficient, giving clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: background thread spawning, need to poll readiness, time and memory spikes. This enables safe agent invocation.
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?
Three sentences front-load key actions and warnings. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers trigger, process, polling step, outcome, and performance impact. Complete for a no-parameter tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. Description adds no parameter info as none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (rebuild), resource (BVH), and context (large manifolds with ENGRAM_DEFER_BVH=1). It distinguishes from siblings by specifying on-demand background build, contrasting with other recall tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit condition for use ('when you need quality recall'), a polling workflow, and performance expectations. Could mention when not to use (e.g., small datasets) but offers sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: explains output (concept name, score, CRS, text snippet), score thresholds (>0.80 strong, 0.65-0.80 relevant, <0.65 weak), CRS meaning (>=0.74 grounded fact), scope defaults to ENGRAM_MEMORY_MODE, time_decay applies backward unitary operator, and zedos_filter values with detailed explanations. No contradictions.
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 long but well-structured with sections (WHEN TO CALL, OUTPUT, ZEDOS FILTER GUIDE, TIME DECAY). Every sentence adds necessary context given the tool's complexity. Could be slightly more concise, but the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/recall tool with no output schema, the description covers output format, score interpretation, CRS meaning, parameter usage, follow-up tool recommendation (mcp_engram_read_concept), and ties into broader system concepts (ENGRAM_MEMORY_MODE, ZEDOS_TRAINING, Phase 2 WS2-B). All essential aspects are addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds substantial value: explains scope default behavior (follows ENGRAM_MEMORY_MODE), time_decay trigger condition and semantics, zedos_filter options with deep explanations (e.g., 'training selects ZEDOS_TRAINING blocks with richer 8-property CLS tuples and NREM bias'). This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search persistent memory by semantic similarity. Returns ranked HolographicBlock memories.' The verb 'search' and resource 'persistent memory' are specific. The output description further clarifies the tool's function, distinguishing it as the primary recall tool among many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'WHEN TO CALL' section advises using before answering technical questions, editing files, or making architectural decisions. Also specifies that time_decay is only for past-work queries. Lacks explicit when-not-to-use or alternatives, but the positive guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral consequences: on success it promotes the block from ZEDOS_HYPOTHESIS to ZEDOS_PRAXIS with crystallized, pinned, CRS=1.0; on failure it penalizes CRS and can lead to auto-scarring. This is detailed and honest about the tool's effects.
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?
The description is well-structured and concise, using bold labels for sections and front-loading the key trigger and effects. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (behavioral side effects, hypothesis system integration, and no output schema), the description covers trigger, success/failure outcomes, examples, and even directs to a sibling tool for further action. It provides a complete mental model for correct usage.
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% with clear descriptions for both parameters. The description repeats the schema information ('concept' as name, 'success' as boolean) but adds minimal extra context, such as implicit use through examples. Baseline 3 is appropriate since the description does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the trigger condition ('after any hypothesis is confirmed to work OR fails in practice') and explicitly defines the tool's purpose: 'Reports empirical success/failure data against a specific ZEDOS_HYPOTHESIS block.' It distinguishes itself from the sibling `mcp_engram_scar` by suggesting its use after failure, providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to call the tool ('after any hypothesis is confirmed to work OR fails in practice') and what to do in the failure case ('then consider mcp_engram_scar'). It also includes concrete examples ('After a code fix works — verify_behavior(concept, success=true)'), making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and exceeds it by disclosing the query mechanism (cosine K-NN over hot blocks/BVH), the return format (ranked concepts + scores + CRS), and the optional timing trailer with field names. It also states the exclusion of keyword/file-path fallback, giving clear expectations.
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?
Description is dense but every sentence adds unique value; however, the 'RSI Cycle 55:' prefix is an internal version detail that adds noise for a generic agent. Overall it is front-loaded and structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a query tool with no output schema, the description states what is returned (ranked concepts, scores, CRS) and the timing trailer details. Combined with rich parameter and usage guidance, there are no critical gaps for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters with descriptions; the description adds meaning for include_timing (structured trailer fields and env var) and emphasizes 'Intent only' as the operative semantic. It does not deeply elaborate on k, but the schema fully handles that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Pure geometric K-NN discovery' and details the pipeline from natural language intent to phase vector to cosine K-NN, clearly identifying the operation and scope. It explicitly contrasts itself with the hybrid fallback and names sibling tools it replaces (list_concepts + search_by_relation), making it distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use contexts: 'fast anchor discovery in optimized wake-up' and 'Fast path for hot ritual rehydrate', plus named alternatives it replaces. The phrase 'Intent only' and 'no keyword/file-path hybrid fallback' implies when not to use it, completing the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return order (pinned first, then top N by CRS), and appends a system_state_vector health line updated every 60s. This is rich behavioral context beyond basic read operation.
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?
The description is appropriately sized and front-loaded with the main purpose. Every sentence adds value: usage, ordering, health line details. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sibling tools, the description is thorough. It explains return format, ordering, and health line frequency. Without an output schema, it still sufficiently describes what the agent will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (top_n) with 100% schema coverage. The schema already documents default and description. The description adds meaning by explaining the ordering logic (pinned first, then top N) and the role of top_n in selecting non-pinned memories, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a project-state digest with pinned memories first, then top N by CRS score. It uses specific verb+resource and distinguishes from siblings like mcp_engram_recall by saying it's a single call replacing multiple queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'WHEN TO USE: at the start of a new session when you need to rehydrate context fast. Single call replaces multiple recall queries.' Also mentions it's ideal as a /wake_up replacement, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![engram MCP server](https://glama.ai/mcp/servers/staticroostermedia-arch/engram/badges/card.svg)](https://glama.ai/mcp/servers/staticroostermedia-arch/engram)

Score Badge

Copy to your README.md:

[![engram MCP server](https://glama.ai/mcp/servers/staticroostermedia-arch/engram/badges/score.svg)](https://glama.ai/mcp/servers/staticroostermedia-arch/engram)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/staticroostermedia-arch/engram'

If you have feedback or need assistance with the MCP directory API, please join our Discord server