lore_context

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 writing bypasses synthesis and is directly authored. However, it does not specify whether writes are overwriting or appending, nor does it describe any side effects or permissions. Still, key behavioral traits are covered.

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

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

The description is two sentences, very concise. Every sentence adds value: the first explains the dual function, the second gives usage context and alternatives. No filler or redundancy.

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

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 hint at return values. It implies reading returns the body, but doesn't explain what write returns. Also, while parameter semantics are good, the overall completeness is slightly hampered by missing return value description. Moderate complexity.

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

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

Schema description coverage is 100%, but the description adds valuable context: explaining that body presence determines read/write mode, that title defaults to area name, project defaults from .lorerc, and providing path examples. 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.

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

The description clearly states the tool reads or writes an area's context document, distinguishing between fetching (omit body) and writing (pass body). It specifies the resource type (context-kind node) and differentiates from synthesis and capture flow, making the purpose very specific and unambiguous.

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

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

The description explicitly advises using this tool for importing/editing hand-written context.md files and directs the capture flow for deriving context from sessions. This provides both when-to-use and when-not-to-use guidance, clearly distinguishing it from sibling tool lore_capture.

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