好啦体检 MCP

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

With no annotations, the description carries the burden and does so well for auth: it names the 401 on missing login and code=40003 with data.bindUrl for unbound cloud-market instances. It also explains the conditional linkage behavior (empty welfareId = unredeemed, non-empty = joins welfare and order), which is real behavioral context beyond the schema. It omits read-only framing and pagination behavior for the limit parameter.

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-loads the login requirement and the core action in two short blocks with no filler prose. The '本体: card → Action: list' ontology line adds little for an agent but costs only a few tokens.

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?

Auth failure modes and the welfare linkage are well covered, and no output schema exists so return values needn't be spelled out. But for a 2-parameter tool with 0% schema coverage, leaving limit undocumented and referencing a nonexistent welfareId parameter is a meaningful gap an agent would trip over.

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 compensate, and it only partly does: cardId is explained as 卡号. Worse, the description discusses welfareId, which is not in the input schema at all, while the actual second parameter (limit) is never mentioned. This is actively confusing rather than merely incomplete.

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: look up the card secret (卡密) and redemption/usage status by card number. That is clearly distinct from the sibling set of welfare/order/contact tools. It stops short of naming which sibling to use for the linked welfare/order data it mentions.

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 '[需要登录]' prefix and the auth paragraph make the prerequisite clear, so an agent knows not to call it unauthenticated. However, there is no explicit guidance on when to prefer this over welfare_detail, welfare_list, or order_list, even though the description implies it joins those domains.

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 exist, so the description carries the whole burden and mostly does: it states that partnerid and external_user_id are server-resolved, that clients must not pass partnerid, and that serviceid is restricted to the caller's own orders. It also spells out the unauthenticated and unbound-instance responses. What is missing is the shape or richness of the returned cautions content.

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 purpose and parameter rules are front-loaded, which is good, but the trailing '本体: knowledge → Action: cautions' taxonomy tag and the parenthetical enumeration add bulk without guiding the call. The auth paragraph is dense yet useful, so it earns most of its length.

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?

There is no output schema, so the description should hint at what comes back; it only says 'cautions (diet, medication, contraindications)'. With three parameters at 0% schema coverage and an unconstrained nested object, an agent still lacks guidance on the expected structure of checkPackage.

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%, so the description must compensate, and it explains the conditional relationship between checkPackage and vendorid and the self-scoping of serviceid. However, it never explains what vendorid identifies or what keys checkPackage should contain, so the object parameter remains partly opaque.

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: query the cautions (diet, medication, contraindications) for a given checkup item. It also tags the domain ('knowledge → Action: cautions'), which helps separate it from siblings like faq or knowledge_get, though it never names an alternative 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 explicit routing rules: pass checkPackage for package cautions, which must be paired with vendorid, while serviceid may only query the caller's own order. It states the auth precondition (login token or user-bound cloud-market place instance) and the two failure modes (401, code=40003 with data.bindUrl). No sibling comparison is offered, which keeps it from a 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?

With no annotations, the description carries the full burden and does well: it discloses the login requirement, the exact failure signals (401 unauthenticated; code=40003 with data.bindUrl when the cloud-market instance is unbound), and the side effect that a "self" contact is system-created. It omits duplicate-handling behavior and rate/side-effect details, keeping 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?

Two compact blocks – business semantics first, then auth/error behavior – with the login requirement front-loaded in brackets. The "本体: contact → Action: create" line adds little but is only a fragment, so waste is minimal.

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 no-annotation, no-output-schema, 8-parameter mutation tool, the description covers auth and minimal-create semantics well but never says what is returned (e.g., a contact identifier) and leaves four parameters (gender, marital, birthday, customerID) entirely unexplained. Adequate, not 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%, so the description must compensate: it marks relation as required and explains that name, mobile, and ID number can be supplied later, effectively covering relation, customerName, customerMobile, and IDType. It gives no meaning at all for gender, marital, birthday, or customerID, leaving half of the 8 parameters undefined in both schema and prose.

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 ("创建家属临时联系人" – create a temporary family/dependent contact), which is clearly distinct from siblings like contact_update, contact_get, and contact_profile_save. It does not explicitly name those siblings, so it falls just 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?

