Server Quality Checklist

Tool Scores

• get_texture_infoC
  2.9/5.0
  Behavior2/5

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

  No annotations are supplied, so the description carries the full burden of behavioral disclosure. It implies a read-only retrieval via 'Get metadata' and lists return properties, but it does not disclose error behavior for invalid/unknown resource IDs, whether a capture must be open first, or that it deliberately does not return the raw texture bytes. Minimal disclosure for a tool with zero annotation support.

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

  Conciseness4/5

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

  The description is lean and front-loaded with its purpose, followed by a compact list of included properties. The Args block is mildly redundant with the schema (it repeats resource_id), but it is short and adds a touch of semantics, so the structure remains clean and efficient.

  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?

  Because an output schema exists, the listed properties (dimensions, format, mip levels) are partially redundant, which is acceptable. The description is mostly adequate for a single-parameter metadata getter, but it omits the relationship to get_texture_data and any prerequisite context, leaving the agent without full guidance on when and how to call it.

  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 for the undocumented resource_id parameter. It adds slight value by clarifying 'The resource ID of the texture', tying the param to the tool's purpose, but this is essentially restating the obvious — it does not explain how to obtain the ID or its expected format. Adequate but thin compensation.

  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 ('Get metadata about a texture resource') and lists concrete properties (dimensions, format, mip levels), which clearly conveys that this returns texture descriptors rather than pixel data — a useful implicit distinction from the sibling get_texture_data. It earns a 4 rather than a 5 because it never explicitly names that sibling or its 'metadata vs data' difference.

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

  Usage Guidelines2/5

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

  No usage guidance is provided. The description never says when to prefer this over get_texture_data, nor mentions that other tools such as open_capture may be prerequisites before a texture resource exists to query. The agent is left to infer the tool's role purely from the word 'metadata'.

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

• get_capture_statusA
  3.5/5.0
  Behavior2/5

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

  With zero annotations provided, the description carries the full burden of behavioral disclosure, and it covers only the loaded case. The most important edge case — what happens when NO capture is loaded (returns false? empty? throws?) — is entirely unstated. For an agent that may call this cold, that gap is significant.

  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 with zero filler. The primary purpose is front-loaded first, and the second sentence adds the return-value detail. Every word earns its place.

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

  Completeness3/5

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

  For a zero-parameter status query with no nested objects, this is mostly adequate — the output schema presumably covers the return shape, and the description covers the loaded case. However, the no-capture edge case, likely the first thing an agent encounters, is not addressed at all.

  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 and 100% schema description coverage, so the schema has nothing to document. Per the rubric, the no-parameter baseline of 4 applies; the description correctly adds nothing about parameters because there are none.

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

  Purpose5/5

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

  The description states a specific verb (Check) and resource (a capture currently loaded in RenderDoc) and identifies the return value (status and API type). It is immediately distinguishable from all sibling tools, which query buffers, textures, draw calls, or pipeline state — none of which check capture-load status.

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

  Usage Guidelines2/5

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

  The description says only what the tool does, with no indication of when to call it (e.g., verifying a capture loaded after open_capture, or confirming a context exists before drawing data). No exclusions or alternatives are mentioned, though the low parameter count lowers the risk of misuse.

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

• get_buffer_contentsA
  3.6/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 full behavioral burden. It discloses the read-only nature ('Read'), the base64 encoding of returned data, and that metadata accompanies the data. However, it does not explain error behavior for invalid resource IDs, the impact of out-of-range offsets, or any side effects (which are likely none given the read-only nature). The disclosure of base64 encoding is useful and beyond what the schema reveals.

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

  Conciseness4/5

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

  The description is efficiently structured with a single purpose sentence followed by a compact parameter list and a one-line return specification. It is appropriately sized for a simple read operation with three parameters. No filler or redundant content, though the return format could have been included in the parameter section for tighter structure.

  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 this is a relatively simple read operation, the description covers the necessary usage context: what it reads, how to configure reads (offset/length), and what comes back (base64 + metadata). The output schema exists, so return format details beyond base64 encoding are handled elsewhere. The only minor gap is explicit usage guidance versus sibling tools, but the overall definition is functionally complete for an agent to call it correctly.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description is fully responsible for parameter semantics. It explains resource_id as 'the resource ID of the buffer to read', offset as 'byte offset to start reading from', and length as 'Number of bytes to read, 0 for entire buffer'. These definitions add meaningful context beyond the bare schema types and defaults, particularly the semantic meaning of the default 0 values.

  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 clear verb ('Read') and resource ('buffer resource'), and provides enough detail to distinguish it from siblings like get_texture_data (which reads textures) and get_draw_calls (which reads draw call lists). It does not explicitly differentiate from get_texture_info, but the buffer-specific focus is clear enough for an agent to identify the resource type it operates on.

  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 context through the 'read' framing and buffer resource specification, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. An agent might reasonably infer that this reads raw buffer data while get_texture_data handles textures, but this is left to inference rather than stated.

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

