Server Quality Checklist

Tool Scores

• get_rerender_causesA
  3.5/5.0
  Behavior3/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 does disclose that the analysis is heuristic and depends on the exported profile, which suggests it is non-mutating and approximate. However, it omits explicit statements about side effects, prerequisites, or reliability limitations, leaving important behavioral traits implied rather than stated.

  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 sentence that front-loads the main action (highlight repeated-rerender components) and then states the added value (explain likely causes via heuristics). There is 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 tool with no output schema and no annotations, the description covers the core result type but not enough surrounding context. It does not explain output structure, prerequisites beyond the implicit exported profile, or how this tool relates to the many sibling analysis tools. The schema documents parameters well, but the description remains minimal.

  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% for all three parameters, so the schema already documents their meaning. The description adds little param-specific value; the phrase 'exported profile' loosely aligns with profileId, but no additional syntax, defaults, or interactions beyond the schema are described.

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

  Purpose4/5

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

  The description states a specific verb and resource: highlight components with repeated rerenders and explain likely causes. It is clearly distinct from sibling tools like get_render_summary or get_slow_components because it focuses on rerender diagnosis using heuristics, though it does not explicitly name those siblings.

  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 by 'derived from the exported profile': an agent can infer this is a post-capture analysis step, likely after load_render_profile. However, the description does not state when to choose this over alternatives such as get_slow_components or compare_renders, nor any conditions where it should not be used.

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

• get_render_summaryA
  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 behavioral disclosure burden. It does convey that the operation is a read-only summary and lists the kinds of information included, which is helpful. However, it does not describe what happens when no profile is loaded, whether the summary is computed fresh or cached, or what the return structure looks like beyond the listed content.

  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, efficient sentence that front-loads the core action and resource, then adds relevant detail about the summary's contents. Every phrase earns its place with no filler or redundant restatement of the tool name.

  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 only two optional parameters and a highly descriptive schema, the definition provides enough context about the returned information. Since there is no output schema, the description's mention of top components and detected issues is valuable. A small gap is that it doesn't describe the behavior when profileId is omitted, though the schema does cover that.

  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 (limit and profileId) are already well documented in the schema. The description adds context by framing the summary around a loaded profile and detected render issues, but it doesn't explain the parameters beyond what the schema already provides. The baseline of 3 applies because the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states a specific action ('Summarize') on a specific resource ('the loaded Next.js render profile') and names the key output contents: top components by render cost and detected render issues. It does not explicitly contrast with sibling tools like get_slow_components or get_rerender_causes, so some overlap ambiguity remains, but the 'loaded profile' scope helps differentiate it.

  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 phrase 'loaded profile' implies the tool should be used after load_render_profile, and the profileId parameter description reinforces this. However, the main description gives no explicit guidance about when to prefer this tool over alternatives such as compare_renders, get_slow_components, or get_rerender_causes, and it doesn't state when not to use it.

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

• get_slow_componentsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose the ranking behavior and the dependence on an already-loaded profile, and 'Return' implies a read-only operation. But it does not state side effects (or lack thereof), behavior when the profile is missing, or whether the result is limited by the default 10-item cap—though some of this is covered by schema parameter descriptions.

  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?

  One front-loaded sentence states the resource, ranking metric, and context with no filler. Every phrase earns its place, and the key scope information appears before any elaboration.

  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?

  Given a fully documented parameter schema, a clear one-sentence purpose, and no output schema, the description provides enough context for an agent to select and invoke the tool: what it returns, how results are ranked, and the loaded-profile prerequisite. It does not describe the return shape, but the lack of an output schema makes this a minor gap rather than a blocking one.

  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 profileId, limit, sortBy, and minSelfDuration with defaults and enums. The description adds minimal extra parameter insight ('total actual render time' roughly aligns with the default sortBy), so the 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 uses a specific verb-resource pair ('Return the slowest components') and adds a concrete ranking criterion ('ranked by total actual render time') plus the required context ('in a loaded Next.js render profile'). This clearly separates it from sibling analysis tools like get_render_summary, compare_renders, and get_rerender_causes.

  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 phrase 'in a loaded Next.js render profile' implies the prerequisite that a profile must first be loaded, and the schema ties profileId to load_render_profile. However, the description does not explicitly say when to prefer this tool over alternatives like get_render_summary or get_rerender_causes, so usage guidance remains implied rather than explicit.

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

