Server Quality Checklist

Tool Scores

• saihm_revoke_shareA
  3.8/5.0
  Behavior3/5

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

  Annotations already indicate idempotent, non-destructive, and read-write behavior. The description adds 'withdraw grantee's access' which confirms the action but does not elaborate on side effects, auth needs, or return values.

  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 the action, second gives usage guidance. No wasted words, 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?

  For a simple tool with 2 parameters, the description covers purpose and usage adequately, but lacks details on return values or confirmation of success/failure.

  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 both parameters are well-documented in the schema. The description does not add extra 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 'Revoke a prior share grant to a recipient for a cell', which is a specific verb and resource, and distinguishes from the sibling tool saihm_share which likely creates shares.

  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 says 'Use this to withdraw a grantee's access', which implies usage, but does not explicitly state when to use vs not use, nor provides alternatives or prerequisites.

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

• saihm_governance_voteA
  3.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a non-readonly, non-destructive, non-idempotent mutation. Description adds that it applies to 'open' proposals, implying constraints on valid proposal states. No further behavioral details (errors, side effects) are provided.

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

  Conciseness5/5

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

  Two concise sentences that front-load the purpose and provide usage guidance. No wasted words; every sentence earns its place.

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

  Completeness3/5

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

  The description covers the basic purpose and parameters, but lacks information about return values or possible error conditions (e.g., if already voted, proposal closed). For a simple mutation with no output schema, it is adequate but not 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% with clear descriptions for both parameters (proposalId hex, approve boolean). The description adds no additional parameter meaning beyond the schema. Baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the verb 'Cast a vote' on a specific resource 'open gSAIHM governance proposal' and specifies the action 'approve or reject'. It distinguishes from sibling tools like 'propose' and other non-governance 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?

  Explicitly states to use this tool to approve or reject an open proposal by proposalId. Provides clear context but doesn't explicitly mention when not to use (e.g., if proposal is closed) or contrast with alternatives beyond what sibling names imply.

  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/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's 'submit' is consistent. However, it adds no further behavioral context (e.g., whether a voting period starts, permissions needed, or outcome feedback). Given annotations cover basics, a 3 is appropriate.

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

  Conciseness5/5

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

  Two concise sentences, front-loaded with the verb and subject. No wasted words; each sentence adds essential 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 has no output schema, so the description could explain the result of a submission (e.g., 'creates a proposal and initiates voting'). It covers the core purpose and constraints well, but lacks return value details. Good overall.

  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 description need not add much. It reiterates the scope enum values, but provides no extra meaning beyond the schema. Baseline of 3 is correct.

  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 ('submit a gSAIHM governance proposal'), specifies the resource and scope constraints ('Scope MUST be emission_param or protocol_upgrade'), and explicitly distinguishes the tool from sibling saihm_governance_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 when to use the tool ('Use this to open a protocol governance vote') and mandates the scope values. It does not explicitly mention when not to use it or 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.

