list_memoriesLists the current memory values the assistant holds for a farm, one per key. Run it before saving a memory to avoid duplicate or conflicting keys.
List what the assistant currently remembers about this farm (the current value per key). Use before saving a memory to avoid duplicate or conflicting keys.
| Name | Required | Description | Default |
|---|---|---|---|
| farm_id | No | The ID of the farm (optional if a default is set). |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe read, so the description's burden is light. It adds useful scoping context (memories belong to the current farm, one current value per key) but says nothing about pagination, volume of results, or what happens if nothing is stored.
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?
Two tight sentences: the what comes first, the when-to-use second. Nothing is redundant or padded.
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 read-only, single-optional-param list tool with annotation coverage, the description supplies purpose, scoping, and a usage cue. No output schema exists, so the description could say more about the returned key/value shape, but 'current value per key' covers the essential structure.
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% with a single optional farm_id parameter, so the schema already documents the input fully. The description only gestures at farm scoping ('about this farm') without adding format or default-resolution details 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?
States a clear verb (list) and resource (assistant memories about this farm), and the parenthetical 'the current value per key' sharpens what is actually returned. It implicitly separates itself from farm-data siblings like list_my_farms and get_farm, though no sibling is named 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?
'Use before saving a memory to avoid duplicate or conflicting keys' gives explicit when-to-use guidance tied to a concrete workflow. It does not name or exclude any alternative tool, but no obvious sibling overlaps with this capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.