aicare_tongue_diagnose提交一张舌头照片完成中医舌象分析，返回结构化报告（体质辨识、健康评分、脏腑功能状态、个性化调理方案、风险提示）。imageUrl 与 imageBase64 二选一。等价于 aicare_detect(kind="tongue")。
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | AICare 的数字用户 ID（如 577974642）。只在需要关联该用户档案时才传；不要传自定义字符串，否则会被拒绝 | |
| imageUrl | No | 公网可访问的照片 URL（与 imageBase64 二选一） | |
| targetId | No | AICare 关爱对象的数字 ID（可选） | |
| imageBase64 | No | 照片的 base64（可带或不带 data: 前缀；≤10MB） |
Changes observed during successful MCP inspections.
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.
Add one secure layer between your agents and this server.