run_conversation_analysis
Analyze an ElevenLabs conversation by ID to get insights, sentiment, or performance data.
Instructions
Run Conversation Analysis
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | ID of the conversation |
Analyze an ElevenLabs conversation by ID to get insights, sentiment, or performance data.
Run Conversation Analysis
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | ID of the conversation |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false, idempotentHint=false, and openWorldHint=true, which already signal that this is a mutating, non-idempotent operation with external effects. The description adds nothing to this - it doesn't explain what the analysis does, whether it incurs costs, how long it takes, or what happens after running. With annotations covering the safety profile, the description still fails to provide any operational context.
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 extremely short, but it's under-specified rather than concise. There's no structure or front-loading of useful information - it's just a restatement of the name.
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 tool that likely triggers a complex analysis process, the description is completely inadequate. It provides no information about what the analysis entails, what output to expect, or any side effects. The presence of an output schema would be helpful, but there is none.
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%, with the single parameter 'conversation_id' clearly documented as 'ID of the conversation'. The description adds no further parameter semantics. When schema coverage is this high, a baseline of 3 is appropriate.
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 'Run Conversation Analysis' is essentially a restatement of the tool name. It doesn't specify what kind of analysis is performed, what output to expect, or how it differs from sibling tools like run_conversation_evaluations. It's a tautology that adds no clarity beyond the name itself.
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?
There is no guidance on when or why to use this tool versus alternatives. The sibling tools include run_conversation_evaluations and run_conversation_simulation_route, but the description provides no indication of which one to choose. No when-to-use, no prerequisites, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.