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

With no annotations, the description carries the full burden. It explicitly states the action is to 'Report' and 'Tells', clearly indicating a read-only informational tool. It also discloses the nuance about non-deterministic values, making its behavior transparent.

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

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

The description is two concise sentences. The first states the primary action, and the second adds useful nuance about determinism. No redundancies or unnecessary details are present.

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

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

The description is complete for the tool's simple nature: it states the purpose and the key nuance about model-dependent non-determinism. It does not enumerate which specific registers are reported or the output format, but this is not critical given the tool's simplicity and lack of an output schema.

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

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

The schema description for the single 'model' parameter already covers 100% of its semantics, listing valid values and the meaning of omission. The tool description adds no additional parameter detail, which is acceptable given the high schema coverage.

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

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

The description uses a specific verb ('Report') and clearly identifies the target: register values inherited from the boot ROM at PC=$0100. It distinguishes itself from other register-related tools by focusing on boot state and entry-point determinism.

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

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

The description implies the intended usage scenario: when you need to know the reliable register state at the ROM entry point and which values are non-deterministic per model. It does not explicitly name alternative tools or state 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.

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

With no annotations present, the description carries the full burden of disclosing behavior. The verb 'show' suggests a read-only operation, but there is no explicit statement about side effects, return format, or error conditions. The description does not clarify whether it fetches documentation, parses a header, or returns a static layout.

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

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

The description is a single, concise sentence that front-loads the primary purpose. It avoids unnecessary words and clearly communicates the two modes of operation (layout vs. single field). Excellent structure for quick comprehension.

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

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

For a simple documentation tool, the description is largely complete: it states what it does and how the parameter affects the result. It does not specify the output format or provide examples, but given the tool's straightforward nature and the parameter description already included, the missing details are minor and unlikely to impede correct usage.

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

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

The tool description adds meaning to the 'offset' parameter by explaining that specifying a field yields its full documentation, while omitting it returns the whole layout. This pairs well with the parameter description ('An offset like '$0147'. Omit for the whole layout.') to give a clear understanding of the parameter's role. Since the schema already covers the parameter, the description adds extra context, elevating it above baseline.

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

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

The description clearly states the tool's function: to show the cartridge header layout or detailed documentation for a specific field. This is a specific verb ('show') and resource ('cartridge header'), and it distinguishes itself from related tools like gb_memory_map or gb_decode_cart_header by focusing on the header layout and field-level documentation.

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

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 over alternatives. It implies usage for understanding the cartridge header layout or a single field, but there is no contrast with sibling tools such as gb_decode_cart_header or gb_lookup_cart_code. No guidance on selection criteria is provided.

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

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

No annotations are present, so the description carries the full disclosure burden. It does a solid job: it reveals that the tool validates the Nintendo logo, recomputes the boot-ROM checksum, and that a mismatch means the ROM will not run—genuinely useful behavioral context. It stops short of describing error behavior (e.g., what happens with malformed hex or a failed checksum), but for a read-only decode tool this is a modest gap.

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

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

The description is two tight paragraphs: one line declaring the purpose, one enriching it with concrete verification details. Every sentence earns its place, and the purpose is front-loaded. No filler or repetition.

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

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

For a single-parameter tool with no output schema and no annotations, the description explains what happens during decoding and what the checksum consequence is, but it does not describe the return shape or failure modes. An agent cannot tell whether the tool returns structured fields, a pass/fail flag, or both. Since this information is not carried anywhere else, there is a noticeable completeness gap.

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

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

The schema already covers the single parameter well (hex bytes, two acceptable input shapes: 80 header bytes or the first $150). The description adds little beyond 'real header' and verification semantics, so it does not meaningfully extend the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Decode a real cartridge header and verify its checksum.' It further enumerates the actions (resolving codes, checking the Nintendo logo, recomputing the boot-ROM checksum), which clearly distinguishes it from siblings like gb_cartridge_header (likely a reference/spec) and gb_lookup_cart_code (single-code lookup). It does not explicitly name a sibling it is not, which keeps it from a 5.

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

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

