Server Quality Checklist

Tool Scores

• elite_memoryC
  2.6/5.0
  Behavior2/5

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

  Annotations already convey mutation and destructiveness (readOnlyHint=false, destructiveHint=true), and the description adds only 'scoped' and 'explicitly approve'. It does not disclose that 'forget' is a destructive action, how 'confirm' guards it, or what side effects 'record'/'approve' have. No contradiction with annotations, but little behavioral context is added beyond them.

  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 short and front-loaded, with no fluff. However, the single sentence is too underspecified for a tool with 9 parameters and at least 5 distinct actions, so it scores slightly below an effective structural outcome.

  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 destructive, writable, multi-action tool with 9 undocumented parameters, the description only gives a title-level action overview. It does not explain action-specific requirements, safeguards like confirm, or what each memory item operation needs, so the definition is not sufficient for reliable invocation by an agent.

  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 parameter clarity, but it only hints at 'scope' and references action names. The meaning of content, memory_id, memory_type, trust_score, privacy_class, and confirm remains opaque, leaving an agent unable to assemble correct calls.

  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 resource ('memory items') and multiple concrete verbs ('Search, record, approve') that match the tool's core actions. It does not explicitly distinguish elite_memory from sibling tools, and omits the forget and associative actions available in the enum, so it is clear but not fully complete.

  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 given about when to use this tool versus elite_prepare or elite_verify, nor about which action values should be chosen in common scenarios. The description implies it handles memory operations but gives the agent no decision criteria for selecting it.

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

• elite_verifyC
  2.7/5.0
  Behavior1/5

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

  The description says 'persist evidence by run_id,' which is a state-changing write, while the annotations declare readOnlyHint=true and destructiveHint=false. This is a direct contradiction about whether the tool modifies state. The continuation workflow is useful behavioral context, but the contradiction makes the description misleading and undermines an agent's safety assumptions.

  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 compact sentence with no filler and a clear temporal sequence: run, persist, follow continuation, then answer. It is front-loaded with the primary action. It could earn a 5 if it also named the check categories or prerequisites, but as written it is efficiently structured.

  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?

  Despite having an output schema, this is a complex tool with 11 optional parameters, an enumerated check list, and a continuation protocol. The description leaves critical operational details unspecified: what the check enum values mean, how the continuation is obtained or invoked, what inputs like command or code relate to, and whether any prerequisites exist. It is not sufficient 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% across 11 parameters, so the description must compensate, but it only weakly hints at two parameters: 'run one check' maps to check, and 'persist evidence by run_id' explains run_id's purpose. It leaves code, draft, query, command, language, step_index, project_root, allowed_files, and forbid_dependency_changes entirely unexplained.

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

  Purpose3/5

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

  The description states a concrete action: 'Run one check' and mentions evidence persistence, so it is not a tautology. However, it never explains what a 'check' verifies or what the tool's domain scope is; the title in annotations ('Verify runtime and capabilities') carries much of the purpose signal. It also does not differentiate the tool from its siblings beyond relying on the 'verify' name.

  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 usage context: run a check, persist evidence by run_id, and follow the returned continuation before producing an answer. This tells the agent the required workflow and sequencing. It does not, however, state when not to use this tool or how it compares to elite_memory and elite_prepare.

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

• elite_prepareB
  3/5.0
  Behavior4/5

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

  The annotations are all false/neutral, so the description carries the burden. It discloses that the tool returns a stateful run_id and a continuation that must be followed in later calls — key behavioral context beyond any structured signal — and it warns the agent that this call is not the final answer.

  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 compact, front-loads the core verb, and uses short directive phrases that an agent can parse quickly. Slight deduction because the juxtaposition of 'Run it is' not clearly the same sentence as 'Not the answer', but overall it earns its space.

  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 described model ('start a task → retain id → follow continuation') is complete enough to attempt a intercepted call, and the workflow-specific directives are present. However, it fails to explain what a 'continuation' looks like, how it relates to siblings, or whether the 'persist' parameter affects that assumed the behavioral guarantee.

  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?

  The schema has two parameters (user_prompt, persist) with zero description coverage, and the tool description adds no parameter details. 'user_prompt' does not even self-evidently map to 'start a non-trivial task' — it takes its purpose entirely from the ambiguous title. The description fails entirely to compensate for the schema's lack of explanation.

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

  Purpose3/5

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

  The description states a clear action ('Start a non-trivial task') and signals its role in the workflow ('Not the answer'). However, it does not name the underlying resource or define what qualifies as 'non-trivial', and only loosely differs from siblings like elite_verify and elite_memory.

  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 instruction to 'Retain run_id and obey the returned continuation after each later Elite call' implies this is the entry point for a multi-step workflow, and 'Not the answer' is a weak exclusion. It gives useful context for when to call it, but stops short of explicitly contrasting it with elite_verify or elite_memory.

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