Server Quality Checklist

Tool Scores

• install_packagesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the operation only affects that session and that packages become available to subsequent exec calls. However, it does not mention side effects like modifying package.json, network requirements, or the need for package-lock updates, which an agent might need to predict outcomes.

  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 no filler. The core command, its purpose, and the session-isolation behavior are all presented efficiently, with the most important information front-loaded.

  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 three-parameter tool with no output schema and no annotations, the description covers the core invocation, purpose, and scope. Minor gaps remain around expected output/errors and whether this modifies package manifests, but the essentials for correct invocation are present.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters clearly. The description adds no parameter-specific meaning beyond what is in the schema, matching the baseline of 3.

  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 action ('Run `npm install`'), a target resource ('in the session workspace'), and the intended outcome ('subsequent exec calls can require/import the packages'). It is clearly differentiated from siblings like create_session, exec, and remove_session by focusing on package installation into an existing session.

  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 context: use this to install packages so later exec calls can import them. It does not explicitly list when not to use it or name alternatives such as exec for running commands directly, so it falls just short of full usage-guideline coverage.

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

• remove_sessionA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the destructive effect ('kills its worker process') and the non-destructive persistence ('workspace directory is kept... dependencies and written files survive'), which goes well beyond what the name and schema alone communicate.

  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 with no wasted words. It front-loads the primary action and side effect, then adds the important persistence detail. Every sentence earns its place.

  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 one-parameter destructive tool, the description is complete: it states what is removed, the side effect on the worker process, and what survives. There is no output schema, but for this tool the return value is not essential to correct 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?

  The only parameter, 'name', is already fully documented in the schema with 'Session name to remove', giving 100% schema description coverage. The tool description adds no additional parameter-level meaning beyond the schema, so it meets but does not exceed the baseline.

  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-resource pair ('Stop and remove a session') and adds a distinguishing side effect: 'kills its worker process'. This clearly separates it from siblings like create_session, list_sessions, and exec, so the agent knows exactly what this tool does.

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

  Usage Guidelines3/5

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

  The usage context is implied: use this when you want to terminate and remove a REPL session. However, it does not explicitly name alternatives or state when not to use it, so the agent must infer when this tool is the right choice among the siblings.

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

• historyA
  4.2/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 read-only nature through 'Return' and details what the history includes (inputs, outputs, errors, captured console). While ordering and limit behavior are not elaborated, the description gives sufficient behavioral context for a read-only query 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 a single, front-loaded sentence that names the action, resource, and content types. The parenthetical adds useful detail without unnecessary words. Every element 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?

  For a simple two-parameter read tool with no output schema, the description covers the return contents and the intended use case. It does not describe the exact ordering of entries or the format of errors/console output, but the phrase 'last N entries' in the schema plus the description provides enough context for correct 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 description coverage is 100%, so both parameters (name and limit) are already documented in the schema. The description does not add per-parameter meaning beyond the schema, but it does clarify what kind of data the session history contains. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool returns evaluation history for a session and lists the specific contents (inputs, outputs, errors, captured console). The verb 'Return' plus the resource 'evaluation history of a session' is specific and clearly distinguishes it from sibling tools like exec, list_sessions, and create_session.

  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 is useful for reviewing what state was built up in a session. It does not explicitly name exclusions or alternatives, but the context is strong enough for an agent to select this tool when a review of session history is needed.

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

• list_sessionsA
  4.2/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 states that all sessions are listed and that pid, workspace, and liveness are included, which implies a read-only, comprehensive operation. It does not explicitly state side effects or output format, but for a simple list operation the behavioral surface is well covered.

  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?

  A single, tightly worded sentence that front-loads the action and resource, then specifies the returned fields. No filler or redundant information.

  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 list tool, the description adequately covers purpose and output fields. It does not specify response formatting or error behavior, but with no output schema and such a simple operation, the missing details are minor.

  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 is 4. The description adds useful context about the fields returned, even though it does not explain any parameters (there are none to explain).

  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 identifies the resource ('REPL sessions') while naming the returned fields (pid, workspace, liveness). This clearly distinguishes it from siblings like create_session and remove_session by operation, and from history/exec by resource.

  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: use this when you need to enumerate all REPL sessions. However, there is no explicit mention of when not to use it or how it compares to alternative tools like history or exec, so the guidance is only implicit.

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

• create_sessionA
  4.4/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 of behavioral disclosure. It clearly explains that each session runs in its own child process, has an isolated context, preserves runtime state across exec calls, and persists until removed. This gives the agent important behavioral expectations without needing annotations.

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

  Conciseness5/5

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

  The description is two sentences and front-loads the core purpose before adding behavioral detail. There is no redundancy, and every sentence contributes useful information for correct usage.

  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 one-parameter tool with no output schema, the description is quite complete: it explains persistence, isolation, and lifespan. It does not mention duplicate-name behavior or the exact response shape, but those are minor gaps for a simple creation tool.

  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 fully documents the single `name` parameter with type, pattern, and description. The tool description adds little param-specific detail beyond referring to the session as 'named', so the schema already does the heavy lifting. 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 states a specific verb and resource: creating a named, persistent Node.js REPL session. It also distinguishes itself from siblings by explaining that session state persists across exec calls and is removed only via removal, making its role clear.

  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 context for when to use the tool: when a persistent, isolated REPL session is needed, as opposed to just executing one-off code. It does not explicitly name alternatives or state when not to use it, but the context around child-process isolation and persistence is strong enough.

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

• execA
  4.4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the full behavioral burden. It discloses state persistence between execs, buffering of syntax-incomplete input across calls, and the return content (inspected result, console output, error). It omits minor details like the exact response structure or whether a missing session is auto-created, but the core execution semantics are 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?

  Four short, information-dense sentences, each earning its place: the primary action and semantics, the buffering behavior, the return values, and state persistence. The most important fact (evaluate JavaScript in a named session) is front-loaded.

  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 side-effecting, stateful execution tool with no annotations and no output schema, the description is largely complete: it covers return values, multi-line buffering, and persistence. It could be stronger by stating whether the session must already exist or whether exec auto-creates it, but overall an agent has enough to call and interpret the result 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?

  Schema coverage is 100% and both parameters already have meaningful descriptions, so the baseline is 3. The description adds extra value by linking the name parameter to persistent session state and clarifying that code is evaluated with full node:repl multi-line semantics, which enriches the meaning of both parameters.

  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: 'Evaluate JavaScript in a named REPL session.' It goes beyond a generic restatement by naming node:repl semantics and explicitly distinguishing the tool's behavior (evaluation with persistent state) from the session-management siblings like create_session or list_sessions, so an agent can tell it apart.

  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 tool's use case is explicit: evaluate JavaScript in an existing named session, with multi-line input continuing on subsequent exec calls. It does not explicitly name alternatives or exclusions, but the sibling set and the phrase 'named REPL session' make the division of responsibility clear: exec is for evaluation, while create_session/list_sessions/history handle session management.

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