Server Quality Checklist

Tool Scores

• assess_riskC
  2.3/5.0
  Behavior1/5

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

  No annotations provided, so the description must fully disclose behavioral traits. It only states the computation purpose but says nothing about side effects, permissions, return format, or whether it modifies state. For a tool that likely reads utility weights and returns an assessment, this is a significant omission.

  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?

  A single sentence with no redundant words, front-loading the primary purpose. However, the extreme brevity contributes to under-specification, but as conciseness alone, it's efficient.

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

  Completeness1/5

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

  The tool has 6 parameters, nested objects, and no output schema, yet the description provides almost no contextual detail. An agent cannot infer what each parameter does, what the expected output format is, or how the risk assessment is structured. This is inadequate for a complex tool.

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

  Parameters1/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 by explaining parameters. It only vaguely references 'candidate actions or plans' but doesn't name any of the 6 parameters (action, project, parameters, candidate_action, candidate_actions, situation_context). No meaning is added beyond what the enum values hint at.

  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 states a clear verb ('compute') and resource ('risk and threat assessment') with context ('against active utility weights'). It distinguishes itself from siblings like set_goal and manage_intentions by focusing on quantitative assessment. However, it doesn't explicitly contrast with evaluate_situation, which could ambiguously overlap in 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?

  No guidance on when to use this tool versus alternatives. While the description implies it's for evaluating candidate actions or plans, it never states exclusions or directs the agent to other tools for different scenarios. With siblings like evaluate_situation and replan, explicit routing is absent.

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

• manage_intentionsC
  2.4/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden, but it only lists verbs. It does not disclose that create/cancel mutate state, that get/list are read-only, that dispatch may have side effects, or what resolving an intention entails. The parenthetical 'wire contract' adds no behavioral detail.

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

  Conciseness3/5

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

  The description is a single sentence with no padding, and the main verbs are front-loaded. However, 'wire contract' is undefined jargon, and the terse structure provides no organization for a tool with six actions and many optional fields.

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

  Completeness1/5

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

  This is a complex tool with 13 parameters, six enum actions, nested objects, no output schema, and no annotations, yet the description supplies almost no operational context. Per-action parameter usage, state transitions, return values, and side effects are all absent.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description names none of the 13 parameters. An agent cannot determine that action selects among six operations, nor which parameters like intention_id, behavior_name, status, or parameters are relevant for each action.

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

  Purpose4/5

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

  The description names a concrete resource, behavior directives, and lifecycle verbs such as queue, dispatch, track, and resolve, making the general purpose clear. It does not differentiate from sibling tools like set_goal or manage_beliefs, and 'wire contract' is jargon, so it stops short of a 5.

  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 guidance about when to use this tool versus siblings such as set_goal, replan, or evaluate_situation. No prerequisites, exclusions, or alternative-selection criteria are provided.

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

• set_goalC
  2.4/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 fully disclose behavior, but it only offers a high-level operation list. It does not mention side effects, permissions, idempotency, or what happens to existing goals during update, decompose, or abandon operations.

  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 one efficient sentence that front-loads the core operations and resource. The verb list is slightly redundant because 'manage' encompasses the other verbs, but there is no filler or wasted space.

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

  Completeness1/5

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

  For a tool with 15 parameters, 6 enum actions, nested subgoals, and no output schema, this sparse sentence is far from complete. It leaves out action-specific parameter requirements, return format, and how this tool fits with sibling tools.

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

  Parameters1/5

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

  With 15 parameters and 0% schema description coverage, the description needed to explain action, id, parent_id, subgoals, status, and related fields. It provides none of that; only the phrase 'hierarchical goals and task DAGs' vaguely hints at parent/subgoal relationships.

  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 identifies the resource (hierarchical goals and task DAGs) and names several concrete operations: register, update, and decompose. This is clearer than a tautology, but the trailing 'manage' is broad and there is no explicit differentiation from siblings like manage_intentions or replan.

  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 guidance on when to use this tool versus alternatives such as replan or manage_intentions. The description does not state which action to choose under which circumstances, nor does it mention preconditions or exclusions.

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

