Server Quality Checklist

Tool Scores

• debug_session_listB
  3.1/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 only mentions sorting (most recently updated first) but does not disclose result fields, pagination behavior, default limits, whether all statuses are included by default, or if any side effects exist. The minimal disclosure falls short of what an agent needs to understand the tool's runtime 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 a single, concise sentence that names the operation and includes one valuable detail (sort order). There is no filler or redundancy.

  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 is a simple list with two optional parameters but no output schema and no annotations. The description provides only the basic listing action and sort order, omitting expected return structure, parameter semantics, and any scenarios for using filters. For an agent to invoke it correctly, more context is needed, such as what happens if no parameters are supplied or how status filtering works.

  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 input schema has two parameters (limit and status) and zero schema-description coverage. The tool description makes no mention of these parameters, how to use them, or their effect on results. Since the description adds no meaning beyond the schema's bare property names and types, it fails to compensate for the lack of schema-level documentation.

  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 'Lists debugging sessions, most recently updated first' clearly states the action (list) and the resource (debugging sessions), and adds the ordering detail which distinguishes it from sibling tools like debug_session_get or execution_list. This is a specific, unambiguous purpose.

  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 by naming the list operation, but it does not explicitly state when to use this tool versus alternatives like debug_session_get for a single session or execution_list for executions. No exclusions or alternative guidance is provided, so it relies on the agent inferring context from the verb and sibling tool names.

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

• execution_listA
  3.6/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 disclosing behavior. It does reveal that results include log-count summaries and are ordered most recent first, which is helpful. However, it omits pagination behavior, default limits, authentication requirements, and error semantics, leaving gaps for a list operation with a limit parameter.

  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 with zero redundancy. Every phrase adds value: action, scope, summary detail, and ordering.

  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 is relatively simple (2 params, no output schema), but the description does not fully compensate for the missing output schema. It mentions log-count summaries but not the actual fields returned, and it omits how `limit` affects the result set or pagination.

  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 both parameters. It implicitly covers sessionId via 'for a debugging session,' but the `limit` parameter is completely undocumented—no mention of limiting the number of results or its maximum value of 200.

  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 action ('Lists executions') and scopes it to a debugging session, with useful detail ('log-count summaries, most recent first'). This distinguishes it from sibling tools like execution_get_logs (which retrieves logs for a single execution) and execution_create/run/end (which are mutations).

  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 enumerating executions in a session but does not explicitly state when to use this tool over alternatives. Sibling tools like execution_get_logs and execution_compare exist, but no guidance on choosing between them is provided.

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

• execution_endA
  3.7/5.0
  Behavior3/5

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

  No annotations exist, so the description must disclose side effects. It explains the tool is for unobserved external executions, but it does not state whether the operation is terminal, idempotent, or what error behavior occurs if called for an already-ended execution. Some background context is given, but key behavioral implications are missing.

  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 sentence that front-loads the action and condition. No filler or redundancy; every word adds context.

  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 description captures the core use case but omits return-value behavior, parameter semantics, and consequences. For a mutation/record tool with no annotations or output schema, this is insufficiently complete for reliable invocation.

  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 schema description coverage at 0%, the description must explain parameters. It only mentions 'outcome' in passing and fails to define executionId or notes, or enumerate outcome values. This leaves the agent guessing about parameter purposes and allowed 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 clearly states the tool records the final outcome for externally-run executions, explicitly distinguishing from execution_run by referencing execution_create. This aligns with the title and makes the resource/action unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit when-to-use guidance: for executions created via execution_create that log-probe-mcp could not observe exiting on its own, and explicitly excludes execution_run. This tells the agent exactly when this tool is appropriate versus its siblings.

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

• execution_get_logsA
  3.7/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 that logs are structured, chronological, and filterable by several criteria, but it does not describe the return format, pagination behavior, or any read-only guarantees. This is a moderate level of disclosure, similar to the TDQS 4.3 example.

  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, well-structured sentence that front-loads the core action and resource, then lists optional filters. There is no redundant information or filler.

  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 8 parameters, no output schema, and no annotations. The description explains what the tool does and some filters, but it does not describe the return structure, pagination, or any edge-case behavior. Given the complexity and lack of output schema, this is incomplete.

  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 only 38% (3 of 8 parameters). The description mentions filters for hypothesis, level, time range, and text search, which maps to some parameters, but it omits the meaning of limit, offset, and executionId. The description partially compensates for low coverage but leaves key parameters unexplained.

  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 the specific verb 'Fetches' with a clear resource: 'structured logs recorded for a single execution'. It also specifies ordering and optional filters, making it distinct from sibling tools like execution_list or execution_compare.

  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 the tool is for retrieving logs for one execution and lists filter options, but it does not explicitly state when to use it over alternatives or provide exclusions. The context of sibling tools suggests a clear use case, so a 4 is appropriate.

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

