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

With no annotations, the description carries the full burden for behavioral disclosure. It does state the return format (JSON array with specific fields), which is helpful. However, it does not clarify behavior when 'symbol' is null (the parameter is optional with default null), nor does it mention whether this is a read-only operation, error conditions, or authentication needs. The description is mostly a structural schema, lacking richer behavioral context.

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

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

The description is exceptionally concise and well-structured, with a clear title, Args section, and Returns section. Every sentence earns its place, and there is no fluff or redundant information. It is front-loaded with the tool's purpose and provides the essential parameter and return field list in a compact format.

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 tool is simple (one optional parameter, no required fields), and the description covers the parameter and return fields adequately. However, the lack of an output schema in the structured data (though the description lists fields itself) and the missing behavior for null symbol leaves a completeness gap. The description is sufficient for a basic retrieval tool but not fully complete for an agent to predict all behaviors.

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

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

Schema description coverage is 100%, so the schema alone fully documents the 'symbol' parameter. The description does not add any meaning beyond the schema; it repeats the same example (000001.SZ). The parameter's optionality and the default-null behavior are present in the schema but their semantic implication (what happens when null) is undocumented. Baseline of 3 applies because the schema does the heavy lifting.

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 identifies the tool as returning Shenwan industry classification (申万行业分类) for a stock symbol, with the resource being industry classification data. It distinguishes itself from sibling tools like 'concepts' or 'concept_members' by the specific domain (industry vs concept). The lack of an explicit verb like 'get' or 'retrieve' is minor because the Args/Returns structure implies a data retrieval operation.

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 provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. With many sibling tools (stocks, concepts, basic), the absence of usage context is a clear gap. No mention of what to do when 'symbol' is omitted or how this relates to other classification tools.

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