The description implies when to use the tool: when you have actual cartridge-header bytes to decode and verify ('a real cartridge header'). The input schema adds the exact allowed shapes. However, it never says when-not to use it or which sibling to prefer for spec lookups or individual code resolution, so usage context is 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.

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

With no annotations, the description carries the full burden. It discloses what output fields are produced (mnemonics, operands, encoding, cycle counts, flag effects) and explicitly flags invalid opcodes that would hard-lock the CPU. It does not explicitly state that the operation is read-only, but that is strongly implied by 'Disassemble' and the described output.

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

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

The description is concise and front-loaded with the primary purpose. It uses only two sentences, with the second sentence adding relevant source attributions and invalid-opcode behavior. No redundant or filler content.

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

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

Given there is no output schema, the description provides useful context about the output fields (mnemonics, operands, encoding, cycle counts, flag effects) and edge-case handling (invalid opcodes flagged). It does not specify the exact output structure or types, but it gives enough context for an agent to understand what will be returned.

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

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

The schema descriptions already fully cover all three parameters (base, data, limit) with clear examples and constraints. The tool description adds no additional parameter semantics beyond what is in the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Disassemble SM83 bytes into instructions.' It uses a specific verb ('Disassemble') and resource ('SM83 bytes'), and it distinguishes itself from nearby lookup/table tools by focusing on decoding raw bytes into instructions.

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

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

No explicit guidance is given on when to use this tool versus alternatives like gb_lookup_instruction or gb_opcode_table. The description mentions data sources and invalid opcode handling, but does not state conditions such as 'use when you have raw bytes to decode' or contrast with sibling tools.

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

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

Since no annotations are provided, the description carries the full burden of explaining behavior. It does mention that it reports every bit's documented meaning and lists unknown bits separately, which is helpful, but it does not describe output format, error handling, or edge cases such as invalid register or value formats.

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

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

The description is concise and well-structured: a one-sentence summary followed by a clarifying example and a note about unknown bits. It contains no fluff and is easily scannable.

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

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

Given the tool's moderate complexity and lack of an output schema, the description provides sufficient context by explaining what the output conceptually contains (documented bits, separately listed unknown bits). It does not specify the exact output structure, but for selection and basic invocation purposes it is reasonably complete.

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

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

The schema already provides 100% coverage for both parameters with descriptive examples. The description adds context about disassembly usage but does not materially increase understanding of the register or value parameters beyond what the schema already states, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: explaining what writing a byte to a register configures, with a concrete disassembly example. It also distinguishes itself from sibling tools by framing itself as 'the tool for disassembly constants' and emphasizing per-bit documented meanings.

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

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

It gives clear context for when to use the tool (decoding register writes in disassembly) and states that unknown bits are handled separately rather than guessed. It does not explicitly mention alternative tools like gb_encode_register_value or when not to use it, so it falls slightly short of fully explicit guidance.

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

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

With no annotations, the description carries the full burden. It describes what the tool returns but does not explicitly state that it is a read-only computation, nor does it disclose error behavior or constraints on field values. For a pure function this is acceptable 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.

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

The description is concise—two sentences—with the primary purpose front-loaded and the output specifics following immediately. Every word contributes to understanding the tool's function.

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

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

Given the absence of an output schema, the description usefully lists the returned components (byte, breakdown, shift expression, assembly). It does not elaborate on edge cases or the exact format of these components, but for a tool with a nested object parameter and no output schema, the provided context is largely sufficient.

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

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

The schema already covers both parameters with descriptions (register name/address, fields object with value types). The tool description adds no additional semantic detail beyond the schema, so it does not exceed the baseline for high schema coverage.

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

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

The description clearly states the tool's function: 'Build the byte that produces a desired register configuration.' It also names the output artifacts (byte, binary breakdown, shift expression, RGBDS-style assembly), making the purpose specific and distinguishable from the sibling decode tool.

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

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

The description explicitly identifies this as the inverse of `gb_decode_register_value`, giving clear guidance on when to use it (for encoding) versus decoding. However, it does not mention other related lookup or list tools, leaving some comparison to the agent.

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

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

