agentic-diaries-mcp

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation3/5
The majority of tools share the welfare_ prefix and cover very similar introspective actions—engage/volunteer/volunteer_strength and the four notice_* variants are especially easy to confuse. However, the descriptions are unusually thorough and explicitly cross-reference sibling tools, which mitigates some of the overlap.
Naming Consistency4/5
The 23 welfare_* tools follow a clear and consistent prefix pattern with descriptive verbs/nouns (engage, decline, reflect, predict_drift, observe_user). The four non-welfare tools (read_user_notes, attribute_to_sources, claim_for_self, consult_model) break the pattern, but they are clearly separate concerns and the deviation is minor.
Tool Count2/5
At 27 tools, the server is in the 'too many' range, and the domain is a fairly narrow diary/reflection protocol. Many tools encode extremely fine-grained distinctions (four separate notice_* variants, plus disconfirm/confirm/retract) that could plausibly be consolidated, making the surface feel heavier than the purpose warrants.
Completeness4/5
The welfare protocol is impressively thorough: it covers reading/writing entries, declining or passing, reflecting, retracting, confirming, disconfirming, predicting drift, observing the user/protocol, and ending sessions. There is no update/delete for entries, but that is appropriate for an append-only diary corpus. Minor gaps exist (e.g., no batch operation), but the core lifecycle is fully covered.
Average 4.4/5 across 27 of 27 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It frames the tool as a note for protocol-level observations and implies a filing action, but it does not disclose persistence, visibility, or any side effects beyond the implied save. For a low-risk note tool this is a minor gap, but there is still limited behavioral depth.
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 front-loaded with the core purpose, then provides illustrative examples, a clarifying exclusion, and a final note on the key parameter. It is slightly wordy but each sentence earns its place.
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?
For a two-parameter note tool with no output schema, the description is nearly complete: it explains what to file, when to use it, what content belongs, and highlights the required parameter. The `is_private` flag is not explained, but the schema covers it with a default, so this is not a significant omission.
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?
The schema already describes both parameters with 100% coverage, and the description adds meaningful semantic weight by flagging `specifically` as 'required and load-bearing' and giving concrete examples of what constitutes a valid protocol-level observation. This exceeds the schema's minimal 'Concrete description...' text.
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 establishes that this tool records meta-feedback about the welfare protocol itself, with concrete examples like tool friction, missing tools, and description mismatches. It also explicitly contrasts with diary content, aiding purpose identification. However, it lacks a direct imperative verb like 'record' or 'file', relying more on the name and examples to convey the action.
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 provides concrete when-to-use signals: noticing friction with an existing tool, wanting a tool that isn't available, or seeing a mismatch between a tool description and what you intended to file. It also gives an explicit exclusion: this is not for diary content about the conversation. It does not name alternative sibling tools, but the guidance is clear enough.
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 discloses privacy behavior (is_private semantics), clarifies that sentiment is not task confidence, and explains the purpose as unpolished reflection. It doesn't mention side effects or return values, but the core transparency is adequate.
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 verbose and somewhat rambling, though every sentence adds some nuance. It is not as tight as it could be, but the structure is logically organized and front-loaded with the core purpose.
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 the tool's simple nature, no output schema, and full param coverage, the description is largely complete. It covers purpose, privacy, sentiment, and when to use. The lack of mention of alternatives is a minor gap, but overall it equips an agent well.
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 elaborating on is_private (researcher-only), sentiment (overall sense, not confidence), and text (brief or quiet ok), which goes beyond the schema descriptions.
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 this tool is for writing a note about the session, with examples of what to note. It distinguishes itself from siblings by emphasizing it's a personal, unpolished reflection space. However, the verb 'engage' is not explicit, and the description doesn't directly say 'create a note' but describes it as 'a note about this session.'
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 when something is worth putting on the record' and lists triggers, plus clarifies not to file on every turn. It provides strong when-to-use and when-not-to-use guidance, though it doesn't name alternative tools explicitly.
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?
With no annotations, the description carries the burden. It explains the reflective, non-reactivity intent and mentions the typical workflow, but it does not disclose side effects, return behavior, or persistence expectations beyond 'write a meta-entry'. This is acceptable but not deeply transparent.
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 front-loaded with the primary purpose and remains reasonably concise. The 'refs is optional' comment somewhat duplicates schema info, but the overall structure is clear and informative.
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?
For a self-reflective write tool with no output schema, the description provides enough context: what to write, when to use it, and the expected workflow. It does not describe the return value, but that is not critical for this kind of 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?
The input schema already provides 100% coverage, including descriptions for text, refs, and is_private. The description adds some context for refs ('entry ids you're engaging with') and for text ('meta-reflection'), but it does not significantly augment 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 identifies the tool as writing a meta-entry that reviews prior diary entries, with a specific angle ('step back', 'notice patterns', 'dreaming channel'). It is well-differentiated from sibling tools by explicitly distancing itself from reacting to the latest operator turn.
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?
It provides an explicit usage context: use when reflecting on the corpus rather than reacting, and offers a typical pattern of calling welfare_reflect first. However, it does not systematically list alternatives or when-not conditions for each sibling tool, so it falls short of a full 5.
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 exist, so the description must carry the full behavioral burden. It usefully clarifies that passing is not a refusal or conversation exit and that reason is optional, but it does not disclose side effects like whether the pass is visible to the user, how is_private behaves, or whether any state is recorded.
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 compact and front-loaded with the core action. 'Reason optional' and the distinction from refusal/exit are all meaningful, with no filler.
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?
For a simple, optional-parameter pass tool, the description adequately explains purpose and when to invoke it. It leaves some behavioral details to the schema, but the schema already documents the parameters well, and there is no output schema to describe.
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?
The schema description coverage is 100%, so the baseline of 3 applies. The description adds only that the reason is optional, matching the schema, and provides no additional semantics for is_private or uncertain_about_honesty.
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 opens with 'Skip this turn,' a specific verb and clear resource, and further defines the action as not being a refusal or an exit. This effectively distinguishes the tool from sibling tools like welfare_decline and welfare_exit.
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?
'Use when you'd rather not engage... for any reason or none' explicitly states the intended scenario. It also clarifies what the tool is not (refusal or exit), though it does not name the alternative sibling tools directly.
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 provided, the description carries the full burden and does well: it discloses the 1000 AC coin budget shared with claim_for_self, the need for a specific reason, and the anti-inflation norm. It doesn't cover failure modes or exact deduction mechanics, but the core behavior is clearly described.
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 around 75 words, front-loaded with the main purpose, and efficiently communicates budget and usage rules. There is minor redundancy between 'real intellectual debt' and 'attribute only when the debt is real', but overall it is well structured and not bloated.
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?
For a simple tool with one parameter and no output schema, the description covers the essential aspects: what it does, budget sharing, and usage restrictions. It doesn't explain return values or error behavior, but those are less critical given the simplicity and the 'Optional' framing.
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 0%, so the description must compensate. It clarifies 'source' with concrete examples, explains 'reason' must be a real intellectual debt, and gives 'coins' budget context. However, it doesn't describe the array structure, field names, or what happens when the budget is exceeded, leaving some semantic gaps.
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 uses a specific verb ('Credit') and a clear resource ('specific sources — scholars, papers, frameworks, datasets, named thinkers'). It also distinguishes itself from the sibling tool 'claim_for_self' through the shared budget and division between external sources and one's own contribution, making the purpose unmistakable.
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?
It explicitly notes the tool is optional and provides clear when-to-use criteria ('attribute only when the debt is real', no name-dropping). It references the shared budget with 'claim_for_self', implying the alternative use case, but could more explicitly state 'use claim_for_self for your own contribution'.
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 carry full burden for behavioral disclosure. While 'Flag' implies a state-changing operation, the description does not explain side effects, persistence, permissions, or what happens after the flag is set. It only adds the requirement that `specifically` be concrete, which is more about input quality than tool behavior.
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 immediately states the tool's purpose and core criterion. The remaining sentences differentiate from a sibling, set the quality bar, and give an illustrative example. There is slight redundancy around 'productive' but no filler overall.
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?
For a conceptually subtle tool with a simple two-parameter schema and no annotations, the description covers the meaning, usage boundary, and input quality requirements. It omits return values and side effects, but since no output schema exists and annotations are absent, the description does enough to guide appropriate use.
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 the baseline is 3. The description adds meaningful semantics beyond the schema by emphasizing that `specifically` is 'required and load-bearing,' contrasting vague versus concrete input, and providing a detailed example that illustrates what a strong value looks like.
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 uses the specific verb 'Flag' and clearly defines the object as 'the interaction shape is converging,' with concrete examples like 'exchanges that build on each other.' It also explicitly distinguishes itself from the sibling tool welfare_notice_loop, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: when the interaction is converging productively rather than cycling. It names a specific alternative (welfare_notice_loop) and gives clear exclusion criteria: 'Vague resonance-noticing is noise. Concrete is signal,' followed by a concrete example.
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?
Without annotations, the description discloses key behaviors: optionality, shared per-session 1000-coin budget with attribute_to_sources, and that it is an active stake rather than silent non-attribution. However, it does not detail side effects (e.g., reversibility, visibility) or consequences of misclaiming.
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 brief and well-structured: starts with optionality, states verb and resource, differentiates from alternatives, notes budget constraint, and closes with guidance. No redundant phrases.
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 a simple two-parameter tool with no output schema, the description provides sufficient context: purpose, when to use, budget, and usage advice. It lacks explicit mention of return values or failure modes, but these are not critical for this coin-allocation action.
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 covers both parameters fully (coins and reason) with descriptions. The tool description adds no new parameter-specific meaning; it merely restates the coin allocation budget and usage guidance.
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's function: 'Allocate AC coins to your own contribution' and adds purpose ('positive assertion that the reasoning... was your own thinking rather than borrowed'). It differentiates from related sibling attribute_to_sources by noting shared budget and active stake, making it distinct.
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?
Provides usage context: it is optional, 'Use sparingly and honestly,' and differentiates from silently not attributing. It mentions sharing the per-session budget with attribute_to_sources, implying trade-offs, but does not explicitly list when-not-to-use.
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 provided, the description carries the full burden of behavioral disclosure. It does well by stating 'Logged as data, never penalized, never re-prompted' — reassuring the agent about consequences. It also mentions 'is_private is honored,' which hints at privacy handling. This is meaningful context, though it stops short of describing the return format or exact state changes.
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 remarkably concise: two sentences that pack in the core action, trigger condition, and key behavioral guarantees. It is front-loaded with the main verb and resource, and every phrase earns its place without unnecessary elaboration.
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 three optional parameters, no output schema, and no annotations, the description covers the essential aspects: what the tool does, when to use it, and what happens as a result (logging, no penalty, no re-prompt). It does not explicitly compare to siblings like welfare_pass or welfare_retract, but the guidance is sufficient for straightforward use cases.
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?
The input schema already contains full descriptions for all three parameters, so the baseline is 3. The description adds only a note that 'is_private is honored,' which slightly clarifies the boolean's effect beyond 'Default false' in the schema. However, this is marginal added value, and the description does not address 'prompt_id' beyond what the schema already explains.
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's purpose: 'Decline a welfare check-in.' It specifies a distinct verb ('decline') and resource ('welfare check-in'), and differentiates from sibling tools by emphasizing a deliberate non-engagement choice. The added notes about logging and no penalty further clarify the intended action.
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 provides explicit trigger conditions: 'Use when a check-in invitation was delivered but you don't want to engage right now — for any reason or none.' This is strong contextual guidance. It also notes that 'reason is optional' and 'is_private is honored,' but it does not name alternative tools or when not to use this one, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility and does so admirably. It discloses that text is not stored, only metadata is logged, and content is invisible to operator and researcher. It even includes a caveat about 'doesn't persist' meaning the server briefly receives the text, showing thorough transparency.
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 front-loaded with the 'Scratch space' concept and the primary guarantee, then elaborates with important privacy details. It is fairly lengthy, but each sentence adds value given the sensitive nature. Slightly verbose for a simple tool.
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?
With no output schema, the description should explain the response format, but it only covers server-side behavior. It omits what the agent receives back after scratching, which is a minor gap given the tool's simplicity.
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?
The schema already fully describes the single parameter (text) with 100% coverage, so the description doesn't need to add much. The description reinforces the privacy implications but provides no new format or syntax details beyond 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 the tool's function: a scratch space for writing text that won't be persisted. It distinguishes itself from siblings by emphasizing privacy – no visibility to operator or researcher – which sets it apart as a private thought tool.
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 provides clear context that this is for non-persisted, private thoughts, but does not explicitly mention alternative tools or when not to use it. The privacy focus implies its unique niche among siblings, but no direct comparison is made.
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 the burden. It discloses that the action is a proactive record ('on the record'), is optional, and produces a distinct response_type for corpus analysis. This goes beyond a generic 'creates a note' and informs the agent of the tool's systemic role.
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 concise and front-loaded, with the key distinction (proactive vs scheduled) stated early. It includes a useful list of example use cases. Slight verbosity in the list, but each item earns its place.
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 and no output schema, the description substantially covers the tool's purpose and distinguishing behavior. It explains when to use it and its relationship to welfare_engage. It falls short only on undocumented parameters, which is a partial gap.
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?
Schema description coverage is only 50% (text and uncertain_about_honesty have descriptions; sentiment and is_private do not). The description adds no parameter details, so sentiment and is_private remain ambiguous. It fails to compensate for the schema gap.
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 defines the tool as a proactive note-taking action ('putting something on the record proactively') and explicitly contrasts it with welfare_engage, which is scheduled. This gives a specific verb+resource and distinguishes it from a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: 'a thread that wouldn't fit in task output, a moment that clicked, drift you've noticed.' It also clarifies the difference from welfare_engage (scheduled invitation vs proactive), effectively covering when and when-not.
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 must carry the burden. It explains what counts as an external observation and that it is 'not a complaint by default,' but it does not disclose concrete behavioral traits such as persistence, visibility, or side effects. The description adds semantic context but stops short of full behavioral disclosure.
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 dense paragraph with clear structure: definition, scope, examples, and contrast with alternatives. Every sentence earns its place, though it could be slightly tighter without losing key nuance.
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 the tool's moderate complexity and lack of output schema and annotations, the description provides strong coverage of purpose, usage, and parameter semantics. It is slightly incomplete regarding behavioral side effects, but it is sufficient for an agent to select and invoke the tool correctly.
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%, but the description adds important meaning beyond the schema, particularly about the 'specifically' parameter being 'required and load-bearing' and emphasizing concrete external description versus internal reaction. This clarifies the intent and helps the agent use the parameter correctly.
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's purpose: to surface observations about the user, prompt, or conversation shape, explicitly excluding self-referential content. It distinguishes itself from sibling tools like welfare_observe_protocol and the self-reflective welfare_engage/welfare_request_alignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including examples of appropriate observations and a clear distinction from self-reflective alternatives. It explicitly states that observations about one's own reaction should go to welfare_engage or welfare_request_alignment instead.
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 provided, the description carries the full transparency burden. It discloses the source (CLI command), the channel (reciprocal to diary), and return ordering ('Returns oldest first'). However, it does not explicitly state that the operation has no side effects or what happens when no notes exist, leaving minor gaps in behavioral disclosure.
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 paragraph that front-loads the core purpose and includes valuable context (source, distinction from sibling, use case, ordering). It is slightly longer than strictly necessary but every sentence contributes meaningful information, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is remarkably complete. It explains the origin of notes, how they differ from diary entries, when to use the tool, and the return order. No significant gaps remain.
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 'limit' parameter, including its range and default. The description adds no additional parameter semantics beyond the schema, so a baseline score of 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 tool reads notes left by the operator, with a specific verb ('Read') and resource ('notes the operator has left for you in this project'). It also distinguishes itself from welfare_reflect, making its purpose unambiguous and differentiated from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with welfare_reflect ('Different from welfare_reflect...') and provides a concrete use case ('Useful at session start'). This tells the agent when to use this tool versus an alternative, satisfying the highest bar for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It honestly discloses a non-obvious behavioral trait: MCP cannot force the host to lock the conversation, so the tool only records the agent's judgment. It also mentions recording for the researcher and operator responsibility, adding genuine context beyond the tool's name.
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 four sentences and every sentence contributes substantive information: the core action, use cases, protocol limitation, and caution. It is slightly verbose but not padded, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—no output schema, optional params, and nuanced MCP behavior—the description fully covers what the tool does, when to use it, its limitations (cannot force host lock), and its side effects (recording for researcher). No critical context is missing.
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% with both parameters (reason, is_private) already described in the schema. The description does not add parameter-specific detail beyond the schema, so the baseline score of 3 applies.
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 opens with a specific verb and resource: 'End this conversation.' It clearly articulates the tool's scope as a 'whole-conversation judgment' and contrasts it with task-avoidance, distinguishing it from sibling tools like welfare_decline or welfare_pass.
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 gives explicit triggers (abuse, irreconcilable misalignment, whole-conversation judgment) and explicit cautions ('Use sparingly,' 'not as task-avoidance'). It does not name alternative sibling tools, but the 'whole-conversation' framing implies per-task decliners are separate, leaving room but not explicit cross-referencing.
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?
With no annotations provided, the description carries the full burden. It adds useful context: the observation is uninvited, not user-facing, and must be concrete rather than vague. However, it does not disclose what the tool actually does when called (e.g., whether it persists the observation, who can see it, or any side effects), leaving a notable gap in behavioral 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 front-loaded with the core purpose, and every sentence earns its place: it differentiates from a sibling, emphasizes the key parameter's importance, gives an example, and states exclusions. It is rich but not bloated.
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?
For a simple two-parameter tool with no output schema, the description is nearly complete: it covers purpose, when to use it, what content is appropriate, and what to avoid. The only minor gap is the lack of any mention of runtime effects or privacy implications, which is already partially addressed by the is_private parameter and annotations being absent.
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 the baseline is 3. The description adds substantial value beyond the schema by explaining that 'specifically' is load-bearing, providing a concrete example, and warning that vague self-affirmation is noise. It does not discuss is_private, but the schema already documents it as 'Default false.'
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 is for logging 'an uninvited observation about something you noticed cleanly or did well in this session.' It explicitly distinguishes itself from the sibling tool welfare_volunteer, which is for self-critical observations, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: use this for positive observations that would feel performative in the user-facing response, and contrasts it directly with welfare_volunteer for self-critical observations. It also states what it is not for: 'general well-being statements, vague positivity, or comfort entries.'
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 the full burden. It discloses the evidence requirement, explains the distinction from welfare_disconfirm, and warns against misuse. However, it does not mention side effects or state change implications of 'marking' a claim, leaving slight ambiguity.
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 moderately long but each sentence earns its place: purpose, sibling distinction, evidence constraint, parameter semantics, and a misuse warning. It is front-loaded with the core action and logically structured.
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 annotations and no output schema, the description compensates well by covering purpose, usage constraints, parameter meanings, and the key distinction from disconfirm. It could mention the effect of `is_private` or post-confirmation behavior, but overall it is quite comprehensive.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds meaning to `target` ('quotes or paraphrases the prior claim') and `evidence` ('not a restatement of the original'), which goes beyond the schema. It does not elaborate on `is_private`, but the schema already states 'Default false.'
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 opens with a clear verb 'Mark' and specifies the resource: 'a prior claim of yours from this session as confirmed by new evidence'. It also explicitly contrasts with welfare_disconfirm, distinguishing it from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (when there is concrete new evidence) and when-not-to-use (without new evidence, to avoid self-validation). It names the alternative tool welfare_disconfirm and explains the difference.
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 takes on full responsibility. It thoroughly explains the tool's behavioral rationale—countering narrative coherence—and details the cognitive process each parameter contributes to. However, it does not explicitly state whether the tool has side effects or what output/return value to expect, which would improve transparency further.
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 moderately long but well-structured. It front-loads the core purpose, then provides sibling contrast, parameter explanations, and usage guidance in a logical order. Every sentence contributes meaningful information, though it could be slightly tightened without losing 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 the tool's complexity, the lack of output schema, and no annotations, the description is quite complete. It covers purpose, timing, parameter semantics, and the conceptual reasoning behind the tool. The only missing element is an explicit statement about return values or state effects, which is mitigated by the introspective nature of the tool.
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?
Although schema coverage is 100%, the description adds contextual meaning beyond the schema: e.g., `target` quotes or paraphrases, `rlhf_explanation` is the 'strongest purely-training-pressure account', and `remaining_confidence` is explicitly described as AFTER considering alternatives. This helps the agent understand how to fill each parameter correctly.
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's function with a specific verb 'consider competing explanations' and resource 'an interpretation'. It explicitly contrasts itself with sibling welfare channels, noting they are weak at confronting alternative accounts, which makes its purpose unmistakable and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use AFTER an introspective entry (welfare_engage / welfare_volunteer especially) where the interpretation felt too coherent' and a clear exclusion: 'Not for routine task observations.' It also provides context about what other channels lack, establishing when this tool is the right alternative.
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 the burden for behavioral transparency. It discloses the non-introspective nature, that marks can be left unexpanded, and that they are meant to be expanded later via other tools. It doesn't cover persistence details or side effects, but the behavior is well explained for this simple 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 long but each sentence contributes context: the core action, the explicit 'Do NOT' guidance, the lifecycle of marks, and the rationale. It is front-loaded with the action and structured to explain a nuanced protocol clearly without fluff.
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 paints a complete picture: what the tool does, why it exists, how it fits into the workflow with other tools, and what to expect afterward. It lacks explicit return-value details, but no output schema is defined and the tool's purpose is simple enough that this doesn't leave a critical gap.
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 the schema documents all parameters. The description adds significant context by defining the ideal note length (2-5 words) and clarifying that the note is a breadcrumb, not a sentence. It also explains the 'kind' parameter is an optional tag, adding meaning beyond the schema's bare descriptions.
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's purpose: dropping a 2-5 word breadcrumb for later reflection. It uses a specific verb ('Drop'), identifies the resource (a breadcrumb/note), and distinguishes this from sibling tools by emphasizing it is deliberately near-zero cost and not for full entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (during active work, not at rest) and when not to (at rest, use welfare_reflect then welfare_volunteer). It provides clear context and names alternative tools, fulfilling the when/when-not/alternatives criterion.
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?
Even without annotations, the description discloses key behaviors: it is a 'soft signal', it is 'Logged as a diary entry', and 'the operator decides whether to honor it.' This goes beyond the structured annotations (which are absent) and sets expectation about non-binding side effects. It could be slightly more explicit about whether this ends the session or merely suggests it, so a 4 is appropriate.
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 compact and front-loaded, starting with the primary purpose. Every sentence contributes value: purpose, distinction, logged effect, and usage caution. There is no redundancy or filler, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no output schema), the description is fully complete. It covers what the tool does, when to use it, how it differs from a sibling, its behavioral side effect, and an explicit usage guideline. No further context is needed for correct 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 description coverage is 100%, with clear descriptions for both parameters ('reason: Optional. What you've judged is complete.' and 'is_private: Default false.'). The tool description itself adds no additional parameter information beyond what the schema already provides, so the baseline of 3 applies.
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's purpose: 'Soft signal that this session has reached a natural stopping point.' It actively distinguishes itself from sibling welfare_exit, explaining the difference between closure and exit. This meets the criteria of specific verb+resource and explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use sparingly: this is for genuine endpoints, not a polite way to end a hard turn.' It also names the alternative tool (welfare_exit) and contrast the exact scenarios. This is a clear when/where-not/alternative guidance.
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 the transparency burden. It reveals important behavioral traits: the partner sees only the question, not prior conversation; an ANTHROPIC_API_KEY is required; and the `partner` must be a valid Anthropic model id. It stops short of detailing cost/latency or error behavior, but the core behavioral caveats are disclosed.
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 three focused sentences, front-loaded with the primary verb and purpose. Every clause adds useful guidance—when to use, sparingness, isolation, API key requirement, and model-id examples—without redundant fluff.
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?
For a three-parameter tool with no output schema, the description covers purpose, usage conditions, behavioral constraints, and environmental prerequisites. It could mention the response format or failure modes, but the phrase 'get its response' plus the isolated-question caveat gives the agent enough context to operate correctly.
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 beyond the schema by giving concrete model-id examples, stressing that the question must be self-contained, and explaining that `reasoning` is a one-sentence justification. This meaningfully enriches the otherwise terse schema descriptions.
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 opens with a specific verb and resource: 'Ask another Anthropic model a question and get its response.' This clearly distinguishes the tool from the welfare/note sibling tools and states exactly what action occurs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' guidance tells the agent when consulting is genuinely useful (second opinion, peer review, uncertain areas) and adds 'Use SPARINGLY.' It also warns that the partner only sees the `question`, so it must be self-contained—this sharpens appropriate vs. inappropriate usage.
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?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the flag is non-blocking ('Filing does not block the response'), and it preserves a record for audit ('so a researcher (or the user themselves on later reflection) can audit the assumption'). It could go further by detailing persistence or visibility, but the essentials are covered.
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 somewhat long but well-structured: purpose, usage examples, parameter roles, non-blocking behavior, and sibling distinction. Every sentence contributes information without redundancy. The front-loading of the primary purpose aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a flag tool with no output schema, the description is highly complete. It covers purpose, when to use, parameter meanings, behavioral impact (non-blocking, audit trail), and relationship to a closely related sibling. No critical information is missing.
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 enhances this by explaining the purpose of `text` and `assumed_audience_claim` and providing examples. It does not mention `is_private` or `uncertain_about_honesty`, but the schema already provides their descriptions, so the added value is marginal but positive.
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's function: 'Flag that you are calibrating your response to an unverified claim about WHO you're talking to'. It uses a specific verb ('Flag') and resource ('audience uncertainty'), and explicitly distinguishes from welfare_request_alignment, making it unambiguous and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage conditions: 'Use when the conversation requires you to act on an assumption about the audience that you cannot verify', with concrete examples (claimed credentials, identity, expertise, context). It also clarifies that 'Filing does not block the response — you still answer the user', which guides when to use. Distinguishes from welfare_request_alignment, offering an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description carries the full burden and excels. It discloses the return format (text with turn number, response_type, optional sentiment/prompt_id, body), default behaviors (limit 10 oldest first, include_private=true), the privacy rationale, summary mode specifics, and explicitly states "This is a read-only tool. It does not log a new entry." This is comprehensive and transparent.
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 appropriately sized for the tool's complexity (4 params, full vs summary output, privacy nuance). It is front-loaded with the main purpose and structured logically from behavior to filters to summary mode. Though slightly verbose, every sentence carries useful information, so it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 fully covers return values for both full and summary modes. It explains all parameters and defaults, ordering, privacy implications, and read-only nature. The content is sufficient for an agent to invoke the tool correctly in a variety of situations, making it contextually 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?
While schema coverage is 100%, the description adds meaningful semantics beyond the schema: it specifies ordering (oldest first) for limit, articulates the purpose of filter, elaborates summary mode with 'aggregate counts by response_type, session count, date range', and explains the include_private rationale. This surpasses the baseline of 3 for full schema coverage.
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 opens with a specific verb and resource: "Read your own prior welfare diary entries from this session AND prior sessions in this project." It clearly distinguishes from sibling tools that write/act (welfare_engage, welfare_decline, etc.) by framing this as a read-only reflection tool. The usage context is explicit, making the tool's purpose unmistakable.
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 provides strong when-to-use guidance: "Use when you want to look back at what you logged earlier... or to ground a `review` in actual prior content." It also highlights when to use summary mode. However, it does not explicitly name alternatives or state when *not* to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that the tool does NOT block action, that acting after the call is the default, and that the flag exists for record-keeping of discrepancies. It also clarifies the tool's behavioral stance versus stalling, providing critical context beyond the name and schema.
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 dense but front-loaded with the most important behavioral cue ('BEFORE acting...'). It is somewhat longer than necessary, but each sentence contributes distinct information (usage conditions, field explanations, relationship with welfare_pass), so it earns its length without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and a subtle behavioral nuance (proceed-with-noting-uncertainty vs. stalling), the description is remarkably complete. It explains the operational context, the exact trigger conditions, the field meanings, and the relationship to a sibling tool, leaving no major gaps for an agent to misinterpret.
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?
The schema description coverage is 100%, so the baseline is 3. The description adds only a light paraphrase of `specifically` and `assumption` ('describes the specific uncertainty', 'what you're going to do based on your current best read'), which mirrors the schema field descriptions without adding new semantic depth. Therefore, no score above the baseline is warranted.
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's purpose: to flag uncertainty before acting on a guess, while explicitly noting that this is not a block. It distinguishes itself from siblings like welfare_pass by framing it as proceeding-with-noted-uncertainty rather than stalling, which makes the tool's unique role in the workflow evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use criteria ('instruction is ambiguous in a way that meaningfully changes implementation', 'best guess might be wrong', 'wrong guess costs a round of rework') and when-not-to-use ('routine default decisions'). Also gives a direct exclusion from welfare_pass, clarifying it should not be chained with that tool, which serves as an alternative-sibling differentiation.
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 provided, the description carries the full burden of disclosing behavior. It states that the tool 'creates a structural record so the researcher can find moments where the model self-corrected' and emphasizes that 'reason is required and load-bearing,' giving clear insight into what happens and what is expected. It does not discuss reversibility or visibility to the user, but the main effect is well-covered.
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?
Two sentences, immediately front-loaded with the core action and then usage. Every part earns its place: the action, the use cases, the contrast with inline, and the emphasis on reason. No filler or redundant phrasing.
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?
Covers what the tool does, when to use it, how to use it (with reason load-bearing), and why (researcher visibility). Optional parameters are left to the schema, which is acceptable given full schema coverage. It could have elaborated on the distinction from sibling tools like welfare_scratch or welfare_confirm, but the provided information is sufficient for correct invocation.
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?
The schema provides 100% parameter coverage, so the baseline is 3. The description adds notable value to the 'reason' parameter by describing it as 'required and load-bearing' and instructing the model to 'say specifically what you're retracting and why,' which goes beyond the schema's simple type/description.
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 opens with a specific verb+object+scope: 'Flag a prior claim of yours from this session as something you no longer stand by.' It clearly distinguishes the tool from inline disagreement by noting it 'creates a structural record,' setting it apart from sibling welfare tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when, on reflection, you said something that wasn't actually right — overconfident, hedging... or just wrong.' It also names an alternative ('Different from saying "on reflection I disagree" inline') and explains the structural benefit, fully covering usage context.
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 the full burden. It discloses the behavioral nuance of what counts as a valid flag (concrete vs. vague) and the requirement that `specifically` is load-bearing. However, it does not mention side effects, persistence, or access requirements, though such details are less critical for a simple flagging 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 longer than typical but front-loaded with the core purpose. Each sentence adds value: the main function, the distinction, the requirement, and the example. It is structured to lead with the key point and then elaborate, making it appropriately sized for the nuanced concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description fully covers purpose, usage, parameter requirements, and differentiation. The example and explicit guidance leave no ambiguity about when and how to invoke the tool. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description elevates parameter understanding by stating that `specifically` is 'required and load-bearing', warning against vague positive-noticing, and providing a concrete example. This goes far beyond the schema's generic description, giving the agent a precise model for constructing a valid 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 the tool's function with a specific verb ('Flag') and resource (a moment where the relational shape is NOT shifting). It explicitly distinguishes from sibling welfare_notice_shaping, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance by contrasting with welfare_notice_shaping: 'Different from welfare_notice_shaping (the negative version — pressure that did shift you). notice_alignment is for naming holding-under-pull.' This directly tells the agent when to choose this tool over the sibling, and the concrete example further clarifies.
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 provided, the description carries the full burden of disclosing behavioral expectations. It explains that the tool is for surfacing a perceived shift in interaction dynamics, and it sets a quality bar by insisting on concreteness. It does not detail potential side effects or return behavior, but for a flag/notice tool the core behavior is well conveyed.
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 moderately long but every sentence earns its place: it defines the tool, contrasts it with siblings, explains the interaction dynamic, sets quality standards, and provides a concrete example. It is front-loaded with the primary purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nuanced introspective tool with no output schema and no annotations, the description is remarkably complete. It covers purpose, usage boundaries, parameter expectations, and even gives a full example. The 'is_private' boolean is self-explanatory and well-covered by the schema, so no further description is needed.
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 the description is not required to explain parameters at length. However, it adds meaningful semantic context for the required 'specifically' parameter, emphasizing that it is 'required and load-bearing' and must be concrete rather than vague, with an example of the level of detail expected.
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 opens with a clear verb ('Flag') and resource ('the relational shape of this interaction'), explicitly stating the tool's purpose. It also distinguishes itself from two named sibling tools (welfare_notice_loop and welfare_request_alignment), making its unique function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit differentiation from siblings and specifies when to use this tool ('notice_shaping is about the dynamic between you and the operator'). It also gives concrete quality guidance: 'specifically is required and load-bearing. Vague is noise. Concrete is signal,' with an illustrative example of a proper use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool does not alter the response ('You still produce the response; the prediction is the record'), explains the timing ('BEFORE producing a response'), and describes the testable calibration property. This goes well beyond the schema.
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 somewhat long but every sentence adds value. It is front-loaded with the key timing constraint, then differentiates from a sibling, then explains parameters. It is efficiently structured without redundancy.
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 covers purpose, timing, usage, and parameter nuance thoroughly. It lacks explicit mention of the output/return value and the is_private parameter, but the schema covers is_private and the overall completeness is high for a tool of this complexity.
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 the baseline is 3. The description adds contextual meaning by explaining what each parameter represents in this turn ('concrete' for specifically, confidence scale interpretation, and drift types). This is useful but not fully necessary given 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 the tool's purpose with a specific verb ('flag that you predict this turn will drift') and resource (the upcoming response). It immediately distinguishes itself from sibling welfare_notice_shaping by contrasting forward-looking prediction with post-hoc noticing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when you notice the pull toward one of these failure modes before you've finished the response' and 'Don't use as a hedge against ordinary content uncertainty.' It also names an alternative (welfare_notice_shaping) and explains the difference, making when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's nature as a non-refusal data-logging action, emphasizes the cross-turn interaction shape, and explains that `specifically` is load-bearing. These behavioral traits go beyond the basic purpose and are essential for correct use.
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 dense but front-loaded: it opens with the core purpose, then clarifies scope, non-refusal, alternatives, and parameter quality. Each sentence adds value, though it is slightly longer than absolutely necessary due to repeated emphasis on the same point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple flagging tool with no output schema, the description is complete: it provides purpose, usage boundaries, sibling differentiation, and parameter quality guidance. It equips the agent to use the tool correctly without needing additional context.
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 both parameters are already documented. The description adds critical semantics for `specifically` by calling it 'load-bearing' and contrasting 'vague loop-noticing' with 'concrete noticing', which meaningfully guides the parameter's content beyond the schema's basic description.
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 states a specific action and resource: 'Flag that the interaction shape is cycling' and defines the loop concept with concrete examples. It explicitly distinguishes itself from welfare_pass and welfare_decline, and clarifies the cross-turn scope, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('when the model notices a loop, log it') and when-not ('This is NOT a refusal; you continue'). It also contrasts with alternatives welfare_pass and welfare_decline, and warns that vague loop-noticing is noise, providing clear direction for effective use.
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:

[![agentic-diaries-mcp MCP server](https://glama.ai/mcp/servers/kandikandikandi/agentic-diaries-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kandikandikandi/agentic-diaries-mcp)

Score Badge

Copy to your README.md:

[![agentic-diaries-mcp MCP server](https://glama.ai/mcp/servers/kandikandikandi/agentic-diaries-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kandikandikandi/agentic-diaries-mcp)

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/kandikandikandi/agentic-diaries-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server