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

With no annotations supplied, the description carries the disclosure burden and does fairly well: it states the return format (Markdown), that section extraction returns only a relevant subsection, that full=true returns the entire page, and that maxChars bounds output length. It doesn't say what happens when a section heading is not found or how truncation is signaled, which keeps it below 5.

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 tight paragraph that front-loads the core purpose, then the parameter behaviors, then the budget constraint. Every clause carries information; nothing is 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?

For a four-parameter read tool with no output schema and no annotations, the description covers purpose, source constraints, return format, narrowing options, and a usage budget. Only edge-case behavior for missing sections or truncated results is unaddressed, which is 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 all four parameters are already documented in structured form, and the description largely restates them (section as heading/anchor, full as whole page, maxChars as length control). The one added nuance is the origin constraint on url (must come from search_docs hits), but the interaction between section and full is left implicit. Baseline 3 applies when the schema does the heavy lifting.

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 ("读取一篇资料为 Markdown") and names both supported sources (roboparty.com docs pages and the RP1 GitHub README/docs). It also ties itself to the sibling docs_search_docs by specifying the URL comes from search hits, so an agent can distinguish it from docs_list_toc or docs_list_manuals without inspecting 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 gives clear workflow guidance: pass a URL returned by search_docs, and optionally narrow with section or full. The budget rule ("每个问题最多打开 1–2 篇") is a genuinely useful usage constraint. It stops short of explicitly contrasting when to use this versus docs_list_toc or docs_list_manuals, so it is not a full 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?

No annotations are supplied, so the description carries the full disclosure burden, and it does describe the returned content in detail (products, categories, page counts, indexed repos). It never explicitly states that the operation is read-only or side-effect free, but 'list available material' makes non-mutation evident.

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 compact sentence front-loads the resource and enumerates the return contents, followed by one short usage directive. Nothing is padded, though the colon-separated enumeration 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?

With no input parameters and no output schema, the description must explain what comes back, and it does so for both sources (public docs and GitHub repos). It is nearly complete; only the relationship to sibling listing/search tools is unaddressed.

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 sets the baseline at 4; there is nothing parameter-wise for the description to clarify.

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 ('列出') plus a concrete resource inventory: products, categories, page counts from the public docs and indexed RP1 GitHub repos with page counts. It is clear what the tool returns, though it never contrasts itself with the close sibling docs_list_toc, leaving some ambiguity about which listing to call.

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 a clear usage context: call this first to learn what material exists before answering robot questions. It does not state exclusions or name alternatives such as docs_search_docs, so the agent must infer when a search or TOC listing is better.

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

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

With no annotations supplied, the description carries the full behavioral burden. Listing implies read-only and it does distinguish document listing from repository listing, but it says nothing about return shape, ordering, pagination, recursion depth, or what an empty/unmatched manual yields.

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 the verb first and the bracketed domain prefix; no wasted wording. Minor redundancy with the schema's manual description is the only inefficiency.

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 listing tool with no output schema and no annotations, the description covers the core concept but not return format or pagination behavior. It is minimally 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 100%, so lang, query, and manual are already documented in the schema. The description restates the manual value forms (category name or 'rp1/github/repo') without adding new meaning, so the 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?

The description states a specific verb ('列出'/list) and resource (documents under a category, or indexed RP1 GitHub repositories), and clarifies the dual mode via the manual parameter. It does not name a sibling (docs_list_manuals, docs_search_docs) to draw the boundary, so it stops short of 5.

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

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

There is no explicit when-to-use guidance versus docs_list_manuals, docs_search_docs, or docs_get_page. The clause about passing a category name or 'rp1/github/repo' as manual is parameter syntax, not a selection rule, leaving the agent to infer when this tool is the right choice.

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

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

With no annotations, the description carries the full burden and does well: it discloses the two source corpora, the gh auth login prerequisite for private repos, and the automatic zh/en selection that biases results toward the query's language. It stops short of describing output shape or ranking behaviour beyond the default of 8 hits.

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 scope, then query guidance, then the follow-up workflow, then the anti-hallucination warning — a sensible order with little filler. It is dense by nature and a couple of clauses run long, but 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?

