Ripplewatch

Log a won or lost deal

log_win_loss

Record the outcome of one deal (for many at once use import_win_loss), with the reason if known and the date it closed. This is the most valuable input: it lets Ripplewatch tie a competitor's moves, and its own gaps, to real deals. The competitor is optional because most lost deals never learn who won: log the reason anyway and Ripplewatch will still count it. A competitor that isn't tracked yet is suggested for tracking instead of rejected. Pass the real close date (closed_on), because trends over time depend on it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "outcome": "<outcome>"
    },
    "name": "log_win_loss"
  }
}

Input Schema

Name	Required	Description
`amount`	No	Deal value, if known.
`reason`	No	Why, in the customer's own words if possible.
`outcome`	Yes	Whether the account won or lost the deal.
`closed_on`	No	The date the deal closed, YYYY-MM-DD. Defaults to today.
`deal_name`	No	The deal or account name, if known.
`competitor_name`	No	The competitor that won (or was beaten), if the deal named one. Leave out when unknown.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 4, 2026

addedInput schema / properties / amount

Added value: +{
+  "description": "Deal value, if known.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / closed_on

Added value: +{
+  "description": "The date the deal closed, YYYY-MM-DD. Defaults to today.",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

changedInput schema / properties / competitor_name / description

Previous value: -"The competitor involved in the deal."New value: +"The competitor that won (or was beaten), if the deal named one. Leave out when unknown."

addedInput schema / properties / competitor_name / maxLength
```
Added value: +200
```
removedInput schema / properties / competitor_name / minLength
```
Removed value: -1
```

addedInput schema / properties / deal_name

Added value: +{
+  "description": "The deal or account name, if known.",
+  "maxLength": 200,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "competitor_name",
-  "outcome"
-]New value: +[
+  "outcome"
+]

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, closed-world), so the bar is lower. The description adds genuinely non-obvious behavior: an untracked competitor_name is not rejected but suggested for tracking, and competitor is optional because most lost deals never identify the winner. It does not cover duplicate handling or what happens to an already-logged deal, so it stops short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the verb and the sibling routing, each carrying operational content. The 'most valuable input' framing is mild product rhetoric but it does reinforce that logging is worth doing even with sparse data, so it just about earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter write tool with full schema coverage and no output schema, the description covers the main ambiguity risks: bulk vs. single, missing competitor, and date fidelity. The remaining gap is return behavior (what the agent gets back after logging, e.g. whether a new competitor suggestion is surfaced in the response).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline would be 3; the description earns above that by adding the meaning behind two optional fields — closed_on must be the real close date because time-series trends depend on it, and competitor_name is deliberately omittable. It still doesn't touch amount or deal_name semantics, which the schema alone carries.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Record the outcome of one deal') and immediately delimits scope against the sibling bulk tool ('for many at once use import_win_loss'). An agent can distinguish it from import_win_loss, log_customer_feedback, and get_deal_impact without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the alternative tool and the condition that selects it (many deals at once → import_win_loss), and tells the agent to log anyway when the competitor is unknown. That is a real when-to-use / when-not decision rule rather than an implied one.

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

All Ripplewatch tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.