"relation 必填，self 由系统创建；姓名、手机号、证件号可后补" implies a minimal-create usage pattern and explains that only relation is needed up front, which is genuinely useful. However, it never states when to choose this over contact_update or contact_profile_save, nor any exclusion conditions, so usage is only implied.

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 add real context: login token requirement, 401 on unauthenticated calls, and code=40003 with data.bindUrl when a cloud instance is unbound. That is meaningful failure-mode disclosure for an otherwise undocumented read tool, though it says nothing about return payload 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?

Front-loads the purpose and then auth, with the ontology line adding a little noise. Reasonably sized with no rambling.

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?

No output schema exists, so the description should describe what '完整信息' includes; it only hints at masked ID fields. Auth behavior is well covered, but the duplicated contactId/contactid parameters go unexplained, leaving a real ambiguity for the agent.

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% and the description never mentions contactId, so it adds no meaning beyond the bare schema. The schema itself exposes both 'contactId' and 'contactid', an ambiguous duplicate the description could have clarified but 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 specific verb (查询/get) and resource (指定就诊人的完整信息), and adds that it returns masked ID numbers, which distinguishes it from a plain lookup. It doesn't explicitly distinguish it from sibling contact_profile_get or contact_list, leaving some overlap 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?

The auth section implies when the call is valid (logged-in user or bound cloud-market instance), but there is no explicit guidance on when to pick this over contact_list, contact_profile_get, or contact_update. Usage is implied rather than stated.

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: it declares the auth requirement (login token or bound cloud-market credential), the failure modes (401 when unauthenticated, code=40003 with data.bindUrl when the instance is unbound), and a downstream behavioral constraint (no profile save until a candidate is chosen).

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 the action and scope, then a compact auth block. Dense but every sentence (trigger, candidate rule, auth, error codes) earns its place; only slight cost is the mixed imperative/ontology phrasing.

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?

No output schema and no annotations, yet the description still covers auth, error surfaces, and candidate-resolution flow. The main gap is the return shape — it implies a contactid field but doesn't state what each contact record contains, which matters for the follow-up contact_profile_save flow.

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%, so the description must compensate; it says gender and relation are filters over the current user's contacts, which is more than the bare schema offers. However it gives no accepted values, casing, or whether both filters combine (AND) — an agent still can't construct valid values reliably.

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: query the current user's contacts filtered by relation/gender, plus an ontology line (contact → list). It is clearly a list operation and separable from contact_get/profile_get siblings, though it never names the alternatives (corp_contact, contact_get) 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?

Gives an explicit trigger ('用户提到家人时必须先调用') and resolution rules: a single candidate may use contactid directly, multiple candidates require user selection, and profile saving is forbidden until selected. What's missing is when NOT to use it versus contact_get or corp_contact for non-family/company contacts.

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 provided, the description carries the full burden and does well: it discloses that a login token or bound cloud-marketplace credential is required, that unauthenticated calls return 401, and that an unbound instance returns code=40003 with data.bindUrl. It does not describe the shape or size of the 'structured health profile' returned, which is the remaining gap.

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 purpose and the login requirement are front-loaded, and the error semantics are stated compactly. The login requirement is stated twice (the '[需要登录]' prefix and the 鉴权 paragraph), a minor redundancy in an otherwise tight definition.

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?

