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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine context beyond them: results are bounded by server-side caps, continuation tokens are handled internally and never returned, and any incomplete result carries explicit completion evidence that must not be used for retirement decisions. That is meaningful disclosure of truncation 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?

Three short sentences, front-loaded with the core action and followed by the two facts that matter most (token handling and the retirement-decision caveat). Little waste, though the line-broken formatting makes it slightly harder to scan than a single tight paragraph.

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?

An output schema exists and covers return values, so the description need not narrate the result shape. It supplies what the schema cannot: the server-side paging model, the meaning of completion evidence, and a hard constraint on downstream use. Combined with annotations, an agent has enough to call this 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 for the three parameters, and it does not. The word 'bounded' gestures at max_pages and max_components but never explains what those caps mean, what defaults do, or what format the repository identifier takes (name, id, path). Only a vague hint of truncation semantics is 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 opens with a specific verb and resource: 'Collect a bounded complete repository component inventory server-side.' That is clearly a read/collection operation on repository content. It does not, however, distinguish itself from plausible siblings such as nexus_generate_inventory_json or nexus_generate_audit_report, so an agent must infer the boundary from the name 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?

Usage is only implied: the note that 'incomplete results must not be used for retirement decisions' tells the agent what this data feeds into, and the 'bounded complete' phrasing hints at a paging-limited enumeration. There is no explicit when-to-use versus the inventory or catalog siblings, and no stated prerequisites for the repository argument.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is supplied structurally. The description adds the useful distinction between live state and declared state, but does not explain what drift detection returns or any limits of the comparison; the output schema covers return values.

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 with no wasted wording. It is concise, though the brevity contributes to the missing usage and parameter details.

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?

This is a read-only comparison tool with an open-world, nested input object and an output schema. The description does not explain the declared_state structure or how the agent should use the drift result, so it is not complete enough for the tool's complexity.

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?

There is one required parameter, declared_state, with 0% schema description coverage and a nested arbitrary object. The description calls it 'a provided declared state' but does not explain its expected structure, format, or how it is compared to live state, so the semantic gap remains substantial.

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 ('Detect') and resource ('drift between live Nexus state and a provided declared state'), which clearly identifies a comparison operation. It does not explicitly differentiate from sibling tools, but none of the named siblings appear to perform state comparison.

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 guidance on when to use this tool versus the sibling tools, nor does it state prerequisites or exclusions. The comparison purpose is implied, but an agent must infer the appropriate context.

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 annotations' read-only, idempotent, and non-destructive safety profile, the description usefully discloses that detection is rule-based rather than, for example, AI-driven or based on arbitrary exploration. It does not clarify the scan scope, data sources, external accesses implied by openWorldHint, or limitations of the rules.

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 single compact sentence front-loads the action and concrete finding types, then adds a useful methodological qualifier. There is no redundant or unnecessary 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?

The annotations and output schema reduce the need to describe safety or return values, and the named checks provide a viable minimum for selection. However, the description omits what environment or resource set is scanned and how narrowly the rule-based results should be interpreted, which are meaningful gaps for a zero-argument scan.

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?

There are no parameters to explain, so the baseline for a zero-parameter tool applies. The description is consistent with a fixed set of checks and does not introduce any undocumented input behavior.

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 and enumerates the findings produced: unused resources, offline repositories, and configuration inconsistencies. The rule-based qualifier further clarifies the approach, but there is no explicit differentiation from the architecture, audit, or comparison 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?

Usage is implied: choose this tool when looking for the three named categories of architecture smells through rule-based checks. It does not state when these checks are appropriate, what they do not cover, or when to prefer nexus_audit_repository_content or nexus_compare_live_state_with_declared_state.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the scope of the explanation (storage, groups, cleanup policies) but says nothing about auth prerequisites, whether the explanation is derived from live or declared state, or how it differs behaviorally from the audit siblings.

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 front-loaded sentence with no filler and immediate scoping after the colon. It is efficient, though the terseness leaves gaps that a few more words could have closed.

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 tool is simple (one required parameter) and has an output schema plus annotations, so much of the burden is offloaded. Still, with zero schema description coverage and no usage guidance, an agent has to guess how to specify the repository name and when to prefer this over nexus_explain_storage_strategy.

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% for the single required "name" parameter, so the schema gives no semantics. The description only implies that name identifies the repository being explained; it does not state expected format (bare name vs. full path/qualified name) or error behavior for unknown repositories.

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 gives a specific verb ("Explain") and resource ("one repository") plus the facets covered: storage, groups, cleanup policies. That separates it from siblings like nexus_audit_repository_content or nexus_generate_inventory_json, though it does not distinguish it from the closely related nexus_explain_storage_strategy.

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 when-to-use guidance, no exclusions, and no pointer to alternatives despite several overlapping siblings (explain_storage_strategy, audit_repository_content, compare_live_state_with_declared_state). The agent must infer that this is the explanatory/read-out tool rather than an audit or generation 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?

