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

Discloses a critical behavioral property beyond annotations: the Key never enters tool parameters, the conversation, or return values, and the input happens via an OS secure prompt. This is real security context the agent cannot get from readOnlyHint/destructiveHint.

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 compact sentence that front-loads the invocation condition before the mechanism and the security guarantee. Zero 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?

Output schema exists, so return values need no explanation. Purpose, trigger, mechanism, and secret-handling are all covered; nothing an agent needs to invoke this safely 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 coverage is 100% and the single `force` parameter is already documented in the schema, so the baseline is 3. The description's mention of '更换' loosely maps to force but adds no syntax, default, or edge-case detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: '打开操作系统安全输入框并把 Key 保存到本机私有配置' tells the agent exactly what happens, distinct from all solve/knowledge 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?

Explicit trigger condition ('仅在用户明确要求配置或更换 IsingQ API Key 时调用') states when to call and implicitly when not to. No sibling overlap exists to route away from.

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 still adds real value by specifying the data source is a local, versioned knowledge pack requiring no API key, which is the one behavioral fact annotations do not convey (implication of possibly stale packaged data).

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 leads with the source and scope, then the offline/no-key constraint. The middle enumeration is long but each entry corresponds to a real query topic, so little is wasted; the semicolon split gives it a clean structure.

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-format explanation is unnecessary. For a simple two-parameter, read-only, idempotent lookup the description covers source, scope and auth requirements; only the locale parameter's role is left 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?

Schema coverage is 50%: topic carries a description and enum, locale has an enum but no description. The description's Chinese enumeration (光电伊辛机, 玉盘·伊辛云, 术语) usefully maps colloquial topics to enum values like ising_machine and glossary, but says nothing about locale or the zh-CN-only restriction, so it only partially compensates.

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 a concrete resource (本机版本化知识包) and enumerates the covered domains (company, products, IsingQ, optical Ising machine, cloud, solutions, cases, FAQ, glossary), which maps cleanly onto the topic enum. It clearly is not a solve/modeling tool like its 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?

The clause '不联网，不需要 API Key' implies the operating context (offline, credential-free lookup) and therefore when this tool is usable, but it states no when-to-use condition, no exclusions, and no routing to the modeling/solve siblings. 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully carried by structured data. The description only adds that the workflow is '本地' (local) and domain-scoped; it adds no further behavioral context such as content scope or freshness.

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 with the core action front-loaded and the qualifying domains appended. No filler, though the domain list is somewhat padding given the generic nature of the tool.

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 presence of an output schema means return values need not be described, and annotations cover the safety profile. Still, the undocumented optional parameter and the absence of routing guidance against sibling tools leave the definition only minimally 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 0% and the description says nothing about problem_summary — its purpose, format, or what happens when it is omitted (it is not required). With a low-coverage schema, the description was expected to compensate and does not.

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 (获取/get) and resource (IsingQ 本地 QUBO 建模流程), so an agent knows it retrieves a modeling workflow, and it lists applicable problem domains. However, it does not distinguish this from the sibling isingq_knowledge_get, leaving the boundary between 'guide' and 'knowledge' unclear.

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 enumerated domains (投资组合、路径规划、车辆路径、排程、图优化) imply when the guide is relevant, but there is no explicit when-to-use statement, no routing versus isingq_knowledge_get or isingq_qubo_validate, and no note that problem_summary is optional.

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 safe-read profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value: determinism (确定性), full local execution with no network call (完全本地执行), and an explicit variable-count bound of 1–2048.

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 action front-loaded and no filler; locality and bounds are packed in efficiently. Slightly overloaded with three separate checked quantities in one clause, 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 values need not be described, and annotations carry the safety profile. Given a 1-parameter tool, the description covers scope, limits, and execution model adequately; only the input QUBO object's expected shape 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?

Schema coverage is 0% for the single required nested 'qubo' object, so the description must compensate. It does say what is checked (variable count, matrix scale, coefficient summary), but never describes the expected structure/shape of the qubo object the agent must supply, leaving a meaningful 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?