Auth and error behavior are covered thoroughly, which is the hardest part for a gated read tool with no annotations and no output schema. Still missing: any hint of what the profile payload contains or its size, and disambiguation of the duplicated contactId/contactid parameters, both of which an agent needs to call this confidently.

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 compensate; it does explain that contactid identifies the target contact and is optional, defaulting to the caller. It does not resolve the schema's real ambiguity, however: two near-duplicate fields, 'contactId' and 'contactid', with no statement of which is authoritative or whether they are interchangeable.

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: retrieve a contact's structured health profile by contactid, and states that omitting contactid returns the caller's own profile. That is unmistakably distinct from contact_profile_save (write) and contact_get (basic contact record), although no sibling is named 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 conditional 'if contactid is not passed, read the current user's own profile' is a genuine usage rule, and the login requirement gates invocation. However, there is no guidance on when to prefer this over contact_get or corp_contact, so the agent must infer the boundary from names alone.

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 declares the login requirement, the exact failure signals (401 unauthenticated, code=40003 with data.bindUrl for unbound marketplace instances), and that the call returns the full updated profile plus `created`. The remaining gap is write semantics — it never says whether the save replaces or merges with the existing profile, or what happens to omitted sections, which matters for a mutation over 12 fields.

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 the login flag and the when-to-call constraint, then caller-specific rules, then return value, then a clearly separated auth section. No filler; the only near-redundant line is the "本体: contact → Action: profile.save" tag.

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 12-parameter mutation with no annotations and no output schema, the definition covers auth, invocation gating, contactid routing, and a return summary — but leaves the payload fields and the replace-vs-merge behavior undefined. An agent could call it correctly in the auth sense yet plausibly destroy existing profile sections.

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 12 parameters, so the description must compensate, and it only addresses the contactid case (self vs. family resolution) — useful, especially given the ambiguous duplicate contactId/contactid properties in the schema. The ten health-profile payload fields (lifestyle, surgeries, medications, examinations, problem_list, family_history, etc.) get no meaning, expected shape, or example anywhere.

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 (save/update) and a specific resource (long-term health profile), and explicitly distinguishes the case from plan recommendation ("仅推荐方案不得调用"), which names the closest sibling concern. An agent can tell this apart from contact_profile_get and plan_recommend without opening either 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 an explicit trigger (only when the user explicitly asks to save/update a long-term profile), an explicit exclusion (do not call for mere recommendation), and per-caller rules: omit contactid for self, resolve a unique contactid for family members, never write family data into the self profile. When-to-use, when-not, and the alternative are all present.

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 provided, so the description carries the full burden. It does add genuinely valuable behavior details — the login token requirement and the specific 401 / code=40003 with bindUrl failure paths — which an agent otherwise wouldn't know. But it omits partial-update semantics (what happens to unspecified fields), whether changes are reversible, and the required identifier (contactId).

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 the login marker and purpose, then auth details in a separate line. Efficient, though the '本体: contact → Action: update' line adds little an agent needs.

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 no annotations, no output schema, and 9 undocumented parameters, the description is thin. It never states which field identifies the contact being updated or what the success response contains, which is essential 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?

Schema coverage is 0% across 9 parameters, and the description only names two fields (姓名、手机号) plus '等'. It doesn't explain what contactId vs contactid vs customerID do, nor that an identifier is effectively required despite the schema listing zero required params — a gap that could cause failed calls.

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 ('更新就诊人信息') with example fields, and the 'update' action distinguishes it from contact_create, contact_get, and contact_list. Sibling differentiation is implicit in the action verb rather than explicitly stated, keeping it below 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 description gives a clear precondition for calling (login required, with specific 401/40003 failure modes), which is useful context. However, it never clarifies when to use this vs contact_profile_save (a very similar-looking sibling) or what happens if the contact doesn't exist.

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 provided, so the description carries the full burden. It adds useful context that the tool is anonymously callable and read-only in effect (a query returning contact details), but it does not discuss permissions beyond anonymity, error behavior, or rate limits.

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 compact and front-loads the anonymous-callable status, the purpose, the return fields, and the usage trigger. The final ontology note is somewhat internal metadata but does not meaningfully bloat the definition.

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 zero-parameter, read-only query with no output schema, the description provides enough context: what it returns, when to call it, and that it can be called anonymously. Additional detail about response shape or failure modes is absent, but the essential invocation context is present.

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, so the parameter-semantics baseline is 4. The description correctly does not invent parameter details, and the empty schema means there is nothing further to document.

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 (查询/query) and resource (好啦商务对接人, business contact for group inspection/business cooperation), and lists the returned fields. It differentiates itself from generic contact CRUD siblings by scoping to business cooperation contacts after a quotation, though it does not explicitly name the closest sibling alternatives.

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 trigger: call when the user needs manual business follow-up after a quotation. It does not provide explicit when-not conditions or direct sibling comparisons, but the business context is clear enough for an agent to select it over generic contact tools.

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 disclosure burden. It usefully discloses that the tool is anonymously callable and that sales will follow up within 24 hours, but it does not say whether a lead record is created, whether duplicate submissions are possible, or what the caller receives back.

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 main sentence is compact and front-loads the anonymous-callability tag plus the scope. However, the appended '本体: corp → Action: inquiry' is redundant boilerplate that consumes space without informing the agent.

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?