• evaluate_situationC
  2.7/5.0
  Behavior2/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 of behavioral disclosure. It mentions 'compute' and 'output' but does not state whether the tool mutates state, requires specific permissions, has side effects, or whether it is read-only. The description lacks any statement about what happens to inputs or whether the operation is safe or reversible.

  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 a single, grammatically correct sentence with no filler or repetition. It is front-loaded with the core action, and while it is not structured with separate sections, it efficiently conveys the high-level purpose in under 200 characters.

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

  Completeness2/5

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

  For a tool with 8 parameters, nested objects, and no output schema, the description is far too sparse. It does not explain expected input formats, the meaning of different action variants, how utilities are computed, or what the output looks like. An agent would struggle to construct a valid request without additional documentation.

  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?

  With schema description coverage at 0%, the description must compensate by explaining the parameters. It offers only vague hints (e.g., 'situation snapshot' likely maps to 'snapshot', 'active weights' may relate to 'utility_profile'), but it does not clarify the meaning of most parameters (e.g., 'action' enum values snapshot/quick, 'project', 'trace_id', 'candidate_actions'). The agent cannot determine how to populate fields correctly.

  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 states a clear verb-resource relationship: 'Ingest multi-modal situation snapshot, compute expected utilities against active weights, and output prioritized action recommendations.' This is concrete and distinct from siblings like 'assess_risk' or 'query_knowledge,' though it does not explicitly name an alternative. It conveys the primary function without ambiguity.

  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 provides no guidance on when to use this tool versus the siblings (set_goal, replan, assess_risk, etc.). There is no mention of conditions, exclusions, or alternative tools. An agent must infer usage solely from the purpose, which is not made explicit.

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

• get_decision_traceC
  2.7/5.0
  Behavior2/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 of behavioral disclosure. It says 'Retrieve' which implies a read operation, but it doesn't disclose whether this tool requires specific permissions, whether it returns sensitive chain-of-thought data, whether it logs access, or what happens when no trace_id is provided. For a tool that retrieves explainable rationale, the lack of disclosure about access control or data sensitivity is a notable gap.

  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 a single sentence that front-loads the key purpose and lists the three main content types (rationale, utilities, risk assessment). It's concise and readable, though it could be slightly more structured by separating the retrieval purpose from the content types.

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

  Completeness2/5

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

  With 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is under-specified. An agent cannot determine what each action value does, how to scope a query, or what the return format looks like. The tool appears to be a complex retrieval tool with multiple modes (latest, get, list, explain), and the description doesn't explain these modes or their relationships.

  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 description coverage is 0%, so the description must compensate for the 5 parameters. It mentions 'past decisions' which maps to trace_id/goal_id, and 'candidate utilities' and 'risk assessment' which map to the tool's purpose, but it doesn't explain the meaning of the 'action' enum (latest, get, list, explain), the 'limit' parameter, or how 'project' and 'goal_id' relate to trace_id. The description adds some context but leaves most parameter semantics unexplained.

  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 states a specific verb ('Retrieve') and resource ('explainable step-by-step chain-of-thought rationale, candidate utilities, and risk assessment for past decisions'), which clearly distinguishes it from sibling tools like set_goal or assess_risk. It doesn't explicitly name a sibling, but the resource is specific enough that an agent can tell it apart from the other tools.

  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 gives no guidance on when to use this tool versus alternatives. It doesn't mention that this is for past decisions only, nor does it explain when to use 'explain' vs 'list' vs 'get' actions. The sibling list includes assess_risk and query_knowledge, which could overlap, but no exclusions or routing guidance is provided.

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

• manage_reasoning_dbC
  2.7/5.0
  Behavior2/5

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

  With no annotations, the description must carry the behavioral disclosure burden, but it only hints at effects through terms like 'restore' and 'audit.' It does not state whether snapshot/restore overwrites data, what maintenance implies, whether audit is read-only, or what side effects any action may have.

  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 brief and front-loaded with the resource and operation families; there is no fluff. It sacrifices explanatory depth for compactness, but for a one-line overview it is efficient.

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

  Completeness2/5

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

  Given no annotations, no output schema, four undocumented parameters, and polymorphic behavior, a one-line list is insufficient. The agent is missing return expectations, side-effect risks, parameter roles, and guidance for selecting an action.

  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 description coverage is 0%, so the description must compensate, but it only paraphrases the enum values rather than explaining params like name, project, or description. The agent gets no guidance on how these parameters relate to each action or which are required beyond action.

  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 resource (the reasoning database) and enumerates the main operations: stats, audit, snapshot/restore, and diffs. This is enough to distinguish it from sibling reasoning/decision tools, although it lacks a proper verb phrase and uses the vague term 'maintenance.'

  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 gives no guidance on when to use this tool versus siblings such as query_knowledge or manage_beliefs. It neither states conditions for each action nor explains which sibling should be used instead. The agent must infer usage entirely from the action enum and tool name.

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

