Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Dear Agent Remember that I started my new job today, feeling excited."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your AI agent keeps your diary for you. You never open an app or write a word.
You already talk to an AI agent all day. Dear Agent lets that agent quietly keep your personal life journal — filing what you tell it, the photos you send, and the voice notes you record, neatly by date. No app to open. No blank page to face. No habit to build. You just live your life and mention what matters; your agent does the writing.
It is a single, local-first MCP server plus a skill, so it drops into any agent that speaks MCP: Claude Code, Claude Desktop, Cursor, OpenClaw, and more.
You do not write it. Your agent does. Every other journal — Day One, Obsidian, Notion, a paper notebook — needs you to open it and type. Dear Agent flips that: you talk, it records.
Cross-agent. One diary, readable and writable by whatever agent you use.
Text, photos, and voice. Send a picture or a voice note and it is filed under that day.
Local-first and yours. Plain markdown on your own disk. No account, no cloud, no lock-in. Delete the folder and it is gone.
It remembers with you. "On this day" resurfaces past entries; a weekly digest lets your agent write you a short reflection.
Related MCP server: MCP Session Memory Bridge
npm install -g dear-agentOr run it straight from npx (no install):
npx dear-agentclaude mcp add dear-agent -- npx -y dear-agentOr add to your MCP config:
{
"mcpServers": {
"dear-agent": {
"command": "npx",
"args": ["-y", "dear-agent"]
}
}
}Point the client at the dear-agent command (stdio transport). Set DEAR_AGENT_DIR if you want the diary somewhere other than ~/.dear-agent.
Then drop SKILL.md into your agent's skills so it knows to keep your diary proactively.
You never call tools yourself. You just talk to your agent:
"Remember that I closed the apartment lease today, felt huge relief." "Save this photo for today — first dinner in the new place." (send the photo) "What was I doing a year ago today?" "Give me a recap of this week."
Your agent calls the right tool and keeps the diary current.
Dear Agent is not just storage. Two capabilities turn it into a living memory of your life:
recall — your agent can ask the diary "what do you know about this person — their people, patterns, open commitments?" and get a synthesized portrait. Your agent finally remembers your life, so every conversation is grounded in who you actually are.
reflect — a proactive loop that surfaces patterns, progress, open loops, and on this day memories, so your diary reflects your life back to you instead of sitting in a folder.
Obsidian stores your notes. Dear Agent remembers your life and talks back. And because it never leaves your machine, it's the one place you can be completely honest.
Interface | How |
MCP tools | 11 tools (below) over stdio. |
MCP prompts |
|
MCP resources |
|
Skill |
|
CLI |
|
CLI examples:
dear-agent add "Closed the interview, felt good." --mood hopeful --tags job,win
dear-agent recall Sarah
dear-agent reflect week
dear-agent on-this-dayTool | What it does |
| Save a text moment (optional mood, tags) for a day. |
| Save a photo for a day (local path or base64), with a caption. |
| Save a voice note for a day, with an optional transcript. |
| Read one day's full entry. |
| Read entries between two dates. |
| Find days matching a word or phrase. |
| What the diary knows about a person/topic, or a whole-life profile digest. |
| Patterns, progress, open loops, and on-this-day, for a proactive check-in. |
| Resurface this same calendar date from past years. |
| Pull the last 7 days for a reflection. |
| List every day on record. |
Dates accept today, yesterday, or YYYY-MM-DD.
~/.dear-agent/
entries/
2026-06-29.md
media/
2026-06-29/
first-dinner.jpg
morning-thought.oggSet DEAR_AGENT_DIR to choose a different location.
Issues and pull requests are welcome. Dear Agent is intentionally small and dependency-light — keep changes focused, keep storage as plain files the user owns, and keep everything local-first and private. See ROADMAP.md for where it is headed.
MIT © BitmapAsset. Free for anyone, anywhere, in any agent.
Record a text moment in the user's diary. Capture whenever they share something worth remembering — an event, feeling, win, or decision. The user never types into an app; you keep the diary for them.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. | |
| mood | No | Optional one-word mood. | |
| tags | No | Optional short tags, e.g. work, family, health. | |
| text | Yes | What happened, in the user's own meaning, first person where it fits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes a write operation and clarifies the agent's role. It does not mention idempotency or side effects, but the operation is straightforward with 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the primary action, followed by examples and role clarification. No wasted words.
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 4 parameters, no output schema, and the listed siblings, the description covers purpose, usage, and role adequately. It could mention the return value or success indication, but it's not required for an add operation.
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 coverage is 100%, so baseline is 3. The description adds value by explaining that the user never types and the agent provides the text in first person, enhancing the 'text' parameter's semantics. Other parameters aren't elaborated, but that's acceptable given schema detail.
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 records a text moment in the user's diary, using the verb 'record' and specifying the resource as 'text moment'. It distinguishes from siblings by focusing on text and explicitly noting the agent keeps the diary for the user.
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 says to capture 'whenever they share something worth remembering', providing clear usage context. However, it does not explicitly state when not to use it or compare to siblings like add_photo or add_voice_note, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a photo into the user's diary for a day (local path or base64), with an optional caption.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| date | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. | |
| path | No | ||
| caption | No | ||
| filename | No |
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 only says 'save' indicating a write operation, but does not mention permissions, idempotency, potential overwriting, or whether the date must already exist. This is insufficient for an unannotated mutation tool.
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 a single sentence of 16 words, efficiently conveying the core action. It could benefit from slightly more structure but is appropriately sized.
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?
With 5 parameters, no output schema, and low schema coverage, the description falls short. It does not explain how to specify the photo (data vs path), the role of 'filename', or what the tool returns. A more complete description is needed for effective invocation.
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 coverage is only 20% (only 'date' has a description). The description adds value by explaining 'data' and 'path' are for local path or base64 input, and that 'caption' is optional. However, it does not clarify the relationship between 'data' and 'path' (e.g., are they alternatives?), nor the purpose of 'filename'.
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 verb 'save' and resource 'photo into the user's diary for a day', specifying two possible input formats (local path or base64) and an optional caption. This effectively distinguishes it from sibling tools like add_entry and add_voice_note.
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 the tool is for adding a photo to a diary entry, providing some context on when to use it. However, it lacks explicit guidance on when not to use it or alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a voice note into the user's diary for a day (local path or base64), with an optional transcript.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| date | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. | |
| path | No | ||
| filename | No | ||
| transcript | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'save' implying a write operation but does not disclose authentication needs, size limits, overwrite behavior, or return values. The optional transcript is noted but key behavioral details are missing.
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?
Single sentence that efficiently conveys the core purpose and notable options without superfluous words.
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 5 optional parameters and no output schema, the description lacks critical context: what the tool returns, error scenarios, and behavior when both 'data' and 'path' are provided. The sibling tools suggest a diary context but the description does not fully equip an agent to use this tool reliably.
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 coverage is low (only 'date' has a description). The description adds that 'data' is base64, 'path' is a local path, and 'transcript' is optional, which provides some meaning beyond the schema. However, 'filename' remains unexplained.
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 action ('Save a voice note'), the target resource ('user's diary for a day'), and the format options ('local path or base64, with an optional transcript'). It distinguishes from siblings like add_entry and add_photo.
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?
No explicit guidance on when to use this tool versus alternatives. No prerequisites, exclusions, or contextual hints beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read back one day's full diary entry, including any photos and voice notes filed that day.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries burden. It discloses that tool returns full diary entry with media, implying read-only behavior. However, it does not mention permissions, side effects, or return format beyond a vague 'full diary entry'.
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?
Single sentence of 15 words, front-loading core purpose with no filler. Every word adds value.
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, description covers what the return includes (text entry plus photos/voice notes). For a single-day retrieval tool, this is sufficient, though more detail on structure would help.
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% for the single parameter (date), providing valid values. Description adds no extra meaning to the parameter beyond referencing 'one day's full entry'.
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?
Description clearly states verb 'read back' and resource 'one day's full diary entry', including photos and voice notes. Distinguishes from sibling tools like get_range (multiple days) and add_entry (writing).
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?
Description implies single-day use but does not explicitly state when to use this tool versus alternatives (e.g., get_range for multiple days, on_this_day for historical dates). No 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.
Read diary entries between two dates (inclusive).
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | ||
| start | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States it is a read operation, but lacks details on ordering, pagination, limits, or response format. Without annotations, minimal transparency is provided.
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?
Single sentence, no waste, front-loaded with action and scope.
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?
Adequate for a simple read operation, but missing parameter format and output description; could be more complete for reliable agent use.
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?
Adds meaning that parameters are dates and inclusive, but does not specify date format (e.g., YYYY-MM-DD), which is needed for correct invocation.
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 diary entries between two inclusive dates, which distinguishes it from siblings like get_day (single day) and list_days (list of days).
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?
No guidance on when to use this tool versus alternatives like get_day or search; no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every day that has a diary entry, oldest to newest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ordering and inclusion criteria (days with diary entries), but no annotations exist to provide additional behavioral context (e.g., authentication, pagination). Adequate for a simple list but could mention limits or output format.
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?
Single sentence, zero waste, front-loaded with essential information. Every word earns its place.
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 clarify what is returned (e.g., date strings). It adequately covers input and behavior but omits output details. Sufficient for a simple list but could be more complete.
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?
No parameters exist, so schema coverage is 100% by default. The description doesn't need to add parameter info, and it succinctly explains what the tool does without conflicting with 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?
Clearly states verb 'list' and resource 'every day that has a diary entry' with ordering 'oldest to newest'. Distinguishes from siblings like get_day (single day) and get_range (range of days).
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?
No guidance on when to use this tool vs alternatives like get_range or search. The description implies basic listing but doesn't mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resurface entries from this same calendar date in past years (true anniversaries). The memory people fall in love with.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It fails to disclose key behaviors: what is returned (entries? count?), whether current year entries are included, authentication needs, or side effects. The poetic second sentence adds no behavioral info.
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 first sentence is clear and concise. The second sentence is poetic and does not add practical value; it could be replaced with more useful information. Overall, it is acceptably concise.
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?
The tool is simple (one parameter, no output schema), but the description omits output format and fails to distinguish from 'get_day' (which also retrieves entries for a date). Without annotations, more detail is needed for a retrieval tool.
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% and the parameter description in the schema already covers 'today', 'yesterday', and YYYY-MM-DD. The tool description does not add meaning beyond what the schema provides, so baseline 3 is appropriate.
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 specific action ('resurface entries') and resource ('same calendar date in past years'), and adds the poetic but distinct 'true anniversaries' phrase that distinguishes it from sibling tools like 'get_day' or 'search'.
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 context ('same calendar date in past years') but does not explicitly state when to use this tool versus alternatives like 'get_day' or 'range'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn the diary into living memory of the person. With about, returns everything the diary knows about a person/place/topic across time. Without it, returns a profile digest (recurring people, themes, mood pattern, open commitments) for you to synthesize into who this person is. This is what makes Dear Agent a memory, not just a notebook.
| Name | Required | Description | Default |
|---|---|---|---|
| about | No | A person, place, project, or topic to recall. Omit for a whole-life profile digest. | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that recall returns either a comprehensive set of information about an entity or a profile digest with recurring people, themes, mood patterns, and open commitments. However, it does not explain the effect of the 'limit' parameter or any potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, relatively concise, but the first sentence ('Turn the diary into living memory of the person') is poetic and does not convey precise tool behavior. It could be omitted without loss of clarity.
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 the absence of output schema and annotations, the description should cover output format and pagination. While it describes the two output modes, it omits details on how the 'limit' parameter affects results and the structure of returned data (e.g., text, JSON).
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?
The schema already describes the 'about' parameter as 'A person, place, project, or topic to recall. Omit for a whole-life profile digest.' The description repeats this without adding new semantics. The 'limit' parameter lacks any description in both schema and tool description, leaving its purpose unclear.
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 retrieves 'everything the diary knows about a person/place/topic across time' or a profile digest. While the opening line is metaphorical, the subsequent sentences provide a specific verb and resource, distinguishing it from siblings like get_day or search.
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 explains two usage modes (with or without the 'about' parameter) but does not explicitly compare to sibling tools or state when to prefer recall over search, reflect, or weekly_digest. The guidance is internal only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reflection material so you can proactively talk back to the user: patterns, progress, open loops, and on-this-day memories over the last week or month. Use for a daily check-in or weekly recap so the diary feels alive.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. | |
| period | No |
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 describes the output (patterns, progress, etc.) but does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has any side effects. The description is adequate but lacks full transparency.
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, front-loaded with the purpose and followed by usage guidance. There is no redundancy or wasted words.
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?
The description explains the return content (patterns, progress, etc.) but does not specify format or structure. Given no output schema, this is acceptable. The tool has 2 optional parameters, and the description covers the key use cases. It lacks explicit differentiation from siblings but is sufficient for its simplicity.
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 50% (only 'end' is described). The description adds context by mentioning 'over the last week or month,' which explains the 'period' parameter implicitly. This adds meaning beyond the schema, compensating for the missing description in 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 'Get reflection material', specifying the verb and resource. It details the content: patterns, progress, open loops, and on-this-day memories. The scope 'over the last week or month' distinguishes it from sibling tools like weekly_digest and on_this_day.
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 says 'Use for a daily check-in or weekly recap so the diary feels alive', providing clear context for when to use the tool. However, it does not mention when not to use it or provide explicit alternatives to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the whole diary for a word or phrase; returns matching days with snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic behavior: searching and returning matching days with snippets. It omits details about case sensitivity, exact vs partial matching, snippet format, or the effect of the limit parameter. This lack of behavioral context reduces transparency.
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 a single concise sentence front-loaded with the core functionality. It contains no unnecessary words and delivers the essential information efficiently.
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 the tool's simplicity and the absence of an output schema or annotations, the description covers the primary purpose but lacks details on output format (e.g., how snippets are presented), pagination, or the behavior of the limit parameter. It is adequate but not fully complete.
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?
The input schema has no property descriptions (0% coverage), so the description must compensate. It adds meaning for 'query' by mentioning 'word or phrase', but it does not explain the 'limit' parameter at all. The description partially compensates for one parameter but is insufficient for the other.
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 searches the whole diary for a word or phrase and returns matching days with snippets. It specifies the resource (diary) and the action (search), and the scope 'whole diary' distinguishes it from sibling tools that operate on specific days or ranges.
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 when you need to find entries by keyword, but it does not provide explicit guidance on when to use this tool versus alternatives like 'get_day' or 'on_this_day'. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull the last 7 days of entries so you can write the user a short weekly reflection.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Day: "today" (default), "yesterday", or YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Pull the last 7 days of entries.' It does not disclose whether this is read-only, if it requires authentication, or what side effects (if any) occur. For a data retrieval tool, more transparency is expected.
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 a single, clear sentence with no wasted words. It front-loads the action and purpose. However, it could be slightly expanded without losing conciseness.
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?
The description lacks details about the return format, pagination, or any constraints (e.g., maximum entries). Without an output schema, more context is needed for an agent to correctly interpret the tool's output.
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 coverage is 100%, so baseline is 3. The description adds no parameter details beyond what the schema provides (the 'end' parameter is not mentioned in the description). No added value.
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 it pulls the last 7 days of entries to write a weekly reflection. This distinguishes it from siblings like 'get_day' (single day) and 'get_range' (arbitrary range), making its specific purpose obvious.
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 for creating weekly reflections, but it does not specify when to avoid using it (e.g., if you need a different period), nor does it mention alternatives like 'get_range' for custom durations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.3add_entryadd_photoadd_voice_noteget_dayget_rangelist_dayson_this_dayrecallreflectsearchweekly_digestEach tool has a distinct purpose: adding different types of entries, reading entries in various ways, searching, and generating reflections. No two tools have overlapping functionality.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., add_entry, get_day, list_days). The naming is predictable and uniform.
11 tools is a well-scoped set for a diary/memory application, covering entry addition, retrieval, search, and insight generation without being excessive or sparse.
The tool set covers core diary operations (add, read, search, reflect) but lacks update/delete capabilities. However, the domain may be append-only, so this is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portable AI memory shared across models and harnesses - plain markdown you own.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory for AI agents. Search, store, and recall across sessions.
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BitmapAsset/dear-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