No annotations, no output schema, and 7 undocumented parameters leave significant gaps. The description covers the what and the follow-up SLA but not the input contract an agent needs to construct a valid call.

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?

Seven parameters with 0% schema description coverage, and the description explains none of them. It never indicates that company, contact and phone are mandatory, nor clarifies what budget, employees, city or message expect (units, formats, free text).

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: submit an enterprise business inquiry, covering cooperation, product info, pricing and complaints. It is distinguishable from nearby siblings like plan_quotation or corp_contact. The trailing 'corp → Action: inquiry' line is metadata that merely restates the name, adding no clarity.

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 says enterprise customers with any question may submit, which implies the trigger condition, but it never says when to prefer this over plan_quotation (explicit quote requests are listed here as well) or corp_contact. There are no exclusions or named 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?

With no annotations provided, the description carries the burden. It usefully discloses the no-auth ('匿名可调用') requirement and the no-query default behavior, but says nothing about return format or pagination. Meaningful context added, but not a full behavioral profile.

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, front-loaded with the anonymous-access note then the default behavior then the parameter constraint. Zero waste.

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 single-parameter lookup with no output schema, the description covers access, default behavior, and param format. It stops short of describing what the returned FAQ items look like, but that is a minor gap for such a lightweight 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 coverage is 0%, so the description must fully document the single parameter, and it does: it specifies short keywords (2-4 chars), gives concrete examples like 报告/预约/空腹, and prohibits full question sentences. This directly compensates for the empty 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 a specific resource (体检 FAQ / health-check FAQ) and clarifies the anonymous-access scope. It's clear what the tool returns, though it never names a sibling (e.g. knowledge_get or help) to differentiate when this FAQ lookup is preferable.

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 both branches: no query lists all questions, a query filters. It also warns against full question sentences. Clear context for calling, but offers no exclusion against the sibling knowledge/help tools.

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 burden and mostly succeeds: it discloses that the tool is callable anonymously (no auth required), which is meaningful context, and that output escalates with input depth. It does not explicitly state read-only/no-side-effects, but for a help lookup that is self-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?

