Server Quality Checklist

Tool Scores

• brain_analyticsB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavior. It mentions the database is local/dev and flags feedback famine, offering some transparency about data source and a specific output feature. However, it does not disclose whether the tool is read-only, what the response format is, or error behavior, leaving 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?

  Two sentences, with the core function in the first and context/caveat in the second. Every word adds value; no redundancy or unnecessary detail.

  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 zero-parameter, no-output-schema tool, the description covers the key aspects: the data source (local/dev SQLite), the tables (prediction/feedback), the metrics (row counts, recency), and a unique flag (feedback famine). It is self-contained enough for an agent to decide if this is the right tool, though more detail on return format would help.

  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, and the schema is empty, so there is nothing to document. The description adds no parameter info, but the baseline for zero-parameter tools is 4, and the description is consistent with that.

  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 provides row counts and recency for specific prediction/feedback tables in a local dev SQLite database, distinguishing it from siblings like brain_db_schema or brain_ml_models. The scope (local/dev) and the 'flags feedback famine' detail give clear purpose.

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

  Usage Guidelines2/5

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

  The description notes this is local/dev rather than production, providing a caution for non-production use, but it does not specify when to choose this tool over siblings or any exclusion criteria. No explicit alternative tools are named, so usage guidance is minimal.

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

• brain_backlogB
  3.3/5.0
  Behavior2/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. It does disclose that the vault scan is bounded, most-recent-first, and adds iCloud latency, plus that it is off by default. However, it does not state whether the tool is read-only, any permission requirements, or other side effects, leaving major 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, front-loaded with purpose, and contains no fluff. Every word adds value, including the technical rationale for the includeVault default.

  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 purpose and one parameter adequately, but lacks details on output format, how 'repos' interacts, and general usage context. Without annotations or output schema, this leaves some uncertainty for an agent deciding on 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 coverage is 0%, so the description must compensate. It explains includeVault in detail (default, behavior, latency rationale) but does not describe 'repos' at all, leaving one of two parameters undocumented. This partial compensation earns a mid 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 identifies the tool's scope: 'Unified open items across GitHub PRs/issues and local git.' This distinguishes it from sibling tools like brain_where_deploys and brain_db_schema. However, it lacks an explicit verb (e.g., 'list' or 'fetch'), relying on the noun phrase 'open items' to imply the action.

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

  Usage Guidelines3/5

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

  The description implies usage (for viewing open items from GitHub and local git) but provides no explicit guidance on when to use this tool versus siblings, nor any exclusions or alternatives. The main detail is the includeVault parameter behavior, not usage context.

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

• brain_where_deploysA
  3.5/5.0
  Behavior3/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 that the tool both resolves and cross-checks against repo config, and implies a read-only operation, but it omits what the response looks like and how errors (e.g., missing path or config) are handled.

  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 one concise sentence, front-loaded with the primary action and object. It contains no filler and communicates the core purpose efficiently.

  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 single-parameter tool with no output schema or annotations, the description provides a clear high-level purpose and enough context to understand the tool's role. However, it does not specify the exact return format or error behavior, making it only minimally 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?

  The single 'path' parameter has zero schema-level description. The description adds that the path is a 'file/path' and connects it to deploy target resolution, but it does not clarify path format, existence requirements, or whether the path is repo-relative or absolute.

  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 'Resolve' and identifies the resource as the 'canonical deploy target' for a file/path, plus a secondary action 'cross-check it against repo config.' This clearly distinguishes the tool from sibling brain_* tools, none of which mention deployment.

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

  Usage Guidelines2/5

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

  There is no explicit statement about when to use this tool versus alternatives, nor any mention of exclusions. The phrasing implies use when a deploy target for a file/path is needed, but it does not offer decision guidance relative to sibling tools.

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

• brain_architectureA
  4.2/5.0
  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 of behavioral disclosure. It discloses the 8000-character truncation and name/basename substring matching, which are key behaviors. However, it omits edge cases like what happens when no document matches or when multiple documents match, leaving some ambiguity.

  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 only two sentences, front-loading the core purpose and then describing parameter-dependent behavior. No fluff or redundancy; every clause contributes to understanding the tool.

  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 and no output schema, the description covers the essential operational modes and constraints like truncation. Minor gaps remain around error handling and multiple-match behavior, but the core functionality is well documented.

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

  Parameters4/5

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

  The schema has no descriptions for the `area` parameter (0% coverage), but the tool description compensates by explaining its function: selecting a specific doc by name/basename substring. This adds meaningful semantic context that the raw schema lacks.

  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 providing curated architecture docs, differentiating it from sibling tools like brain_db_schema or brain_ml_models by domain. It also specifies two distinct behaviors (list vs. retrieve) based on the `area` parameter, which fully explains its purpose.

  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 for both modes: without `area` it lists doc names/sections/sizes, and with `area` it returns the doc content. It does not explicitly mention alternatives or exclusions, but the domain-specific naming makes when to use it obvious.

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