• get_hot_commitsA
  3.9/5.0
  Behavior4/5

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

  The verbs 'rank' and 'show' clearly indicate a read-only analysis operation, and 'inside each spike' discloses the output grouping behavior. With no annotations present, the description carries the behavioral disclosure burden, and this description reasonably conveys sorting and nesting behavior, though it stops short of defining the cost metric or error 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?

  A single, front-loaded sentence immediately states the core action ('Rank the most expensive commits') and then adds the nested output detail. There is no filler or repeated information from the schema.

  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 schema fully covers parameters and the description states the tool's purpose and output grouping. However, there is no output schema or annotations, and the description does not specify the exact return shape or how 'expensive' is measured, so the agent must infer some 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 schema already documents all four parameters, including defaults and semantics for priorityLevel. The description adds no parameter-level meaning beyond reinforcing the 'loaded render profile' context for profileId, so the baseline score 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 specific action verbs 'rank' and 'show' with clearly identified resources: 'most expensive commits' and 'top components inside each spike.' This makes it distinguishable from sibling tools like get_slow_components (component-focused) and capture/load tools (setup-focused).

  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 phrase 'in a loaded render profile' conveys that the tool requires an existing profile, implying it should be used after load_render_profile. However, it does not explicitly state when to prefer it over alternatives such as get_slow_components or get_render_summary, and no exclusions are given.

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

• run_render_captureA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool may start a dev server and require user clicking, or run an automated test suite, and that user intent must be confirmed first. However, it does not mention whether existing capture data is overwritten, whether the call blocks until the user finishes, or what side effects to expect beyond render generation.

  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 compact and well-structured: it leads with the prerequisite, then gives a clear instruction to ask the user, followed by a scannable two-option list. Every sentence earns its place and there is no filler.

  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 two-parameter tool with no output schema nested in a workflow, the description covers the call trigger, the required user confirmation, and the two valid generation methods. It does not describe return behavior or what happens after capture completes, but the sibling tools such as stop_render_capture and get_captured_renders make the surrounding workflow inferable.

  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 both sessionId and method, including enum meanings and provenance. The description adds workflow context around the method choices but does not materially extend the parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.

  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 places the tool in a workflow: it is called after instrumentation is wired up, and it triggers render generation via one of two methods. It distinguishes itself from begin_render_analysis by referencing it as the prerequisite step, and from the analysis/capture siblings by its role as the run step, though it relies somewhat on the title for the exact action.

  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 gives explicit when-to-use guidance: only after steps 1–3 of begin_render_analysis, and only after asking the user which render method they want. It enumerates both acceptable methods (manual-interaction and test-suite) and describes what each entails, so an agent knows exactly how to proceed.

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

• stop_render_captureA
  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 burden of behavioral disclosure. It accurately states the core state-changing behavior: stopping a live session, finalizing buffered events, and returning a profileId. However, it does not disclose whether the operation is irreversible, whether calling it on an already-stopped session errors or is a no-op, or whether any cleanup/race conditions apply. 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?

  A single, well-crafted sentence that leads with the action, states the mechanism, and lists downstream consumers. No filler, no redundancy. Every clause 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 description explains the return value (a profileId) and its usability with four sibling tools, which is especially valuable given there is no output schema. It could be more complete by explicitly stating the prerequisite of an active session (e.g., 'must have an active live capture started by run_render_capture or begin_render_analysis'), but the overall context is sufficiently clear for a single-parameter 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 only parameter, sessionId, is already fully documented in the schema as 'The sessionId returned by begin_render_analysis' (100% schema description coverage). The tool description adds no additional semantic meaning about the parameter itself, only mentioning the returned profileId. Baseline 3 applies because the schema does the heavy lifting.

  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 ('stop') with a clear resource ('live render-capture session') and enumerates the outcome ('finalize the buffered events into a render profile'). It also names the sibling tools that consume the returned profileId, making it easy to distinguish from the other render-capture/analysis tools in the sibling 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 clearly implies this is the terminating step for a live capture session, and it explicitly tells the agent what to do with the result by listing the tools that accept the returned profileId. It lacks explicit when-not-to-use guidance (e.g., no active session or already stopped), but the context is strong enough to route correct usage.

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

