probe_technology_details

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 discloses a non-obvious behavior — that selected_ids are auto-resolved to technology names from a cached prior question ('会自动尝试从刚才的提问缓存里转成技术名') — and describes the return shape (structured follow-ups plus a ready-to-read natural-language question). Auth/permission and failure behavior are not covered.

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?

Uses labeled Args/Returns sections and front-loads the core purpose, which aids scanning. Slightly verbose in the setup paragraph and the Returns block duplicates what Args already implies, but nothing is genuinely wasted.

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 multi-step interactive tool with no annotations and no output schema, the description supplies the missing pieces: the pipeline position, each parameter's role, and the return format. An agent has enough to call it correctly, though edge cases (e.g. what happens when selected_ids cannot be resolved) are 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?

Schema description coverage is 0%, but the description documents all three parameters, including the tricky selected_ids semantics (comma-separated indices, auto-conversion from cache) and the relationship between selected_ids and selected_technologies. This compensates well 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 action (追问技术细节) on a specific resource (users' confirmed technologies) and explicitly positions itself as the second step of probe_idea_question, so an agent can distinguish it from that sibling without opening either schema. Concrete examples (YOLO 版本, MediaPipe API, 树莓派型号) make the intent unmistakable.

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 a clear precondition ('用户确认了想了解/想用的技术后') and names the preceding alternative (probe_idea_question) as step one, so the sequencing is unambiguous. It does not spell out when this tool should be skipped, but the trigger condition is well defined.

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