langfuse-mcp-java

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

Annotations already mark destructiveHint=true and idempotentHint=false. The description adds crucial context: specific deletion scope (ALL versions vs labeled vs specific number) and explicitly states 'irreversible'. This explains *what* gets destroyed under different conditions, going beyond the binary safety flags.

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?

Information-dense structure using bullet points for the three behavioral modes. Every sentence earns its place: purpose statement, filter behavior breakdown, required field reminder, and irreversibility warning. No redundancy.

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?

Covers deletion modes and irreversibility well, but there's unresolved tension: the schema marks all 3 parameters as required while the description describes label/version as optional filters (to be 'omitted'). The description doesn't clarify this discrepancy, leaving ambiguity about the actual invocation contract.

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 has 100% coverage (baseline 3). The description significantly adds meaning by explaining the interaction logic between parameters—specifically that label and version function as optional filters despite being schema-required, and the consequences of omitting them. This semantic mapping between parameter presence and deletion scope is essential.

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?

Clearly states the action ('Deletes prompt versions') and target resource ('promptName'), distinguishing it from sibling tools like create_prompt, get_prompt, and update_prompt_labels. The specific focus on 'versions by name' clarifies scope.

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?

Excellent coverage of behavioral modes based on parameter combinations (omit both/supply only label/supply only version). Explicitly notes 'promptName is required' and warns 'This action is irreversible', providing important guardrails. Could explicitly contrast with update_prompt_labels but the filter logic serves as strong implicit guidance.

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