explain_concept

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 reveals the adaptive behavior based on mastery level and indicates a read-like operation ('Get'), but it does not mention potential side effects, prerequisites such as existing mastery data, or how the depth parameter interacts with the adaptive logic. The description provides some behavioral context but lacks completeness.

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 consists of two concise sentences, front-loaded with the primary purpose. The first sentence defines what the tool does, and the second elaborates on the adaptive behavior. Every word earns its place, with no redundancy or filler.

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 relatively simple tool with all parameters documented in the schema, the description effectively conveys the core functionality and adaptive nature. However, it does not describe the return format or the interaction between the depth parameter and mastery-based adaptation, which could be relevant for an agent. Since there is no output schema, a bit more detail would be ideal, but overall it is adequately complete for a read-only explanation 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 schema description coverage is 100%, so all parameters are already documented with descriptions. The tool description adds context about mastery level influencing explanation depth, but it does not explicitly reference the 'depth' parameter or clarify how it interacts with the adaptive system. Since the schema fully covers parameter meaning, a baseline score of 3 is appropriate.

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 function: to get an adaptive explanation of a concept based on mastery level. It distinguishes itself from siblings like get_concept (static retrieval) and ask_question (interactive Q&A) by emphasizing the personalization aspect. The verb 'Get' is specific enough, and the resource 'explanation of a concept' is explicit.

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 should be used when an adaptive explanation is needed, but it does not explicitly mention when to prefer it over get_concept or ask_question. No exclusions or alternative tools are named, so usage guidance is only inferred from the adaptive wording.

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