• brain_ml_modelsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description adds critical behavioral context by stating that presence on disk does not mean the model is loaded or active, preventing a common misinterpretation. It also makes clear this is a listing operation, but it does not describe output format or error behavior for misconfigured directories.

  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 with no fluff. The core action and object are front-loaded, and the caveat is presented as a distinct, clearly separated clarifying sentence.

  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 zero-parameter, presumably read-only listing tool, the description sufficiently covers the main action and key caveat. Minor ambiguities about how directories are 'configured' and the exact return format remain, but the absence of an output schema and the simplicity of the operation make this acceptable.

  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?

  There are zero parameters, so the baseline score is 4. The description adds contextual meaning by referencing 'configured model directories', giving a hint about the implicit configuration without needing parameter-specific details.

  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 ('List') and a clear resource ('on-disk ML model artifact files across configured model directories'). This distinguishes it from sibling tools like brain_where_deploys, which focus on deployment locations, by explicitly naming the on-disk artifact scope.

  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 use when an inventory of on-disk model files is needed, but does not explicitly state when to prefer this tool over alternatives or when not to use it. The caveat about loaded/active status is semantic rather than a usage guideline, and there are no references to sibling tools.

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

• brain_reframeA
  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 full burden. It discloses that priority/evidence/title/why/action/systems/phases are server-side derived and never accepted from the caller, and that the output is a reasoning contract the calling model must execute to answer lens questions and emit a verdict. This is significant behavioral transparency, though it doesn't mention read-only status or error conditions.

  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 primary action. Every clause contributes: the input modes, the server-side derivation constraint, the output contract, and the caller's expected execution. No filler.

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

  Completeness4/5

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

  For a complex tool with nested anyOf and no output schema, the description explains the core purpose, input alternatives, server-side constraints, and the nature of the output (reasoning contract with verdict). It lacks specifics about the reasoning contract's structure or error cases, but it covers the essential contextual need.

  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 explicitly names `recommendationKey` as the lookup key and describes `taskContext` as a bounded task-only subject alternative. It also clarifies that certain fields are never accepted. However, it doesn't explain the individual properties of taskContext or the `lens` enum values, leaving the agent to rely on schema enums. Partial compensation.

  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 ('Reframe') and identifies the resource ('a real brain_recommend recommendation ... through a reasoning lens'). It also distinguishes from siblings by explaining the alternative task-only input and the server-side derivation, clearly differentiating from tools like brain_recommend and brain_lenses.

  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 states when to use the tool: when you have a recommendationKey or a bounded task-only subject. It also explains that priority/evidence/etc are derived server-side, so the caller should not provide them. It doesn't explicitly name alternative tools or exclusions, but the context makes the usage context clear.

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

• brain_fabrication_auditA
  4.3/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 behavioral disclosure burden. It clearly labels the operation as 'read-only' and 'static,' indicating no side effects. It also discloses the limitation that findings are a 'signal, not proof,' which is important for correct interpretation. It does not describe internal behavior like rate limits or exact scanning methodology, but this is sufficient for a scan tool.

  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, using only two sentences to convey purpose, scope, usage guidance, and parameter override. It is front-loaded with the verb and resource, making it easy to quickly grasp. No filler or redundant information.

  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 tool has no output schema, so the description should ideally clarify what the tool returns (e.g., list of findings, severity, file paths). While it mentions 'findings' and 'certifying REAL/ABSENT,' it does not describe the return format or pagination. Given the moderate complexity and lack of output schema, the description is serviceable but leaves room for ambiguity about the exact output structure.

  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 0%, so the description must compensate. It does so by explaining that the `dirs` parameter 'overrides the configured SYSTEM_BRAIN_FABRICATION_DIRS list for this call,' which gives meaningful context beyond the raw schema. The description does not explain element formatting or constraints, but the single-parameter scope is adequately addressed.

  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 performs a 'read-only static scan' for 'fabricated-core leaves' with a specific definition (Math.random()-fed confidence/accuracy/score/decision values). It also scopes the scan to 'configured engine directories' and distinguishes itself from sibling tools by focusing on fabrication auditing rather than deployments, backlog, or architecture.

  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 practical usage context: it is a 'signal, not proof' and directs users to 'verify each finding against stub-detection-audit before certifying REAL/ABSENT.' It also explains how the `dirs` parameter overrides the default directory list. However, it does not explicitly contrast with sibling tools or state when not to use the tool.

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

