List all materials in the current Blender file with user counts to identify used and unused materials for cleanup or review.
List all materials in the blend file with user counts.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0+hardened.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a read-only operation. The description adds the useful detail that the tool returns user counts, which goes beyond the annotation. There is no contradiction, and the description is consistent with the read-only nature. The addition of user counts is a small but meaningful extra behavioral insight.
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, front-loaded sentence with no fluff. It states the action and the output in a direct manner, making it highly efficient for an agent to parse.
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 description fully conveys what the tool does (lists materials) and what it returns (user counts). An output schema exists to detail the exact return structure, so nothing essential is missing. For a simple parameterless read-only list, this is complete.
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 tool has zero parameters, so the input schema is trivially complete with 100% coverage. The description does not need to explain any parameter semantics because there are none. Baseline 4 is appropriate for a parameterless tool.
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 verb (list), the resource (all materials), and an additional detail (with user counts). It is specific and distinct from sibling list tools like list_objects or list_lights, leaving no ambiguity about what the tool does.
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 conveys the purpose but does not explicitly say when to use this tool versus alternatives such as list_material_info or get_material_info. The context is clear enough that an agent can infer usage, but no exclusions or alternative routing are provided, so a 3 is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.