• get_draw_call_detailsA
  3.7/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 of behavioral disclosure. It mentions the output includes vertex/index counts, resource outputs, and other metadata, which gives some insight into its read-only nature and return content. However, it does not explicitly state it is read-only, mention any permissions, or note any side effects or limitations (e.g., only works on captured frames).

  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 well-structured: it states the purpose in the first line, then provides the parameter explanation, and then summarizes the output contents. No redundant information, and the most important detail (what it does) is front-loaded. Every sentence earns its place.

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

  Completeness3/5

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

  The description lacks context about the operational environment. It doesn't mention that a capture must be open or that event_id likely comes from get_draw_calls/results. While the output schema exists and the description mentions expected fields, prerequisites for calling this tool are not stated, making it incomplete for an agent encountering it for the first time.

  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?

  Despite the schema having no property descriptions, the description's Args section explicitly explains event_id as 'the event ID of the draw call to inspect,' adding meaning beyond the plain integer type in the schema. This fully clarifies the parameter's purpose, so the description compensates for the lack of schema descriptions.

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

  Purpose5/5

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

  Description clearly states the tool retrieves detailed information about a specific draw call. The verb 'Get' and resource 'detailed information about a specific draw call' distinguish it from siblings like get_draw_calls (which lists draws) and find_draws_by_* (which searches by criteria). Purpose is unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an open capture), how to obtain an event_id (e.g., from get_draw_calls), or any scenarios where it should not be used. The usage context is entirely left to the agent to infer.

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

• find_draws_by_resourceA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It explains the exact-match behavior, the return payload (draw calls with event IDs and match reasons), and the scope of resources searched. It does not mention side effects or permissions, but for a read-like search this is sufficient and adds meaningful context beyond the 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?

  The description is concise and well-organized, with a clear opening line, an Args section, and a returns/scope section. Every sentence contributes useful information without redundancy, making it efficient for an agent to parse.

  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 presence of an output schema (though not shown), the description covers the key return details (list of draw calls with event IDs and match reasons) and the resource scope. It lacks information about pagination or limits, but these are minor for a single-parameter search tool, so overall it is appropriately complete.

  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 description compensates by explaining the resource_id parameter with an example format (e.g., 'ResourceId::12345' or '12345'). This provides practical guidance on acceptable input, which the schema alone does not offer, making the description essential for correct invocation.

  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: finding draw calls that use a specific resource ID via exact match. It specifies the resource types searched (shaders, SRVs, UAVs, render targets, depth targets), distinguishing it from sibling tools like find_draws_by_shader and find_draws_by_texture, which use different criteria.

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

  Usage Guidelines2/5

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

  The description implies usage when a resource ID is known, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusion criteria. It never references sibling tools, so an agent must infer the appropriate context from the description alone.

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

• find_draws_by_shaderA
  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 discloses partial match behavior and that it searches all stages by default, and it mentions the return format (list with event IDs and match reasons). However, it does not explicitly state that the operation is read-only, nor does it mention potential performance implications or pagination. The provided details are useful but not exhaustive.

  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 efficient and well-structured. The first sentence states the core action, followed by a clear 'Args' section and a return description. There is no fluff, and the most important information (partial match, optional stage) is front-loaded.

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

  Completeness4/5

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

  The description covers the main aspects needed to invoke the tool: what it searches for, the parameters, and what it returns. Given the existence of an output schema (which likely details the return structure), the description does not need to over-explain returns. Minor gaps like handling of no matches or sorting are not critical. It is complete enough for an agent to use correctly.

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

  Parameters4/5

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

  Schema coverage is 0%, so the description must compensate. It does: it explains shader_name as 'Partial name to search for in shader names or entry points' and stage as 'Optional shader stage to search (if not specified, searches all stages)'. This adds meaningful context beyond the raw schema, which only defines types. The description effectively documents both parameters.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Find') and resource ('draw calls using a shader'), and even specifies partial matching. This distinguishes it from siblings like find_draws_by_texture and find_draws_by_resource, which target different attributes. The purpose is immediately obvious.

  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 when to use it (when searching draws by shader name or entry point) but does not explicitly mention alternative tools or conditions for not using it. The parameter guidance (e.g., 'if not specified, searches all stages') is helpful, but the description does not contrast with siblings.

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

