query_learning_context

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

With no annotations this description carries the full burden. It valuably discloses non-obvious traits: outcome counts cover current experience versions in this project only, agent reports/unknown outcomes do not count as measured success, pattern matching is lexical and belief retrieval is hybrid. However, it omits return structure, ordering, and any cost/permission notes.

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?

Purpose is front-loaded in the first clause, with the semantic caveats following in terse sentences. Dense but no filler sentences; the only cost is that caveats compete with the core purpose early on.

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?

A retrieval tool with 3 undocumented parameters, no annotations, and no output schema needs more than this. Return shape and the meaning/format of 'context' are missing, leaving the agent unsure how to invoke it correctly despite the useful caveats about counts.

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%, so the description must compensate, and it largely does not. The critical 'context' parameter is never explained (how a situation is expressed for lexical pattern matching), nor is 'project' scoping or the 'limit' bound clarified beyond the incidental note about lexical matching.

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 verb ('Retrieve') and resource ('relevant beliefs and situation-matched procedures') along with return contents (outcome counts, Beta estimates). It is distinguishable from simple list/query siblings in spirit, though it never explicitly contrasts with 'query_relevant' or 'list_beliefs'.

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?

No when-to-use guidance is provided: it does not say when this tool should be chosen over 'query_relevant', 'list_beliefs', or 'query_intervention'. The disclaimers about counts and retrieval are interpretive caveats, not invocation guidance.

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