conversation_signalsThe 40 moments in a sale worth acting on, in six groups (buying signals, appointment handling, follow-up gaps, coaching moments, record gaps, agent handoffs). Without a signal, returns the list; with a signal slug, returns what it sounds like, why it matters, what to do next, how to coach it and how to practice it.
| Name | Required | Description | Default |
|---|---|---|---|
| signal | No | A signal slug from the list |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds behavioral value by disclosing the conditional return behavior (list vs. detailed breakdown) and the specific sections included in the detailed response (sounds like, why it matters, what to do next, how to coach, how to practice). No contradiction.
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?
Two tightly written sentences with no filler. The opening sentence establishes the tool's scope and grouping, and the second immediately explains the dual-mode behavior. Every word earns its place.
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 read-only reference tool with one optional parameter and no output schema, the description is comprehensive. An agent knows exactly what to expect in both invocation paths and has no critical missing information needed to call it correctly.
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 schema covers the single parameter fully ('A signal slug from the list'), so the baseline is 3. The description enriches this by explaining the behavioral difference when the parameter is omitted versus provided, which goes beyond static schema documentation.
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 is a library of 40 sales moments grouped into six named categories, with two explicit modes: returning the full list when no signal is provided, or returning detailed guidance for a specific signal slug. This distinguishes it from action-oriented sibling tools like answer_ai_caller_question or score_call.
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?
Usage is implied through the description of behavior: an agent can infer to call this when needing signal definitions or reference material. It explicitly explains both invocation modes (with/without the optional signal parameter), providing clear context, though it does not name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.