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

No annotations are provided, and the description does not disclose behavioral traits such as whether it is read-only, latency, rate limits, or authentication requirements. As a query tool, read-only behavior is implied but not stated.

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 concise with two short sentences that convey the essential information without any unnecessary detail. It is front-loaded with the purpose.

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?

Given the low complexity (2 parameters, simple types) and presence of an output schema, the description is adequate for a basic query tool. However, it lacks behavioral context like error handling or result limitations, which could be important for an 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 description coverage is 0%, so the description must add meaning. It only hints that 'ent_info' can be an enterprise name, credit code, or registration number, but does not specify format or provide any details for the 'extra_params' parameter. The description does not fully compensate for the lack of schema descriptions.

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 clearly states it queries enterprise business registration information using one of three identifiers (name, credit code, registration number). It uses a specific verb and resource, and is distinct from sibling tools like trademark or patent queries.

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 mentions the query inputs (enterprise name, credit code, registration number) but does not explicitly state when to use this tool versus alternatives such as fuzzy search or deep query. No guidance on when not to use 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 provided, the description carries full responsibility for behavioral disclosure. It states the tool performs a 'deep' query but does not clarify what 'deep' entails, such as scope of data, rate limits, authentication requirements, or if the operation is safe read-only. Basic query intent is implied but not explicitly stated.

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 very concise with two front-loaded sentences. It efficiently conveys the core purpose and parameter selection rule without wasted words, though it could benefit from a clearer structural breakdown.

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?

Given the tool has 5 parameters, no schema descriptions, and an output schema exists, the description is insufficient. It does not explain what 'deep' means, what data the query returns, or that only one identifier should be provided. The output schema exists but the description does not reference or complement it.

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% with no parameter descriptions. The description adds value by explaining the rule that one of four identifiers must be used ('四选一'), but it does not describe the format or constraints of each identifier, nor does it explain the 'extra_params' field. Partial compensation.

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 clearly states the tool queries basic business information (deep) and lists the four acceptable identifier types. However, it does not explicitly differentiate from the sibling tool 'p0010010_query_business_profile', though 'deep' suggests a different scope.

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 indicates that exactly one of four identifiers should be provided ('四选一') but provides no guidance on when to use this tool versus alternatives like fuzzy search or business profile query. No prerequisites or exclusion criteria are mentioned.

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 must disclose behavioral traits. It only states a fuzzy search is performed, but does not mention result limits, ranking criteria, or any side effects. An output schema exists, but behavior is not explained.

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 short (two sentences) and to the point, with no extraneous words. It could be slightly more informative without sacrificing conciseness.

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?

Given 4 parameters and an output schema, the description is insufficient. It fails to explain optional parameters, result format, or any constraints. The tool is relatively simple, so a minimal description is expected, but gaps remain.

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 description only mentions the '企业名称关键字' (ent_name), ignoring type, region_id, and extra_params. The description adds no meaning beyond the parameter names themselves.

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 clearly states the tool performs a fuzzy search of company names by keyword, distinguishing it from sibling tools that query specific business data (trademarks, patents, etc.). The phrase '简版' hints at a simplified version, but no full version is listed.

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

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

No guidance is provided on when to use this tool versus alternatives, or what the optional parameters (type, region_id, extra_params) are for. The description only implies usage for keyword-based fuzzy matching.

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 must fully disclose behavior. It only states the query method (by enterprise name or document number) but omits details such as pagination (page_no, page_size), the role of tm_reg_no and extra_params, any required permissions, or the structure of the response. This leaves significant gaps for the agent.

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 short and to the point, but it lacks structure (e.g., no separation of purpose from parameters). It front-loads the core action but omits important details. While concise, it could be more informative without adding 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?

Given the tool has 5 parameters with no schema descriptions, no annotations, and an output schema (unknown content), the description is insufficient. It covers only the basic search criterion but fails to explain pagination, optional filters, or the nature of the returned data.

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 input schema has 5 parameters with zero description coverage. The description only mentions the required 'ent_info' parameter (enterprise name or document number), ignoring the purpose of page_no, page_size, tm_reg_no, and extra_params. An agent cannot infer their semantics without additional information.

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 clearly states the tool queries trademark information by enterprise name or document number, distinguishing it from sibling tools focused on patents, copyrights, or business profiles. However, it could be more specific about the output (e.g., returning a list of trademarks) to enhance 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?

The purpose implies it is for trademark queries, and sibling tools cover other IP types (e.g., patent, copyright), so usage context is somewhat clear. However, there is no explicit guidance on when to use this tool vs alternatives, nor any mention of prerequisites or limitations.

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 provided, and the description omits behavioral traits such as pagination behavior, authorization requirements, or rate limits. The agent is left uninformed about side effects or 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 description is two sentences long, front-loaded with the main purpose, and contains no redundant 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?

