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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful context that it works from a non-destructive startup snapshot and does not perform a POST that drains buffers, though it does not discuss permissions 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 a single compact sentence separated by semicolons, front-loading what is returned and following with usage boundaries. Every clause adds distinct information with no filler.

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

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

The output schema and rich annotations cover return values and safety, and the description adequately explains purpose and exclusions. However, for a tool with seven parameters and low schema description coverage, the missing parameter guidance leaves a meaningful gap in invocation guidance.

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 only 29%, and the description does not explain any of the seven parameters such as cursor, maxDepth, targetId, maxResults, or minDurationMs. With most parameters undocumented in the schema and nothing added in the description, an agent gets little semantic guidance for configuring the 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 resource and return contents: a non-destructive startup snapshot with version, timeline span, slowest steps, and parent-child chain. It also distinguishes the tool from request-latency analysis and a buffer-draining POST, so its diagnostic role is clear without opening the schema.

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

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

It explicitly says to call it when troubleshooting slow startup and explicitly excludes current request latency and buffer-draining POST behavior. It does not name a specific sibling alternative, but the usage boundary is otherwise clear.

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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds two genuinely useful facts beyond that: it does not execute SQL or migrations, and unreported pending states require a trusted expectation to be interpreted. It still says nothing about result ordering, pagination behavior, or how UNKNOWN/OUT_OF_ORDER are derived.

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 dense sentence with the resource description front-loaded and the usage trigger second. Efficient, though the semicolon-joined clauses on unreported pending states are compressed enough to need re-reading.

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-value explanation is not required, and annotations cover the safety profile. However, a 10-parameter tool with zero schema descriptions needs the prose to explain filtering, pagination and engine selection, and the description covers only a fraction of that surface.

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 0% across 10 parameters, so the description carries the full burden. It only gestures at migrationBean, the expected-set inputs, and the status fields; state, cursor, maxResults, engine, targetId, contextId and version are entirely undocumented in both places, leaving the agent to infer pagination and scoping semantics.

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: returns reported migrations, checksums, ordering and exception state across all containers and migration beans. That is clearly a migration-audit operation, distinct in domain from the health/startup/drift/config siblings, though it never names or contrasts them explicitly.

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 a concrete trigger: call it when troubleshooting migration failures or version discrepancies. It also hints at the expected-set workflow for unreported pending states, but offers no explicit when-not-to-use guidance or routing to an alternative tool such as drift detection.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower; the description still adds useful semantics: the response is differences plus graded root-cause candidates, and the caveat that file timestamps alone cannot prove a process was not restarted. That caveat is non-obvious interpretation guidance not present in 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?

A single dense sentence, front-loaded with the comparison verb, with semicolon-separated clauses that each carry a distinct fact: what is compared, what is returned, when to call, omission semantics, and the timestamp caveat. No filler.

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

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

An output schema exists, so return values needn't be described, and the core comparison contract is stated. But for an 11-parameter tool with nested objects, the description leaves the control parameters (target, pagination, scope-completeness, source revision vs. modification time) unexplained, which is a real gap for correct invocation.

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% across 11 parameters. The description names only the four expected* dimensions (beans, routes, migration version, profiles) and the omission rule; it says nothing about targetId (the 'authorized workspace'), cursor, maxResults, maxDepth, sourceRevision, sourceModifiedAt, or expectedScopeComplete, which materially change comparison behavior. Most parameters have no semantics anywhere.

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 (compare) and specific resources (Bean, route, migration version, Profile expectations vs. runtime), and the drift framing separates it from the sibling tools that inspect those things individually (inspect_beans, verify_mappings, check_migrations). An agent can identify this as the cross-dimension comparison tool without comparing schemas.

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 states a clear trigger — call when source code and runtime behavior disagree — and adds the rule that omitted dimensions are not compared, which tells the caller the call is valid with partial input. It does not name a sibling as an alternative or state when not to use it, so it falls short of 5.

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=false, so the safety profile is covered. The description adds genuinely new behavior: results are pre-sanitized, component drill-down happens locally, and log/heap-dump/raw-stack retrieval is deliberately out of scope — useful expectations for an agent interpreting the payload.

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 dense sentence with the return payload front-loaded, then the trigger condition, then the scope exclusions — no filler. The semicolon-separated structure is readable, though the parameter surface is compressed away entirely.

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 re-explained, and purpose/trigger/boundaries are well covered. But for a tool exposing eight optional parameters — including a pagination cursor, a target selector, and detail/healthy toggles — with zero schema descriptions, the description leaves an agent unable to choose parameters intelligently.

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?

Eight parameters with 0% schema description coverage means the description carries the full explanatory burden, and it largely abdicates it. Only componentPath gets an indirect nod ("组件下钻在本地完成"); group, targetId, maxDepth, maxResults, cursor, includeDetails, and includeHealthy are left entirely undefined in both schema and prose.

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 specific outputs (overall health status, an abnormal-component tree, sanitized structured errors plus remediation code), which is a concrete verb+resource pair rather than a restatement of the name. It is clearly separable from the inspection/mapping siblings, though it never names them explicitly.

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 an explicit triggering condition for use. The trailing clause functions as a negative boundary (no logs, heap dumps, or raw exception stacks), but no alternative tool is named for those needs, so it falls short of a full when-not/alternatives map.

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 readOnly, idempotent, non-destructive, closed-world. The description adds genuine behavioral detail beyond them: auto-reading the authorized condition report on missing beans, expanding nested/transitive blocking chains, and returning 'unknown' rather than guessing when evidence is insufficient. That evidence-gated output policy is valuable context, though it omits pagination/response mechanics already partly covered by 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?

A single dense sentence that front-loads the return content and follows with the trigger condition; every clause carries signal. Slightly compact for the number of concepts, but no filler.

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

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