• set_utility_weightsC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description alone carries the burden of behavioral disclosure. It hints at mutation ('configure', 'activate') but never says whether activation is immediate, persistent, reversible, or what side effects occur on existing behavior. The read actions (get/list) are not disclosed at all through the description, even though they are part of 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 definition is a single front-loaded sentence that communicates the core action and the domain of the weights. It avoids fluff and is easy to skim. Adding a pruning phrase such as 'get/list' or a usage hint would make it longer but not necessarily wordier, so it is adequate for its length.

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

  Completeness2/5

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

  The tool has six parameters, a free-form nested object, no output schema, and no annotations. A one-sentence description leaves out essential decision points: what each action does, how 'weights' values are represented (ranges, types), what project/name/is_active/description are for, and what the tool returns. This is materially incomplete for an agent selecting and invoking the tool safely.

  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 0%, so the description must add meaning. It does add the semantic content of the 'weights' object by listing its five attributes, which is genuinely useful. However, the other five parameters (name, project, is_active, description, and the action semantics beyond the enum) are left undocumented, so a fair fraction of the parameters are still ambiguous.

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

  Purpose4/5

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

  The description names a specific verb ('configure and activate') and a clear resource ('multi-attribute utility weights') with a concrete list of attributes. It distinguishes itself from the decision-making siblings like set_goal and assess_risk. However, it only mentions two of the four actions in the enum; the 'get' and 'list' actions are omitted, so the stated purpose under-represents the actual scope.

  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 guidance on when to use this tool versus alternatives. Nothing explains context such as 'when your utility profile needs updating' or rules out per-decision tweaking versus global strategy. The attribute list is the only subtle hint, leaving the agent to infer the purpose.

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

• replanC
  2.8/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 behavioral traits. It mentions 'abort/recreate intentions' which implies mutation, but it does not explain what happens to existing intents, whether changes are reversible, or the response format. It lacks detail on side effects or preconditions.

  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 a single concise sentence, front-loaded with the main action. There is no redundancy and it is easy to read, though it lacks any structural breakdown of use cases or alternatives.

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

  Completeness2/5

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

  Given 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, side effects, required parameters, or the meaning of action enum values. An agent would struggle to call this correctly without more context.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any parameters. The 6 parameters (action, goal_id, project, trigger_event, preserve_completed, blocker_description) are undocumented in the description, leaving the agent without guidance on how to fill them beyond the raw schema.

  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 a specific verb and resource: 'Regenerate sub-task DAG and abort/recreate intentions' and gives trigger conditions. It distinguishes from siblings like set_goal or manage_intentions by focusing on replanning upon blockers/state changes, though it does not explicitly name alternatives.

  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 there are unexpected blockers or environmental state changes, but it does not explain when not to use it or how it relates to siblings like evaluate_situation or assess_risk. It gives context but no explicit guidance or exclusions.

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

• query_knowledgeC
  2.9/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the burden of behavioral disclosure. 'Search' signals a read-only intent with no destructive effects, and 'by context similarity' describes the matching behavior. However, it does not state what the response contains, whether limits or pagination apply, or any operational constraints.

  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 a single front-loaded sentence with no filler and it immediately states the core operation. It is concise and well structured, even though its brevity limits completeness.

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

  Completeness2/5

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

  For a tool with 6 parameters, no output schema, and no annotations, one line of purpose is insufficient. An agent cannot determine what the tool returns, how to configure the search modes and filters, or what default behavior to expect. The description is adequate as a high-level summary but incomplete for reliable invocation.

  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 description coverage is 0%, so the description must compensate, but it only introduces the general idea of 'context similarity'. It doesn't explain the three action values, limit, project filtering, context_tags, or pattern_type, leaving the agent to infer parameter meaning from names and enums alone.

  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 uses a specific verb ('Search') and names concrete resources: learned heuristic patterns, tactics, and past decision traces. The added mechanism 'by context similarity' makes the intent clear. However, it doesn't explicitly distinguish this from get_decision_trace, which could also return decision traces.

  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?

  No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives such as get_decision_trace or manage_reasoning_db are mentioned. The description implies a context-similarity search use case but leaves the decision of which sibling to choose to inference.

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

• manage_beliefsB
  3/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 behavioral disclosure and does add meaningful mechanics: TTL-based expiration sweeps, exponential confidence decay, and category filtering. However, it does not disclose mutating or destructive aspects such as what 'expire' or 'reconcile' actions actually do, whether operations are reversible, or what side effects updates trigger.

  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 dense sentence with no filler or repetition. It front-loads the core concept and packs three meaningful behavioral details into a compact structure.

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

  Completeness2/5

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

  This is a complex tool with 12 parameters, four action enum values, and no output schema or annotations, so the description needs to explain action semantics, return behavior, and usage context. The current one-sentence teaser omits how the action parameter drives behavior accordion-style, what each action returns, and when a caller should choose management over querying.

  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 description coverage is 0%, so the description must compensate, but it only hints at a few parameter clusters: expires_at via TTL sweeps, confidence/decay_rate via confidence decay, and category via filtering. The remaining parameters—action, object, source, project, subject, belief_id, predicate, and client_request_id—receive no explanatory support from the description.

  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 resource as a structured belief state and highlights key behaviors: TTL expiration sweeps, exponential confidence decay, and category filtering. It is not a tautology and evokes a distinct maintenance role compared with siblings like query_knowledge and manage_intentions, though 'maintain' is somewhat broad and does not enumerate the action families from the schema.

  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?

  No guidance is provided about when to use this tool versus alternatives such as query_knowledge, manage_intentions, or manage_reasoning_db. The description implies a general maintenance purpose but offers no exclusions, prerequisites, or routing criteria.

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