• begin_render_analysisA
  4.2/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 meaningful behavior: live streaming via react-scan/lite and manual relying on a user-shared DevTools Profiler JSON export, plus the instruction to ask first. However, it does not state whether the tool starts a capture, returns a session ID, or has side effects, which leaves some behavioral uncertainty for a 'begin' action.

  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 compact and front-loaded with the core purpose, followed by a scannable two-option breakdown and a single mandatory user-consultation note. No sentence is wasted.

  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 entry point, the description is nearly complete: it defines both enum values, explains tradeoffs, and mandates user consent. It could be more explicit about what the tool returns or what happens after invocation, but this is a minor gap given the simple schema and clear sibling context.

  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 fully documents the enum with descriptions, so the baseline is strong. The description adds helpful selection context: live gives exact rerender causes, source locations, and changeDescription, while manual requires no install and depends on the user exporting a JSON and sharing a file path. This goes beyond the schema's brief enum notes.

  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 'Entry point for render profiling,' clearly stating the tool's role and resource. It distinguishes itself from siblings by framing the tool as the initial decision point rather than a load, compare, or summary operation, and it enumerates the live vs manual branches.

  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 instructs 'Ask the user which approach they prefer before calling this tool,' a clear precondition for invocation. It also contrasts live (requires npm install, richer data) with manual (no install, less detailed), giving the agent decision criteria. It does not spell out cases where a sibling tool should be used instead, but as the intended entry point this is sufficient.

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

• compare_rendersA
  4.2/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 behavioral disclosure burden. It clearly communicates a non-destructive analytical operation, the fact that it diffs two existing profiles, and the four ranked result categories. It does not detail response shape or edge cases, but the core behavior is accurately and sufficiently 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 entire description is one tight, front-loaded sentence with no filler. It states the operation, the resource, and the output dimensions in under 20 words, and every part contributes to understanding the tool.

  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?

  Given the moderate complexity, fully documented parameters, and no output schema, the description provides enough invocation-critical detail: the two required IDs, the loaded-profile prerequisite, and the ranked diff categories. It could be more explicit about output ordering or result shape, but nothing essential to selecting or calling the tool is missing.

  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 input schema already documents every parameter. The description adds a light conceptual framing by calling the parameters 'loaded render profiles' and implying ranking, but it does not provide meaningful semantics beyond what the schema already states. 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 uses a specific verb ('Diff') and a clear resource ('two loaded render profiles'), then enumerates the exact output categories: regressions, improvements, additions, and removals. This distinguishes it meaningfully from siblings like get_slow_components or get_render_summary, which summarize or list rather than compare two profiles.

  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 a clear prerequisite: profiles must already be loaded, matching the sibling load_render_profile. It provides clear context for when to use the tool—comparing two profiles—but does not explicitly state when not to use it or name a specific alternative, so it stops 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.

• load_render_profileA
  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 operation type (load), the input (file path), the output (profileId), and how that output is used by other tools. It does not discuss failure modes or side effects, but for a load tool this is arguably sufficient 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: the first states the core function, the second provides a clear step-by-step workflow and return-value context. No redundant phrasing or fluff.

  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?

  The description fully covers how this tool fits into the larger workflow, what input is needed, and what output to expect. Given the tool has a single parameter and no output schema, all essential information is present for an agent to invoke it 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?

  Schema coverage is 100%, so the schema already documents filePath as an absolute or relative path. The description adds minimal extra meaning ('share the file path here'), staying at the baseline of 3 since the parameter semantics are adequately covered by 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 uses a specific verb ('Load') and resource ('React DevTools Profiler JSON export'), and clearly identifies the tool as 'the entry point for the manual profiling path.' It distinguishes itself from sibling analysis and capture tools by specifying this is the import step that produces a profileId.

  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 explicit workflow context ('open React DevTools... Export JSON → share the file path here') and lists the downstream analysis tools. It does not explicitly state when not to use this tool or name an alternative for automated capture, but the manual-path framing makes the intended usage clear.

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

• get_captured_rendersA
  4.7/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 and does so well. It explains that the tool does not stop the session, what fields it returns, and how to interpret an important signal (unknownEvents count). This is strong transparency for a diagnostic 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 well-structured, opening with the key diagnostic purpose and then providing concrete return-value context. Every sentence contributes useful information—purpose, behavior, return fields, and usage guidance—without fluff.

  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 diagnostic tool, the description covers what the tool does, when to call it, what it returns, and how to interpret a non-obvious result. The absence of an output schema is adequately compensated by the explicit list of returned information.

  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%, and the schema already documents sessionId as returned by begin_render_analysis. The description does not need to add parameter meaning, 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 clearly identifies the tool as a diagnostic for peeking at live render-capture session progress, naming the specific resource and the non-destructive nature of the operation. It distinguishes itself from the sibling tools like stop_render_capture by explicitly stating it is not a required step before stopping.

  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 explicitly states when to use this tool ('Only call this if something seems wrong') and what it is not for ('not a required step before stop_render_capture'). This gives clear usage context and prevents unnecessary invocation.

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