Dense but front-loaded: the anonymous-access and three-tier facts come first, then each tier's behavior in the same breath. No filler, though the run-on comma structure makes it slightly harder to parse than separate lines would.

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 meta/discovery tool with 2 optional params, no output schema, and low complexity, the description covers the full behavioral contract an agent needs to invoke it correctly. Only the shape of the returned listings is left implicit, which is acceptable for a help index.

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%, so the description must compensate, and it does: ontology is described as the filter selecting a tool set, and sub_action is defined as a fully-qualified action name with concrete examples (vendor.list, plan.quotation). The compound-key relationship between the two parameters is conveyed, though the exact format semantics of ontology naming are only shown by example.

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 mechanism (a three-tier help/discovery system) and precisely enumerates what each call level returns. It is unmistakably distinct from all siblings, which are concrete business operations rather than a self-describing index of them.

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 call ladder: no args for the ontology list, ontology alone for its tools, ontology + sub_action for parameters. That is effectively 'when to use which mode'. It does not explicitly say to prefer calling a known tool directly instead of going through help, but the progressive-disclosure framing implies it.

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 disclose key traits: the call is anonymous-callable ([匿名可调用]), it is a read-only lookup, and it produces a prompt that must act as an external MCP agent's system prompt governing downstream quotation wording and templates. It does not describe what happens on an invalid URI or what an unlisted URI returns, which is the remaining gap.

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 capability and URI list come first, then the scenario workflow, so it is well front-loaded with no filler sentences. The second half is a single long run-on clause that is slightly denser than needed, but every sentence carries operational 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 one-parameter read tool with no output schema and no annotations, the description supplies the URI catalog, the anonymous-access note, the sibling routing rule, and the mandatory ordering with plan_quotation - enough to call it correctly. Missing only error behavior for bad URIs and any sense of return shape.

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%, so the description must compensate, and it does by enumerating the valid URI values with short glosses (状态码, 联系人, 健康画像, 企业团检方案顾问引导词). It does not state whether uri is required, what the format/prefix convention is beyond the examples, or whether unlisted URIs exist.

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 domain knowledge on demand) and immediately enumerates the concrete knowledge artifacts available (enums, objects/contact, objects/contact-profile, objects/checkup-proposal). It also distinguishes itself from the sibling help() tool by routing 'action parameter' lookups there.

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 routing is given for two cases: use help() for action parameters, and in the group checkup quotation scenario load knowledge_get({uri:"objects/checkup-proposal"}) FIRST, then call plan_quotation. The ordering constraint and the alternative tool are both named, leaving nothing to inference.

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 provided, the description carries the full burden and does a good job: it discloses the authentication requirement, the exact failure modes (401 for unauthenticated, code=40003 plus data.bindUrl for an unbound instance), and the read-only nature implied by 查询. It stops short of pagination, rate limits, or response shape beyond the field list.

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 the login marker and a one-line purpose statement, followed by a compact auth/error block — all of which earns its place. The '本体: order → Action: detail' ontology tag adds little for an agent choosing a tool and is the main piece of 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?

There is no output schema, and the description compensates by enumerating the detail payload (appointment, hospital, package items, payment status) and covering auth failure behavior thoroughly. The remaining hole is what serviceid must contain, which leaves the agent guessing at 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% and the single parameter, serviceid, is completely unexplained in both schema and description. The agent must infer that serviceid is the order identifier the detail lookup keys on — a critical ambiguity given the tool queries 'a single order' but the parameter is named after a service id.

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 even enumerates what the detail contains (预约信息、医院信息、套餐项目、支付状态). The word 单个 implicitly contrasts with the sibling order_list, but no sibling is named explicitly, so it falls short of full differentiation.

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 establishes the precondition for use (must be logged in / bound cloud-market instance) and what happens otherwise, which is genuine usage context. However, it never says when to choose this over order_list (e.g., that you first need an order id from the list endpoint) or any other alternative.

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 delivers real behavioral detail: login token or bound cloud-market instance credential required, 401 when unauthenticated, code=40003 with data.bindUrl when the instance has no bound user. It also discloses that partner identity is resolved server-side so partnerid must not be passed. Missing only pagination/ordering behavior.

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-loads the login requirement and the core action in the first clause, then auth details. Every sentence carries information, though the auth paragraph is somewhat long for the amount of content and could be tightened.

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?

No output schema exists, so the description should say more about what a call returns — shape of the order list, whether pagination metadata is included, total counts. Auth and filter-capability coverage are good, but the response side and pagination semantics are absent for a 3-parameter 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 0%, so the description must compensate, and it partially does: filter supports $gte/$lte date ranges and $in/$or multi-value matching, and partnerid must be omitted. However page and limit are entirely unexplained — no defaults, bounds, or ordering semantics.

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 ("查订单") and names the backing collection (userOrders), plus an ontology mapping ("本体: order → Action: list"). It is clearly a list operation distinguished by name from the sibling order_detail, though the description never explicitly contrasts them.

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 by the single phrase "查订单"; there is no guidance on when to call this versus order_detail, or on typical search scenarios. The rest of the text is auth prerequisites, not selection advice.

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 substantial work: it discloses the returned data.list shape, that planList is split per population, that discount is a partner discount factor (e.g. 5 = 5折, null if none), and forbids fabricating items/costs. It omits error behavior, auth, and idempotency details, which keeps it from 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?

