aicare-mcp

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

Annotations only mark it non-read-only and open-world; the description goes far beyond by disclosing the exact billing model (2 credits, charged whenever a report is produced including '照片不合格、无数据', not charged on param errors/unavailable kind/download failure/upstream failure), the photoUsable=false semantics, and a medical-disclaimer boundary. This is unusually rich operational context.

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?

Dense but front-loaded: purpose and return shape come first, then the kind source, then billing, then the failure/retake path and disclaimer. Each clause carries real information, though the billing sentence is long and could be split for faster scanning.

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 mutation-style tool with no output schema, the description covers prerequisites, billing, failure modes, the photoUsable signal, and the non-diagnostic boundary. An agent has everything needed to call it and interpret the result.

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 carries the per-field documentation and the baseline is 3. The description still adds cross-tool meaning: kind must be a live type and its input form depends on inputMode from aicare_list_kinds, which is routing information absent from the schema itself.

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 ('提交一张照片做 AI 健康检测') plus the return shape (structured report with 体质辨识、健康评分、脏腑功能等), which lets an agent distinguish it from retrieval siblings like aicare_get_detection. It does not explicitly contrast itself with the overlapping aicare_tongue_diagnose sibling, so it falls 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?

Gives concrete prerequisites and routing: 'kind 取自 aicare_list_kinds 中 status=live 的类型', and it tells the agent what to do on failure (按 photoGuide 重拍). It stops short of naming when to prefer this over aicare_tongue_diagnose, so no explicit alternatives/exclusions.

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, covering the safety profile. The description adds useful behavioral context beyond that: results are returned in reverse chronological order and the operation is free ('免费'), which is valuable for cost-sensitive planning.

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 efficient sentence with no wasted words. The core query action and scope are front-loaded, followed by the ordering detail and intended use case.

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 read-only history query with full annotation coverage and no output schema, the description is largely complete: it states what is returned, in what order, and that it is free. It could be improved by noting how it differs from aicare_tongue_history or clarifying pagination behavior, but nothing critical for correct invocation 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 description coverage is 100%, so kind, userId, and limit are already well documented in the schema. The description only implies that kind selects a detection category and userId identifies the user, which does not add meaning beyond what the schema already provides.

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 ('历史报告') with scope ('某用户某一类检测') and ordering ('按时间倒序'), so the core action is clear. However, it does not explicitly differentiate itself from close siblings such as aicare_tongue_history, which also returns detection history, leaving some ambiguity about when this generic-kind tool is preferred.

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 '用于回看或前后对比' gives a clear intended context for using the tool. It does not name alternatives or exclusions, but it provides enough usage direction for an agent to know this is a historical review endpoint.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds useful cost information (免费) and the ownership constraint for userId-less detections, but says nothing about the report's format or size.

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 with the retrieval action front-loaded, followed by the special-case constraint and cost note. Every sentence carries distinct information with no 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 simple read-only single-record fetch with full annotation coverage of the safety profile and no output schema, the description covers what it returns (the detection report), when it is required, and its cost. Only minor detail about report contents is absent.

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 parameter is fully documented in the schema, so the schema does the heavy lifting. The description only confirms healthCheckId is the key without adding format or sourcing detail beyond what the schema already states.

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 (检测报告) scoped by healthCheckId, with a clear single-record scope that distinguishes it from the list-style sibling aicare_detect_history. Sibling differentiation is present but not named explicitly, so it falls 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?

Gives one concrete when-to-use condition: unattributed detections lacking userId can only be retrieved with this tool. However, it never names the alternative (e.g., aicare_detect_history) or states the general case, leaving the choice mostly implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false. The description adds only the async follow-up context (final result after detect running) and does not cover polling behavior, result readiness, or return shape.

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 triggering condition first and no redundant text. It is appropriately sized for a one-parameter follow-up 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?

For a simple one-parameter read-only job-status/result tool with rich annotations and no output schema, the description gives enough to know when and why to call it. It could mention result readiness or polling expectations, but nothing critical is missing for 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 100%, with job_id documented as the value returned by aicare_detect. The description reinforces that same source but adds no parameter syntax or constraints 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?

