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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description correctly does not claim any mutation. It adds useful context by saying the response contains commit hash, fetch date, counts, and licence, which the agent cannot learn elsewhere since there is no output schema. However, 'how to refresh it' is ambiguous about whether the tool returns refresh instructions or performs a refresh, and no caching/staleness behaviour is disclosed.

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

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

A single sentence with no filler, and the most important element (version identity) is front-loaded. The only weakness is the fragmentary opening and the slightly vague trailing clause about refreshing.

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 zero-argument, read-only metadata tool with no output schema, the description covers the essentials: what is reported (version, fetch date, counts, licence) and a hint at refresh guidance. It is close to complete; a sentence clarifying that the tool only reports and does not trigger a refresh would close the remaining 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 tool takes zero parameters, which is the baseline-4 case; there is nothing parameter-wise for the description to explain. It does not mislead about inputs, and calling it requires no arguments.

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 names the resource (BJJGraph version metadata) and enumerates the specific contents: commit, fetch date, counts, and data licence. That is enough to distinguish it from the seven sibling tools, all of which retrieve graph content rather than environment metadata. It is phrased as a sentence fragment, but the intent 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?

There is no explicit statement of when an agent should call this tool versus just proceeding with bjj_search or bjj_get_technique. The phrase 'how to refresh it' hints at a diagnostic/provenance use case, but the description never says to check this before trusting counts, nor that it is optional context. Usage is only weakly implied.

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 safety is covered. The description adds real behavioral context beyond them: routes are restricted to successful technique outcomes only, and when the target is a submission the routes terminate at a position where it can be attempted rather than at the submission itself. That is exactly the kind of semantic quirk the schema cannot express.

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?

Three tight sentences, front-loaded with the core action, then the output shape, then the submission special case. Minor deduction: "a few" is vaguer than necessary when max_paths has a documented default of 3.

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 no output schema, the description steps up by sketching the return shape (each step lists the techniques that achieve it) and the semantics of the submission-target mode. It does not mention path ranking/ordering or what happens when no route exists, which are the remaining gaps for a search 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?

Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond it by demonstrating the accepted position string form, including role notation ("Half Guard bottom → Back Control top"), and by clarifying that the `to` value may be a submission name — a non-obvious dual-mode input the schema only hints at.

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: "Finds a few shortest routes from one position to another using only successful technique outcomes." The parenthetical example (Half Guard bottom → Back Control top) makes the domain concrete, and the sibling set (search, get_technique, get_position, position_options) has no other path-finding tool, so it is unmistakable.

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?

Usage is implied by the description — call it when you want routes between two positions — but there is no explicit when/when-not guidance or comparison to siblings like bjj_position_options or bjj_search, which an agent could plausibly choose instead. The submission-target case is the only conditional rule given.

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 establish that this is a safe read-only operation against a closed knowledge base. The description adds useful context about the content returned for each concept type, but it does not explain pagination behavior or response format beyond implying that results may be long.

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 front-loaded sentence that identifies the tool's scope immediately and uses its parenthetical details to clarify the three concept categories. Every clause contributes useful information without 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 read-only retrieval tool with a fully described schema and no output schema, the description gives enough information about what content is returned. It omits explicit pagination details, but page and max_chars are documented in the schema, so the remaining gap is minor.

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 goes beyond the schema by explaining what the system, principle, and learning note categories contain, which helps an agent choose the appropriate type filter rather than just reading the enum values.

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 retrieval action and names the three concept categories it returns: system, principle, and learning note. It clearly distinguishes concept content from the sibling retrieval tools by describing what kinds of resources are covered, though it does not explicitly contrast those siblings by name.

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 phrase 'Full content' implies this tool should be used to retrieve details after a broader search or listing, but it does not explicitly say when to use this versus bjj_search, bjj_list, bjj_get_technique, or bjj_get_position. Usage is inferable from the description, but not fully routed.

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 safety is covered. The description adds useful return-content detail, but it does not disclose pagination/truncation behavior despite supporting page and max_chars parameters.

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, front-loaded sentence that lists the returned sections without obvious filler. It is dense but appropriately sized, though the long colon-delimited list makes it slightly run-on.

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 full schema coverage and useful annotations, the description supplies the missing return-content picture by naming the detail sections and attempt weights. It omits pagination/default behavior, but that is documented in the schema, leaving only a minor 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?

Schema description coverage is 100%, so the schema already documents name, role, sections, page, and max_chars. The description repeats the role and section concepts but adds no syntax or defaults beyond what the schema provides.

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 identifies the resource as one BJJ position and enumerates the detail returned (overview, principles, decisions, drills, menu, related positions, clips). It is specific enough to distinguish this as a detail-retrieval tool, but it does not explicitly differentiate itself from siblings such as bjj_get_technique or bjj_position_options.

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 no explicit guidance on when to use this tool versus bjj_position_options, bjj_search, or bjj_get_technique. Usage is only implied by 'Detail for one position,' with no exclusions or alternative-routing instructions.

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 safety profile is covered. The description adds what categories of content exist (outcomes, probabilities, counters, safety, clips), but says nothing about pagination behavior, defaults, or output size limits beyond the schema's page/max_chars fields. No annotation contradiction.

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?