Everything stated earns its place, and the purpose plus input format is front-loaded before the return-value and prerequisite details. The single dense paragraph is harder to scan than a structured breakdown, which keeps it from a 5.

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 complex quotation tool with a free-form schema and no output schema, the description covers input field semantics, output shape, discount interpretation, the knowledge_get prerequisite, and the reservation.book handoff. Nothing an agent needs to call it 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?

Schema coverage is 0% and the schema is effectively free-form objects, so the description must supply all meaning — and it does: it enumerates each quote item's fields (tier, budget, healthConcerns, populations with man/lady/girl defaults) and explains partnerId is a UUID passed through for partner pricing.

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+resource: enterprise group checkup quotation (企业团检报价), and immediately explains that quotes is an array with one plan per tier. An agent can distinguish it from siblings like plan_recommend or reservation_book because it names its own input structure and downstream handoff to reservation.book.

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 an explicit prerequisite: load knowledge_get({uri:"objects/checkup-proposal"}) as the system prompt before calling, and it states that planId must be passed to reservation.book rather than hand-assembling items. It does not explicitly contrast with alternatives like plan_recommend, so 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?

With no annotations, the description carries the full burden and does well: it declares a login requirement, the 401 response for unauthenticated calls, code=40003 with data.bindUrl for unbound cloud-market instances, and that the call is long-running with a suggested progress-reporting pattern. It stops short of describing pagination, rate limits, or failure modes during recommendation.

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 auth marker is front-loaded, followed by purpose, return contract, next-step routing, and finally the auth/error block in a separate paragraph. Every sentence carries information, though the inline '本体: plan → Action: recommend' tag is low-value noise.

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 documents the return shape (selected_items with constraintId, plus planId) and the handoff to reservation.book. Auth and latency behavior are covered, but the ten undocumented input parameters leave a real gap for a tool this parameter-heavy.

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 10 parameters, so the description must compensate, yet it only loosely names gender, marital status, budget, and health concerns (mainComplaint). age, welfareid, userContext, modification, reportHistory, and previousPackage receive no explanation at all, leaving over half the inputs opaque.

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 (recommend personal health-checkup items) and states its inputs (gender, marital status, budget, health concerns) and outputs (data.selected_items with constraintId, plus planId). It does not explicitly contrast with plan_quotation, the closest sibling, which keeps it below 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 concrete downstream guidance: 'planId 直接传给 reservation.book 预约，不要自己拼项目', and recommends calling progress.report at each stage for a long-running operation. It also states authentication prerequisites and the failure codes. What's missing is when to prefer plan_quotation or other siblings instead.

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 provided, the description carries the disclosure burden and does add real value: it declares the call is anonymous-safe and that nothing is written to business data, which reassures an agent about side effects. It does not say whether successive progress messages replace or accumulate for the user, nor whether there is any rate limit on repeated calls.

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, front-loaded with the purpose, then the call cadence, then the side-effect boundary. Every sentence contributes and nothing is padded.

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 purpose, cadence, and safety profile are covered, which is most of what an agent needs. But with three parameters, no annotations, and no output schema, the unmentioned `stage` and `percent` fields are a real completeness gap for a tool intended to be called repeatedly mid-task.

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 compensate. It explains the required `text` parameter well, including that it must be user-readable and gives a concrete example ("report parsing, ~10 seconds"). However, the optional `stage` and `percent` parameters are never mentioned in either schema or description, leaving two of three parameters semantically opaque.

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 (report progress for long-running tasks) and immediately scopes the effect: it does not persist business data, it only surfaces process to the user. No sibling tool overlaps this purpose, so an agent can distinguish it cleanly.

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 explicitly says when to call: once per completed stage during a long-running task. That is a concrete cadence rule rather than an implied one. It stops short of naming an alternative tool for cases where the task finishes instantly or fails, but no obvious sibling exists for that.

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 so thoroughly: auth requirements, 401/40003 behavior, contact handling, IDType validation, planId-only item source, payment link behavior, duplicate unpaid-order behavior, and status semantics are all disclosed.

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 long but largely justified by a complex booking, contact, payment, and auth flow, and it is front-loaded with login and purpose. It is dense rather than cleanly structured, but most sentences add operational value.

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?