Names a specific verb (校验/validate) and resource (稀疏 QUBO), and scopes it precisely: deterministic validation of agent-generated QUBOs for combinatorial optimization. This clearly distinguishes it from siblings like isingq_solve_start and isingq_solve_result_get.

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 the validation context (QUBO generated by the Agent for combinatorial optimization problems), but never states when to call it versus the solve tools, nor any precondition such as "run before isingq_solve_start" or any when-not guidance. Usage must be inferred.

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 declare readOnlyHint=false, and the description explains why by disclosing the local-record update side effect — that is genuine behavioral context beyond the flags. It also scopes the return payload to success ('成功时'), implying failure yields something different. It stops short of saying whether the call blocks or how often to poll.

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 sentence with the verb and resource front-loaded and zero filler. The trailing clause listing return fields is slightly redundant given an output schema exists, but nothing is wasteful.

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 enumerating return values is not required, and the tool is otherwise simple with one parameter. Still missing: whether the task must be running, what a non-terminal response looks like, and how this differs from isingq_solve_result_get — gaps an agent polling for progress would want closed.

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 single required parameter solve_id has 0% schema description coverage and is never mentioned in the description, so neither layer documents its format or source. The phrase '远端任务' only weakly implies a task identifier.

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-plus-resource (查询 IsingQ 远端任务) and adds the key effect (更新本地记录) and the success return payload. This is clear without opening the schema, but it never distinguishes itself from the sibling isingq_solve_result_get, which sounds like it retrieves the same 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?

The description says it queries '一次' (once), which hints at a repeated-polling pattern, but it gives no explicit when/when-not, no prerequisites, and no comparison to isingq_solve_result_get. With a near-identical results sibling present, the absence of routing guidance is a real gap.

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 the safety profile is covered. The description still adds real value beyond them: the explicit '不联网' confirmation and, more importantly, the caveat that the result does not assert business feasibility or global optimality — a semantic guardrail the annotations 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?

A single dense sentence, front-loaded with verb and resource, then behavioral caveats. No filler, though the semicolon-packed clause about feasibility/optimality could be slightly easier to parse.

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. The gaps are the provenance/format of solve_id and what happens when a stored result is absent, which matter 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?

There is one required parameter (solve_id) with 0% schema description coverage, and the description says nothing about its format or where it comes from (e.g., returned by isingq_solve_start/isingq_solve_poll). With low coverage the description is expected to compensate and does not.

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 concrete verb (读取) and a well-scoped resource (本机保存的求解状态、结果与来源信息), so an agent knows this retrieves a persisted solve rather than starting or advancing one. It does not name the sibling that is closest in function (isingq_solve_poll), so the distinction must be inferred from '本机保存的'.

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 '读取本机保存的' plus '不联网' implies this is for already-persisted results as opposed to the networked polling tool, which is useful implied context. However, it never explicitly says when to choose this over isingq_solve_poll or isingq_solve_start, so the routing burden stays with the agent.

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 flag this as destructive, open-world, idempotent and non-read-only, but the description adds meaningful context: the QUBO is converted to a matrix, the local personal API key is used, a remote task is created, and a user-confirmation gate is mandatory. It stops short of disclosing cost/quota or rate limits for the remote submission.

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 sentences, front-loaded with what happens on invocation and followed by the mandatory pre-call confirmation workflow. No filler, though it could be tightened by naming the alternative validation tool.

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 the confirmation workflow is covered. Still, for a destructive, open-world remote submission with nested objects and 0% parameter documentation, missing guidance on solver_options and idempotency_key leaves the agent under-informed for safe 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 4 parameters, so the description carries the full burden. It only indirectly explains model_summary (shown to the user for confirmation) and implies qubo; solver_options and idempotency_key — the key that prevents duplicate costly submissions — are never addressed.

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 converts the QUBO to a matrix and creates a remote solve task via the local IsingQ API key. This is clearly distinguishable from siblings like isingq_qubo_validate (validate only) and isingq_solve_poll (poll status), 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 a real precondition — the agent must display the model summary and matrix SHA-256 and obtain user confirmation before calling, and the Host may re-confirm. However, it offers no routing guidance among siblings, e.g. whether isingq_qubo_validate should run first, leaving sequencing implied.

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