civitai-mcp-ultimate

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

The description adds valuable behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, the description reveals that 'Previews cached locally for Read tool' and explains the purpose of 'exclude_used' to 'avoid duplicate posts.' This provides practical implementation details that help the agent understand caching behavior and duplicate avoidance.

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 efficiently structured with bullet-like formatting that clearly presents each parameter and its semantics. While comprehensive, every sentence serves a purpose in explaining parameters or behavioral context. It could be slightly more front-loaded by moving the caching note earlier, but overall it's well-organized and avoids unnecessary verbiage.

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?

Given the tool's complexity (16 parameters, 0% schema coverage) and the presence of annotations and output schema, the description provides complete contextual information. It fully documents all parameters, explains key behavioral aspects like caching and duplicate avoidance, and provides usage context. The output schema existence means the description doesn't need to explain return values, making this description comprehensive for the agent's needs.

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?

With 0% schema description coverage for 16 parameters, the description carries the full burden of explaining parameter semantics. It successfully documents all 16 parameters by listing them with clear explanations of their purposes, acceptable values, and usage contexts (e.g., 'browsing_level: "PG", "PG-13", "R", "X", "XXX" (comma-separated)' and 'requester: who is requesting... Always specify for publishing workflows').

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: 'Get top images/videos from Civitai — best for finding great prompts.' It specifies the exact resource (images/videos from Civitai) and distinguishes itself from sibling tools like 'browse_images' or 'search_models' by focusing on 'top' content with specific ranking criteria.

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 provides clear context for when to use this tool ('best for finding great prompts') and mentions 'publishing workflows' for the requester parameter. However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list, such as 'browse_images' or 'search_models', for different use cases.

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