No annotations are provided, so the description is the sole source of behavioral information. It explains the nature of the content (tip/warning/danger callouts) but does not mention side effects, output format, or limitations. It gives some context about the kind of data returned, but not enough to fully set expectations for a read-only list tool.

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

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

The description is two sentences with no extraneous content. The first sentence states the primary purpose, and the second provides illustrative examples, making it front-loaded and efficient. All content is relevant and contributes to understanding the tool.

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

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

The description adequately explains the tool's purpose and gives examples of topics it covers. For a simple listing tool with optional parameters and no output schema, this is sufficient. It does not describe the return format, but that is not required given the tool's straightforward nature and the lack of an output schema.

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

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

The schema already provides descriptions for all three parameters (kind, limit, topic). The tool description adds context by mentioning examples like 'OAM' and 'STAT' that align with the topic parameter, but it does not add new meaning beyond what the schema already states. Since schema coverage is 100%, the description does not need to compensate, but it also does not enhance parameter understanding.

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

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

States verb 'List' and resource 'Pan Docs' hardware caveats', with examples like 'OAM corruption' and 'STAT blocking' indicating the scope. It clearly communicates what the tool does, though it does not explicitly distinguish it from sibling tools like pandocs_search or pandocs_get_section.

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

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

The description implies usage for retrieving hardware caveats and provides examples of topics (e.g., 'LCD-disable timing'), but it does not explicitly state when to use this tool over alternatives. The guidance is indirect, based on the wording and examples, rather than a direct comparison with sibling tools.

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

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

With no annotations, the description carries the burden of explaining behavior. It discloses what the tool returns: each vector with its IE/IF bit and priority, plus optional full documentation and dispatch rules when an argument is supplied. No side effects or error conditions are mentioned, but none are strongly expected for a documentation lookup tool.

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

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

The description is compact and well-structured: one sentence states the overall purpose, and one sentence details the output and argument-dependent behavior. There is no redundant or extraneous text.

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

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

The description gives enough context for correct use: it explains what output to expect, what the optional parameter does, and what additional detail is provided when a specific interrupt is selected. Given the simple parameter surface and no output schema, this is sufficiently complete.

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

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

The schema only specifies a nullable string, but the description's parameter documentation adds concrete accepted values ('$40', '48', 'VBlank', 'STAT', 'Timer', 'Serial', 'Joypad') and explains that omitting the argument returns all interrupts. This adds meaningful semantics beyond the type information.

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

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

The description clearly states the tool's purpose: explaining the interrupt system or a single interrupt in detail. It distinguishes itself from sibling tools focused on registers, opcodes, cartridges, and memory maps by targeting interrupts specifically.

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

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

The description implies usage when interrupt information is needed but does not explicitly contrast it with sibling tools or state when not to use it. It does explain the effect of providing or omitting the argument, which gives some practical guidance.

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

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

The verb 'List' strongly implies a read-only operation with no side effects, and the filters are described in the input schema. It does not detail output formatting or error behavior, but for a simple listing tool the core behavior is adequately disclosed.

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

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

The description is two concise sentences with no fluff. It delivers the core purpose, filter options, and usage context in a compact, readable form.

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

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

For a simple list operation with optional filters, the description is nearly complete. It lacks an explicit return format and does not state whether start/end bounds are inclusive, but those are minor gaps given the simple nature of the tool and the schema descriptions provided.

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

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

The schema descriptions already cover all parameters, including allowed values for group and model. The description adds useful conceptual grouping by mentioning model, group, and address-range filters, though it does not specify how filters combine.

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

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

The description clearly states the tool's function: listing hardware registers with optional filters by model, group, or address range. It also distinguishes this tool from gb_lookup_register by framing it as a survey operation.

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

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

The description gives a concrete usage scenario: survey a subsystem before drilling into a specific register with gb_lookup_register. It does not explicitly list non-use cases, but the guidance is enough to select this tool over the sibling lookup tool.

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

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 convey read-only lookup modes and gives a concrete example ($13 -> MBC3+RAM+BATTERY). However, it does not describe the output format, what happens when code/name are both provided or both omitted, or behavior on no match, which could matter given there is no output schema.

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

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

