Extract a specific section from memory.md by heading name, with optional line limit for truncated output.
Returns the contents of a single `## Heading` section from memory.md.
Args:
section_name: Case-insensitive section heading (without leading `#`).
max_lines: Max lines of body to return (truncated with a tip).
| Name | Required | Description | Default |
|---|---|---|---|
| max_lines | No | ||
| section_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.12.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses truncation behavior and the case-insensitive heading matching, but it does not state what happens when the section is missing, whether the tool is strictly read-only, or any permission/side-effect details.
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?
Front-loaded with the return behavior, followed by compact parameter notes. Every line earns its place with no restating of the tool name or filler.
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?
For a low-complexity read tool with an output schema, this covers the essential call semantics. The main remaining gap is what happens when the requested section does not exist, which matters for correct agent behavior.
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 0%, so the description must compensate, and it does: section_name is documented as a case-insensitive heading without a leading `#`, and max_lines is explained as the body line limit with truncation behavior. It could have mentioned the default value of 200, but otherwise it adds real meaning beyond the bare 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?
States a specific verb and resource: returns the contents of a single `## Heading` section from memory.md. That scope (single section) distinguishes it from siblings like read_memory and read_memory_index, though it doesn't name those alternatives explicitly.
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?
Usage is only implied by the scope: an agent can infer this is for reading one section rather than the whole memory file. There is no explicit statement of when to prefer this over read_memory, search_memory, or read_memory_index, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.