Agent Sense

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (CPU, memory, disk, network info, with optional detailed mode for temperature, battery, GPU) and emphasizes the importance of real-time data for performance diagnosis. However, it lacks details on potential limitations like rate limits, error conditions, or data freshness, which would be helpful for a tool with no annotation coverage.

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 appropriately front-loaded with the core purpose, but it includes repetitive warnings (e.g., multiple ⚠️ symbols and emphatic statements) and a lengthy list of scenarios that could be more streamlined. While informative, some sentences could be condensed without losing clarity, making it slightly verbose for its content.

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 complexity (hardware diagnostics with real-time data) and lack of annotations or output schema, the description does a good job covering purpose, usage, and return values. It specifies what information is returned in both basic and detailed modes. However, it doesn't describe the output format (e.g., structured data vs. text) or potential errors, leaving some gaps for the agent to infer.

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 100% description coverage for its single parameter 'detailed', so the baseline is 3. The description adds value by explaining what 'detailed mode' includes (CPU temperature, battery status, graphics card info), providing context beyond the schema's boolean description. This compensates meaningfully, though it doesn't cover edge cases or default behavior implications.

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's purpose: '获取用户硬件配置和实时使用情况' (get user hardware configuration and real-time usage). It clearly distinguishes from siblings like get_location, get_system_info, and get_time by focusing specifically on hardware metrics (CPU, memory, disk, network) rather than location, general system info, or time.

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 extensive, explicit guidance on when to use this tool, listing 7 specific scenarios (e.g., performance complaints, resource diagnosis, configuration inquiries). It also includes strong imperatives like '强制调用场景' (mandatory call scenarios) and '必须调用' (must call), clearly directing the agent to prioritize this tool over alternatives in relevant contexts.

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