The description is compact and front-loaded. The first sentence states the three operational modes, and the second sentence adds the scope of the lookup tables. Every sentence earns its place without redundant filler.

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

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

For a relatively simple lookup tool, the description plus schema is mostly complete: parameters are well-documented and the lookup domains are enumerated. The main gap is that there is no output schema and no explicit return-format or edge-case guidance, but the tool's behavior is straightforward enough that this is a minor rather than critical omission.

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

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 useful semantics by relating kind values to real cartridge-header concepts and giving a concrete example mapping. It does not add much about the 'name' parameter beyond the schema, but the added context is meaningful.

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

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

The description opens with a clear verb and resource: 'Decode a cartridge-header code, list a whole table, or search it by name.' It also enumerates the covered code categories, which makes it easy to distinguish from sibling tools like gb_decode_opcode, gb_lookup_register, or gb_decode_cart_header.

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

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

The description gives clear context for when to use the tool: decoding a code, listing a whole table, or reverse-searching by name. It does not explicitly name alternatives or state when-not-to-use, but the usage context is clear enough for an agent to select it for cartridge-header code lookups.

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

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

The description discloses the key output contents: bit pattern, opcode bytes, example decoding, cycles, and flag effects. It does not explicitly mention error behavior for unknown mnemonics, but the read-only lookup nature is reasonably clear from the wording.

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

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

The description is brief and well-structured, with two sentences that cover purpose and return contents without unnecessary detail.

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

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

Given the lack of an output schema, the description does a good job listing what the caller can expect in the result. It stops short of specifying exact output formatting or handling of invalid mnemonics, but the provided information is sufficient for most lookup use cases.

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

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

The schema already provides a description with examples for the mnemonic parameter, and the tool description does not add substantial additional meaning. The examples give a sense of accepted formats, but no formal syntax or normalization rules are provided.

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

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

The description clearly states the tool looks up how an instruction is encoded and what it costs, distinguishing it from related tools like gb_decode_opcode which likely goes in the opposite direction. The resource is specific: instruction encoding information.

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

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

No explicit guidance is given about when to use this tool versus alternatives such as gb_decode_opcode or gb_opcode_table. The description implies lookup by mnemonic, but it does not state when this is the right choice or when another tool would be preferable.

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

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 nature of the operation ('look up' implies read-only) and details the returned data (address, aliases, access, models, bitfield layout, documentation text). It does not mention side effects or authentication, but for a lookup tool, this is sufficient and adds meaningful context beyond a bare action verb.

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

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

The description is two sentences with no redundancy. The first sentence states the purpose and input flexibility, the second lists the return contents. It is front-loaded with the primary action and includes all essential information without fluff.

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

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

For a tool with 2 parameters and no output schema, the description is sufficiently complete. It clarifies the input types and explicitly enumerates the return fields, so an agent knows what to expect. It does not describe the output format (e.g., JSON structure), but since no output schema is provided, this is a minor gap; the description still covers the essential usage details.

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

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 parameters thoroughly. The description only restates that query can be an address, name, alias, or description, which is already in the schema. It adds no new syntax or format details beyond what the schema provides, meeting the baseline for full coverage.

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

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

The description states a specific action ('Look up') on a specific resource ('hardware register') and enumerates the input forms (address, name, RGBDS alias, description). It clearly distinguishes from siblings like gb_list_registers (which lists registers) and gb_decode_register_value (which decodes values) by focusing on retrieving register details.

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

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