• find_draws_by_textureA
  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 behavioral disclosure burden. It adds meaningful traits beyond the name: partial matching on texture resource names, searching SRVs/UAVs/render targets, and returning event IDs with match reasons. This gives an agent a clear picture of what the search covers, even though side-effect language is not explicit.

  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, with a clear one-line purpose followed by Args and Returns sections. Every sentence earns its place, and the most important behavioral scope statements are front-loaded.

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

  Completeness4/5

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

  Given the single parameter, no annotations, and an existing output schema, the description covers the key operational context: input semantics, search domains, and return contents. It does not discuss potential side effects or performance, but for a search-style tool the description is largely sufficient.

  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%, so the description must explain the parameter. It clearly defines texture_name as a partial name to search against texture resource names, which directly compensates for the bare schema. It could add case-sensitivity or wildcard details, but the essential semantics are present.

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

  Purpose5/5

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

  The description states a specific verb and resource—find draw calls by texture name—and clearly differentiates from siblings like find_draws_by_shader or find_draws_by_resource. The addition of 'partial match' and 'Searches SRVs, UAVs, and render targets' makes the tool's scope unambiguous.

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

  Usage Guidelines3/5

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

  The usage context is implied through the description: use this when you need to locate draw calls referencing a texture by name. However, it does not explicitly state when to prefer this over sibling tools like find_draws_by_resource or find_draws_by_shader, nor does it mention any exclusions.

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

• get_frame_summaryA
  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 burden. It is clearly framed as a read-only summary operation and discloses what information will be returned. It does not address edge cases like calling before a capture is opened, but no contradictory destructive or mutating behavior is implied.

  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, begins with a one-sentence summary, and uses a compact bullet list to convey the return categories. Every part adds useful information 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 no-parameter getter with an output schema, the description is largely complete: it summarizes the categories of returned data and requires no input configuration. The only notable gap is not mentioning the prerequisite of an open/current capture, which appears to be implied by sibling tools like open_capture.

  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 and 100% schema description coverage, so there is no parameter detail the description needs to add. The baseline for a no-parameter tool is 4, and the description appropriately focuses on the return content 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 states a specific verb ('Get') and resource ('current capture frame') and clearly enumerates the contents of the summary. The bullet list distinguishes it from sibling tools that target individual draw calls or buffer contents, so an agent can tell this is the frame-level statistics tool.

  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 as the go-to for high-level frame statistics, listing draw calls, dispatches, markers, and resource counts. However, it does not explicitly say when to prefer this over get_capture_status or get_draw_calls, nor does it mention that a capture/frame must already be open.

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

• get_shader_infoA
  4.2/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 what the tool returns (disassembly, constant buffers, resource bindings) but does not state side effects (e.g., read-only behavior), permissions, or error conditions. The 'get' verb implies non-mutating, but this is not explicit, leaving some behavioral uncertainty.

  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: one purpose sentence, an Args block with per-parameter explanations, and a one-line return summary. It is front-loaded with the core purpose and wastes no words. Every sentence contributes to understanding the tool.

  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's simplicity, an output schema exists (which handles return structure), and the description covers purpose, parameters, and return content. There is nothing an agent needs to call it correctly that is missing. It fully addresses the 'what' and 'how' for this tool.

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

  Parameters5/5

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

  The description adds substantial meaning beyond the bare schema. It explains that event_id is 'the event ID to inspect the shader at' and stage is enumerated with all six possible values. Since schema coverage is 0%, this description fully compensates and gives the agent clear guidance on what each parameter means.

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

  Purpose5/5

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

  The description clearly states the verb 'Get', the resource 'shader information', and specifies scope ('specific stage at a given event'). It distinguishes itself from siblings like get_draw_calls or get_texture_info, which deal with different resources. The return types are also previewed, leaving no ambiguity about what the tool does.

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

  Usage Guidelines3/5

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

  The description implies when to use it (when you need shader details for a particular stage/event) but does not explicitly contrast it with alternatives like find_draws_by_shader or get_pipeline_state. It provides context but lacks explicit exclusions or 'use instead of' guidance, so it's adequate but not fully proactive.

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