There is no output schema, yet the description explains key returns such as serviceid, orderEntryUrl, and payUrl, along with payment, duplicate-order, and auth error behavior. It is complete enough for an agent to understand the full reservation flow.

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 9 parameters, and the description only meaningfully explains planId, contactId, and IDType. Required parameters hospitalCode, vendorid, and appointmentDate, plus payType, timespan, and contactid, are left undocumented, so it 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?

The description states a specific verb and resource: health-check reservation booking via planId, then partner ordering. This clearly distinguishes booking from sibling tools such as reservation_cancel and reservation_modify by action.

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 prerequisites and flow: login required, contactId is used directly when present, and without contactId it describes elicitation and H5 fallback behavior. It does not explicitly route against sibling alternatives, but the booking context is clear.

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 at all, the description carries the full burden and does well: it discloses the auth requirement, two concrete error responses, and the refund side effect on paid orders. It stops short of saying whether cancellation is reversible or whether the refund is synchronous, which are the remaining operational unknowns for a destructive action.

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 core action and its refund consequence are front-loaded, followed by auth and error behavior. Slightly padded by the '本体: reservation → Action: cancel' ontology line, which an agent does not need to invoke 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?

For an unannotated, output-schema-less mutation tool, the description covers auth, error codes, parameter provenance, and the refund consequence. Missing only reversibility/idempotency and refund timing, which are secondary.

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 single parameter is undocumented in the schema. The description compensates by explaining that reservationId is the serviceid returned by reservation.book, which is exactly the provenance an agent needs to populate it correctly.

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 adds a material side effect ('已支付订单会同时发起退款'). It ties the input to a sibling ('预约号取自 reservation.book 返回的 serviceid'), which implicitly separates it from reservation_modify, though it never names that alternative 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 clear preconditions — a login token or a user-bound cloud-market instance — plus the specific failure modes (401, code=40003 with data.bindUrl). That is useful context but it is authentication guidance, not a when-to-use/when-not-to-use rule against reservation_modify, and no alternative is named.

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 usefully discloses authentication requirements: user login token or bound cloud marketplace credentials, plus 401 and 40003 error behavior with data.bindUrl. It still omits some mutation traits such as whether rescheduling can fail due to availability or policy constraints.

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 purpose and authentication requirements are front-loaded and the auth/error details are useful. However, the line '本体: reservation → Action: modify' largely restates the tool name and title, adding minor redundancy.

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 two-parameter mutation with no annotations and no output schema, the description gives adequate operational context around auth and errors. It is incomplete because the critical appointmentDate format is unspecified in both schema and description, leaving an agent to guess the required date syntax.

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 compensate. It does clarify that the operation uses a reservation number and a new reservation date, mapping to reservationId and appointmentDate, but it does not specify the expected date format or other constraints.

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: changing a reservation date, explicitly '按预约号改期' by reservation number. The action 'modify' is clearly distinct from sibling operations such as reservation_book and reservation_cancel.

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 makes clear this is for rescheduling an existing reservation by reservation number, which implies use only when modifying a date rather than booking or cancelling. It does not explicitly name sibling alternatives or exclusions, so it stops short of a 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?