The description adequately states the purpose and key input, but lacks usage guidelines and behavioral details. An output schema exists but is not sufficient to compensate for missing guidance on when and how to use.

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 description adds meaning for the required 'ent_info' parameter (allowed inputs: name, credit code, registration number), but ignores 'page_no', 'page_size', and 'extra_params'. With 0% schema coverage, more parameter context 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?

The description explicitly states it queries 'enterprise software copyright information' and specifies the input criteria (enterprise name, unified social credit code, or registration number). This distinguishes it from sibling tools like trademark or patent queries.

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

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

No guidance on when to use this tool vs alternatives (e.g., work copyright query). It only describes what it does, without scenarios or 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?

No annotations are provided, so the description carries the full burden. It states a query operation, implying read-only, but lacks details on rate limits, authentication, error handling, or behavior when no results are found.

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 concise sentence with no wasted words. It is front-loaded with the purpose, but could be structured better with additional details.

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?

Despite having 5 parameters and an output schema, the description provides no information on return values or parameter details. It is incomplete for effective use.

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

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

Schema description coverage is 0%, and the description does not explain the parameters (e.g., pub_no, page_no, page_size). The schema titles are generic, and the description adds no meaning beyond the parameter names. This is inadequate for correct parameter usage.

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 clearly states the tool's purpose: querying enterprise work copyright information using enterprise name, business registration number, or unified social credit code. It explicitly distinguishes it from sibling tools like trademark, software copyright, and patent queries.

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

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

The description implies usage when work copyright info is needed but provides no explicit guidance on when to use this tool vs alternatives or any prerequisites. No exclusions or comparisons are 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?

With no annotations provided, the description carries full burden but only states it queries data. It fails to disclose read-only nature, authentication needs, rate limits, or behavior on no results.

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 concise sentence that immediately states the tool's purpose. It is appropriately front-loaded but could benefit from slight expansion on parameters.

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?

Given 4 parameters, 0% schema coverage, and no annotations, the description is too minimal. It lacks details on pagination, output schema expectations, and usage scenarios beyond the main input.

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 description adds meaning to the required parameter 'ent_info' by listing acceptable values (name, registration number, credit code). However, it does not explain 'page_no', 'page_size', or 'extra_params', and schema coverage is 0%.

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 explicitly states the tool queries ICP filing information using enterprise name, registration number, or credit code. It clearly differentiates from sibling tools that handle other business data.

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

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

The description implies the tool is used for ICP filing queries and specifies acceptable input types for the main parameter. However, it does not explicitly compare with sibling tools or state when not to use 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?

No annotations provided, so description carries full burden. It implies a read operation (query) but does not explicitly state it is read-only, nor does it disclose any behavioral traits like authentication requirements, rate limits, or side effects.

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

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

Two sentences are concise. First states purpose, second adds date format. Could include more structure but efficient.

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 7 parameters and an output schema not shown, description lacks details on pagination (page_no, page_size), filtering by patent type (ptt_type), or extra_params. Date range is hinted but not fully explained. Incomplete for a query tool with many optional parameters.

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 description must compensate. It mentions date format for date parameters but provides no meaning for page_no, ptt_type, page_size, extra_params. Only ent_info is implied by '根据企业名称'. Insufficient detail.

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 clearly states it queries patent information with the enterprise as patent applicant, specifying the resource (patent info) and action (query by enterprise name). It distinguishes from siblings focusing on trademarks or copyrights.

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

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

No guidance on when to use this tool versus alternatives like trademark or copyright queries. There are no prerequisites or exclusions mentioned.

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?

The description mentions a two-step orchestration but does not explain how the tool handles the process (e.g., how entryId is obtained, what happens if multiple results, error handling). It references an 'entryId' parameter that is not present in the input schema, causing confusion. With no annotations provided, the description carries full burden for behavioral disclosure but falls short.

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 very short (two sentences), which is concise, but it sacrifices essential information. It is front-loaded with the purpose, but lacks parameter details and usage guidance. It could be considered under-specified rather than properly concise.

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?

Despite the tool having 10 parameters and an output schema, the description provides minimal context. It does not explain the orchestration logic, date format, pagination, or what the tool returns. An agent would struggle to invoke it correctly without additional knowledge.

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 only mentions 'ent_name' and 'entryId' (entryId not in schema) but does not explain the other 9 parameters like page_no, start_date, end_date, info_label, etc. No format, default behavior, or constraints are given, making it nearly impossible for an agent to use the tool 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?

