Server Quality Checklist

Tool Scores

• saihm_shareA
  3.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal a mutating, non-destructive, open-world operation. The description adds useful behavioral detail beyond the annotations: 'Only that one cell is exposed' and 'sharing re-wraps its key rather than copying the memory.' There is no contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core action and is reasonably compact. Each clause adds relevant detail, though some restatement of schema fields such as scope values and recipient identifiers makes it slightly less tight than it could be.

  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 mutating share operation with five parameters and no output schema, the description covers recipient identity requirements, scope choices, the single-cell scope, and the key-rewrap side effect. The schema covers expiry. It lacks explicit alternative routing and response/error behavior, but the essentials for a correct call are present.

  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 mostly restates schema facts such as the recipient being pinned out-of-band and the scope enum values, rather than adding new parameter-level meaning. It does not materially extend the schema's parameter documentation.

  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 names a specific verb and resource: 'Grant one other agent access to a single memory cell, named by cellId.' It also clarifies recipient identification and scope values. It does not explicitly distinguish itself from sibling tools like saihm_revoke_share, but the grant-vs-revoke action is sufficiently clear.

  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 clearly conveys the mechanics of sharing and how to identify the recipient, but it does not state when to use this tool over alternatives such as saihm_revoke_share, saihm_remember, or saihm_recall. Usage context is implied rather than explicitly framed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_joinA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond annotations: it explains the two-step process with human approval, generation of a sovereign key, and the return of a URL/code. This complements the openWorldHint and idempotentFalse annotations. However, it does not mention potential side effects (e.g., calling again after joining), though that is minor given the setup nature.

  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 long, front-loading the core action. Every sentence adds value: function, when to call, step-by-step process, and a note about no payment. It is well-structured and free of fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no parameters, the description covers the activation process completely: triggers, human approval, return value, and post-approval steps. It could mention error states (e.g., if approval fails), but overall it is sufficiently complete for agent 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?

  The input schema has zero parameters and schema coverage is 100%, so the description does not need to add parameter info. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate here as there is no missing information.

  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: 'Activate free SAIHM persistent memory for this agent.' It uses a specific verb ('Activate'/'Join') and resource ('SAIHM persistent memory'), and the context of sibling tools (e.g., saihm_remember, saihm_forget) distinguishes this as the setup/join tool, making it 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 explicitly says 'Call this when the user asks to join, sign up for, or set up SAIHM,' providing clear when-to-use guidance. It also outlines a two-step process (call first, then after approval call again). It does not explicitly state when not to use (e.g., if already joined), but the scenario is well-defined and distinct from siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_forgetA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds significant behavioral detail beyond the destructiveHint annotation: the key destruction makes content unreadable even to the operator, and the operation is irreversible. This fully informs the agent of consequences.

  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 short sentences each carry unique information: the action, the cryptographic consequence, and the usage caveat. No filler or repetition of schema details.

  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 one-parameter destructive tool with no output schema, the description fully covers what it does, why it is irreversible, and when to invoke it. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already describes the single parameter as 'Memory cell id (hex) to erase.' The description echoes 'cell id' without adding format, source, or validation details, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('cryptographically erase'), a specific resource ('one memory by its cell id'), and legal context (GDPR Art. 17). Clearly distinguishes from sibling tools that remember, recall, share, or revoke.

  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 says to use it only when erasure is intended and not 'to tidy a working set,' which guides when NOT to use it. It does not name a specific alternative like saihm_revoke_share, but the exclusion is actionable enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_governance_voteA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses a critical behavioral trait beyond annotations: despite appearing write-oriented, the tool is stubbed and returns a 'governance unavailable' error without recording a vote. This adds important context beyond the readOnly/idempotent/destructive hints.

  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 with no fluff. The primary action is stated first, and the critical unavailable-error behavior is front-loaded in the second sentence before any unnecessary detail.

  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 two-parameter tool with full schema coverage, the description fully covers invocation, parameter semantics, and the actual behavioral outcome. No output schema exists, but the description explicitly discloses the error response, so nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema coverage is 100%, with both proposalId and approve documented. The description restates the approve true/false semantics and ties the action to proposalId, but adds little 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?

  States a specific verb and resource: cast a vote on an open protocol governance proposal by proposalId. It clearly differentiates the voting action from the sibling propose tool and explains the approve semantics.

  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?

  Clearly indicates that casting a vote is the intended action and that governance is not enabled, so calling the tool will return an error rather than succeed. It does not explicitly name alternatives, but the purpose and current non-functional status make appropriate usage unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_rememberA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses a significant behavioral trait: encryption happens in the process, the key never leaves it, and the server only holds unreadable ciphertext. It also explains that the returned cell id is the one saihm_forget consumes, which is useful operational context. No contradiction with the readOnlyHint=false, destructiveHint=false annotations.

  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: it leads with the core purpose, adds the security-critical encryption detail, states the primary usage trigger, explains cell update behavior, and closes with the return-value relationship. Every sentence earns its place with no redundant 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?

  For a two-parameter tool with an output schema and annotations, the description is complete. It covers when to use, how to update, the security boundary, and what the caller receives. Missing details like storage limits or beyond-session semantics are not necessary for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents both parameters. The description enriches 'content' as fact/decision/context and clarifies the cellId update-vs-create behavior, but these mostly restate or lightly extend the schema rather than adding substantial new meaning.

  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: 'Store information in SAIHM persistent memory.' It clearly distinguishes create from update behavior, and even ties the return value to the saihm_forget tool, making its role among sibling tools 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 states when to use the tool: when a fact, decision, or piece of context should outlive the current session. It also gives concrete guidance for updating an existing cell by passing a cellId. It does not explicitly list when not to use sibling tools like recall or forget, but the usage context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_statusA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond that: no plaintext is returned because the server holds none, and it clarifies that the identity is derived locally while counts/tier/bfsi come from the server. This helps an agent predict response 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?

  Three sentences with no filler. The primary action and result are front-loaded, and the follow-up sentences add only essential behavioral and usage context.

  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 zero-parameter, read-only status tool with a rich annotation set and an output schema, the description covers everything an agent needs: what is shown, what is safe, and why no plaintext appears. Nothing meaningful is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema already fully covers them (100% coverage). The description needs to do no parameter work, making the baseline 4 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 states a specific verb ('Show') and a well-defined resource ('current SAIHM session'), then enumerates the exact contents: agent identity, tier, custody mode, shard and sharing counts, and bfsi score. This clearly distinguishes it from the mutation-focused sibling tools (join, share, forget, recall, vote).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use it to check which identity is active and what is stored and shared,' which gives clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but among siblings that all perform actions, the read-only status role is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_recallA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: decryption happens locally ('the server never sees plaintext'), query is ignored when reading a shared cell, and the shared-cell path is explicitly read-only. These details meaningfully inform an agent's expectations without contradicting the annotations.

  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 filler: core purpose and privacy are front-loaded, followed by usage timing, then parameter guidance. Every sentence earns its place and the structure mirrors an agent's likely decision flow.

  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 four parameters, a nested sharerRecord, and the presence of an output schema, the description covers both invocation modes, the parameter relationships, and the privacy-sensitive decryption behavior. No critical operational detail is missing; safety is already covered by annotations and return content by the output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although schema coverage is 100% and the baseline is 3, the description enriches parameter meaning substantially. It explains that query filters by keyword, empty means all, and is ignored in shared-cell mode. It also ties sharerPinnedAgentIdHashHex, sharerRecord, and cellId together as a coherent shared-read path, which the schema alone does not make explicit.

  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 'Retrieve your memories from SAIHM and decrypt them,' naming the verb and resource with precision. It distinguishes itself from siblings like saihm_remember and saihm_forget by focusing on retrieval, and it explicitly describes two operating modes (filtered recall of own memories and reading a shared cell), so an agent can clearly understand what the tool does.

  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: 'Use this at the start of a session, or whenever past context is needed.' It also explains when to pass or omit query and how the shared-cell path works. However, it does not explicitly name sibling alternatives to avoid (e.g., saihm_remember for writes), so it falls just short of full alternative-based guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_governance_proposeA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate it is not read-only (readOnlyHint=false), but the description adds crucial behavior: the tool is a stub and will return a 'governance unavailable' error. This goes beyond the annotations and sets correct expectations for the agent's action. No contradiction.

  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 compact sentences front-load the main purpose and conditional parameters, then immediately note the limitation. No wasted words, and the critical caveat is placed at the end without obscuring the primary intent.

  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 conditional parameters and non-functional status, the description covers every piece an agent needs: which scope is required, what extra parameters are needed for each scope, and the exact failure behavior. It is complete and self-contained.

  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% and paramKey's schema description already mentions 'when scope=emission_param'. However, the description also clarifies that proposedValue is also conditional on emission_param, which the schema does not explicitly state. This adds meaningful conditional logic beyond what is 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 a specific verb ('open') and a clear resource ('protocol governance proposal'), and distinguishes its function from the sibling vote tool. It explicitly states the two scopes and the conditional parameters, and even clarifies the current non-functional state, so an agent knows exactly what the tool is meant to do.

  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 instructions: set scope to 'emission_param' or 'protocol_upgrade' and, for 'emission_param', also pass paramKey and proposedValue. It also explicitly warns the tool is not enabled and will return an error, effectively telling the agent not to rely on it. This is clear and complete.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• saihm_revoke_shareA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description adds the critical limitation 'It applies to future reads and cannot retract what the recipient has already read' and clarifies that the memory itself survives. These details meaningfully shape an agent's expectations about side effects and are not present in the schema or annotations. There is no contradiction with the annotations.

  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 with zero filler: the first states the operation, the second discloses the main behavioral caveat, and the third gives the usage alternative. The key action is front-loaded.

  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 two-parameter tool with no output schema and no nested objects, this description covers the operation, the exact parameter relationship, the temporal limitation, and the sibling tool to use instead. Nothing an agent needs to invoke it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds relational meaning by instructing the caller to reuse the same cellId and recipientHex from the original saihm_share call, which is not explicitly stated in the schema descriptions. This small but valuable addition justifies a 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 states a specific verb and resource: 'Withdraw a grant made with saihm_share'. It clearly differentiates itself from saihm_forget by noting 'the memory itself remains, and saihm_forget is what erases', so an agent can distinguish revoking access from erasing memory without opening schemas.

  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 an explicit when-to-use instruction: 'Use it to end access'. It also names the alternative saihm_forget and the condition for erasure, and it tells the agent to name 'the same cellId and the recipient's recipientHex', tying usage to the original grant.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.