• brain_roadmapA
  4.3/5.0
  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 discloses important behaviors: filename-matched selection, most-recently-modified-first ordering, counting open checklist items, and bounded content reads with a default and maximum. It does not mention return format or authentication, but for a read-only scan tool this is reasonably 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 two sentences, front-loaded with the purpose, and contains no fluff. The second sentence efficiently explains the parameter and its rationale without repetition.

  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 only one optional parameter, no output schema, and no annotations, the description covers all essential invocation details: what is scanned, how notes are matched and ordered, what is counted, and the limit behavior. It is complete enough for an agent to select and call 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?

  The schema only provides min/max for the limit parameter, but the description adds meaning by stating the default (6) and explaining that it bounds content reads to prevent stalls from iCloud-hosted vaults. This compensates for the lack of schema descriptions, though it could clarify exactly what is being limited.

  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: scanning configured Obsidian vaults for plan/roadmap/next-steps notes and counting open checklist items. It specifies the resource, action, and scope, distinguishing it from sibling tools like brain_backlog or brain_architecture.

  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?

  Usage context is implied by the mention of 'plan/roadmap/next-steps notes,' but the description does not explicitly state when to use this tool versus alternatives, nor does it name sibling tools or provide exclusions. It offers no direct when-to-use guidance.

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

• brain_db_schemaA
  4.4/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 read-only behavior via the system sqlite3 CLI and states that table names are validated to prevent injection. This goes beyond the schema, though it does not detail output format or error 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 two concise sentences, with the first stating the primary function and optional argument, and the second adding behavioral notes. Every word contributes; no 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 (one optional param, no output schema), the description covers purpose, parameter semantics, and key behaviors. It lacks an exact return format and error handling details, but it provides a functional understanding sufficient for an agent to decide to invoke and interpret results.

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

  Parameters4/5

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

  The schema has one optional string parameter `table` with zero description coverage. The description compensates by explaining that providing `table` switches from listing all tables to inspecting that specific table's columns/indexes/row count. It also mentions validation of table names, adding semantic 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 clearly states the tool's function: listing tables in the configured SQLite database and optionally inspecting a table's columns/indexes/row count. It uses specific verbs ('list', 'inspect') and a distinct resource (database schema), distinguishing it from sibling tools focused on other brain domains.

  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 implies usage for exploring the local SQLite database schema, with a clear distinction between listing all tables and inspecting a specific one via the `table` parameter. While it doesn't explicitly name alternatives or exclusions, the context is clear, and the sibling tools appear domain-specific, making the usage unambiguous.

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

• brain_lensesA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output includes an 'applyGuidance' string and that the model is expected to execute it, not just read the list. This goes beyond a simple list tool, but it doesn't disclose other potential behavioral traits like return details beyond the mentioned string.

  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: purpose, parameter, and output expectations. Each sentence adds distinct value, front-loading the core function. No filler or redundancy.

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

  Completeness5/5

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

  For a simple tool with one optional parameter and no output schema, the description covers the tool's purpose, the parameter, and the nature of the output (including the applyGuidance string and expected action). This is 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?

  The schema for 'kind' has no description and only an enum, so the clarification that 'kind optionally filters to one lens kind' adds meaning. It confirms the parameter is an optional filter, which is not otherwise self-evident from the bare schema. However, the enum values themselves are reasonably self-explanatory.

  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 explicitly states 'List available reasoning lenses (mental models / thinker-inspired frames) for framing a decision.' This is a specific verb ('list') and resource ('reasoning lenses') with a clear purpose (framing a decision). The lens-specific focus distinguishes it from sibling tools like brain_backlog or brain_architecture.

  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: it's for framing a decision, and it instructs the calling model to 'pick the 1-2 lenses that bite hardest on the live problem and apply them, rather than treating the list as reference material.' However, it does not explicitly compare against alternatives or state when not to use this tool.

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

• brain_recommendA
  4.8/5.0
  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 thoroughly. It discloses that the tool is read-only, deterministic, rule-based (not a model), that every candidate cites its source tool and number, that per-source health is reported to prevent degraded evidence from appearing supportive, and that the output includes a reasoning contract for the calling model. These behavioral details go well beyond what annotations would need to cover.

  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 dense but purposeful sentences. It front-loads the primary function, then explains the deterministic nature with evidence tracing, and finally describes the output contract. Every sentence adds substantial value with no filler or redundancy.

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

  Completeness5/5

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

  Given the tool's complexity, the absence of annotations, and the lack of an output schema, the description is remarkably complete. It explains the tool's scope, parameter behavior, evaluation approach, evidence-integrity safeguards, and the reasoning contract expected of the caller. It provides enough context for an agent to select and invoke the tool correctly and to interpret its output.

  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 schema has one optional boolean parameter, 'deep', with zero schema-level documentation. The description fully compensates by explaining that 'deep: true' adds the roadmap scan. This adds clear meaning to the only parameter, and no other parameters exist to be undocumented.

  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: 'Rank next steps from the brain's own read-only evidence.' It clearly distinguishes itself from sibling tools, which are individual source viewers (backlog, analytics, etc.), by positioning this as a cross-source ranking/decision tool. It also clarifies that it is deterministic and NOT a model, preventing semantic confusion.

  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 clearly implies when to use this tool: when next-step recommendations need to be generated from available brain evidence. It also explains the optional 'deep: true' parameter for including roadmap scans. However, it does not explicitly state when not to use it or name alternative tools for specific situations, though the sibling list makes this fairly obvious.

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