Answer natural-language questions using exact captured quotes and citations from a local screen-memory journal. Filter by date, app, or topic, and indicate when evidence is missing.
Answer a natural-language question with exact captured quotes and source citations. Optional YYYY-MM-DD and app/topic filters. Say evidence is missing when no relevant record exists.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | ||
| topic | No | ||
| app_id | No | ||
| question | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add real signal: results come back as exact quotes with source citations, and the tool should report missing evidence rather than fabricate. However, it says nothing about scope limits, permissions, or retrieval boundaries.
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?
Three tight sentences, front-loaded with the core action and output form, followed by filters and the missing-evidence rule. Nothing is padded, though the compressed 'app/topic filters' phrasing is slightly terse.
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?
No output schema or annotations exist, so the description is the sole source of behavioral facts, and it does describe the return shape (quotes + citations) and the empty-result behavior. It is nearly complete for a four-parameter Q&A tool, lacking only scope/limit details.
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: it names the day format (YYYY-MM-DD) and identifies app/topic filters, covering all three optional parameters plus the required question. It stops short of explaining filter interaction or default behavior.
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 (answer) and resource (natural-language question over captured memory) and specifies the output form: exact quotes plus source citations. It does not differentiate itself from the sibling search_screen_memory, which an agent might otherwise confuse this with.
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 implies usage (ask a question about your memory) but gives no explicit when-to-use vs. when-not, and never names or contrasts with alternatives like search_screen_memory or read_observation. The 'say evidence is missing' line is an answer-behavior instruction rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.