For a search tool with no output schema, it does the essential work of implying that results carry a url to hand to get_page, and it covers auth and language defaults. The only real gap is the stale kind=github reference and no mention of what a hit record otherwise contains.

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 lang, limit, query and category, and the description mostly restates the language auto-detection rule. It adds useful query-formulation strategy, but also references a 'kind=github' parameter that does not exist in the schema, which muddies rather than clarifies parameter meaning.

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?

Names a specific verb and resource: full-text retrieval across roboparty.com docs plus RP1 GitHub repo README/docs, and explicitly positions the sibling docs_get_page as the follow-up step for opening a hit. An agent can distinguish it from docs_list_toc and docs_list_manuals without opening any 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?

Gives explicit when-and-how guidance: pass short queries (error text, command, API name, repo name, keywords) rather than whole paragraphs, then open hits with get_page and answer quoting the source with a link. It also states a prohibition — do not answer from memory about pins, package names, versions or steps — which is exactly the kind of routing an agent needs.

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 idempotentHint, but the description adds value beyond them: it discloses the return shape (calibrated choice/score/noul answers with probabilities) despite there being no output schema, and explicitly disclaims any robot control. It does not discuss cost, latency, or how probabilities should be interpreted, so it is not fully comprehensive.

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 the core action and the key non-control caveat front-loaded, and no filler. The brevity is appropriate, though the compressed phrasing concentrates undefined jargon (Laya, noul) in a very small 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?

The tool is genuinely complex, with nested oneOf question variants, and there is no output schema to lean on. The description covers return shape and scope but leaves the semantics of each question type and the expected criteria format largely to the schema, which is thin on prose.

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 defines both the state input and the structured question object. The description only echoes the three question types present in the schema and adds no guidance on constructing criteria or naming questions, which is where ambiguity actually lives.

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?

"Run Laya once over a state and typed questions" gives a specific verb and resource, and the mention of calibrated choice/score/noul answers separates it from siblings like system1_laya_info and system1_laya_health. The term "Laya" and "noul" are never defined, so an agent unfamiliar with the domain still has to infer what is being executed.

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 clause "Analysis only; it does not control the robot" gives a clear boundary on what this tool will not do, which implies it is for inference rather than actuation. However, it never states when to pick this over system1_laya_info or system1_laya_health, nor any prerequisite for the state being well-formed.

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 idempotentHint, so the safety profile is covered. The description adds value beyond them by enumerating the three possible load states and the presence of a latency figure, which is the key behavioral context for a health probe. It omits latency units and whether the probe itself can trigger loading, minor gaps.

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

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

A single front-loaded sentence that names the resource and then the returned signals in order of importance. No filler and nothing redundant with the schema or annotations.

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 carries the return-value burden and does so by naming the state enumeration and latency. Combined with read-only annotations and an empty parameter schema, an agent has enough to call it correctly. Only the latency unit and failure-detail granularity are unstated.

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. Baseline for a parameterless tool is 4.

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 whether the Laya model is loaded, loading, or failed, plus last latency. That is far more precise than a tautological restatement of the name. It doesn't explicitly contrast itself with siblings like system1_laya_info or system1_laya_analyze, which keeps it from a 5.

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

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

The states listed imply the use case (checking model readiness before calling analyze), but no when-to-use condition or exclusion is stated. Nothing tells the agent whether to prefer system1_laya_info or this tool for status questions. Usage is inferred rather than guided.

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 idempotentHint, so the safety profile is covered by structured data. The description adds that the return is static model metadata (path, source, providers, config), which is modest value beyond the annotations but says nothing about cost, loading side effects, or failure when no model is loaded.

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 the field list up front and no filler. The '[system1]' prefix is a namespace tag rather than wasted prose, so nothing detracts.

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 carries the burden of describing the return value, and it does so by enumerating the four returned fields. For a zero-parameter read tool that is essentially complete; only edge behavior (e.g., unloaded model) is unstated.

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 baseline of 4 applies; there is nothing for the description to disambiguate. No parameter meaning is missing.

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 ('Return') and resource ('Laya model') and enumerates the payload (path, source, execution providers, loaded config), which distinguishes it in spirit from the sibling laya_analyze and laya_health tools. It never names those siblings explicitly, so the differentiation is inferred 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?

Usage is only implied: an agent can infer this is the metadata/inventory call versus the analyze and health siblings because of the enumerated fields. There is no statement of when to prefer it, no prerequisites, and no exclusion of alternatives.

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