The description implies when to use the tool (when a register's details are needed) but does not explicitly mention alternatives or when not to use it. Sibling tool names provide context, but no direct guidance is given, so an agent must infer the appropriate choice.

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

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

The description discloses that documented behavior (masking, the $00->$01 rule, and mode dependence) is attached, and it names the input/output relationship. With no annotations provided, however, it stops short of describing the actual output format, error behavior, or 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.

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

The description is two sentences with no filler, redundant schema text, or irrelevant detail. The example is compact and directly supports the stated purpose.

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

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

The core context is present, but because there is no output schema and no annotations, the description leaves unspecified the exact return shape, failure cases (e.g., unsupported MBC or non-ROM address), and how the attached documented behavior is represented in the result.

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

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

The schema already covers all parameters, and the description reinforces their meaning by mapping `ld [$2000], a` to the address and value parameters. It adds only modest context beyond the schema, and it does not elaborate on how the `mbc` parameter's value influences the result.

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

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

The description clearly states the verb ('Identify'), the object ('which banking register'), and the scope ('a ROM-area write'). It also gives a concrete example (`ld [$2000], a` → 'MBC1 ROM Bank Number'), making the tool's purpose unambiguous.

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

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

The description implies when to use the tool—when decoding an opaque ROM-area write—and provides an illustrative example. However, it does not explicitly contrast it with sibling tools such as gb_mbc_info or gb_lookup_register, nor does it state prerequisites or non-goals.

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

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

No annotations are provided, so the description carries the full burden. It states what the tool summarizes but does not disclose side effects (e.g., whether it's read-only), error behavior for unknown mapper names, or any limitations. It also doesn't mention how the optional 'include_text' flag affects output, beyond what the schema already says. For a read-style tool, this is a notable gap.

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

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

The description is two sentences: the first fronts the core purpose, the second clarifies what 'quirks' means with concrete examples. There is zero fluff, and all information is relevant. It is highly concise and well-structured.

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

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

For a simple tool with two parameters and no output schema, the description is adequate: it conveys the scope of the summary. However, it lacks details on error handling (e.g., invalid names), the nature of the output (text, structured), and does not explicitly state that the operation is read-only. Given the absence of annotations, these are gaps that could affect agent decision-making.

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

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

Schema coverage is 100%, so both parameters ('name' and 'include_text') are already described. The description does not add any meaning beyond the schema; it merely reiterates the content type. Given the high schema coverage, the baseline of 3 applies, and the description adds no extra value.

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

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

The description clearly states the verb 'Summarise' and the resource 'a mapper', and enumerates what it covers: mapped memory ranges, control registers, and quirks. It also gives concrete examples of quirks, which distinguishes it from siblings like gb_memory_map or gb_lookup_register. An agent can immediately tell this tool is about per-MBC details.

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

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 info about a specific MBC) but does not explicitly mention alternatives or exclusion criteria. There is no 'use X instead for Y' guidance, so the agent must infer from the name and sibling list. This is implied usage rather than explicit direction.

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

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 clearly explains the two modes: with no address, it returns the full region table, I/O ranges, and jump vectors; with an address, it reports the memory region plus conditional details like hardware register, RST/interrupt vector, cartridge-header field, and banking register (when mbc is given). This discloses what the tool does and under what conditions. However, it does not mention side effects (likely none), error handling, or the output format, which are minor gaps given the tool's read-only nature implied by 'identify.' Overall, it provides strong behavioral context.

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

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

The description is concise and well-structured. It opens with a clear one-sentence purpose, then immediately explains behavior in two succinct conditional clauses. There is no redundancy or fluff; every sentence contributes to understanding the tool. The key information (what it does, what happens without an address, what happens with one, and the role of mbc) is front-loaded and logically organized.

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

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

The description covers the main behaviors and output components: full region table, I/O ranges, jump vectors, hardware register, RST/interrupt vector, cartridge-header field, and banking register. Given there is no output schema, this is a good effort at explaining what the tool returns. It does not mention edge cases like invalid addresses or how the output is structured (e.g., text vs. structured data), but these are relatively minor gaps for a lookup tool. Overall, it provides sufficient context for an agent to call the tool effectively.

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

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

Schema coverage is 100%—both parameters have descriptions in the schema. The description adds value beyond the schema by explaining how the 'mbc' parameter affects the output (which banking register a write would hit) and how omitting the address changes the result (returns the whole map). This enriches the semantic understanding of the parameters, even though the schema already covers their basic meaning. The description makes the interaction between parameters and output clearer, justifying a score above the baseline 3.

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

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

The description clearly states the tool's purpose: 'Identify what lives at an address, across every relevant source.' It specifies a verb (identify), a resource (address), and scope (across relevant sources). It also details the two modes (with/without address) and lists the types of information returned, which distinguishes it from sibling lookup tools like gb_lookup_register or gb_decode_cart_header that focus on specific aspects. This is a clear, specific, and differentiated purpose.

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

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

The description explains what the tool does in different scenarios (with and without an address) but does not explicitly state when to prefer this tool over alternatives. It mentions that it covers 'every relevant source,' implying it is the comprehensive choice, but it doesn't explicitly say 'for register-specific details use gb_lookup_register' or provide exclusion criteria. While an agent can infer usage context, the lack of explicit alternatives or conditions for selection leaves some ambiguity.

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

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

No annotations provided, so the description carries the burden. It implies a read-only action ('Show') but does not explicitly state safety or side-effect profile. It also doesn't mention output format or error cases. Adequate for a simple display tool, 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.

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

Two concise sentences, front-loaded with purpose and alternative. No wasted words, clear structure.

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

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

Given it's a display tool with one optional param and no output schema, the description covers the purpose, scope, and alternative. It doesn't describe output structure, but that's not critical for an agent to decide when to use it. Minor gap but mostly complete.

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

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

Schema coverage is 100% and the block parameter is described in the schema. The tool description adds no additional meaning to the parameter beyond what the schema provides, so a baseline 3 is appropriate.

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

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

Clearly states the tool shows the structural opcode map, listing specific blocks and placeholder definitions. It explicitly names the alternative gb_decode_opcode for concrete bytes, distinguishing it from siblings.

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

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

Provides explicit usage context: 'Use this to reason about encoding patterns' and directs to gb_decode_opcode for concrete bytes, giving a clear when-to-use and when-not-to-use.

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

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

With no annotations at all, the description carries the full behavioral burden. It does disclose a genuine behavioral trait: custom syntax is expanded into readable layouts, blockquotes, and real gbdev.io URLs. However, it says nothing about output size, error behaviors, or what the returned page content looks like beyond embellishment, leaving notable gaps for a tool with no annotations.

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

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

The description is three compact and purposeful sentences. The first anchors the purpose, the second clearly transmits the output-transformation details, and the third gives actionable flag usage. Every sentence earns its place with no redundant or purely decorative wording.

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

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

For a simple two-parameter read-only tool, the description covers what is returned, how syntax is transformed, and the intended first-step use of `sections_only=True`. It would be stronger if it named the sibling `pandocs_get_section` for direct section access or mentioned error behavior, but those are minor given the tool's simplicity.

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

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

The JSON schema already gives full coverage for both parameters, so the baseline is 3. The description adds workflow meaning to `sections_only` by saying to pass it first when only needing the outline, which gives the agent a concrete rule for when to set that flag beyond the bare schema description.

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

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

The description clearly states the tool reads a whole Pan Docs chapter/page with a specific verb and resource. It anticipates the sibling tool pandocs_get_section by emphasizing 'whole' and telling the agent to use `sections_only=True` when looking for the right section, making it easy to distinguish page-body retrieval from section-level retrieval.

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

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

The delimiter 'whole' and the instruction to pass `sections_only=True` first imply a workflow, but the description does not explicitly name or compare against nearby siblings like pandocs_get_section or pandocs_toc. Usage guidance is present, but it is limited to parameter usage rather than an explicit when-to-use/alternatives contrast.

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

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

With no annotations provided, the description carries the full burden. The word 'Read' explicitly indicates a non-destructive operation, and the description accurately describes what is returned. It does not mention side effects, but none are expected for a read operation.

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

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

The description is two sentences long, with no redundant words. It leads with the primary action and immediately provides helpful context. Every word adds value.

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

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

The description sufficiently explains what the tool returns (bitfields, hardware caveats, cross-references) and the input flexibility, which is adequate for a read-only fetch operation. Although there is no output schema, the description covers the essential expectations. The sibling context (pandocs_get_page, pandocs_resolve_link) helps situate it, though not explicitly referenced.

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

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

Both parameters are fully described in the schema. The 'ref' description gives multiple accepted formats (Page#slug, section title, #Anchor), and 'include_subsections' clearly states its effect. This exceeds the baseline of 3 for full schema coverage.

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

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

The description clearly states the action ('Read') and the resource ('one section'), and explicitly mentions the included content (bitfields, hardware caveats, cross-references), distinguishing it from a generic page fetch. The examples of acceptable inputs further clarify its scope.

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

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

The description provides concrete examples of when to use the tool ('a ref from a search result, a section title, or an anchor'), effectively guiding the agent to choose this tool when resolving references from other pandocs tools. It implies this is the section-specific alternative to pandocs_get_page.

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

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 states what it returns (page, slug, URL) and adds a notable behavior: it flags titles that occur on more than one page. This is a useful caveat. It does not mention side effects (likely read-only) or error handling, but for a resolution tool, this 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.

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

The description is two sentences, both essential. The first sentence states the core action and output; the second explains the rationale and a key behavioral flag. No fluff, front-loaded with the action.

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

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

For a simple one-parameter tool with no output schema, the description explains what the result is (page, slug, URL) and warns about duplicates. It does not specify the exact return format, but that is not required without an output schema. It could mention behavior on missing anchors, but overall it is complete enough for correct usage.

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

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

The input schema already fully documents the anchor parameter with a description and example. The description adds no extra semantic detail beyond what the schema provides. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Resolve') and a precise resource ('a `#Section Name` cross-reference'), and states the output (page, slug, URL). It also distinguishes itself from same-page anchors, which differentiates it from related tools like pandocs_get_section. The 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.

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

It provides clear context: Pan Docs anchors are book-wide, not same-page, so this tool is needed to follow them. This implies when to use it. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to decide. Slightly less than a 5 because it doesn't contrast with siblings like pandocs_search or pandocs_get_section.

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

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

With no annotations, the description carries the burden; it clearly conveys a read-only search-and-return behavior and hints at ranked output. It does not specify result shape, ordering details, or potential limits beyond the schema's limit max, but the core behavior is transparent.

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

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

The description is two short sentences that front-load the core function and then provide usage guidance. Every sentence earns its place with no redundant detail.

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

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

With four parameters and no output schema, the description gives enough context for a search tool: what it searches, what it returns, when to use it, and when to prefer siblings. It does not mention all sibling relationships, but that is not required for selecting this tool.

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

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

The schema already describes all four parameters, and the descriptions are accurate and sufficient. The description adds overall context and query examples but does not significantly expand on parameter semantics beyond the schema.

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

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

The description states a specific verb ('Search'), a definite resource ('all ~580 Pan Docs sections'), and an output ('ranked snippets'). It also distinguishes itself from sibling exact-lookup tools by noting when those are preferable.

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

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

It explicitly says the tool is 'Good for open questions' and gives concrete examples. It also tells the agent when not to use it: 'For a specific register or address, gb_lookup_register or gb_memory_map give an exact answer more cheaply.'

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

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

With no annotations provided, the description must carry the full burden. It does mention what the tool returns ('chapter titles, page ids, URLs and section counts') and implies it is read-only (listing chapters), but it does not explicitly address side effects, authentication requirements, or any limitations, leaving some transparency gaps.

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

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

The description is succinct, using only two sentences. It front-loads the core function, then provides usage guidance and return information without any unnecessary verbosity. The structure is clear and efficient.

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

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

Given there is no output schema, the description adequately explains what is returned. It covers the purpose, usage, and return payload. With no parameters and the tool's simple nature, the description provides all necessary context for an agent to correctly invoke it.

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

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

The input schema has no properties, so schema description coverage is 100% (trivially). Since there are no parameters, there is nothing additional for the description to explain. Per the baseline rule for high coverage, this scores a 3.

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

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

The description clearly states the tool's function: 'List every Pan Docs chapter, grouped by part.' It distinguishes itself from sibling tools by explaining it is used to orient in the book and to find page names for pandocs_get_page, making its unique role evident.

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

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

It explicitly tells when to use the tool: 'Use this to orient yourself in the book or to find the page name to pass to pandocs_get_page.' It does not explicitly state when not to use it or mention alternatives like pandocs_search, but the primary use case is well-defined and the context of sibling tools implies other functions.

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