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

Annotations declare readOnlyHint=true, and the description adds behavioral context by explaining that references are split into internal and external and that the tool supports jar paths, class directories, and nested jar notation. This goes beyond the annotations without contradicting them.

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: a one-sentence summary, a short 'useful for' framing, and a clean Args list. No filler or redundant content; every line contributes to selection or invocation.

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 the presence of an output schema, the description fully covers what the tool does, when to use it, and how to specify each parameter. Nothing essential is missing 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.

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

Schema description coverage is 0%, so the description carries the full burden of explaining parameters. It does so excellently: jar formats, class_name matching options, include_jdk scope, and limit meaning are all spelled out clearly, adding real value over the bare schema titles.

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 and resource: 'List the classes a compiled class references, split into internal and external.' This clearly distinguishes it from sibling tools like jar_read_source or jar_disassemble by focusing on dependency references rather than source or bytecode.

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 use cases: tracing what a class touches and identifying which dependency supplies a type, with the note that it works 'without decompiling anything.' It does not explicitly name alternative sibling tools, but the context is strong enough for an agent to infer when this tool is appropriate.

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?

Annotations only say readOnlyHint=true and openWorldHint=false, so the description carries meaningful extra value. It details what is included (declaration, annotations, fields, method signatures, generics, parameter names under -g, thrown exceptions, constant values) and explicitly what is not included (method bodies), giving an agent an accurate model of behavior.

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, well-structured, and front-loaded. The first sentence states the purpose, the second adds key trade-offs, and the Args block provides necessary parameter detail without redundancy. Every sentence contributes information not already present in the schema.

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 read-only outline tool, the description is complete: it covers input formats, resolution behavior, output scope, caveats about debug symbols, and exclusions. An output schema exists to define return values, so the description does not need to repeat those details. The only external reference, 'resolved like jar_find_class', is reasonable since that sibling already exists in the toolset.

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 0%, so the description must explain all parameters, and it does. Each param gets a concrete explanation: jar accepts paths or nested-jar syntax, class_name accepts FQCN/simple/glob and references jar_find_class resolution, visibility gives the allowed values, and the two booleans are explained with examples.

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 and resource: 'Show a class's API: declaration, annotations, fields and method signatures.' It clearly differentiates this from related tools by framing it as 'the cheap alternative to decompiling or reading source' and by stating that method bodies are not included, which distinguishes it from jar_read_source and jar_disassemble.

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 for when to choose this tool: when only an API outline is needed and decompiling/source is overkill. It also notes the exclusion of method bodies, which signals when another tool would be needed, though it does not explicitly name those alternative siblings or provide a when-not-to-use list.

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?

Goes well beyond the readOnlyHint annotation by disclosing an environmental requirement ('needs a JDK on PATH'), a supported-input limitation ('nested ! specs are not supported'), and a size-related behavior ('empty returns every method (often large)'). These details help the agent anticipate real-world failure modes and avoid huge outputs.

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 tightly organized: purpose first, usage guidance second, then a clean Args list. Every sentence adds operational value; there is no filler or repetition of structured data.

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 read-only inspection tool with an output schema and four parameters, the description provides all essential context: prerequisites, when to use it, parameter semantics, and an important limitation. Nothing critical is missing for selecting or invoking the tool correctly.

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 0%, so the description carries the full explanatory burden. It compensates thoroughly: jar is described as 'Archive path or classes directory' with a limitation, class_name as 'FQCN, simple name or glob', method with its empty-value behavior, and limit as 'Maximum lines of disassembly'.

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 and resource: 'Disassemble one method's bytecode with javap'. It clearly differentiates this from sibling tools by explaining it is for when 'the API outline and the source are not enough', which distinguishes it from jar_class_outline, jar_read_source, and similar tools.

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 when-to-use guidance: 'Reach for this only when the API outline and the source are not enough', with concrete examples like checking what a method compiles to or reading a class with no sources. It also gives a practical directive to 'Always pass method to keep it small', which helps the agent invoke it correctly.

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?

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: search scope (build output, Maven repo, Gradle cache) and the classifier behavior ('also list -sources, -javadoc and -tests jars'). No contradiction with 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 compact and front-loaded: core purpose first, then a practical use case, then parameter details. Every sentence earns its place with no redundant phrasing.

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?

