match_main_contract

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds the source URL and exchange choices, but it does not disclose behavior such as data freshness, network dependency, error handling for invalid symbols, or the format of the returned string. This is acceptable given the read-only nature declared by annotations.

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, containing only the source, parameter choices, and return type. It avoids unnecessary prose. However, the Chinese title duplicates the annotation title, and the long URL might be considered noise, though it does provide the data source. The structure is acceptable but could be improved by front-loading a clear verb phrase.

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 (one optional parameter, returns a string) and the annotations providing safety context, the description is mostly adequate. It covers the source and parameter choices, but it does not explicitly state what the function does beyond the return type, nor does it describe the format of the main contract string or behavior for invalid exchange codes. These are minor gaps for a simple read-only 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?

The input schema has zero description coverage for the 'symbol' parameter, but the description compensates by explicitly listing the five valid exchange choices: {'czce', 'dce', 'shfe', 'cffex', 'gfex'}. It clarifies the expected values, which is essential since the schema only defines 'symbol' as a string with a default. It does not explain what each code means, but the list itself adds significant semantic value.

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 indicates the tool returns the main futures contract string for a given exchange, with the Chinese title '新浪财经-期货-主力合约' and return type '主力合约的字符串'. However, it lacks an explicit verb phrase and does not differentiate from sibling tools like futures_main_sina or futures_display_main_sina, which likely serve similar purposes.

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 alternative futures tools. It only lists valid exchange codes and the return type, with no context about use cases, prerequisites, or exclusion of sibling tools. The schema default for 'symbol' (cffex) is mentioned in the schema but not explained in the description.

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