Annotations already state readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that results come “with evidence,” which is useful behavioral context, but it does not explain scope, limitations, or what evidence is included.

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 with no redundant wording. Every part contributes to stating the tool’s 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?

With no parameters and an output schema present, the description does not need to explain return values. However, for an explanation tool in a rich sibling set, it remains thin on scope—such as which repositories are covered and what “evidence” means—leaving some ambiguity about how to apply 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 tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline score for a parameterless tool 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?

The description gives a specific verb and object: explain how blob stores are used by repositories. It is clear what the tool does, though it does not explicitly contrast itself with siblings such as nexus_explain_repository or nexus_understand_architecture.

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 guidance on when to choose this tool over related explanation tools. The intended use is implied by the name and description, but no conditions, exclusions, or alternatives are stated.

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 read-only, idempotent, non-destructive behavior, while the description adds the generated artifact's abstraction level and Markdown format. It does not clarify the architecture's source or scope, the significance of open-world access, or whether the document is returned rather than persisted.

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 single sentence is front-loaded with the action and includes only useful scope and format information. There is no redundant or unnecessary 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?

The description is sufficient to invoke a simple zero-argument tool, and the output schema removes the need to explain return fields. It still leaves the source and scope of the architecture unclear and provides too little selection context relative to closely related siblings.

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 has no parameters, so there are no parameter semantics requiring documentation; the zero-parameter baseline applies. Any ambiguity about the analyzed repository or environment is a scope issue rather than missing 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 gives a specific verb ("Generate"), resource ("high-level architecture overview document"), and format (Markdown). It does not explicitly differentiate the tool from nexus_understand_architecture or the other document-generation 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?

"High-level architecture overview" implies that the tool is appropriate when an overview document is wanted. However, there is no explicit when-to-use or when-not guidance, nor routing to nexus_understand_architecture for analysis rather than document generation.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds only "current" (implying freshness/no persistence of history) and "from available Nexus APIs" (implying dependence on which APIs are configured), but does not say whether anything is written to disk, what happens when APIs are unavailable, or how long generation takes.

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 short sentence with no filler and the action front-loaded. Its brevity works against it slightly, since the single sentence is essentially all the guidance provided.

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?

Return-value documentation is unnecessary because an output schema exists, and there are no parameters to explain. Still, for a zero-arg report generator the description is thin: it does not characterize the report's contents or scope, nor how it relates to the sibling audit tools, which is the main thing an agent needs to choose 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 tool takes zero parameters, so the schema carries no semantics that the description must compensate for; baseline 4 applies. The only descriptive nuance, scoping to "available Nexus APIs", slightly clarifies what the call operates against.

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 a specific verb and resource ("Generate ... audit report"), so an agent knows the action and product. However, it does not distinguish this from the closely related sibling nexus_audit_repository_content or other nexus_generate_* tools, leaving the boundary of "audit report" undefined.

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 guidance on when to call this versus nexus_audit_repository_content (which presumably produces the underlying audit data) or the other generate_* siblings such as nexus_generate_inventory_json. No prerequisites, sequencing, or exclusions are stated.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds only the notion that operations are bucketed by functional domain, which hints at output shape but says nothing about how domains are determined or whether the result is persisted anywhere. With annotations carrying most of the burden, a 3 is appropriate.

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 front-loaded sentence with no filler, and the core action plus grouping criterion arrive immediately. It is efficient but borders on under-specification for a tool whose name promises a 'capability map' that the sentence never defines.

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?