States that the tool retrieves the final result of a job when aicare_detect returns status=running and job_id. It names the sibling that produces the job_id and scopes the resource to detection job results, though it does not explicitly contrast with aicare_get_detection.

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 gives the triggering condition: aicare_detect must have returned status=running along with job_id. It implies not to use otherwise, but does not name alternatives or when-not scenarios beyond that trigger.

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=true, idempotent=true, destructive=false and openWorld=false, so the safety profile is covered. The description adds real value beyond that: it discloses the payload contents (types, availability flags, photo requirements) and that the call is free, which helps an agent budget/schedule it. It stops short of detailing return format, but that gap is minor.

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 front-loaded sentence plus a short routing clause. Every element (contents, sequencing, cost) earns its place; no padding or repetition of the title.

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 enumeration tool with no output schema, the description conveys exactly what is returned and when to reach for it. Nothing an agent needs to select or invoke this correctly 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?

With zero parameters the baseline is 4; there is nothing to misinterpret. The description correctly implies a call with no inputs and adds no spurious filtering options.

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 (列出/检测类型清单) and enumerates the concrete contents returned: 18 detection types across 舌苔/面部/指甲/口腔/皮肤, open-status, and photo requirements. An agent can distinguish this from aicare_detect or the history/get tools 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?

Explicitly routes the agent: '调用 aicare_detect 之前先看这里' names the sibling tool it precedes and the condition for using it. The '免费' note further aids the decision. No alternative is left implicit.

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 safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), and the description adds value beyond them by enumerating the returned report contents despite no output schema. It omits auth, cost, and rate-limit context, which keeps it short of a 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 compact paragraph front-loads the action, then the return contents, then the parameter rule, then the sibling equivalence. Dense but every clause carries information; 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?

With no output schema, the description compensates by listing the report fields, and all parameters are documented. The relationship to sibling detection tools is noted. It stops short of full completeness only by not clarifying selection among the detect/history/get siblings.

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

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

Schema coverage is 100%, so the schema already documents all four parameters, including the imageUrl/imageBase64 mutual exclusivity. The description restates the '二选一' rule but adds no syntax or format detail beyond what the schema provides, matching the baseline-3 case.

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 (submit a tongue photo for TCM tongue-image analysis) and enumerates what the report contains (constitution, health score, organ status, plan, risk warnings). It also distinguishes itself from the general sibling by declaring equivalence to aicare_detect(kind="tongue"), so the agent can place it precisely without opening a 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?

The note that this equals aicare_detect(kind="tongue") clarifies the relationship to a sibling, but it doesn't state when to prefer this tool over aicare_detect or aicare_tongue_history. Usage is implied (use for tongue diagnosis) rather than explicitly bounded, with no exclusions given.

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 and non-destructive behavior, so safety is covered structurally. The description adds the sort order and the aliasing relationship, but says nothing about authentication, pagination behavior, or how results are returned for a user-scoped history read. That is useful added context but leaves real behavioral 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?

Two short sentences, zero filler, with the core purpose and ordering front-loaded before the equivalence note. Every clause earns its place.

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 appropriately characterizes the return as a historical report list, and the annotations carry the safety profile. Missing details such as result fields or empty-history behavior are minor for a simple filtered list tool.

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%, with both userId and the limit/maximum already documented in the schema. The description only implies user scoping (某用户) and adds no syntax, default, or range detail beyond the schema, 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 and resource (query a user's past tongue-diagnosis report list) plus the ordering (reverse chronological), and explicitly identifies its relationship to the sibling tool aicare_detect_history(kind="tongue"), so an agent can tell it apart from aicare_tongue_diagnose (new diagnosis) without opening 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 names the equivalent alternative call with the exact argument, which tells the agent when either form is interchangeable. It does not, however, state when to prefer this tool over aicare_detect or aicare_tongue_diagnose, so the guidance is clear but not exhaustive.

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