An output schema exists, so return-value explanation is not required, and the behavioral narrative is solid. However, for a 10-parameter tool with 20% schema coverage, key controls (pagination, depth, target/context scoping) remain undocumented, leaving the agent under-informed to call it precisely.

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 10 parameters and only ~20% schema description coverage, the description needs to compensate but largely does not. It hints at bidirectional direction and condition depth via '双向依赖图' and '条件报告', but leaves cursor, maxDepth, maxResults, targetId, contextId, and packagePrefix unexplained.

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: it returns matching Beans, aliases, and a bidirectional dependency graph, and augments with condition-report details when a Bean is missing. This is clearly distinguishable from siblings like inspect_config or verify_mappings, though it does not name them explicitly.

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 an explicit trigger: call when troubleshooting injection or conditional assembly (排查注入或条件装配时调用), which is clear usage context. It stops short of naming alternatives or when-not conditions, so it is a 4 rather than a 5.

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, it discloses that results are returned after mandatory double-layer redaction, that the capability is disabled by default, and that it cannot be used for secrets or full configuration export. These are meaningful operational and security behaviors that an agent needs in order to invoke it responsibly. There is no contradiction with readOnlyHint, idempotentHint, or destructiveHint=false.

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?

It is a single, front-loaded sentence: return scope first, then when to use it, then safety constraints. There is no filler, and each clause adds information relevant 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?

The output schema exists, so the description need not explain return values, and the annotations already cover the read-only/idempotent safety profile. However, with 7 parameters and low schema description coverage, the description leaves notable invocation gaps around pagination, target/context selection, and includeValues. It is adequate but not fully complete for correct parameter use.

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

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

The schema description coverage is only 14%, so the description must carry most parameter meaning, but it only mentions prefix and key-pattern invocation. It does not explain targetId, contextId, cursor, maxResults, or includeValues, leaving several parameters without descriptive semantics in either the schema or the description. The propertyKeyPattern schema description helps, but overall compensation is weak for a 7-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?

The description gives a specific verb and resource set: it returns effective properties, bound beans, source locations, and active profiles after mandatory double-layer redaction. The resource scope is clearly configuration inspection rather than health, startup, migrations, drift, bean listing, OpenAPI, or mappings, so an agent can distinguish it from the 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?

It explicitly says to call this when troubleshooting property binding or configuration overrides, and to do so via prefix or key pattern. It also states clear exclusions: the capability is disabled by default and must not be used to obtain secrets or export full configuration. It does not name a specific alternative sibling, which keeps it from a 5.

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 read-only, idempotent, non-destructive and closed-world behavior, yet the description still adds real value: default inlining of direct and second-order same-document refs, no remote ref resolution, no full-document dump, no business execution. That is genuine behavioral context beyond the structured fields. It stops short of describing pagination/cursor behavior, which the 8-param schema implies.

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 dense sentence front-loads the return behavior before usage and exclusions, with no filler. The semicolon-chained clauses are efficient, though packing return semantics, usage guidance and three exclusions into one sentence slightly hurts scannability.

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 shape needs no explanation and the description's account of ref inlining is appropriate. But for an 8-parameter tool with a oneOf/allOf selector constraint and only 13% schema coverage, omitting how the selectors combine and how cursor/maxResults paginate leaves a real gap for correct invocation.

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 only 13% (only pathPattern is documented), so the description must compensate and largely does not. It obliquely conveys maxRefDepth's default of 2 via '二阶同文档引用' and gestures at '精确选择器', but says nothing about schemaName vs pathPattern vs operationId exclusivity, cursor, maxResults, or targetId, leaving the most consequential parameters unexplained.

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 concrete verb/resource pair ('返回匹配操作或 Schema') and bounds the scope by stating it does not return the whole document or resolve remote refs. It does not need to differentiate from siblings, which are diagnostics/bean/config tools with no overlapping purpose. The only weakness is that 'matching' against what corpus (the OpenAPI spec) is inferred from the name/title 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?

'确认接口契约时使用精确选择器调用' gives a clear usage context and a call-style directive (use precise selectors). However, no alternatives are named and the mutual exclusivity between the three selector styles (schemaName vs pathPattern/operationId) that actually determines correct invocation is never explained.

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 readOnly/idempotent/non-destructive annotations, the description adds two pieces of real behavioral context: it does not send requests to the application's business URLs, and a registration match does not imply the request will succeed. That second caveat is important for interpreting results and is not derivable from 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?

It is a single compact sentence-pair with the purpose front-loaded and no filler. The two negative caveats are slightly compressed into the same clause chain, but nothing is wasted.

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-value explanation is rightly omitted, and the annotations cover the safety profile. However, with 7 parameters, a required-anyOf constraint, and pagination via cursor/maxResults, the description leaves an agent without guidance on required inputs or result-size limits, so it is only adequate rather than complete.

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

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

Schema description coverage is only 29%, with 7 parameters, and the description explains none of them: cursor, maxResults, targetId, and contextId are entirely unaddressed, and the anyOf requirement (at least one of pathPattern/httpMethod/controllerClassPattern) is not mentioned. Even the two glob patterns that carry schema descriptions get no added meaning. The description does not compensate for the coverage gap.

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 set: it returns unified MVC/WebFlux routes, handlers, and method descriptors. An agent can tell this is a route-registration inspection tool rather than a bean/config/drift inspector. It stops short of naming a sibling such as springboot_search_openapi, which also deals with request mappings, so differentiation is only partial.

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 states a concrete trigger — call it when troubleshooting a path, HTTP method, or Controller that is not registered — which is a clear positive condition for use. It gives no explicit exclusion or named alternative for when to prefer springboot_search_openapi, so the guidance is clear but not complete.

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