get_user

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

No annotations are provided, so the description carries the burden. It discloses the mechanism (calling pool contract's get_user ABI method via algod simulate), which implies a read-only simulation. However, it doesn't disclose what happens if the market is paused, what the return data contains, or any side effects (likely none). The phrase 'via algod simulate' gives some transparency about the simulation nature, but more context on output or errors would be helpful.

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 a single sentence that is reasonably concise and includes the essential action and method. It is not overly verbose, but could be slightly improved by adding a brief note on usage without bloating.

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?

The tool has three simple parameters with full schema coverage, so the description doesn't need to explain return values (no output schema exists, but the description could mention what 'position data' includes). Contextually, it's complete enough for a straightforward getter, but the lack of output schema and minimal description of the return payload leaves some ambiguity about what exactly is returned and how to interpret it.

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 coverage is 100%, with descriptions for all three parameters. The description itself doesn't add much beyond the schema, but that's acceptable because the schema already documents each parameter. The description does clarify that the tool targets a DorkFi lending market, which gives context to the symbol parameter, but this is minimal added 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 states the tool retrieves a user's on-chain position data for a DorkFi lending market, specifying the contract call and method (get_user) and the simulation via algod. It distinguishes from siblings like get_markets and get_market by focusing on a user's position, though it doesn't explicitly mention 'get_position' which might be a close alternative.

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 is used when you need a specific user's position in a specific market, but it doesn't provide explicit when-to-use versus alternatives like get_position or get_health_factor. Sibling names suggest overlapping functionality, but no guidance is given on choosing among them.

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