• get_texture_dataA
  4.2/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 full burden of behavioral disclosure. It states it returns base64-encoded bytes and metadata, and describes parameter semantics (like cube map face ordering). However, it does not mention potential side effects, error conditions, or authorization requirements. For a read-only operation, the description adequately implies non-destructive behavior but lacks full transparency on failure modes.

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

  Conciseness4/5

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

  The description is structured with a clear purpose statement, then a numbered Args list, followed by a return description. It is front-loaded with the core action and does not waste words. The details are necessary given the parameter complexity, so the length is justified and remains organized.

  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 parameter-rich read tool with an existing output schema, the description covers the essential aspects: what it does, parameter meanings, and return format. It could further address error handling or prerequisites (e.g., valid resource ID), but given the tool's simplicity and presence of an output schema, it is largely complete.

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

  Parameters5/5

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

  The input schema has no descriptions for parameters (0% coverage), so the description must compensate. It does exceptionally well: each parameter is clearly defined, including special semantics for slice (cube map face indices) and depth_slice (3D texture extraction). This far exceeds what the schema provides and is essential for correct usage.

  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 'Read the pixel data of a texture resource' which identifies the specific verb (read) and resource (texture pixel data). This distinguishes it from sibling tools like get_texture_info which likely returns metadata, and get_buffer_contents which targets general buffers. The purpose is explicit and 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 that this tool is for reading texture pixel data, which is distinct from other tools that retrieve info or buffer contents. However, it does not explicitly state when to use this tool over alternatives or provide exclusion conditions. The context is clear but not as directed as it could be.

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

• open_captureA
  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 full burden of behavioral disclosure. It explicitly notes that opening a capture will close any currently open capture, which is a key side effect. It also mentions the return type. However, it does not disclose error behavior (e.g., invalid path) or whether the operation is safe/reversible, but the side effect disclosure is valuable and goes beyond the 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?

  The description is concise and well-structured with clear sections: a one-sentence overview, an Args section, a Returns line, and a Note. Every sentence adds value—no filler. The side effect is front-loaded via the Note, making it prominent. It is appropriately sized for a simple one-parameter 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?

  There is an output schema (though not shown), so the description does not need to detail return values. It covers the main behavior (opening a file), the single parameter, and the key side effect. It lacks information about potential errors or preconditions, but for a straightforward 'open' tool, it is largely complete. The existence of an output schema means the return format is presumably documented there.

  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 description coverage is 0%, so the description must compensate. The 'Args:' section explicitly explains that capture_path is the 'Full path to the capture file to open', adding meaning beyond the schema's bare string type. This clarifies the expected format and intent, though it could specify path delimiters or relative path handling, but the provided explanation is sufficient for a single parameter.

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

  Purpose5/5

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

  The description clearly states the verb 'Open' and the resource 'RenderDoc capture file (.rdc)', which is specific and unambiguous. It also notes that it returns success status and information, distinguishing it from the sibling get_* tools which are read-only queries. The purpose is immediately clear.

  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 does not explicitly state when to use this tool versus alternatives. While it's implied that one must open a capture before querying it with the get_* tools, the description does not say so directly. There is no mention of when not to use it or any prerequisites. It provides functional context but lacks explicit routing guidance.

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

• get_action_timingsA
  4.3/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 of behavioral disclosure. It clearly documents default behavior (returns timings for all actions when event_ids is not specified), explains the marker_filter and exclude_markers semantics, and discloses the hardware dependency with 'GPU timing counters may not be available on all hardware/drivers'. The return structure is also fully outlined. Slight lack of explicit note about read-only nature, but this is minor for a query tool.

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

  Conciseness4/5

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

  The description is well-organized with an Args section and Returns section, keeping the purpose statement front-loaded. It is slightly longer than necessary but every section adds value—the note about hardware support is important. Nothing is redundant.

  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's moderate complexity (3 optional params, no output schema provided but described inline), the description covers all necessary details: parameter behavior, return format, and the hardware caveat. The agent has everything needed to call it correctly without additional documentation.

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

  Parameters5/5

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

  The description explains each parameter in detail: event_ids defaults to 'all', marker_filter is a partial-match filter, exclude_markers is a list to exclude. It also describes the effect of omitting each one. This goes far beyond the input schema, which only provides types and defaults. The 0% schema coverage means the description fully compensates.

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

  Purpose5/5

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

  The description opens with a specific verb+resource: 'Get GPU timing information for actions', and explicitly names example actions (draw calls, dispatches). This clearly distinguishes it from sibling tools like get_draw_calls (which lists actions) and get_frame_summary (which summarizes frames).

  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 explains what the tool does and how filters work, but never explicitly contrasts it with alternatives or states when to prefer this tool over get_draw_calls or get_frame_summary. The usage context is implied (for timing data) but no exclusions are given. This leaves the agent to infer selection.

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

