Server Quality Checklist

Tool Scores

• engrim_contextC
  2.9/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 of behavioral disclosure. It indicates a read-like operation ('Return') but does not explicitly state it is read-only, nor does it mention any side effects, truncation behavior, or limits beyond the character budget parameter. It lacks details on what happens if the budget is exceeded or how the pack is constructed.

  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, focused sentence that front-loads the core action and resource. It avoids unnecessary fluff and is appropriately sized for the tool's simplicity, though it could arguably add more structure or bullet points if needed.

  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 the lack of annotations and output schema, and the incomplete parameter information (project is undocumented), the description is insufficient for an agent to confidently invoke the tool. It does not explain the return format, what constitutes 'high-signal records,' or how the project parameter behaves. The tool is simple, but the missing context around parameters and output leaves 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?

  The description mentions 'within a character budget,' which aligns with the budget parameter, but the project parameter is completely undocumented in the schema (0% schema description) and the description does not clarify it. With 50% schema coverage, the description fails to compensate for the missing parameter meaning, leaving agents uncertain about the 'auto' default and acceptable values.

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

  Purpose5/5

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

  The description states a specific verb ('Return') and a clearly defined resource ('the project's session-boot memory pack'), and even elaborates on its purpose ('curated, high-signal records that orient you at the start of work'). This distinguishes it from sibling tools like engrim_recall or engrim_add, which clearly serve different operations.

  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 implies it is intended for session start ('orient you at the start of work') but provides no explicit guidance on when to use this tool over alternatives, nor any exclusions or prerequisites. There is no mention of when not to use it or how it differs from engrim_recall.

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

• engrim_addA
  3.8/5.0
  Behavior3/5

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

  There are no annotations, so the description carries a heavier burden. It adds the concrete behavior that records persist across sessions and are durable, which is helpful. It does not disclose side effects, overwrite semantics, permissions, or latency. Given the simple 'add' nature, this is adequate but not rich.

  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 that front-load the core purpose and then provide direct usage guidance. There is no filler and every phrase earns its place.

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

  Completeness3/5

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

  For a 7-parameter, no-output-schema, no-annotation tool, the description is short. It covers why (durability) and when (decision points, facts) but does not outline the fields, the exact semantics of type, or how the memory is structured. Enough for a rough call, but could be richer.

  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 only 57% and the description adds minimal value beyond it. It hints at 'facts/feedback/state' which map to the type enum, but it does not clarify the roles of summary, tags, detail, global, project, or origin_agent. An agent would have to rely mostly on the bare schema descriptions.

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

  Purpose5/5

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

  The description clearly states the verb ('Write') and the resource ('durable memory record') plus an explicit behavioral promise (persists across sessions). It is easily distinguished from sibling tools like engrim_recall or engrim_context, which are about reading or retrieving, not writing.

  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?

  Gives explicit when-to-use guidance: 'Use at real decision points and for durable facts/feedback/state.' This is useful contextual selection information. It does not name the sibling alternatives or state when not to use it, so it falls just short of a 5.

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

• engrim_recallA
  4/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. It discloses hybrid keyword + semantic ranking behavior and implies a read-only operation by saying 'Search... and recall.' It does not mention any side effects, performance constraints, or output format, which is a gap, but the ranking behavior adds meaningful detail.

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

  Conciseness5/5

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

  Two compact sentences with no fluff. The first sentence states the action and method, and the second adds contextual usage guidance. Key information is front-loaded and every phrase earns its place.

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

  Completeness4/5

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

  The tool is moderately complex (6 parameters, mostly optional) and has no output schema. The description explains when to use it and what it recalls, but does not describe the return structure or ordering. Given the absence of an output schema, a small note on return format would enrich complete picture, though it is adequate.

  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 input schema has 100% description coverage for all parameters, so the schema already documents each parameter. The description does not add extra beyond what the schema provides (max records, filtering by tag/type, project, include_stale). Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly identifies the tool's function as searching the project's engrim memory with hybrid keyword + semantic ranking, and specifies the resource ('engrim memory'). It distinguishes this retrieval action from likely sibling tools (add, review, context) by stating it recalls prior decisions, facts, feedback, and state.

  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 before non-trivial work to recall prior decisions...', giving a clear context for when to invoke the tool. However, it does not mention alternatives or exclusion criteria, though the usage window is well-defined.

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

• engrim_reviewA
  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 burden of explaining behavior. It discloses that the result is a heuristic verdict and that null means 'unknown because no transcript log exists', giving important runtime context without pretending to be authoritative.

  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 tight sentences, front-loads the purpose, and includes the important safe_to_clear edge case without fluff. Every word adds value.

  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 single optional parameter and no output schema, it explains both the main output and the null safe_to_clear edge case. It could have specified the exact output shape of the surfaced decisions, but is still complete enough for an agent to use the tool correctly.

  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 already fully documents the only parameter (project, default 'auto'), and the description does not add anything about project semantics, valid values, or edge cases. Baseline 3 is appropriate because schema coverage is 100%.

  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 what the tool does: it checks coverage by surfacing recent transcript-log decisions that are not yet in curated memory. This is specific and clearly separate from recall/add/context behavior, though it does not explicitly name sibling tools for differentiation.

  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 gives actionable timing guidance ('before clearing context') and explains the safe_to_clear result semantic, including the null case for missing transcript logs. It does not explicitly say when NOT to use it or name alternatives, so it falls just short of full routing guidance.

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