The description clearly states the tool's purpose: querying enterprise public opinion information. It mentions a two-step process involving P0050007 and P0050008, which adds specificity. However, it does not explicitly differentiate this composite tool from the individual sibling tools p0050007_query_public_opinion_list and p0050008_query_public_opinion_detail, which would help an agent choose between 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?

No guidance is provided on when to use this composite tool versus using the individual sibling tools. There is no mention of prerequisites, scenarios where this is appropriate, or situations where alternatives are better. The description lacks usage context.

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 full burden but only mentions the ent_name parameter. It does not disclose read-only nature, pagination, rate limits, or any behavioral quirks. The schema's many parameters are unaddressed.

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 concise at two sentences, but it sacrifices completeness. It front-loads the purpose but lacks structure for the many parameters.

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?

Given 9 parameters, 0% schema coverage, and a presumably rich output schema, the description is severely lacking. It only addresses ent_name, leaving users uninformed about other fields, filters, and result format.

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 only explains the ent_name parameter with an example. The other 8 parameters (page_no, end_date, etc.) are completely undocumented, adding no semantic value 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?

The description clearly states it's a query for enterprise public opinion information list and mentions the key parameter ent_name. It distinguishes from sibling tools like p0050008_query_public_opinion_detail by being a list query, but does not explicitly differentiate from other list-type siblings.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, filters, or scenarios where this tool is preferred over others like detail queries or info queries.

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 bears the burden. It discloses the two-step process when using ent_name, but omits details on side effects, rate limits, or authorization requirements.

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

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

Two sentences, efficient and front-loaded with key behavioral information. No unnecessary words.

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 an output schema, the description covers the main usage pattern. However, it lacks details on extra_params and edge cases (e.g., both parameters provided).

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%, but the description adds meaning for entry_id and ent_name by explaining their usage priority. The extra_params parameter remains undocumented.

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 the tool queries enterprise public opinion details, and provides specific guidance on using entry_id or ent_name. It clearly distinguishes from siblings like p0050007_query_public_opinion_list.

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 advises preferring entry_id and explains the behavior when only ent_name is passed. However, it does not explicitly state when not to use this tool or compare with siblings.

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

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

The description indicates the tool performs a verification (matching check), which is a read-only operation. No annotations are provided, but the description does not contradict any potential annotations. It does not detail side effects, authentication needs, or rate limits, but for a simple verification tool, this is minimally adequate.

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 sentence that is front-loaded with the tool's function. Every word is essential and there is no redundant 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?

Given the tool's simplicity and the presence of an output schema, the description is moderately complete. It fails to mention prerequisites or error scenarios, but it covers the core purpose and inputs adequately for most use cases.

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

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

Schema description coverage is 0%, and the description only mentions the parameters in a general sense ('企业名称' and '统一社会信用代码/企业注册号'). It does not provide format, constraints, or examples, leaving significant gaps for an agent to correctly invoke the tool.

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 clearly states that the tool verifies two elements of business (name and registration number). It uses specific verbs and resources, and it distinguishes itself from the sibling tool 'p0060008_verify_business_three_elements' by specifying 'two elements'.

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

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

The description implies usage for verifying business name and registration number matching, but it does not explicitly state when to use this tool over alternatives like the three-element verification or query profiles. No exclusions or alternatives are mentioned.

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 must fully disclose behavioral traits. It only states 'verify consistency' without detailing what happens on success/failure, side effects, authentication needs, or rate limits. Basic safety profile is unclear.

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 concise sentence conveying the core purpose. It is efficient but could benefit from slight restructuring (e.g., bullet points) for readability.

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 description covers the basic purpose but does not mention return values, error handling, or output schema behavior. With an output schema present but not referenced, more detail would improve completeness.

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. The description names the three required parameters in natural language (企业名称, 统一社会信用代码/注册号, 法定代表人姓名) corresponding to ent_name, reg_no, fr_name, adding meaning beyond bare schema. However, extra_params is not explained.

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 clearly states the tool verifies consistency of three business elements (name, credit code/registration number, legal representative). It uses a specific verb 'verify' and resource 'business three elements', distinguishing it from siblings like the two-element verification tool.

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

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

The description implies use for three-element verification but does not explicitly state when to use this tool versus alternatives (e.g., two-element verification). No guidance on prerequisites or context is provided.

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, and the description provides no behavioral details such as error handling, rate limits, or authentication requirements.

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?

Very concise but at the expense of critical information; not optimally structured for an AI 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?

Despite having an output schema and many sibling tools, the description lacks any context about return values or usage scenarios.

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 description does not explain any of the three parameters beyond names.

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?

Description identifies tool as 'Generic CISP JSON gateway query' and contrasts with product-specific tools, making purpose clear despite lack of detail.

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 states 'Prefer product-specific tools when available,' providing clear when-to-use and when-not-to-use guidance.

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