With no annotations, the description carries the burden: it does disclose anonymous callability and that results are an aggregated summary excluding individual stores, which is genuine behavioral context. It says nothing about result size, ordering, or whether empty brands are included.

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, front-loaded clauses with the answer level stated immediately; the trailing '本体: vendor → Action: brands' is internal taxonomy boilerplate that adds little for an agent but costs only a few tokens.

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 zero-parameter, no-output-schema read tool, the description plus the aggregation note is enough to call it correctly. Only the exact shape of the returned brand/city mapping is left 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 to document and the baseline is 4. The description correctly implies no filtering input is needed.

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: query which cities each health-check brand covers, and clarifies the aggregation level (brand-level summary, not specific stores). This separates it from a store-level listing, though it never names the sibling vendor_list it is closest to.

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 by the negative constraint '不返回具体门店' — an agent can infer this is for brand-level coverage rather than store lookup, but there is no explicit when-to-use/when-not and no named alternative such as vendor_list.

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 load and does disclose meaningful behavior: anonymous callability, the external tenant whitelist, the internal-only partnerid, the default radius, and which brand is used when vendorids has multiple entries. It does not describe the response shape, result limits, or error behavior when no criterion is matched.

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 purpose followed by a numbered list of modes and then caveats — efficient and scannable. The trailing ontology tag ('本体: vendor → Action: list') and bracketed callable marker add little for an invoking agent.

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 8-parameter, annotation-free lookup tool, the description covers invocation strategy, defaults, and access constraints well. The remaining gap is that with no output schema, it never says what a result entry contains (store fields, distance, pagination), which an agent needs to plan the call.

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 accounts for all eight parameters and explains the grouping logic that the schema cannot express: hospitalCode vs lon/lat vs province/city/district are mutually alternative selectors, radius applies only to the geographic mode, and vendorids behaves as a filter within a mode. That is exactly the compensation required.

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 (query store addresses) and enumerates the three lookup modes. It also names vendor_brands as the prerequisite/alternative, so the agent can separate this from sibling list tools 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?

Gives explicit routing rules: at least one of three call shapes must be supplied, radius defaults to 50000, vendorids only narrows within a chosen mode, and vendor_brands should be called first when brand/city coverage is unknown. It also states the external-caller restriction to health100/haolaruici and that partnerid is internal-only.

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 disclose real behavioral facts: login token required, 401 when unauthenticated, code=40003 plus data.bindUrl for unbound cloud-market instances. It still doesn't say whether the read is strictly non-mutating or whether errors beyond these two exist.

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 the login requirement marker, then purpose, then auth failure modes — each sentence carries information. The '本体: welfare → Action: detail' line is somewhat redundant with the tool name but harmless.

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 tool with no output schema and no annotations, the auth/error disclosure is valuable, but the undocumented vendorid parameter and the absence of any hint about return shape leave gaps. Adequate but not 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%, so the description must compensate and largely fails. '指定福利' loosely maps to the required welfareid, but the optional vendorid is never mentioned and no format/source for the IDs 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+resource ('查询指定福利的详细内容') and enumerates what the payload contains (检查项目列表、规则说明、适用机构). The name/title pair 'welfare.detail' also distinguishes it from sibling welfare_list, though the description never explicitly says so.

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 context is implied rather than stated: 'detail' plus a required welfareid suggests it is called after welfare_list, but no explicit when-to-use/when-not or alternative routing is given. The auth preconditions are the only concretely stated invocation guidance.

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 behavioral burden and does a good job on auth: it names the login token requirement, states that unauthenticated calls return 401, and that an unbound cloud-market instance returns code=40003 with data.bindUrl. It says nothing about what a result looks like, whether results are paginated/capped, or how multiple matches (e.g., a common name) are resolved.

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 leading '[需要登录]' flag plus the one-line purpose is well front-loaded, and the auth paragraph is compact. The closing '本体: welfare → Action: list' line is framework boilerplate that adds little for an agent.

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?

There is no output schema and no annotations, and four of the seven parameters are undocumented while the return shape, match-ambiguity handling, and pagination are unaddressed. Auth and error behavior are covered, but for a 7-param list tool with no structured help, this is not enough to call it correctly and interpret results.

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 7 parameters exist, so the description must compensate and it only partly does: it explains mobile/name/userid as alternative identity keys. Four parameters (ID, rootid, partnerid, serviceid) get no mention at all, and the example key 'customerMobile' does not match the schema property name 'mobile', which risks a wrong invocation.

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: query the userWelfare collection of 体检件 (health-checkup records), and tags it 'Action: list', which contrasts implicitly with the sibling welfare_detail. It never explicitly says 'for a single record use welfare_detail', so the sibling differentiation is only implied by the 'list' verb.

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 gives concrete lookup modes (by customerMobile, by name, or by userid if already known), which is real usage guidance for choosing parameters. It does not say when this tool should be preferred over welfare_detail or welfare-adjacent siblings, and gives no exclusion rules or limits on result count.

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