Front-loaded with the core purpose ('Full detail for one transition or submission'), followed by a compact enumeration of what is included and one practical tip. No wasted framing, though the long section list is slightly dense.

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?

All five parameters are documented, annotations cover safety, and there is no output schema to explain. The description tells the agent what content areas exist and how to narrow retrieval via `sections`, which is enough to call it correctly. Minor gap: no explicit mention of how page and max_chars interact for long results, though the schema covers the basics.

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 name, page, sections enum, max_chars, and perspective. The description reinforces the meaning of `sections` ('fetch only what you need') and lists returned content categories, but adds no format, ordering, or interaction details beyond the schema. 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?

States a specific verb and resource: 'Full detail for one transition or submission', and enumerates the content categories returned. It is clearly distinguishable from list/search siblings by implication, but never names a sibling or explicitly contrasts 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 only usage guidance is 'Use `sections` to fetch only what you need', which is a tuning tip rather than when-to-use-this-vs-alternatives guidance. There is no explicit exclusion or routing cue relative to bjj_search, bjj_get_position, or bjj_find_paths.

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 safety and scope are covered structurally. The description adds that results include a 'one-line summary,' which is useful behavioral context beyond the schema. It does not describe pagination behavior or other operational details, so the added value is modest.

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 sentences with no wasted words. The core listing behavior is front-loaded, followed by the optional filter note, making it easy to scan.

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 rich schema, annotations, and the absence of an output schema, the description provides enough context: it names the supported kinds, says results are one-line summaries, and mentions the optional filter. No critical calling information 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 100%, so the baseline is 3. The description adds semantic clarity for the 'type' values by mapping 'system' to game plans/courses and 'submission' to submission families, going beyond the enum labels even though the schema already documents the parameters.

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: 'Lists entries of one kind with a one-line summary.' It also enumerates the supported entry kinds, making the tool's purpose clear. It does not explicitly contrast itself with siblings like bjj_search or bjj_get_technique, so it falls 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 usage is implied by the required 'type' parameter and the phrase 'Lists entries of one kind,' so an agent can infer this is the browsing/list tool. However, the description gives no explicit guidance on when to use this instead of bjj_search or the get tools, and no alternatives or exclusions are 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 already declare readOnlyHint and openWorldHint=false, so the description's job is to add context beyond safety. It does: results are ordered by most-commonly-attempted first, each entry carries a success rate, and each outcome maps to where it leads (success/failure/counter). No auth, rate-limit, or paging behavior is discussed, but the substantive output semantics are 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?

One dense sentence with no filler, front-loaded with the verb and resource. It is slightly run-on because the output contract (ordering, success rate, outcome destinations) is packed into the same sentence, but every clause carries information.

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?

There is no output schema, so the description must describe results, and it does: ordering, success rate, and outcome destinations. With 100% schema coverage on the six (mostly optional) parameters, the gaps are minor — nothing states that role defaults to both or that the position string can encode a slash-suffixed role, though the schema examples cover that.

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 enums document role, type, and ruleset, so the schema carries the parameter burden. The description's only added semantics are 'in a given role' and the ordering of results; it does not explain how ruleset affects probabilities or how limit interacts with roles. Baseline 3 applies.

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: lists transitions and submissions available from a position in a given role. The scope is clearly narrower than a position lookup (bjj_get_position) or a search (bjj_search). It never names a sibling explicitly, so sibling differentiation is only inferable from the scope wording.

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?

Usage is implied by the title 'What can I do from here?' and by the phrase 'from a position in a given role', which suggests pairing with a position lookup. There are no explicit when-to-use/when-not statements and no reference to alternatives such as bjj_get_position or bjj_find_paths, so the agent must infer the 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 cover safety (readOnlyHint=true, openWorldHint=false), and the description adds real behavioral color beyond them: matching is fuzzy, aliases are searchable, partial English names resolve, and Korean terms are auto-translated. It does not describe result ordering or pagination behavior, but the schema already documents limit/offset.

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 tight sentences with no filler; the resource coverage is front-loaded and the fuzzy-matching caveat follows immediately. Every clause carries information an agent can act on.

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 search over a fully documented schema, the description covers what can be matched and the fuzziness caveat. With no output schema, it could have said what a result looks like (name + type + id), but that gap is small for a search 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?

Schema coverage is 100%, so all four parameters including the type enum are fully documented in structured fields, giving a baseline of 3. The description adds only marginal semantics for 'query' (aliases, partial names, Korean translation) beyond the schema's own 'name or part of a name' wording.

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 ('Fuzzy search') and enumerates the resource types it covers (positions, transitions, submissions, systems, principles, learning notes), which distinguishes it from the get_* and list siblings by its search-oriented nature. It does not explicitly name the sibling it replaces, so differentiation is implied rather than stated.

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 lookup usage and notes that partial English names work and Korean terms are translated, which is useful query guidance. It never says when to use this instead of bjj_list or bjj_get_technique/bjj_get_position, leaving the search-vs-retrieve choice to inference.

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