Server Quality Checklist

Tool Scores

• brain_memoriesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. The verb 'List' implies a read-only operation, and the context of checking existing memories supports this. However, it does not explicitly state side effects, authorization needs, or error behavior, and the mention of 'tags' is inaccurate relative to 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 two concise sentences that state the function and intended use. It is efficient, though the inaccurate 'tags' mention is a small blemish that could confuse rather than inform.

  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 simple tool with three optional parameters and no output schema, the description provides adequate purpose and usage context. However, it does not explain return values, how project_id interacts with SAOR_PROJECT_ID, or address the missing 'tags' parameter, leaving some gaps.

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

  Parameters2/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema and actually misleads by mentioning 'tags' as a filter when no such parameter exists in the schema. This inaccuracy reduces the score.

  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 lists memories in the brain with optional filters, using a specific verb and resource. It does not explicitly differentiate from sibling tools like brain_list, but the focus on memories and the 'before writing new memories' context provides some distinction.

  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 an explicit use case: 'Use to understand what the brain already knows before writing new memories — avoid duplicates.' It does not mention when not to use it or name alternatives, so it stops short of a full 5.

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

• brain_feedbackA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It does state that the tool 'Creates a performance memory' (a write operation), but it omits other relevant behavioral traits such as whether it overwrites existing memories, reversibility, or any permission requirements. The disclosure is minimal and partially implicit.

  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, consisting of two sentences that immediately convey the primary action and its purpose. Every phrase earns its place, 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?

  Given the low complexity, 100% schema parameter coverage, and absence of an output schema, the description is mostly complete. It explains the tool's effect (creates a performance memory) and the schema details the inputs. The only notable gap is the lack of behavioral side-effect details, but this is partially addressed in the transparency dimension.

  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 provides 100% coverage with clear descriptions for all four parameters (outcome, metrics, learnings, project_id). The description adds little beyond the schema, mentioning 'what worked, what didn't, metrics' which maps to outcome and metrics, but does not enhance understanding of the parameters' syntax or formatting.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('Report') and resource ('the brain'), and differentiates it from siblings by noting it creates a 'performance memory' for learning. This distinguishes it from generic memory tools like brain_remember or brain_absorb.

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

  Usage Guidelines3/5

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

  The description implies usage when reporting an outcome (what worked, what didn't, metrics), but it does not explicitly state when to use this tool versus alternatives like brain_remember or brain_context. No exclusions or alternative recommendations are provided.

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

• brain_absorbA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must convey behavior on its own. It does disclose a key behavioral trait: the brain structures input into memories, strategies, and knowledge automatically. However, it does not mention side effects such as deduplication, overwriting, auth requirements, or processing time, leaving some transparency gap.

  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, well-structured sentence that front-loads the verb and resource ('Feed raw text into the brain'), then provides examples and a brief note on processing. Every phrase contributes meaning, with 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?

  For a simple ingest tool with full schema coverage and no output schema, the description covers the purpose, acceptable content types, and post-processing behavior. It could optionally mention querying the ingested data, but that is not essential for using this tool correctly. Overall, it is sufficiently 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?

  All three parameters are fully documented in the schema, so the baseline is 3. The description's examples like 'CLAUDE.md' and 'brand guidelines' add a hint of source/content values but do not go beyond the schema's own descriptions. No additional parameter semantics 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 action ('Feed raw text into the brain') and the resource, with concrete examples like CLAUDE.md files, brand guidelines, and meeting notes. It also distinguishes itself by noting that the brain 'structures it into memories, strategies, and knowledge automatically,' which differentiates ingestion from simple storage.

  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 this tool: when feeding raw text or documents into the brain. It does not explicitly mention alternatives or when not to use it, but the examples and phrasing make the primary use case obvious. Sibling tools like brain_query and brain_remember imply complementary roles.

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

• brain_createA
  4/5.0
  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 discloses the 'lens' model and cross-brain context, which is useful conceptual context, but it doesn't mention operational behaviors such as return values, potential conflicts, or permissions. This is a moderate level of transparency.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the action, and every sentence adds value. No filler 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?

  Given the tool's simplicity (3 documented parameters, no output schema, no annotations), the description covers the essential purpose and conceptual model. It lacks explicit return-value information, but the create operation is straightforward. The second sentence provides useful context about cross-brain behavior, making it reasonably 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 well-described parameters (name, description, initial_context). The description doesn't add much detail beyond the schema, but the 'lens' metaphor indirectly helps interpret the purpose of the parameters. Baseline of 3 is appropriate since the schema already provides adequate 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 tool's purpose: 'Create a new brain for a new project, client, or domain.' It uses a specific verb ('create') and resource ('brain'), and the second sentence explains the conceptual model, distinguishing it from sibling tools like brain_absorb or brain_remember.

  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 phrase 'for a new project, client, or domain' gives clear context on when to use this tool. It doesn't explicitly name alternative tools, but the distinction between creating a new brain versus interacting with existing ones (e.g., brain_query, brain_absorb) is implied by the wording.

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

• brain_queryA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of revealing behavior. It does disclose the non-obvious output trait ('synthesized answer'), but it doesn't explicitly confirm read-only behavior or mention any side effects, latency, or failure modes. This is adequate but has clear gaps.

  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 and every word earns its place. It front-loads the action ('Ask the brain a specific question'), delivers the output type, and closes with a crisp usage trigger—all in under 30 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 two well-documented parameters and no nested objects, the description is largely complete. It covers purpose, output type, and when to invoke, though it doesn't detail response structure or error cases; the lack of an output schema makes those gaps slightly more noticeable.

  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 fully documents the 'q' and 'project_id' parameters. The description adds context by emphasizing 'specific question' and 'recall', but it doesn't add extra parameter-level detail beyond the schema, so the baseline 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 uses a specific verb ('Ask') and resource ('the brain'), clearly stating it returns a synthesized answer from the brain's knowledge. It distinguishes itself from siblings by positioning this tool for recall of specific facts ('a prior decision, a preference, a pattern') rather than listing or storing memories.

  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 instructs when to use the tool: 'Use this when you need to recall something specific' with concrete examples. It doesn't name alternate sibling tools or give when-not scenarios, so it stops short of the full 5.

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

• brain_rememberA
  4.1/5.0
  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 memories are auto-linked via tags ('Tag every memory so the brain can auto-link it to related knowledge across all brains') and that memory compounds ('every memory you write makes the next session smarter'). It does not detail failure modes or rate limits, but for a simple write tool, this is sufficient context.

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

  Conciseness4/5

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

  The description is four sentences, front-loaded with the core action, and contains useful behavioral guidance. The final sentence about compounding is slightly motivational but still informs the agent of the tool's value. No filler 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 write tool with 7 parameters and no output schema, the description provides essential context (when to use, tagging behavior, persistence). It does not explain return values, but the absence of an output schema reduces that need. It is complete for the agent's immediate decision to call the tool, though it could include a brief example.

  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 all parameters. The description adds a general directive to 'Tag every memory' consistent with the tags parameter, but adds no syntax or format details beyond the schema. Baseline 3 is appropriate when the schema carries the load.

  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 'Write a memory to the brain' with a specific verb and resource. It distinguishes itself from sibling read/search tools by emphasizing it is a continuous write operation, and the context signals show it is the memory-writing sibling among query-like 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 gives explicit when-to-use guidance: 'Do this CONTINUOUSLY as you work — not at the end' and lists trigger conditions ('When the operator makes a decision, shares a preference, or you learn something useful'). It does not mention exclusions or alternatives, which would push it to a 5.

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

• brain_contextA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden. It discloses that the brain carries forward prior session data ('never start cold') and explains the behavior of scope='all' for cross-brain thinking. It does not discuss side effects or permissions, but for a load operation the disclosed behavior 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?

  The description is four concise sentences, front-loaded with purpose. Every sentence adds value: what loads, when to call, persistence benefit, and scope option. No fluff.

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

  Completeness4/5

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

  The tool has simple parameters and no output schema. The description explains what context is loaded and the rationale, which is sufficient for an agent to select and invoke it. It does not describe return format, but for a context loader that's not essential.

  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 already describes all three parameters with 100% coverage. The description adds no new parameter details beyond what's in the schema, mentioning scope='all' but the schema also documents that. Therefore baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool loads the brain and lists its components (identity, soul, memories, constraints, agent instructions). It distinguishes from sibling tools like brain_query or brain_remember by framing this as the session-start loader. The verb 'load' and resource 'brain' are specific.

  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 instructs to call this at the start of every session, providing clear timing guidance. It does not explicitly mention alternatives or when-not-to-use, but the context is strong enough. Sibling tools exist but are not compared.

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

• brain_identityA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It says 'Load' implying a read operation and describes scope ('lighter', 'without full memory load'), which transparently indicates the tool is a non-destructive subset read. It does not explicitly state side effects or return format, but the read nature is clear.

  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, front-loaded with the main verb and resource. Every phrase earns its place, comparing to brain_context and giving a use case.

  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 one optional parameter and no output schema. The description lists the loaded items and contrasts with brain_context, providing enough context for an agent to decide. Could mention that project_id defaults, but schema already covers it.

  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 sole parameter project_id is fully documented in the schema (100% coverage), so baseline is 3. The description adds no parameter-specific details, but none are needed 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 uses a specific verb ('Load') and resource ('the brain's identity'), enumerating its contents. It explicitly distinguishes itself from the sibling brain_context by noting it's lighter. This fully clarifies 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 Guidelines5/5

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

  States 'Lighter than brain_context' and 'Use when you need the brand voice without the full memory load.' This gives explicit when-to-use guidance and names the alternative. No exclusions, but clear enough.

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

• brain_listA
  4.5/5.0
  Behavior4/5

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

  There are no annotations, so the description itself implies a read-only operation by saying 'List all brains'. It adds context about what each brain is and a pointer to brain_context, which helps the agent understand the domain. It doesn't disclose any side effects or requirements, but for a simple list operation, none are indicated.

  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: the first states the action, the second gives the use case and a cross-reference. Every sentence contributes value, no 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?

  The description covers the tool's purpose, when to use it, and what to expect (brains and their IDs). It also gives a contextual tip about brain_context with scope='all'. Given no output schema and no parameters, this is sufficient.

  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 parameter semantics are not applicable. The description adds context about discovering IDs and the notion of 'brains as lenses', which gives background, but there are no parameters to document. Baseline 4 for zero-param tools.

  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 all brains in the workspace' — a specific verb and resource. It further clarifies the purpose by saying 'Use to discover available brains and their IDs', and distinguishes from siblings by positioning brain_list as the discovery tool while referencing brain_context for cross-brain thinking.

  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 to discover available brains and their IDs', indicating when to use it. It also provides an alternative usage by pointing to 'scope='all' on brain_context to think across all of them'. It doesn't explicitly state when not to use it, but the 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.