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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description's contribution is disclosing the shape of the payload (types, fields, operations, permissions), which is genuinely useful, but it says nothing about caching, completeness guarantees, or whether the catalog reflects server-side configuration changes.

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; the resource and the enumerated contents come first. Nothing in it is redundant with the name 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 usefully stands in for one by listing the four kinds of information returned. For a zero-argument, read-only catalog tool that is nearly sufficient; the only real gap is the missing distinction from health_schema, which matters given how many sibling discovery tools exist.

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 4 applies. The sentence correctly refrains from inventing filtering or pagination parameters that the empty schema does not support.

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 — it enumerates the writable data types, fields, operations and required permissions that the catalog returns — so an agent knows exactly what this tool produces without opening a schema. It is clear, but it never contrasts itself with the closely-named sibling health_schema, so sibling differentiation is left to inference.

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 statement of when this catalog should be consulted versus health_schema, health_status or health_list, all of which sound adjacent. The 'writable' qualifier implies a discovery use case, but no condition, prerequisite or alternative is spelled out.

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 disclose readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the record-shape constraint (只填該類型內容，不含外層 DataPoint), which is genuinely useful, but it omits behavioral notes on dry_run defaults or idempotency conflict handling that the schema already carries.

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 tightly written sentences with the primary action front-loaded and the schema-check prerequisite and record-shape note following in a logical order. 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?

For a 4-parameter creation tool with a nested free-form record, enum-typed data_type, and existing annotations, the description covers the construction guidance an agent needs. There is no output schema to explain, and remaining gaps (dry_run semantics, idempotency behavior) are already documented in the schema.

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%: data_type's enum is self-documenting and dry_run/idempotency_key are described in-schema, while record has no schema description. The description partially compensates by explaining that record should contain only the type's inner content and exclude the outer DataPoint wrapper, but adds nothing for the other parameters.

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

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

States a specific verb (新增/create) and resource (官方支援寫入的健康資料類型), making the creation intent unambiguous against siblings like health_update and health_delete. It further anchors the workflow by naming health_schema as the prerequisite field-checking tool.

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?

Explicitly prescribes the prerequisite workflow (先用 health_schema 檢查欄位), which tells the agent how to prepare before calling. It stops short of naming when-not-to-use or contrasting with health_update for existing records, so it is clear context without full routing alternatives.

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 destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is partially covered. The description adds the preview-first workflow and the requirement to obtain explicit user instruction, but does not disclose scope of deletion, irreversibility, or return behavior beyond what annotations and the dry_run field already imply.

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 short sentences with no filler, and the deletion purpose is front-loaded ahead of the preview guidance. Efficient and well-ordered, though terse to the point of under-delivering detail.

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 destructive, open-world delete tool with no output schema, the description covers the essential preview-before-delete workflow but omits what deletion affects, whether it is reversible, and the meaning of data_type/names. Adequate but with clear gaps given the tool's risk profile.

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 50%: dry_run and idempotency_key are documented in the schema, but data_type and names have no descriptions anywhere. The description's phrase "指定資料點" loosely gestures at the targets but does not clarify the names array or the data_type values, so it fails to 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 states a specific verb and resource: "明確刪除指定資料點" (explicitly delete specified data points). This is clearly a delete operation distinguishable from siblings like health_create and health_update, though it does not name any sibling 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 conveys a usage workflow — preview first and obtain the user's deletion instruction — which implies required prerequisites before acting. However, it offers no guidance on when to choose this tool versus alternatives, leaving usage implied rather than explicit.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond that — nothing about auth requirements, error behavior for an invalid/missing name, or result shape — so it contributes little on this dimension.

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, front-loaded with the verb and resource, with zero filler. It is efficient, though its brevity is also why it leaves gaps elsewhere.

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 single-parameter read tool whose annotations already convey the safety profile, the description is minimally adequate. It omits failure modes (unknown resource name) and any return-value orientation, but with no output schema and full read-only annotations, those omissions are not fatal.

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 must carry the load for the single parameter. It does partially compensate by stating that the value must be the complete Google Health resource name rather than an ID fragment, but it gives no example format or path syntax.

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 (讀回 / read back) and resource (資料點 / data point) and specifies the lookup key (full Google Health resource name). It is clear on its own, but it never distinguishes itself from siblings like health_list or health_catalog, so an agent must infer the boundary.

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 statement of when to use this tool versus health_list (enumerate) or health_catalog/health_schema (discovery). The only implied guidance is that the caller must already possess a full resource name, which is a weak hint rather than a routing rule.

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 readOnlyHint=true, openWorldHint=true, and destructiveHint=false already supplied by annotations, the description adds useful behavioral context: results are scoped to data written by this OAuth client, and pagination is retained rather than auto-fetching the entire history. It does not cover return format or rate limits, but it meaningfully supplements 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?