Covers all four parameters, the search domain, and the intended workflow. Since an output schema exists, return values are already handled. The description is complete for correct invocation and routing.

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 0%, but the description fully compensates by explaining every parameter: query with glob example, search_path with path separator note, include_classifiers with concrete classifier names, and limit as maximum count. This adds real meaning beyond the bare 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?

States a specific verb and resource: 'Find jar files on this machine by name', with concrete scopes (build output, Maven repo, Gradle cache). The use case of turning a jar name into a path for other tools clearly distinguishes it from siblings like jar_find_class or jar_search.

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?

Gives explicit usage context: 'Use it to turn ... into a path you can pass to the other tools.' This implies when to invoke it, but does not name specific alternatives or state when not to use it. Clear context but lacks explicit exclusions.

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 annotations already declare readOnlyHint: true and destructiveHint: false, and the description adds meaningful behavioral context: supported archive forms, classes directories, nested jar notation, name matching modes, and limit semantics. It does not mention no-match behavior or the exact return composition, but those are secondary given the read-only safety profile.

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, front-loaded with the core purpose, then the use case, then structured parameter details. Every sentence carries information, and there is no filler or repetition that wastes an agent's attention.

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 three-parameter read-only lookup tool with no output schema, the description gives the agent enough to select and invoke it correctly: accepted inputs, match forms, limit behavior, and downstream tool chaining. The 'concrete class name' phrasing also clues the return value sufficiently.

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 provides no descriptions for its three properties, so the description fully compensates. The Args block explains jar with paths, class directories, and nested archives, name with simple/FQN/glob examples, and limit as the maximum matches returned. This is strong, concrete parameter documentation.

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 and resource: 'Find classes in an archive' by simple name, fully-qualified name, or glob. It also grounds the tool in a practical use case, turning 'where does HttpClient live' into a class name for downstream tools. It does not explicitly contrast itself with siblings like jar_find or jar_search, so it stops short of full sibling differentiation.

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 'Use this to...' sentence gives explicit guidance on when to invoke the tool: when you need to resolve a vague class reference into a concrete class name for jar_class_outline or jar_read_source. It does not state when not to use it or name a preferred alternative, so it misses the full 5-level 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the read-only nature is covered. The description adds useful behavioral context including the ability to point jar at a classes directory or `outer.jar!nested.jar`, and that an empty pattern matches everything. These are informative but largely parameter-level rather than deeper behavioral disclosures such as output shape or error cases.

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: a one-sentence purpose, two lines of usage guidance, and a clean Args list. Each sentence earns its place and the most important information is front-loaded. No filler or redundancy.

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 a 5-parameter tool with zero schema descriptions, the description is highly complete. It covers all parameters, provides examples, notes special cases, and mentions paging. The output schema exists, so the description need not detail return values. The only minor gap is sibling differentiation, which is already accounted for in other dimensions.

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 0%, so the description carries the full burden of explaining parameters. It does so thoroughly: jar's accepted forms, pattern glob syntax with examples, kind enum values, limit semantics, and offset paging. Every parameter is explained with enough detail for an agent to construct a correct call.

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 and resource: 'List entries in an archive, filtered by glob and kind.' This is clear and non-tautological. However, it does not explicitly differentiate this tool from siblings like jar_find or jar_search, so the agent must infer distinctions from the tool name and action alone.

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 practical usage hints for parameter values ('Use kind='text' to find configuration, kind='archive' to find jars bundled inside a fat jar') and recommends this tool over `unzip -l`. It does not, however, explain when to choose jar_list over sibling tools such as jar_find, jar_search, or jar_overview, leaving some selection 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?

Annotations already mark readOnlyHint=true, and the description aligns by describing a non-mutating summary operation. It adds useful behavioral context beyond annotations by specifying the output dimensions and the accepted input forms, including nested archives like `app.jar!BOOT-INF/lib/dep-1.0.jar`.

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: a one-sentence summary of behavior, one sentence of usage guidance, then a short Args block. Every sentence adds value, and the key guidance is front-loaded.

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 one required parameter, an output schema, and read-only annotations, the description covers all the information an agent needs to select and correctly invoke the tool. It also positions the tool among many siblings by saying to start here, reducing ambiguity in a crowded tool family.

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 0%, so the description must carry the parameter semantics. It does so thoroughly: 'jar' is explained as a path to jars, wars, aars, zips, exploded directories, or nested archives with a concrete syntax example. This fully compensates for the sparse 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 uses a specific verb ('Summarize') and names the exact resource and output fields: manifest, size, packages, class count, and source attachment. This makes the tool's purpose immediately clear and distinct from listing, searching, or extracting jar contents.

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 explicit when-to-use guidance: 'Start here when you meet an unfamiliar jar.' It also tells the agent what not to do instead ('instead of unzipping it or listing every entry'), which implies exclusions even if sibling tool names are not named.

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?