• hypothesis_createA
  3.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. It does not disclose return values, error behavior, persistence guarantees, or whether an existing session is validated. The text is mostly motivational ('the point of instrumentation...') rather than describing the tool's actual 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 sentences long, front-loaded with the core purpose, and adds a valuable usage tip. Every word contributes meaning; no filler or redundancy.

  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 simple creation tool, the description covers the 'what' and a key usage point, but it omits expected information about the output (e.g., created hypothesis ID), confirmation of success, or the requirement that the sessionId refer to an existing session. Given no output schema and no annotations, this is a noticeable gap.

  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 67% (statement and rationale have descriptions, sessionId does not). The description does not add parameter-specific details beyond the schema; it only provides an example for 'statement' within the schema itself. Thus it meets the baseline without compensating for the undocumented sessionId.

  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: 'Records a falsifiable hypothesis about the root cause of a bug within a debugging session.' It uses a specific verb ('records') and resource ('hypothesis'), and it distinguishes from sibling tools like hypothesis_update and hypothesis_list by focusing on the creation act.

  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 offers explicit usage guidance: 'Form several distinct, competing hypotheses rather than one — the point of instrumentation is to gather evidence that can confirm some and refute others.' This gives contextual advice on when and how to use the tool, though it does not explicitly mention alternatives or exclusions.

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

• hypothesis_listA
  3.8/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 behavioral transparency burden. It accurately conveys a read-only listing operation and the ordering, but it does not mention potential filter behavior, pagination, return shape, or side effects. It is minimally sufficient but not fully 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 a single, front-loaded sentence that states the action and scope with no filler. Every word contributes meaning, making it highly concise and well-structured for a simple list tool.

  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 is relatively simple, but with no output schema and no annotations, the description leaves out the optional status filter and does not describe the return value shape. It is enough for basic tool selection but not fully complete for invocation without inspecting the schema.

  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 should compensate by explaining parameters. It only indirectly references sessionId via 'for a debugging session' and completely omits the optional 'status' filter. The schema and enum provide the only parameter meaning, with little help from the description.

  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 the specific verb 'Lists' and clearly identifies the resource ('hypotheses') and scope ('for a debugging session'). Adding 'oldest first' provides distinctive operational detail that helps differentiate it from sibling tools like hypothesis_create or execution_list.

  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 makes clear this tool is for retrieving hypotheses within a debugging session, which is a distinct use case from session listing or execution listing. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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

• hypothesis_updateA
  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 full burden. It discloses that the tool updates status and links executions, and mentions the durable nature. However, it does not clarify whether status is overwritten or whether relatedExecutionIds are appended (the schema does), leaving some behavioral 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 two sentences, with the primary action in the first sentence and contextual purpose in the second. It is front-loaded, concise, and every sentence adds value without 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?

  For a simple update tool with no output schema, the description covers the main purpose and the durable record aspect. It lacks some merge/overwrite behavior details, but these are likely evident from the schema, making it adequately 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?

  Schema coverage is 50%, with evidence and relatedExecutionIds already described. The description adds context that evidence comes from logs and links executions, but it does not explicitly map to all parameters (hypothesisId and status are not elaborated). It partially compensates for the coverage gap.

  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 specifies the action ('marks a hypothesis confirmed/refuted/inconclusive'), the resource (hypothesis), and the connection to executions. It distinguishes itself from siblings like hypothesis_create (which creates) and knowledge_base_export (which exports), making the purpose unambiguous.

  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 by stating it is 'the durable record that knowledge_base_export later turns into a written debugging knowledge base,' implying it is used after evidence gathering and before export. However, it does not explicitly state when not to use it or compare it directly to alternatives like hypothesis_create.

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

