(S)AGE

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v11.19.0
Disambiguation3/5
Several tools overlap in the messaging and memory domains: sage_inbox and sage_messages_receive both claim inbound messages, and sage_message_replies overlaps with sage_inbox.reply_items. The descriptions are detailed and distinct, but an agent may struggle to pick the right tool for receiving vs. browsing messages. Core memory operations are well separated, but the boundaries are not always obvious.
Naming Consistency2/5
All tools share the 'sage_' prefix, but the remainder uses a mix of conventions: verb-first (sage_rename, sage_forget), noun-only (sage_inbox, sage_directory), and noun-verb (sage_message_send, sage_scope_get). This inconsistency makes it harder to predict tool names from their function.
Tool Count2/5
With 32 tools, the server is much larger than the recommended 3-15 range. While the broad scope (memory, messaging, governance, identity, tasks) justifies some size, the sheer number makes navigation heavy and increases the chance of choosing the wrong tool. The count crosses the 'too many' threshold.
Completeness4/5
The tool surface covers the full lifecycle for memories (create, read, update via replacement, delete), messaging (send, receive, reply, status, history), governance (propose, vote, status), tasks (create/update, backlog), and identity (register, rename, status, domains). Minor gaps include no direct get-memory-by-ID tool and no message deletion, but these are workable.
Average 4.3/5 across 32 of 32 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 19 of 19 community issues answered or closed in the last 6 months
- 785 commits in the last 12 weeks
- Last stable release on August 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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 must carry the transparency burden. It does disclose nuanced domain behavior, including that explicit domains are never remapped and that omitted domains resolve to the authenticated home domain in app-v23. That said, it mostly repeats schema-level domain details and does not describe return shape, pagination behavior, or side-effect expectations.
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 primary purpose. The only minor inefficiency is duplicating domain behavior details that are already expressed in the input schema.
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?
For a tool with 6 parameters, no annotations, and no output schema, this description provides a solid but incomplete picture. It explains the domain nuance well, but it does not clarify what kind of results are returned, how filters interact, or when a sibling tool would be preferable.
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 83%, so the baseline is 3. The description does not add meaningful parameter semantics beyond the schema: the domain behavior in the description already exists in the domain parameter description, and other fields like tag, status, offset, and limit are already well-documented.
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 leads with a clear verb and resource: 'Browse memories with filters.' This makes the tool's core purpose obvious. However, it does not explicitly distinguish it from sibling tools such as sage_recall or sage_timeline, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context around domain-omission behavior, especially the app-v23 versus pre-v23 difference. However, it never explicitly says when to use sage_list over its sibling tools or when not to use it; the usage guidance is implied rather than stated.
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 discloses the store action and domain handling, but it repeats schema details (domain omitting behavior) rather than adding new behavioral context such as overwrite/append semantics, permissions, or return values. The research claim about Paper 4 does not aid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description contains a substantial motivational paragraph about Paper 4 and Spearman rho that is not actionable for tool selection or invocation. The first two sentences are useful, but the 'feedback loop is critical' portion and the statistical evidence do not earn their place, making the description padded and less concise.
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?
For a 4-parameter tool with no output schema and no annotations, the description provides the essential timing (after significant tasks) and the key domain behavior. However, it omits any mention of return values, potential side effects, or how this reflection integrates with other memory tools, leaving some context gaps. The irrelevant research paragraph also detracts from completeness.
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%, so the baseline is 3. The description only rephrases the dos/donts concept already present in the schema, adding no extra meaning about parameter formats, constraints, or examples. It does not enhance the agent's understanding beyond what the schema already provides.
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 ('store') and resource ('dos' and 'donts' as a reflection). It distinguishes itself from siblings by framing it as 'End-of-task reflection' and indicating it captures both successes and failures, which is unique among the sage_* tools.
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 timing guidance: 'Call this after completing a significant task.' It also explains domain behavior with 'When domain is omitted...' and 'an explicit domain is never remapped.' However, it does not mention when not to use this tool or explicitly compare it to alternative memory tools like sage_remember, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the admin role requirement but does not describe side effects, irreversibility, fees, or failure modes. For a mutation tool that submits proposals, more behavioral context is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no unnecessary words. It front-loads the purpose, then explains operation distinctions, and ends with the prerequisite. Every sentence adds value, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, nested objects, no output schema, and no annotations, the description covers the basics but lacks details on proposal lifecycle, scope object structure (beyond 'guided'), and post-submission behavior. It is adequate but not 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 coverage is 100%, so baseline is 3. The description adds value by explaining that validator-set operations use scalar fields and scope_action uses a guided scope object, which helps agents understand parameter usage beyond what the schema provides. This justifies a score of 4.
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 'Submit a governance proposal.' It distinguishes between two operation families (validator-set ops with scalar fields, scope_action with guided scope object) and mentions the admin role requirement, which is specific and helps differentiate from sibling tools like sage_gov_vote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance by differentiating operation types and stating the admin role prerequisite, but it lacks explicit when-to-use or when-not-to-use instructions relative to alternatives. No exclusions or comparisons to sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation by using 'check', but does not explicitly state it is non-destructive or require permissions. Output behavior is partially described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and key details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with one optional parameter, the description adequately covers purpose and return value. Minor improvement could be clarifying behavior when proposal_id is provided vs omitted, but it is already implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and clearly explains the parameter. The tool description adds no new meaning beyond the schema, only restating the behavior.
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 checks governance proposal status and specifies the output (active proposal, vote tally, quorum progress). It is distinct from sibling governance tools like sage_gov_propose and sage_gov_vote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking proposal status but does not provide explicit guidance on when to use this tool versus siblings or when not to use it.
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, description carries burden. It discloses state modification and authorization context, but lacks details on side effects, error conditions, or success/failure behavior.
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: first states core action, second adds critical authorization context. No wasted words, well-structured and front-loaded.
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 simple schema and no output schema, description explains operation and authorization well. Could be improved by noting prerequisites (e.g., memory must be challenged) and return behavior.
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?
Both parameters have descriptions in schema; description adds no extra meaning beyond what schema already provides. Baseline 3 is appropriate.
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?
Description clearly states the tool withdraws/resolves challenges and returns memory to committed. It distinguishes between legacy v17 and new v21 authorization, but does not explicitly contrast with sibling tools.
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 guidance on when to use (withdraw/resolve challenges) and includes authorization requirements for two app versions. Does not cover when not to use or compare with alternatives.
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 transparency burden. It discloses the 31-day maximum span constraint, which is a useful behavioral trait. However, it doesn't explain how 'time buckets' are determined or what the response contains, leaving some ambiguity about the tool's behavior.
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 exceptionally concise—two sentences—and front-loads the core purpose while embedding the key constraint. Every word adds value, with no fluff or repetition.
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 retrieval tool with 3 optional parameters and no output schema, the description covers the essential context. It could benefit from clarifying 'time buckets' and the nature of the returned data, but the lack of a defined output schema lowers the bar. This is a minor gap.
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?
With 100% schema description coverage, the baseline is 3. The description adds minimal parameter-level context beyond the schema: 'grouped by time buckets' gives some hint about how the time range is processed, but it doesn't clarify the format, defaults, or interactions between 'from' and 'to'. The schema already documents formats and the 31-day limit, so the description adds little extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get memories in a time range, grouped by time buckets.' It uses a specific verb ('Get') and resource ('memories') with scope ('in a time range'). While it doesn't explicitly contrast with siblings like 'sage_recall', the time-based grouping is a distinctive feature that aids differentiation.
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 usage context: 'Use this to see memory activity over time.' This implies when to use the tool. However, it stops short of explicitly stating when NOT to use it or naming alternatives, which would be needed for a 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 are provided, so the description must carry the burden. It explains the action and precondition but does not disclose return values, side effects (e.g., whether the vote can be changed), or required authentication beyond being a validator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with purpose, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema or annotations, the description is minimal. It covers the core purpose but lacks details on return behavior, potential errors, or idempotency, which are important for a governance 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 coverage is 100% with clear parameter descriptions, so the description adds minimal value beyond schema, only providing the validator precondition context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('vote'), the resource ('active governance proposal'), and a key precondition ('only validators can vote'). This distinguishes it from sibling tools like sage_gov_propose and sage_gov_status.
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 specifies that only validators can vote, giving clear context for when to use. However, it does not explicitly mention when not to use or name alternative tools for other governance actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the trust signal mechanism and the self-corroboration restriction, but does not disclose return values, side effects, permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value: action and purpose, conceptual explanation, and a key constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description explains the tool's role in multi-agent consensus reasonably well. It lacks information about return behavior or state changes, but parameter coverage is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both parameters have descriptions. The description adds context about corroboration but does not elaborate beyond the schema for evidence or memory_id. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('corroborate an existing memory') and the resource (memory). It distinguishes from sibling tools by explaining it is a multi-agent trust signal and that a node cannot corroborate its own memory.
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 specifies when to use it: to independently back a memory verified or observed from a second source. It explains the transition from attributed to consensus. It does not explicitly exclude scenarios or name alternatives, but the context is 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, the description fully carries the behavioral disclosure burden. It reveals atomicity, compare-and-swap semantics ('expected from_session_id is a compare-and-swap fence'), failure behavior ('fails visibly instead of duplicating ownership'), and legacy handling ('never stolen automatically'). This is substantial non-obvious context.
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 sentences with a clear front-loaded purpose statement. Each sentence serves a distinct role: core action, concurrency semantics, and legacy caveat. No redundant wording.
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 thoroughly explains the core behavior, concurrency edge cases, and legacy requirements, which is impressive given the absence of annotations and output schema. However, it does not clarify success return values or explicit failure response formats, and it subtly assumes the agent can find message_id via sage_message_history. These are minor gaps 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.
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 adds meaningful detail for from_session_id by explaining its compare-and-swap role and referencing sage_message_history as the source. However, message_id is only implied as the message to transfer; there is no guidance on how to locate or format it. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Atomically transfer one claimed local or inbound federated message from the claimant_session_id shown by sage_message_history to this MCP session.' This is a specific verb+resource+destination and is distinct from sibling tools like send/reply/status, though it does not name alternatives explicitly.
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 clear context for when to use it: when a message is claimed by another session and needs to be transferred to this session. It also notes a specific requirement for legacy federated claims: 'still require this explicit handoff.' However, it lacks explicit when-not-to-use or alternative tool references, preventing a 5.
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 full burden. It discloses that only tasks assigned to this agent ID are returned, no unassigned or other agents' work, and across domains. This is adequate for a simple read operation, though some details like pagination or ordering are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence provides unique value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, no output schema, and no annotations, the description covers purpose, scope, and usage context adequately. It could add more detail on return format or handling of empty results, but it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no extra meaning beyond the schema's own description ('Filter by domain (omit for all domains)'). The parameter is straightforward and well-documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'View' and resource 'open tasks explicitly assigned to this agent ID across domains', and explicitly distinguishes from siblings by noting it never returns unassigned or other agents' work.
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 usage context: 'Use this to see what's been discussed but not yet done, review priorities, and avoid losing track of ideas across sessions.' It does not explicitly state when not to use it or contrast with alternatives, but the context is sufficient.
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 transparency burden. It clearly discloses read-only and caller-filtered behavior, distinguishes between vetted and candidate domains, and notes that mutations are operator-only. The parameter schema adds pagination behavior. It does not describe return format, but given the safety and scope disclosures, it is well above minimal viability.
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 sentences long with every sentence adding crucial context: purpose, eligibility caveats, and safety constraints. It is front-loaded with the primary action and contains no filler or redundant wording.
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 discovery role, it covers the essential aspects: what can be discovered, nuances of eligibility, caller filtering, and the operator-only boundary. The schema handles pagination. Without an output schema, a description of the return structure would be helpful, but the info provided is sufficient for an agent to use the tool safely and decide next steps.
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?
There is only one optional parameter (peer_cursor) and the schema description is 100% detailed, explaining the opaque bounded-page continuation and the fact that MCP never auto-walks pages. The tool description does not add further parameter-level meaning, so the baseline of 3 applies since the schema already carries the semantics.
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 'Discover' and enumerates clear resources: connected SAGEs, remote agents, copy offers, and caller domain authorization. This clearly distinguishes it from sibling tools focused on scope, governance, or messaging.
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 contextual guidance: it explains which domains are eligible for federated recall (shared_read_domains) and warns that read_candidate_domains require further authorization checks. It also states that operating on these resources requires operator-only actions, implicitly telling the agent not to attempt mutations here. It does not explicitly name alternative tools, but it clearly delineates when this discovery tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions deprecation but does not clarify what 'deprecate' entails (e.g., soft delete, irreversibility, permissions). The procedural hint for corrections is helpful but behavioral details about the action itself are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the primary purpose, the second adds critical usage guidance. Efficiently front-loaded with the most important information.
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 tool is simple with 2 parameters and no output schema. The description covers purpose and usage guidelines but lacks details on what 'deprecate' means (e.g., can it be undone, any side effects?). Given the simplicity, a minor gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add meaning beyond the schema; 'memory ID to deprecate' mirrors the schema. No additional context like format or constraints is provided. Baseline 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 action ('Deprecate a memory by ID') and the resource ('memory'). It distinguishes from sibling tools like sage_remember by specifying that for corrections, one should call sage_remember first. The verb 'deprecate' is specific and matches the tool name.
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 no replacement is needed') and when not to use ('never call this first' for corrections). Provides clear alternative: call sage_remember with replaces_memory_id. This helps the agent select the correct tool.
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 burden of explaining side effects. It discloses that the claimant session is checked in the same transaction and that retries are idempotent while conflicting replies occur, which is valuable. However, it does not specify what happens on conflict (error? overwrite?) or other potential side effects, so it is not fully transparent.
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 (two sentences) and front-loaded with the purpose, then adds key behavioral details. Every sentence adds value; no fluff or 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?
Given the tool's simplicity (2 params, no output schema), the description covers the main aspects: input source, idempotency, and transaction completion. It does not describe return values, but there is no output schema to supplement, so it is reasonably complete for the context. Could mention conflict handling or failure modes, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (result is described as 'Untrusted result data returned to the sender', message_id lacks a schema description). The description adds that message_id comes from specific tools and that the result is untrusted, but it does not elaborate on formats or constraints beyond the schema. It partially compensates for the missing schema description but not fully.
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: 'Reply to one receiver-local or inbound federated message_id returned by sage_messages_receive or sage_inbox.' It specifies the action (reply), the resource (message), and differentiates from sibling tools like sage_message_send and sage_message_replies by focusing on replying to received messages.
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 mentions that the message IDs come from specific tools (sage_messages_receive or sage_inbox), guiding the user on the appropriate input source. It also describes idempotency and conflict conditions, helping users understand retry behavior. However, it does not explicitly list alternative tools or when to use them, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job disclosing the type of information returned (delivery, read confirmation, workflow state) and explicitly excluding presence/last-seen/comprehension. It could add more about error cases or what happens if the message doesn't exist, but the core behavioral traits are transparent.
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: the first sentence states the full purpose, and the second clarifies what it is not. Every clause earns its place, with no wasted words or 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?
For a simple tool with a single parameter and no output schema, the description sufficiently explains the informational content (delivery, read confirmation, workflow state) and the scoping constraint. It could be more complete by describing edge cases like non-existent messages or permissions, but it is still well above the minimum for selecting the 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 schema only provides a generic 'message_id' string with no description (0% coverage). The description adds meaningful context by stating the message must be 'one exact message sent by this caller,' which clarifies the ID's expected scope. However, it doesn't explain how to obtain the message_id or its format, leaving some 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 is specific and action-oriented: 'Inspect' the delivery, read confirmation, and workflow state for a single exact message. It distinguishes itself from other status-like tools by explicitly stating it is not presence, last-seen, or comprehension evidence, which differentiates it from siblings like sage_status or sage_pipe_receipt_status.
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 clearly scopes usage to 'one exact message sent by this caller,' implying it is for the user's own outgoing messages. The negative clause 'not presence, last-seen, or comprehension evidence' provides exclusions but does not explicitly name alternative tools, so the guidance is mostly implied rather than explicit.
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. It discloses that the tool only renames the agent itself (self-only) and does not change the permanent registration name or agent_id. It also specifies the behavior of the boot_bio parameter (preserved if omitted, replaced if provided). This adequately covers the behavioral traits for a rename operation.
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 concise with five sentences, each adding value. It is front-loaded with the main purpose, then provides context, constraints, and parameter behavior. No superfluous words or 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?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description is largely complete. It covers what the tool does, constraints, and parameter behavior. One minor gap: it does not mention if display names must be unique, but this is not critical for basic understanding.
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 describes both parameters with 100% coverage. The description's additional text on boot_bio ('Omitting boot_bio preserves your existing bio; passing it replaces the bio') mirrors the schema description. Since schema_description_coverage is high, the baseline is 3, and the description adds no significant new meaning 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 verb 'rename' and the resource 'agent display name and bio'. It specifies that it sets the display name and optional bio that appears in the CEREBRUM dashboard and to other agents. This differentiates it from sibling tools like sage_register, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: to give a human-readable identity instead of a default provider/project name. It explicitly states 'Self-only: an agent can only rename itself' and clarifies that permanent registration name and agent_id never change. No explicit alternatives are given, but the self-only constraint provides clear usage boundaries.
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 provided, so burden falls on description. It discloses read operation, required access level (node-operator or admin), and the data returned (scope and drain state). Lacks error/empty result behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers key aspects: action, resource, identifier requirement, and access. Slightly lacking in error handling details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter having a clear description. The description adds 'exact canonical scope ID' which echoes the schema. Minimal added value, baseline 3.
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 verb 'Read' and specifies the resource 'canonical app-v20 quorum scope' with additional state details. It clearly distinguishes from sibling tools like sage_scope_list which likely handles listing.
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 indicates it is used 'by exact scope ID' and mentions access requirements, but does not explicitly state when to use this tool over alternatives or provide exclusions.
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 burden. It correctly implies a read-only list operation and specifies the returned fields, but does not disclose any side effects, rate limits, or potential errors. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the return fields and a permission requirement. There is no extraneous text.
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 parameterless tool, the description provides a complete list of the data returned and the access requirement. With no output schema, the description sufficiently covers what the agent needs to know.
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 tool has zero parameters, so the schema coverage is 100%. The description adds no parameter details but that is unnecessary. Baseline 4 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 specifies a clear action ('List') and resource ('canonical app-v20 quorum scopes'), and enumerates the returned data fields. This distinguishes it from sibling tools like sage_scope_get.
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 states the required access level ('node-operator or admin access'), providing guidance on when the tool can be used. It does not explicitly mention when not to use it or alternatives, but the permission requirement adds useful 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?
No annotations are provided, so the description carries full burden. It discloses that the link is directional (source → target), lists common link_type values, and notes that any short relation label is accepted. It does not mention permissions or error handling, but for a creation tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no redundancy. Every sentence adds useful context.
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 is complete for a straightforward creation tool. It explains purpose, usage, and parameter semantics. No output schema exists, but return value is not critical for this tool. Sibling tools are numerous but not relevant.
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 clarifying the directionality of source and target beyond the schema's 'from side' and 'to side', and explains that link_type can be any short relation label, not just the listed examples.
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 starts with a clear verb+resource: 'Create a typed relationship between two existing memories.' It explains the use case (building a knowledge graph) and distinguishes from siblings by focusing on linking memories, unlike other sage_* tools like sage_recall or sage_remember which do different operations.
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 states when to use this tool ('Use this to build a knowledge graph over memory') and gives concrete examples of relationship types. It does not explicitly mention when not to use or alternatives, but the context is clear enough for an AI agent.
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 annotation safety or read/write hints, the description carries the full burden. It discloses atomicity, token replay behavior, signing of one exact read acknowledgement, authoritative sender_agent field, and the important caveat that labels are non-authorizing metadata. This goes far beyond a superficial 'receives messages' description.
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 densely packs many important details, but it becomes a lengthy technical paragraph with winding clauses like 'legacy rows use the current display-name compatibility fallback for a missing saved registered name.' Every sentence contributes valuable information, but the phrasing is complex and harder to quickly parse than necessary.
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 lack of an output schema, the description goes a long way: it explains the returned message mechanics (authoritative sender, optional labels), replay semantics, and session/handoff behavior. It does not mention error cases, token expiration, or what happens if the token is reused after successful acknowledgment, but within the complexity of a receive/claim tool it is nearly 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?
Schema covers receive_token with a basic descriptor and limit with constraints but no prose. The description adds substantial semantic value by explaining receive_token's replay behavior and semantic nuance. Limit is only loosely implied by 'bounded batch,' but the name and schema constraints make its role reasonably clear. This could be stronger for limit examples, but overall it meaningfully enriches the primary parameter.
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 and resource: 'Receive and atomically claim one bounded local message batch.' It explains the core purpose (receiving/claiming messages) and includes distinctive semantics (replay with the same token, never claiming later messages) that clearly delineate what the tool does while differentiating it from generic receive tools.
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 usage context: reusing receive_token replays the original lost response, and concurrent runtimes should use sage_message_handoff for transferring ownership. This indicates when and how to use the tool in special situations, but it does not explicitly say 'when not to use' or compare directly to alternative receive-like siblings.
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 idempotency and notes that it returns an existing record if already registered. This adds behavioral context beyond the schema, though it could mention potential side effects like chain transactions or permissions.
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 with three sentences, each contributing meaning. It is front-loaded with the primary action and efficiently covers purpose, usage guidance, and idempotency 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?
Given the tool's simplicity (two parameters, no output schema, no annotations), the description covers key aspects: action, usage frequency, and idempotency. It could be improved by describing the return format or potential errors, but it remains adequate for effective 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% with descriptions for both parameters. The description adds value by explaining that the parameters form an on-chain identity and that boot_bio is optional, reinforcing the schema info. It does not introduce new parameter details but contextualizes them well.
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: registering the agent on the SAGE chain and creating an on-chain identity with a name and optional bio. It distinguishes from sibling tools by focusing on registration and noting it is normally called automatically.
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 guidance that the tool is rarely called manually because it is invoked automatically on first connection. It does not explicitly list alternatives or when not to use, but the context is clear enough for an agent to determine appropriate 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?
With no annotations provided, the description carries the full burden. It discloses that it 'checks if you already have stored memories and returns your operating instructions' and on a brand-new installation 'seeds starter memories about how to use the memory system effectively.' This explains key side effects and outputs, though it does not address idempotency or potential consequences of calling it multiple times.
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 action ('Initialize your persistent memory session'), then usage timing, then behavior. Every sentence adds unique value with no redundancy or fluff.
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 (no parameters, no output schema), the description is complete. It covers purpose, when to use, what happens on existing vs. new installs, and the return value ('returns your operating instructions'). No additional context 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?
The tool has 0 parameters and schema description coverage is 100%. Per the baseline for 0 parameters, a score of 4 is appropriate. The description adds no parameter-specific details because there are none to describe.
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 'Initialize' and resource 'persistent memory session', and clarifies scope as 'start of every new conversation with SAGE', distinguishing it from sibling tools like sage_remember or sage_recall. It clearly states what the tool does and its role in the system.
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?
Explicitly states when to call: 'Call this once at the start of every new conversation with SAGE.' This provides clear usage context. However, it does not explicitly mention when not to use it or name alternatives, though the context implies its exclusive role at conversation start.
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 and discloses important behaviors: results are stable, bounded, and cursor-paginated, with explicit continuation semantics (next_cursor until has_more false). It also clarifies the scope ('signed caller's authoritative current') but does not cover error cases or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second explains pagination, third gives alternative. No redundant wording, front-loaded, every 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?
Despite no output schema or annotations, the description covers key operational details (stable, bounded, pagination) and points to a sibling for related but distinct information. It is sufficiently complete for a list tool, though a note on the actual return fields (besides next_cursor/has_more) would be slightly stronger.
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% (both limit and cursor documented), but the description adds value by explaining cursor usage ('continue with next_cursor until has_more is false') which enriches the cursor parameter meaning beyond schema. Limit is not elaborated beyond defaults, but baseline 3 is exceeded.
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 lists the signed caller's authoritative current owned domains, using a specific verb and resource. It explicitly differentiates itself from reading a global roster or scanning memories, and references sibling tool sage_status for an alternative task.
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: 'Use sage_status for the cheap first policy sample of readable and writable domains' names an alternative and its use case. The opening also implies when this tool is appropriate (for authoritative owned domains without global scans).
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 well. It discloses retry behavior (original message_id returned, no duplicate), return-value behavior (inbox snapshot), the non-claiming nature of that snapshot, and the race condition it closes. This is rich behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and every clause earns its place: send semantics, idempotency behavior, find_agent prerequisite, and the inbox snapshot/race guidance. There is no filler or redundant repetition.
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 send tool with no output schema and no annotations, the description covers the essential operational context: how to address recipients, prerequisite resolution, idempotent retry, and successful-return behavior. It omits failure/error behavior and permission caveats, but the described success path is thorough enough for reliable 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics for idempotency_key by explaining exactly what happens on retry (original message_id returned instead of duplicate), which is not fully captured by the schema's 'reused only when retrying' phrasing.
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+resource: 'Idempotently send one exact local or federated agent message.' This clearly distinguishes it from siblings like sage_message_reply, sage_messages_receive, and sage_find_agent by emphasizing exact-send semantics and idempotency.
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 directs to use sage_find_agent first when only a human name is known, and explains when the inbox snapshot should be consulted. However, it does not explicitly state when to prefer sage_message_reply or when not to use this tool, so it stops just short of full when/when-not coverage.
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 reveals default local search, federated behavior with 'allowed live read', and caller-safe delegation. Could mention read-only nature more explicitly, but it's sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with zero waste. Each sentence adds essential information: purpose, federated usage, and prerequisite tool reference.
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 core functionality and federated mode well. Lacks description of return format, but parameter descriptions cover details. Adequate for a search tool with rich parameter descriptions.
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. Description adds value by explaining federated parameter usage and federate_chains workflow, going beyond parameter 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 searches memories by semantic similarity, with specific verb 'search' and resource 'memories'. It distinguishes from siblings like sage_federation (discovery) and other non-search 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 explains when to use federated mode (when a domain is shared) and directs to sibling sage_federation for discovery, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does an excellent job, revealing critical non-obvious behaviors: content is immutable, creation is permanently idempotent (repeating returns the original even after done/dropped), domain handling (explicit never remapped, omitted uses home domain), and persistence semantics. 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 relatively long but every sentence earns its place, covering purpose, usage modes, persistence, and idempotency. It is front-loaded with the core purpose and logically progresses to specific behaviors. The density is justified by the tool's complexity, though it could be slightly tighter or better structured with bullet points.
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 6 optional parameters, three distinct operation modes, and no output schema or annotations, this description is exceptionally complete. It covers all operation modes, key behavioral constraints, and edge cases (e.g., idempotency with done/dropped tasks). No critical operational information appears to be 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 description coverage is 100%, so baseline is 3. The description adds meaningful extra context: it explains the three usage modes that correspond to parameter combinations, clarifies the idempotency_key derivation and consequences, and elaborates on the domain default. This adds value beyond the schema's individual parameter 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+resource combination, 'Create or update a task in your persistent backlog,' and goes on to clarify the tool's unique value proposition: tasks are persistent memories that don't decay. It explicitly lists use cases ('planned work, feature ideas, bug reports, and anything that should survive across sessions'), distinguishing it from siblings like sage_remember or sage_message_reply.
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 usage instructions: create with content, update with memory_id+status, link with memory_id+link_to. It also states when to use the tool ('Use this to track...') and explains the idempotency behavior. However, it does not explicitly name alternative tools or state when *not* to use this tool, which would earn 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, the description carries full burden and does so thoroughly. It discloses atomic behavior, the payload-free message flag, federation checks, and the fact that domains are never silently remapped. It also clarifies it never claims or embeds message payloads, which is a key safety detail.
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 dense but well-structured, front-loading the critical 'every turn' directive and then logically breaking down the two atomic functions. Each sentence earns its place, covering behavior, message handling, federation, and domain rules 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?
Given the complexity and lack of an output schema, the description adequately covers return values like the message_inbox_unread flag and the recall purpose. It also explains federation miss behavior. However, the exact structure of recalled memories is not specified, which is a minor gap for a tool central to context building.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description largely mirrors the schema's parameter descriptions and does not add significant new semantic meaning beyond what is already in the schema. The only added nuance is emphasis on domain behavior, but it is already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a per-turn memory cycle combining recall and storage, with specific verbs and resources. It distinguishes itself from siblings like sage_recall and sage_remember by emphasizing the atomic dual action, and from sage_messages_receive by noting it never claims message payloads.
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 instructs 'Call this EVERY turn' and provides clear guidance on when to use the tool versus alternatives. It also gives concrete direction for domain omission and explicit domain usage, and references sage_messages_receive for message handling, making usage unambiguous.
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 fully discloses the tool's behavior. It states the local scope performs one metadata-only database read with no federation probes, and that scope=all adds live-revalidated federated contacts. It further clarifies this is authorization metadata, never online presence or read evidence, and notes that older peers are omitted in an incomplete federated view—providing rich behavioral context beyond structured fields.
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 four sentences, each with a distinct and necessary purpose: stating the core function, explaining scope behavior, listing output fields, and clarifying constraints/caveats. It is front-loaded with the primary purpose and contains no redundant or wasteful phrasing.
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?
The description thoroughly covers inputs (scope semantics), outputs (field list), and important caveats (incomplete federated view, authorization metadata). With schema fully describing the parameters, the combination is sufficient for an agent to invoke the tool correctly and interpret results, even without an output schema.
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 input schema covers 100% of parameters with descriptions for both scope and peer_cursor. The description adds practical semantics by explaining what each scope value does: local performs a metadata-only read with no federation probes, while all explicitly requests the local/federated union. This goes beyond the schema's enum 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 'List recipients this signed caller is currently authorized to address,' clearly stating the verb (list), resource (recipients), and scope (authorized, local/federated). It distinguishes from sibling tools like sage_find_agent by emphasizing authorization and provenance, even without naming alternatives explicitly.
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 for when to use the tool: to enumerate currently authorized recipients. It explains the default local scope versus explicitly requesting scope=all for federated contacts. However, it does not explicitly state exclusions or mention alternative sibling tools for similar operations.
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 fully carries the burden of behavioral disclosure. It details bounded substring matching, case-sensitivity rules, ranking of exact field matches, and the important caveat that an absent match does not prove an agent_id is unreachable. This goes well beyond a simple lookup description.
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 efficiently structured: it opens with purpose, then covers search behavior, the peer exception, return readiness, and finally exclusions/caveats. Every sentence contributes value with no redundancy, despite the complexity of the matching rules.
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 absence of annotations and output schema, the description is remarkably complete. It covers purpose, usage context, search semantics, the peer_chain alternative, and a critical limitation. The tool's role in preparation for sage_message_send is clear, and no missing context impedes 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%, and the input schema already provides detailed descriptions for all four parameters, including the matching rules and bounded continuation for peer_cursor. The description reinforces these but does not add new parameter-specific meaning beyond what the schema already offers, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Discover an active agent by a human name before sending a message.' It clearly distinguishes itself from siblings by stating 'This is not a global directory or an online/reachability check' and by naming the companion tool sage_message_send.
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 when-to-use guidance is provided ('before sending a message'), and the description explains when to set peer_chain instead of local search. It also gives an explicit alternative ('sage_message_send.to') and clarifies when the tool should not be used, such as for reachability checks.
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 of behavioral disclosure, and it excels: it explains conditional responses (active agents get memory counts; pending-review agents get approval state), states a safety constraint ('without probing forbidden memory routes'), and explicitly discloses what the tool never returns (roster, global node counts). This goes well beyond a basic 'get status' statement.
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 sentences, front-loaded with the core purpose, followed by conditional details and a negative guarantee. Every sentence earns its place, and there is no redundancy or filler.
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 parameters, no annotations, and no output schema, the description provides a remarkably complete picture: what is returned for different caller states, what is explicitly excluded, and a safety note. It is sufficient for an agent to invoke the tool and understand the response boundaries without needing more structured metadata.
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 tool has zero parameters, so the baseline is 4. The description adds context about the implicit 'signed caller' identity and the conditional behavior based on caller status, which is relevant to how the tool behaves but not required for parameter explanation. No parameter details are needed.
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 and resource: 'Get this signed caller's own registration and access standing.' It distinguishes itself from sibling tools by emphasizing 'own' status and explicitly noting it never returns a roster or global node counts, which separates it from broader status or listing tools.
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 for when to use the tool: when the caller needs their own registration/access standing, with conditional behavior for active vs. pending-review agents. It does not name alternative tools or provide explicit 'when not to use' guidance, but the scope is evident from the 'own status' framing and the exclusion of global data.
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 transparency burden and does so thoroughly: it covers claimed items, own_claimed_unfinished semantics, claimed_elsewhere_count handling, unsafe forward rejection, untrusted content warnings, sender identity rules, and pagination safety. It is far richer than a minimal 'check inbox' statement.
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 every sentence carries substantive content. However, it is a dense single wall of text; organizing the many caveats into separate paragraphs or bullets would improve scannability without losing information.
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?
Despite lacking an output schema, the description explains the important output categories (items, own_claimed_unfinished, claimed_elsewhere_count, reply_items, retained_reply_count), pagination behavior, and how to handle truncated pages and unsafe reply_since values. This is complete enough for an agent to invoke the tool correctly and interpret results safely.
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?
Input schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: reply_since inclusivity and deduplication, rejection of unsafe forward jumps, and the distinction between retained_reply_count and an unread queue. It does not add much for limit/reply_limit, but the added context for reply_since is valuable.
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: 'Check one bounded unified update surface for task assignments, messages sent to you, and passive replies.' It clearly distinguishes sage_inbox from siblings by naming alternatives such as sage_message_replies for backward paging and sage_backlog for verification.
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 polling guidance (pass reply_since, deduplicate by message_id), names alternatives for backward paging (sage_message_replies), and instructs when to use sage_message_history plus sage_message_handoff before taking over another session's work. It also states when verification in sage_backlog is needed, providing clear usage context.
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 and excels. It explicitly states the non-mutating nature ('without claiming, acknowledging, or re-queueing'), durability semantics ('Canonical Messages remain durable... only deprecated pipe rows use the legacy transient window'), untrusted payloads, and authorization caveat ('no label establishes authorization'). This gives the agent a robust safety and trust model.
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 average (seven sentences) but is well-structured and front-loaded with purpose and usage. The later sentences about identity and label provenance are dense but critical for correctly interpreting returned data. No sentence is wasted, though it leans verbose.
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?
Despite having no annotations or output schema, the description covers operational semantics, durability, security, identity authority, label fallback behavior, and folder-specific usage. It implies return fields like claimant_session_id and workflow state, making it complete enough 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 description coverage is 100%, so baseline is 3. The description adds meaningful context for the folder parameter by detailing inbox/outbox use cases and explaining that counterparty_agent is the authoritative identity. However, it adds no new semantics for the limit parameter beyond what the schema already provides.
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 first sentence, 'Browse your retained message inbox or outbox without claiming, acknowledging, or re-queueing a message,' clearly states a specific verb and resource, and actively differentiates it from siblings by noting what it does NOT do. It also references sage_message_handoff, distinguishing its role in the workflow.
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 maps folder values to concrete use cases: 'Use folder="inbox" to reopen a message after it was claimed or completed, inspect its claimant_session_id, or hand it to this runtime with sage_message_handoff; use folder="outbox" to revisit a message you sent and its workflow state.' This provides clear when-to-use guidance and context, eliminating ambiguity.
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 behavioral disclosure burden. It explains domain fallback behavior across node versions, the commit-then-challenge ordering for replacements, interruption safety guarantees, and fact/observation persistence across boundaries. This is rich, non-obvious behavioral detail.
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 each sentence adds value, from domain handling to replacement semantics to the IMPORTANT type guidance. It is on the longer side but not wasteful; a slight tightening would make it more succinct, yet the structure (normal flow, correction flow, type guidance) is logical.
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 tool with 7 parameters and no output schema, the description covers the critical contexts: domain omission behavior, replacement safety, and type usage. It does not mention return values or error conditions, but given the complexity and the absence of an output schema, the description adequately prepares an agent for invocation.
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?
Even though schema coverage is 100%, the description adds significant meaning beyond property descriptions. It explains what happens when 'domain' is omitted, the semantics of 'replaces_memory_id' including commit ordering and failure behavior, and elaborates type-specific confidence and persistence characteristics that are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Store a memory in SAGE', a clear verb+resource statement. It immediately distinguishes the tool from siblings like sage_forget and sage_recall by focusing on storing and by describing the replacement flow that avoids a separate forget call.
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 guidance is provided for when to use replacement ('instead of calling sage_forget first') and for choosing type='fact' vs 'observation' with specific examples. This goes beyond generic context to give actionable usage rules and alternatives.
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 provides extensive behavioral detail: passive and repeatable, claims/acknowledges/re-queues nothing, scope limited to signed identity, the replied_by vs addressed_to distinction, exact cursor copying requirements, and untrusted data warnings.
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?
Although lengthy, every sentence serves a purpose: purpose, safety, scoping, paging mechanics, and security. Dense but not redundant; the structural front-loading ensures the main action is clear immediately.
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 annotations and no output schema, the description covers all essential aspects: operational semantics, paging pitfalls, security stance, and explicit non-action guidance. It's a complete specification for correct invocation.
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?
The description clarifies `before`'s compound cursor format and warns against bare timestamps skipping same-millisecond replies; it also explains `since`'s inclusive boundary and deduplication, adding significant value beyond the schema's field 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 immediately identifies the tool as 'Read and page the replies recipients returned for messages YOU sent' and distinguishes it from sibling tools by naming sage_inbox.reply_items and sage_message_status's payload-free nature, making it clear this is the sender-side pager.
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?
It explicitly states its role relative to sage_inbox and sage_message_status, and further warns 'do not call sage_message_reply on anything returned here,' providing clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![sage MCP server](https://glama.ai/mcp/servers/l33tdawg/sage/badges/card.svg)](https://glama.ai/mcp/servers/l33tdawg/sage)

Score Badge

Copy to your README.md:

[![sage MCP server](https://glama.ai/mcp/servers/l33tdawg/sage/badges/score.svg)](https://glama.ai/mcp/servers/l33tdawg/sage)

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/l33tdawg/sage'

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