Annotations only mark readOnlyHint and openWorldHint; the description adds useful behavioral details: binary entries are described not dumped, the jar parameter accepts a classes directory or nested outer.jar!nested.jar path, and line numbers are 1-based. These go beyond the schema and annotations, though it does not cover error behavior or limits.

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: purpose in the first sentence, followed by one usage tip and a concise parameter list. No redundant or marketing language.

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 unusual path forms, binary-entry behavior, and line-selection parameters, which is sufficient for most invocations given the available output schema and readOnly annotation. It falls short only in not clarifying the boundary with jar_read_source for Java source code.

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?

With 0% schema description coverage, the description fully compensates: jar's accepted path forms are specified, entry is defined as an exact path with an example, and start_line/line_count are explained as 1-based and line counts. Every parameter receives meaning beyond the bare schema property names.

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 a specific verb and resource: 'Read one text entry from an archive' and lists typical entry types (MANIFEST, service files, XML, config). It also notes binary entries are described rather than dumped, which clarifies scope, but it does not explicitly distinguish itself from sibling jar_read_source or other jar_* tools.

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 one comparative directive: 'Prefer this over unzip -p', and implies it is for text entries. It does not state when to use jar_read_entry versus the sibling jar_read_source or when not to use it, so the usage signal is mostly implicit.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the search order: inside the archive itself, then the matching -sources.jar in Maven or Gradle layout. It also explains the behavior when source is unavailable ('say so and fall back to jar_class_outline') and details the explicit sources_jar override. This is rich behavioral context that the annotations alone do not provide.

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 opening sentence states the core purpose immediately. The behavior is explained in a short paragraph, followed by a compact Args list that documents every parameter. Each sentence earns its place, and the fallback and override details are included without unnecessary verbosity.

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 five parameters, no schema-level descriptions, and an output schema present, the description is complete. It covers all parameters, explains archive/source resolution, gives the fallback path, and sets expectations about windowed reading. There is no meaningful missing information an agent would need to select or invoke it correctly.

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 0%, so the description must carry the full burden of parameter documentation. It does: jar accepts an archive path, classes directory, or nested jar syntax; target accepts an FQCN or entry path; start_line is 1-based; line_count is meant for windowed reading; sources_jar is an explicit override. This adds significant meaning beyond the bare schema properties.

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: 'Read attached Java/Kotlin source for a class, one line window at a time.' This clearly distinguishes it from sibling tools like jar_class_outline and jar_read_entry by focusing on source code and line-window access. The name and description align well, and the fallback mention reinforces its role.

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: reading attached source for a class, and explicitly says to fall back to jar_class_outline if no source is available. It also advises using a line window rather than reading entire files. It does not enumerate all sibling alternatives, but the fallback and windowing guidance provide practical routing.

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?

Annotations already establish readOnlyHint=true, and the description reinforces this by saying 'without extracting anything.' It also adds meaningful behavioral detail about searching inside .class files when include_class_strings=True and returning matching lines, going beyond the 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 compact and well-structured: a one-sentence purpose, a short usage rationale, then a clean Args list. Every sentence adds information without unnecessary padding.

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 has an output schema and annotations, the description fully covers invocation context: what to search, how to target entries, how to enable regex and class-string search, and how to limit results. No critical guidance is missing.

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 0%, so the description carries the full burden for parameters. It provides meaningful explanations for all seven parameters, including jar's support for classes directories and nested jar notation, query's regex option, path glob semantics, and the behavior of include_class_strings.

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 'Grep text and source entries inside an archive, returning matching lines,' which names a specific verb, resource, and result. It clearly distinguishes itself from sibling tools like jar_list or jar_find_class by focusing on content search rather than listing or class discovery.

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 concrete use cases: finding a property key, bean name, SQL fragment, or log message. It does not explicitly mention when to prefer a sibling tool, but the use-case framing and content-search focus make the intended context clear.

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