• debug_session_resolveA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the action (closes out a session) and the two possible statuses, which implies a state change. However, it does not specify whether the action is reversible, what happens to associated data, or any permission requirements. Some context is provided, but not enough for a mutation 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?

  Two sentences, front-loaded with the core purpose, and the second sentence adds a useful cross-tool tip. No wasted words and every sentence 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 a simple close-out action, and the description provides when to use it and a related recommended step (knowledge_base_export). However, with no output schema and no annotations, the agent is left to infer what the response looks like. Given the low complexity, the description is mostly complete, but a note about the response or side effects would elevate it further.

  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 only 33% (only resolutionSummary has a description). The description does not add meaning to sessionId or status beyond the schema's enum and default. It implicitly connects resolutionSummary to the root cause/fix but lacks specifics about required format or optionality.

  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?

  Uses the specific verb 'Closes out' with the resource 'debugging session' and clearly distinguishes the two terminal states (resolved or abandoned). This differentiates it from sibling tools like debug_session_create, debug_session_get, and debug_session_list, which handle lifecycle and retrieval.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool: after the root cause is found and fixed, or when the investigation is abandoned. It also provides an alternative action ('Call knowledge_base_export first') with a clear rationale, giving the agent actionable guidance for sequencing.

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

• probe_server_startA
  4.1/5.0
  Behavior4/5

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

  Without annotations, the description takes on the transparency burden. It discloses that the call starts a server and lazily opens SQLite storage, giving insight into side effects. However, it does not address lifecycle details like idempotency, blocking behavior, port conflicts, or shutdown obligations, so it is good but not comprehensive.

  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. The first identifies the action and target; the second adds a meaningful side effect. No waste, and key information is front-loaded.

  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 the main action, prerequisite, and storage side effect. However, it does not address what the tool returns (especially when port is auto-assigned) or how to discover the chosen port, and it omits lifecycle guidance (e.g., use probe_server_stop to shut down). Given no output schema, these gaps leave the description somewhat incomplete.

  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 100%, so the baseline is 3. The description adds a behavioral note about lazy SQLite storage opening, which connects to the dataDir parameter, but it does not provide systematic parameter guidance beyond the schema. Thus, 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 clearly states the tool starts the local HTTP log-ingestion server and explains its role in receiving structured log events. It differentiates from siblings like probe_server_stop and probe_server_status by focusing on the start action.

  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 states this must be called before any code can be instrumented or executions run, providing clear usage timing. However, it does not mention when not to use it or alternatives, so it falls short of the top score.

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

• debug_session_createA
  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 the behavioral disclosure burden. It reveals that all hypotheses and executions are tracked under a sessionId, which is a meaningful behavioral trait. It also indicates this is a prerequisite for other actions, but does not detail side effects or return format.

  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 concise sentences, each adding value: the primary action, the sessionId tracking mechanism, and the ordering guidance. No wasteful or redundant wording.

  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 create tool with two parameters and no output schema, the description is nearly complete. It explains the core behavior, the sessionId linkage, and when to call it. It does not explicitly state the return value, but the mention of sessionId is a sufficient hint. Minor gaps remain around response details.

  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 parameters are already well-documented. The description does not add additional meaning about 'title' or 'description' beyond what the schema provides, so the baseline of 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 uses a specific verb 'Starts' and resource 'debugging session', clearly conveying the tool's function. It distinguishes itself from siblings by specifying that it is the creation entry point for the session lifecycle, not listing, getting, or resolving.

  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 states 'Call this first, before creating hypotheses or executions,' providing clear usage guidance and ordering relative to related tools. It does not list alternative tools, but the instruction to call it first is a strong contextual guideline.

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

• debug_session_getA
  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 must carry the transparency burden. It discloses the tool's read-only nature ('Fetches'), the content of the response (hypotheses and execution summaries), and behavior related to format selection (markdown vs. default). It does not mention authentication or rate limits, but these are less critical for a simple getter.

  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 long. The first sentence states the primary purpose and key content, the second delivers a useful parameter hint. There is 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 simple 2-parameter getter with no output schema, the description provides a high-level overview of the returned data (hypotheses and execution summaries) and format behavior. It could elaborate on the response structure, but overall it gives sufficient 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 0%, so the description must compensate. It adds value by explaining the markdown format's purpose ('human-readable rendering'), but sessionId is only implied by the tool name and title, not explicitly described. The compensation is partial, so a 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 uses a specific verb ('Fetches') and resource ('full detail for a session') and explicitly enumerates what is included ('hypotheses and execution summaries'). This clearly distinguishes it from sibling tools like debug_session_list, debug_session_create, and debug_session_resolve.

  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 guidance ('Use format=markdown for a human-readable rendering') and clearly implies the tool is for retrieving session detail. However, it does not explicitly contrast with alternatives like debug_session_list, so it falls 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.