The definition is a single compact sentence that front-loads the query scope before the pagination behavior, with no filler. It is concise, though it could be structured to include essential parameter guidance without becoming bloated.

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 listing tool with no output schema and 0% schema description coverage, the description omits critical details: what data_type values are valid, what filter does, how pagination tokens/sizes behave, and what the returned records look like. The scope/pagination note helps, but the definition is far from 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%, yet the description never mentions the required data_type parameter, the filter parameter, or how page_size/page_token should be used. The only parameter-adjacent hint is '保留分頁,' which is not enough to explain four undocumented parameters.

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

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

The description gives a clear verb ('查詢' / query) and a specific resource scope ('此 OAuth 用戶端寫入的資料' / data written by this OAuth client), and it clarifies that pagination is preserved rather than fetching the full health history. It does not, however, explicitly distinguish health_list from sibling list/get/status tools.

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 or alternative-tool routing. The statement about pagination and not auto-fetching the full history is behavioral context, but it does not tell an agent when health_list should be chosen over health_get, health_status, or other siblings.

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 idempotentHint=true and destructiveHint=false, so safety is partly covered. The description adds genuine behavioral detail: missing nutrition values are not zero-filled, and anonymous foods cannot be updated after insertion (a notable immutability trait). It omits the dry_run preview-by-default behavior, which is central to calling this correctly.

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

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

Three tight clauses with the purpose front-loaded and no filler. Efficient and on-point, though arguably over-terse given the tool's complexity.

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 an 11-parameter mutation tool with no output schema, the description is thin. It never mentions dry_run defaulting to preview-only (the single most important fact for an agent to invoke correctly), nor the timezone/idempotency semantics needed for safe writes. The description leaves significant gaps in the calling contract.

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 only 36%, so the description must compensate. It clarifies that nutritional values (fat_g, carbs_g, protein_g, calories_kcal, servings) are optional and not padded, but says nothing about dry_run, meal_type, the two timestamps, or idempotency_key beyond what the schema already documents. Partial compensation only.

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+resource: 寫入飲食紀錄 (write a meal record). This clearly distinguishes it from health_log_workout (logging exercise) at the resource level, though no sibling is named explicitly. Purpose is unambiguous.

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

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

No when-to-use vs when-not guidance and no routing to alternatives among the many health_* siblings (create/update/get/list). Notes that nutrition values may be omitted but provides no context about when this tool should be chosen over health_create or health_log_workout.

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=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description reinforces that actual start/end times are mandatory, but omits the most consequential behavior — that dry_run defaults to true so nothing is written until explicitly set false — leaving that to the schema.

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

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

Two tight sentences with no filler, front-loading the core action before the detail-handling and time-requirement notes. Every clause carries information.

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

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

For a 10-parameter write tool with 40% schema coverage and no output schema, the description covers the essentials but leaves gaps: the preview-by-default behavior, the idempotency-conflict rejection, and the large exercise_type enum go unmentioned. Adequate, but an agent must read the full schema to invoke it 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?

With schema description coverage at only 40%, the description compensates partially: it explains that notes carries per-set weight/reps/exercise and that start_time/end_time must be genuine. It says nothing about exercise_type, idempotency_key semantics, dry_run, distance, calories, active_minutes, or display_name, so most parameters remain unexplained by the description.

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 (寫入運動或重訓場次 — write an exercise or weight-training session), which is clearly distinct from the sibling health_log_meal. It does not name or contrast any sibling explicitly, so it stops short of 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?

