tripo_list_projects

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

No annotations are provided, so the description carries the full burden of disclosure. It does communicate useful behavioral context: results are ordered newest-first, the results belong to the account, and the key output field is project_id. However, it does not mention that the operation is read-only, does not list the fields of a project entry, and does not address error or empty-result cases, which is a real gap because there is no output schema.

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?

It is two compact sentences with the primary behavior and the downstream use of the returned ID front-loaded. The trailing note about the internal assets/v2 endpoint is implementation trivia that does not help an agent decide or call, but it takes minimal space.

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 simple two-optional-parameter list tool with no annotations and no output schema, the description covers what the tool is and why you would call it. However, because there is no output schema, it should say more about the shape of a returned project entry (such as available fields and whether a total count is returned), so an agent knows what to expect from the result.

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 100%; both parameters (size with a default of 20 and a maximum of 50, and offset with a default of 0) are fully documented in the schema itself. The description adds nothing about the parameters, so the schema does the work.

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 states a clear verb+resource combination: it lists the account's model projects, states the ordering (reverse chronological), and says the list yields project_ids for other tools. This makes it easy to tell apart from the sibling generation and editing tools, which all perform actions rather than list resources. The description does not explicitly name any sibling tools, so it is not a full 5.

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 says to call this tool to obtain a project_id for use in other tools, which implies that it is a discovery/entry-point step in a workflow. It does not state when this tool is preferred over any alternative, and it does not give any exclusions, so the usage guidance is only implied.

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