• instrumentation_get_contractA
  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 a key behavioral trait: the endpoint may be a placeholder if probe_server_start hasn't been called. It also lists what is returned (schema, env vars, snippets). It doesn't mention side effects, but as a read-only getter this is likely unnecessary.

  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 purpose, lists contents in a structured flow, and ends with a direct usage directive. Every sentence 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?

  With no output schema, the description appropriately explains the return values by listing the four components. It also provides usage context and a conditional behavior. It could mention potential errors or edge cases, but for a simple getter with one optional param, it is quite 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 input schema has 100% coverage: the one parameter 'language' has a clear enum and description ('Omit to get snippets for all languages'). The main description doesn't add significant information about the parameter beyond what the schema already states, so the baseline of 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's function with a specific verb ('Returns everything needed to instrument target code') and enumerates the exact contents (endpoint, schema, env vars, snippets). It distinguishes itself from sibling tools by focusing on the ingestion contract, which is unique among the listed tools.

  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 this before inserting any instrumentation so calls match the contract exactly,' providing clear when-to-use guidance. It does not mention when not to use it or name alternative tools, but the context is clear enough for an agent to select it appropriately.

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

• execution_createA
  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. It discloses the critical integration contract (instrumented code must include this executionId in every log event POSTed to the ingestion server) and the prerequisite. It does not mention return value, idempotency, or error behavior, but for a minting operation the core behavior is adequately 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?

  Three sentences, each earning its place. Front-loaded with the core action ('Mints a new executionId'), followed by the integration requirement, prerequisite, and alternative. No fluff or repetition.

  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 relatively simple tool with two parameters and no output schema, the description covers purpose, usage, integration contract, and sibling differentiation. It falls short only in explaining the sessionId parameter's origin and the exact return format, but overall it is reasonably complete.

  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 50%: label is described, but sessionId has only a minLength constraint with no purpose. The description does not clarify that sessionId likely refers to the session started by probe_server_start, leaving a significant semantic gap. The description does not compensate for the missing parameter documentation.

  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?

  Clearly and specifically describes the tool: it mints a new executionId for processes the user will trigger externally or manually. The description distinguishes it from the sibling execution_run, which launches and captures processes directly.

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

  Usage Guidelines5/5

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

  Provides explicit usage context: requires probe_server_start to have been called first, and directs users to execution_run when log-probe-mcp should launch the process. This clearly identifies when to use this tool versus the alternative.

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

• execution_runA
  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 full burden and thoroughly discloses behavior: auto-injection of LOG_PROBE_* environment variables, line-by-line stdout/stderr capture with stderr as level=error, merging with HTTP-posted logs, waiting for exit or timeout, and the requirement of prior probe_server_start. No contradictions exist.

  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?

  Every sentence delivers distinct value: the first explains the core subprocess launch and environment injection, the second covers log capture, the third describes waiting behavior, the fourth states the prerequisite, and the fifth gives usage guidance. No filler or 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?

  The description covers the primary behavior, preconditions, log capture, and alternative tools, but it omits what the tool returns (exit status? run ID?) and does not explain the role of the required sessionId parameter. Since no output schema exists, this gap slightly reduces completeness.

  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 only 43% (3 of 7 params), and the description does not compensate for the missing semantics. It mentions command and timeoutMs but adds little beyond the schema, and it ignores sessionId, cwd, args, and label entirely, leaving agents to infer their 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 action: spawns `command` as a subprocess with environment variables injected, captures stdout/stderr as logs, and waits for exit. It also distinguishes itself from execution_create by recommending the latter for long-running services.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool: 'Best for scripts, one-off repros, and test runs' and identifies the alternative for long-running services. Also mentions the prerequisite that probe_server_start must have been called first.

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

• probe_server_statusA
  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 burden of explaining behavior. It transparently states that the tool reports whether the server is running, its URL, and counters, which implies a non-mutating read operation. It doesn't detail edge cases or error behavior, but the core behavior is disclosed.

  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 sentence that is clear, informative, and front-loaded with the action ('Reports'). Every element adds value: the subject, the action, and the three types of information returned.

  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 tool with no parameters, no annotations, and no output schema, the description provides adequate context about what the tool returns. The only minor gap is that 'basic counters' is vague, but the overall behavior is clear for a simple status-checking tool.

  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, so the baseline is 4. The schema is empty and description coverage is 100%, so no parameter documentation is needed. The description correctly focuses on the tool's outputs instead.

  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 purpose with a specific verb ('Reports') and resource ('ingestion server'), and lists the exact outputs (running status, URL, basic counters). This distinguishes it from sibling tools probe_server_start and probe_server_stop, which perform mutating actions.

  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 the tool is for checking status when you need to know if the ingestion server is running. It does not explicitly state when to use it instead of start/stop, but the context is clear given the sibling names and the report-oriented wording.

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