It gives partial usage guidance by saying where per-set detail belongs (notes) and that real start/end times are required, which implies 'do not fabricate times'. There is no statement of when to use this versus health_update/health_log_meal, or of any prerequisite such as the preview-first workflow.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond that — no mention of caching, upstream source, failure modes when a data_type is unknown, or what the referenced schemas represent.

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 no filler, and the resource being fetched is front-loaded. It is efficient, though the brevity comes at the cost of the missing detail noted elsewhere.

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 one-parameter lookup tool with no output schema and an open-world source, the agent still needs to know what data_type tokens are legal and roughly what shape comes back. The description supplies neither, leaving it under-specified relative to the tool's actual 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?

Schema description coverage is 0% for the single required parameter, and the description only echoes it vaguely as '特定資料類型' without listing valid data_type values, casing/format, or where to discover them. With one undocumented required param, the description does not compensate for the schema 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?

States a specific verb (取得/get) and resource (官方 Discovery 欄位與所有引用 schema) scoped to a data type, so an agent can tell this returns schema metadata rather than health records. However it offers no explicit differentiation from schema-adjacent siblings like health_catalog or health_get, and 'Discovery 欄位' is jargon an agent must guess at.

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 condition that selects this over health_catalog or health_get, and no prerequisites named. The agent must infer the usage context entirely from the tool name.

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, openWorldHint=true, and destructiveHint=false. The description adds one notable behavioral fact beyond annotations: it does not return credentials or tokens. However, it does not describe return format, auth requirements, or rate limits, so it remains at a minimum-plus level.

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 words. It states the core purpose first and then adds the sensitive-data exclusion.

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 parameterless read-only status tool with robust annotations and no output schema, the description covers the essential scope and privacy behavior. It could better distinguish itself from sibling status-related tools, but it is otherwise complete enough to invoke 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?

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. The description appropriately does not introduce parameter details.

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 in Chinese: viewing OAuth authorization status and permissions. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as health_write_status or health_catalog.

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 offers no guidance on when to use this tool versus alternatives. The caveat about not returning credentials or tokens is useful, but it is not a when-to-use or when-not-to-use instruction.

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 the full safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=true, openWorldHint=true). The description adds useful constraints not in the structured data, namely that anonymous diet records cannot be updated and that 'record' must contain complete type content. It omits the most important behavioral trait, the dry_run preview-vs-write default, though that is covered by the schema.

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, action front-loaded, zero filler. Slightly dense phrasing but no wasted content.

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 mutation tool with a nested 'record' object, four required params, no output schema, and rich annotations, the description covers the key eligibility constraint and record requirement. It still leaves data_type semantics and the dry_run write/preview distinction (the highest-stakes behavior) unaddressed in 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 only 40% (dry_run and idempotency_key documented), so the description must compensate. It clarifies 'name' as a full resource name and 'record' as complete type content, adding real value, but leaves 'data_type' completely unexplained in both schema and description.

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 clear verb (更新/update) and a mechanism (依完整資源名稱/by full resource name), so the agent knows it is an update operation. However, the resource '可更新資料點' (updatable data points) is generic and does not distinguish which entity is being updated relative to siblings like health_create, health_delete, or health_log_meal.

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 one explicit exclusion ('匿名飲食不可更新'/anonymous diet cannot be updated), which is genuine when-not guidance. But it names no alternatives and does not explain when to prefer this over health_create or health_write_status, leaving most usage inference to 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine context that this is a local idempotency lookup of a prior write, which is not derivable from annotations, but it omits what happens on a miss and what the result looks like.

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 concept (idempotency lookup) is front-loaded with the rationale trailing. It is efficient, though quite terse relative to the tool's workflow role.

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 one-parameter read tool whose annotations already cover safety and which has no output schema, the description is close to sufficient. Still missing is any hint about the return value or the no-result case, which an agent calling an idempotency-check tool would reasonably want.

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 parameter is documented in the schema only as an untyped string (0% coverage), so the description carries the burden and does explain the semantic role of idempotency_key: the key whose local write result is being queried. That meaningfully exceeds the bare schema, though no format or length guidance is given.

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 (本機寫入結果) scoped by an idempotency_key, so the agent knows it retrieves a prior write's outcome. It is distinguishable from the mutating siblings (health_create/update/delete) but never names an alternative or sibling to contrast with.

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?

"避免重送" (to avoid resending) implies the intended usage: check before retrying a write. However, it stops at implication — it never says when to prefer this over health_get or health_list, nor what to do if no matching key exists.

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