• saihm_shareA
  4.2/5.0
  Behavior4/5

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

  The description adds 'end-to-end authenticated' and 'out-of-band pinning' beyond the annotations. Annotations already note the tool is not read-only and not destructive. There is no contradiction, but the description does not detail side effects or concurrency 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 short sentences with no fluff. The first sentence front-loads the core action and authentication, the second clarifies usage. Every word earns its place.

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

  Completeness4/5

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

  For a tool with five parameters (including a nested object) and no output schema, the description covers the essential usage and security requirement. It does not describe return values, but the action is straightforward enough that an agent can infer output.

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

  Parameters3/5

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

  All five parameters have descriptions in the input schema (100% coverage). The description adds little beyond the schema, only implicitly mentioning cellId and recipient. Baseline 3 is appropriate as the schema already documents 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 clearly states the verb 'share' with the resource 'a cell' and specifies the action is 'end-to-end authenticated'. It distinguishes the tool from siblings by focusing on granting access, which contrasts with revoke_share, remember, etc.

  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 when to use the tool: 'grant another agent access to a specific memory'. It also mentions the prerequisite step 'Pin the grantee's agentIdHash out-of-band'. However, it does not explicitly state when not to use or list alternatives, though sibling tools imply other actions.

  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_rememberA
  4.4/5.0
  Behavior4/5

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

  Discloses persistence and encryption ('persistent encrypted memory sealed client-side'), adding value beyond annotations. Also mentions update behavior. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

  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 concise sentences; purpose is front-loaded, and every word adds value. No redundancy or filler.

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

  Completeness4/5

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

  Given output schema exists (as per context), description need not explain return values. It covers creation/update behavior adequately. Could mention error handling but not critical for a simple tool.

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

  Parameters4/5

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

  Schema provides full parameter descriptions, and description adds context about encryption and persistence. The description clarifies the purpose of the cellId parameter for updates, complementing 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?

  Clearly states verb (store), resource (information to persistent encrypted memory), and distinguishes from siblings (for persisting facts across sessions). Also mentions update capability, 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?

  Explicitly tells when to use (when a fact, decision, or context needs persistence across sessions). Does not explicitly state exclusions, but sibling context allows inference of alternatives like saihm_recall or saihm_forget.

  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 behavioral details beyond annotations: explains the cryptographic process, endpoint-side DEK destruction, and irreversible nature. Aligns with and extends destructiveHint=true and idempotentHint=true.

  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 wasted words. Front-loaded with the core action: 'Cryptographically erase a memory (GDPR Art. 17).' Efficient and clear.

  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?

  Complete for a single-parameter tool with full schema coverage and annotations. Explains purpose, effect, and usage directive. No gaps given the context.

  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 one parameter described as 'Memory cell id (hex) to erase.' Description only repeats 'by its cell id,' adding no new meaning beyond the schema. 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 tool cryptographically erases a memory (GDPR erasure) and destroys the DEK, which is a specific verb+resource. It distinguishes from siblings like remember, recall, share, etc., by focusing on deletion.

  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 'Use this only to permanently and irreversibly delete a memory by its cell id.' This gives clear direction on when to use, though it doesn't mention when not to use or alternatives, but is sufficient for a destructive tool.

  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=true, destructiveHint=false, idempotentHint=true. The description adds value by clarifying 'no plaintext' and enumerating the state aspects visible, which is beyond what annotations provide.

  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 contains no redundant information. Every word contributes to understanding.

  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 has no parameters, an output schema exists, and it is a simple status read, the description provides complete context: what it shows, that it's operator-observable, and the specific fields. No gaps.

  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?

  With no parameters and 100% schema coverage, the baseline is 4. The description adds no parameter information but explains the tool's purpose without needing parameters, which is sufficient.

  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 'Show' and the resource 'operator-observable session status', listing specific fields (tier, shards, sharing, BFSI, custody). This distinguishes it from sibling tools which are mutation or recall 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 says 'Use this to check...' providing clear usage context. It does not explicitly state when not to use, but the sibling tools (remember, forget, recall, etc.) imply this is for status checks only.

  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?

  Description adds client-side decryption, read-only nature for shared cells, and prerequisite sharing. Annotations already declare readOnlyHint, so description supplements without contradiction.

  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?

  Two sentences, front-loaded with primary use case. The second sentence is slightly lengthy but still clear and focused.

  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?

  With output schema present and full parameter descriptions, the description covers both use cases (own memory recall and shared cell reading) completely.

  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 detailed parameter descriptions. The tool description adds context about the combined usage for shared cells, but most semantics are already in schema.

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

  Purpose5/5

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

  The description clearly states the tool retrieves and decrypts memories, and also can read shared cells. It distinguishes from sibling tools like remember, forget, and share.

  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 says to use at start of session or when past context is needed, and explains when to use the shared cell reading feature with conditions.

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