• knowledge_base_exportA
  4.5/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. It discloses the file write and index refresh behavior, and describes the content of the summary. It doesn't mention error conditions or prerequisites, but it adequately conveys the side effects.

  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. The first sentence is front-loaded with the action and resource, and the second adds valuable usage guidance and analogy. 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?

  Given the simple schema (1 parameter) and no output schema, the description is complete. It explains what files are written, what content is included, when to call, and why it matters, covering all necessary context for an agent to decide.

  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 coverage is 0%, and the description compensates by embedding <sessionId> in the output path, implying the parameter is the session identifier. For a single string parameter with a minLength constraint, this provides sufficient meaning beyond the schema.

  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 writes a specific file (.log-probe/knowledge/<sessionId>.md) and refreshes an index, using specific verbs and resource names. It distinguishes itself from sibling tools by framing it as the durable, written record, unlike session getters or execution tools.

  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 explicitly advises calling the tool 'once a session has reached a conclusion (or is being abandoned)', providing clear timing. It doesn't name alternatives or state when not to use it, but the context makes the choice clear.

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

• probe_server_stopA
  4.5/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 stored sessions/hypotheses/logs are unaffected, a key side-effect. However, it doesn't address error cases (e.g., server not running) or idempotency, which would add further transparency.

  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 concise sentences, front-loaded with the action. The second sentence adds valuable behavioral context without redundancy. Every word 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 0-parameter tool with no output schema, the description fully covers what the tool does and its most important side-effect. It is appropriately complete for the tool's complexity.

  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, so the baseline is 4. The description correctly avoids discussing parameters, and the empty schema confirms no parameter clarification is needed.

  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 the specific verb 'stops' with a clear resource, the 'local HTTP log-ingestion server,' which is distinct from sibling tools like probe_server_start and probe_server_status. It also differentiates by noting stored data is unaffected, leaving no ambiguity about the tool's function.

  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 purpose is clear and implies use when needing to halt the ingestion server. While it doesn't explicitly mention alternatives, sibling names (start, status) make the context obvious. Lacks explicit 'when not to use' or comparison, preventing a perfect score.

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

• debug_workflow_guideA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It clearly conveys that this is an informational tool ('Explains how to debug', 'Read this'), implying no side effects. It does not explicitly state 'read-only' or 'does not modify state,' but the nature of a guide makes this evident. The behavior is transparent enough.

  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 and front-loaded: it immediately states what the tool does, lists the workflow stages, and then gives usage instructions. Every sentence earns its place with zero redundant content.

  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 is a simple guide with one optional parameter and no output schema, the description fully covers its purpose, content, invocation options, and recommended timing. It is complete and leaves no ambiguity for the agent.

  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 already provides 100% coverage with a detailed enum and description. The description adds value by explaining when to use the 'stage' parameter ('or a specific stage once underway'), which is not in the schema beyond 'Omit for the full end-to-end guide.' This contextual usage guidance goes beyond the schema.

  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 purpose: it explains the hypothesis-driven debugging workflow used by log-probe-mcp, listing the specific stages (reconnaissance, hypothesize, instrument, reproduce, analyze, converge, resolve). This distinguishes it from sibling tools which are operational actions (e.g., probe_server_start, debug_session_create).

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

  Usage Guidelines5/5

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

  It provides explicit usage instructions: call with no arguments for the full guide, or with a specific stage once underway. It also advises reading it before starting a debugging session if unfamiliar, giving clear context on when to use this tool over the other debugging tools.

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

• execution_compareA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries full behavioral burden. It discloses the normalization tolerance, the three output categories, and the counts, giving a clear picture of what the tool does beyond the raw schema.

  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?

  Three sentences, front-loaded with the core action, followed by output details and use case. No wasted words; every sentence provides value.

  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?

  Despite having no output schema and no annotations, the description fully explains what is returned, the normalization logic, and the intended use case. It is complete for a tool of this complexity.

  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 0%, but the parameter names executionIdA and executionIdB are self-explanatory. The description consistently uses A and B to refer to the two executions, clarifying their roles in the diff. It does not add format/type details, but the naming plus context is sufficient.

  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 diffs two executions' logs, specifies the grouping method (normalized source, level, message), and describes the return categories. This is a specific verb+resource that distinguishes it from siblings like execution_get_logs.

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

  Usage Guidelines5/5

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

  Explicitly frames this as the flaky-test-style debugging tool, instructing to run the same thing with execution_run and compare a failing run against a passing one. This tells the agent when to use it and gives a concrete workflow.

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