Dear Agent

by BitmapAsset

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.3
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.6/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dear-agent MCP server](https://glama.ai/mcp/servers/BitmapAsset/dear-agent/badges/card.svg)](https://glama.ai/mcp/servers/BitmapAsset/dear-agent)

Score Badge

Copy to your README.md:

[![dear-agent MCP server](https://glama.ai/mcp/servers/BitmapAsset/dear-agent/badges/score.svg)](https://glama.ai/mcp/servers/BitmapAsset/dear-agent)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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