An output schema exists, so return values need not be explained, and with no parameters the call mechanics are trivial. Still, the description leaves open what a 'capability map' is, whether generation requires a loaded spec, and how this differs from sibling inventory/catalog generators — gaps that matter for a tool in a dense family of eleven siblings.

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, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is 100% and the empty properties object is self-explanatory.

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 gives a specific verb ('Group') and resource ('the instance's REST operations') plus the grouping dimension ('functional domain'), so the agent knows exactly what is produced. It does not, however, distinguish itself from nearby siblings such as nexus_openapi_list_operations or nexus_generate_inventory_json, which an agent could easily confuse with this grouping output.

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 guidance on when to call this versus nexus_openapi_list_operations or nexus_generate_inventory_json, and no stated preconditions (e.g. that an OpenAPI spec must already be loaded). The agent must infer the use case entirely from the one-line purpose.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and determinism profile is fully covered by structured data. The description adds only the output serialization format (JSON); it does not state scope (whole repository vs. current workspace), whether it scans the filesystem, or any cost/limit, which is what would earn a higher score given the annotation coverage.

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 front-loaded sentence with no filler, which is well-matched to a parameterless generator. It is arguably over-terse for a whole-repository scan, but every word earns its place and nothing is redundant.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What is missing is scope and differentiation: with eleven sibling artifact generators and no parameters, the description should say what "core Nexus objects" are and how this JSON inventory differs from the Markdown catalog.

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, so there is nothing for the description to disambiguate; the schema is empty and 100% described. Baseline 4 applies for a no-parameter tool.

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 ("Generate") and a specific artifact ("structured JSON inventory of all core Nexus objects"). An agent knows the action and output format, but "core Nexus objects" is undefined and nothing distinguishes it from the near-identical sibling nexus_generate_repository_catalog_md, which presumably produces the same inventory in Markdown.

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 when-to-use, when-not-to-use, or alternative-selection guidance at all. The many siblings (catalog_md, architecture_md, audit_report, capability_map) all produce repository-level artifacts, so the agent is left to guess which artifact it wants and when JSON is preferable to Markdown.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety and repeatability profile is covered structurally. The description only adds that the artifact is 'detailed' and Markdown-formatted; it does not say whether a file is written to disk or content is returned, or what the catalog covers.

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 short sentence with no filler and the key noun (catalog) front-loaded. It is efficiently written, though the brevity reflects under-specification rather than deliberate density.

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?

An output schema exists and no parameters need explaining, which lowers the burden considerably. Still, for a tool whose whole value is the generated document, the description gives no sense of the catalog's scope or how it differs from the inventory/architecture generators beside 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The sentence does confirm the output format, which is the only semantics available here.

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 ('Generate a detailed repository catalog document') plus the output format (Markdown), so the action is unambiguous. It stops short of distinguishing this catalog from sibling generators such as nexus_generate_inventory_json or nexus_generate_architecture_md.

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 when-to-use guidance, no mention of prerequisites, and no reference to any alternative tool. An agent facing four generation siblings (catalog, inventory JSON, architecture MD, audit report) gets no signal about which one to pick.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the useful nuance that the document is 'live' (fetched from the running instance) rather than static, but says nothing about result size, pagination, or failure behavior when the instance is unreachable.

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 front-loaded sentence with no redundant wording; the discriminating detail ('live') is placed where it will be read. It is arguably too terse, since one more clause about what is returned or when to prefer it would earn its space.

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 an output schema present and rich annotations, the description does not need to explain return values or safety. However, for a discovery tool sitting among eleven repository-analysis siblings, it should say how it relates to them (e.g., use this to enumerate endpoints before calling compare_live_state_with_declared_state), which it omits.

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 and the input schema has no properties, so there is nothing for the description to disambiguate. Baseline for a parameterless tool 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 ('List REST operations') plus a qualifier about the source ('from the instance's live OpenAPI document'), which separates it from the repository-analysis siblings. It stops short of naming a sibling it complements or replaces, so an agent must infer the boundary itself.

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 when-to-use or when-not-to-use guidance. The word 'live' hints that this is for runtime discovery rather than declared-state inspection (as in nexus_compare_live_state_with_declared_state), but the description never states that distinction or any prerequisite such as the instance being reachable.

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, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds real value beyond them by enumerating what the summary covers (counts, formats/types, blob stores, group membership, offline repos) and noting results come "with evidence," which signals citations/backing data rather than bare assertions. It omits any note on cost, latency, or size of the summary, which is the main remaining 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?

A single sentence that leads with the verb and resource, then lists the covered dimensions compactly. Every clause names a distinct piece of content; there is no filler or restatement of the tool name.

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 zero parameters, an output schema present, and full annotation coverage, the description only needs to convey scope and placement — and it conveys scope well. The missing piece is placement relative to siblings (inventory JSON, architecture markdown, smell detection), which is the one thing an agent still has to guess.

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, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. Nothing in the text misleads about inputs.

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?

Specific verb ("Summarize") plus a specific resource ("the instance") and an enumerated scope: object counts, repositories by format/type, blob store usage, group membership, offline repositories. An agent can tell this is a broad inventory/overview read. It does not, however, distinguish itself from close siblings such as nexus_generate_inventory_json or nexus_generate_architecture_md, which appear to cover overlapping ground.

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 word "Summarize" — this is the high-level overview call — but there is no explicit when-to-use statement, no when-not, and no named alternative among the eleven siblings. The agent must infer that this is the entry point before drilling into nexus_explain_repository or nexus_generate_architecture_md.

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