manage_object_repo

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

With no annotations, the description carries the full burden. It discloses key behaviors: save exports to a specific path with metadata, load appends with optional transforms, search filters by query/category/tags/quality. However, it does not detail side effects (e.g., overwrite behavior, permission requirements) or handling of edge cases.

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 brief (7 lines) with a clear summary line and bullet-point breakdown of operations. It is front-loaded and efficient, though the first line 'Object repository management' slightly overlaps with the subsequent detail.

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 18 parameters, no annotations, and no schema descriptions. The description explains only a fraction of these parameters and does not cover important fields like version, author, quality_rating, etc. Given the parameter richness, the description is significantly incomplete.

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. It partially explains parameters related to operations (query, category, tags, quality for search) but does not cover many others like object_name, version, author, min_quality, complexity, limit, quality_rating, public. The description adds limited value beyond listing parameters in the schema.

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 purpose: managing an object repository with four specific operations (save, load, search, list_objects). It distinguishes itself from sibling tools like manage_asset_library by specifying the repository location (~/.blender-mcp/repository/) and the actions involved.

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 usage scenarios by listing operations (e.g., export vs. append), but it does not explicitly state when to use this tool over alternatives like blend_export or manage_asset_library. No when-not or exclusion criteria are provided.

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