• get_draw_callsA
  4.3/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 of behavioral disclosure. It explains the hierarchical return structure and describes the semantics of each filter (e.g., 'partial match', 'only include actions with flags'), making the tool's behavior predictable. While it does not explicitly state read-only semantics, the verb 'Get' implies it, and 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.

  Conciseness4/5

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

  The description opens with a one-sentence summary, then lists parameters in an 'Args' block. It is efficient and front-loaded, with no filler. The parameter explanations are concise but complete. It could arguably be more compact by merging some lines, but the structure is clear and appropriate for a tool with many filters.

  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 tool has seven optional parameters and returns a hierarchical tree of GPU actions. The description covers all parameters and states the output structure ('hierarchical tree of actions including markers, draw calls, dispatches, and other GPU events'). Since an output schema exists, detailed return type specifications are not required. No critical information is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, meaning the schema provides no property descriptions. The tool description fills this gap by explaining every one of the seven parameters, including defaults and meaning (e.g., 'Include child actions in the hierarchy', 'partial match' for marker_filter, and the list of flag names in flags_filter). This is essential for correct invocation.

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

  Purpose5/5

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

  The description states a specific verb ('Get'), a specific resource ('all draw calls and actions'), and a scope ('current capture'). It clearly distinguishes itself from siblings like 'get_draw_call_details' (details of a single draw call) and 'find_draws_by_shader' (filtered search), so an agent can tell them apart without opening schemas.

  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 purpose implies usage when an agent needs the full picture of draw calls and actions, but there is no explicit guidance on when to choose this tool over alternatives like 'find_draws_by_shader' or 'get_frame_summary'. No when-not-to-use conditions or alternative names are mentioned, leaving it to inference.

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

• list_capturesA
  4.3/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 of behavioral disclosure. It does state the return schema (filename, path, size, modified time) and that it lists files in a directory, implying a read-only, non-destructive operation. But it does not reveal whether the search is recursive, how it handles missing/unreadable directories, or sorting order—minor gaps for a listing tool but not critical.

  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 efficiently structured: a one-line purpose, then a compact Args section, then a Returns list. Every sentence adds value—no filler, no repetition of the tool name. It front-loads the core function and provides exactly the metadata an agent would need.

  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's simplicity (one parameter, one purpose), an output schema exists (confirmed by signal), and the description explicitly enumerates all return fields, the description is complete for correct invocation. No additional context is required for an agent to decide to call it and interpret results.

  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 description coverage is 0%, so the description must compensate. It does: the 'Args' section explicitly explains that 'directory' is the path to search, giving the parameter purpose and type (string). While it doesn't specify path format (absolute vs relative) or permissions, it fully covers what an agent needs to know to provide the one required parameter.

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

  Purpose5/5

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

  The description uses a specific verb ('List') and a concrete resource ('RenderDoc capture files (.rdc) in the specified directory'). It clearly differentiates from siblings like get_buffer_contents or get_draw_calls, which operate on a single capture's internals rather than enumerating files. The scope is 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—you use this to locate .rdc captures on disk—but it does not explicitly state when NOT to use it or name alternatives (e.g., 'use open_capture to load a specific file'). However, the purpose is so distinct from the siblings that the usage context is effectively self-evident.

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

• get_pipeline_stateA
  4.5/5.0
  Behavior4/5

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

  With no annotations at all, the description carries full responsibility. It discloses the exact nature of the operation (a read of pipeline state) and details the full return structure, which constitutes behavioral transparency. It does not mention side effects or prerequisites beyond the event_id, but as a 'get' operation those are not expected, so the coverage is adequate.

  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 with a lead sentence stating the purpose, followed by an Args section and a bulleted list of returned state. It is concise yet comprehensive, front-loading the core purpose and using formatting for readability without unnecessary 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 single-parameter tool with an output schema, the description is complete: it specifies the input, explains the output in detail, and provides enough context for an agent to use it correctly. The inclusion of a full return breakdown makes it self-sufficient even without inspecting the output schema.

  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 only defines event_id as an integer with no description (coverage 0%). The description adds an explanation: 'The event ID to get pipeline state at', which clarifies the parameter's purpose beyond the raw type. It compensates for the schema's lack of description, though more detail about what constitutes a valid event ID (e.g., from a capture) would be even better.

  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 retrieves the 'full graphics pipeline state at a specific event' and enumerates the detailed components (shaders, resources, samplers, etc.). This verb-resource pair is specific and distinguishes it from siblings like get_draw_call_details or get_shader_info, which focus on narrower aspects.

  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 implicitly conveys usage by requiring an event_id and stating the tool returns state at that event, implying one should use it when needing a comprehensive snapshot. However, it does not explicitly mention when not to use it or point to alternatives, which is a minor gap given the diverse sibling set.

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