Caddence

Check a golf deal link

check_deal_link

Read-onlyIdempotent

Checks a UK golf retailer product link against that same page's own price record. Answers "is this deal real?": whether today's price is under, at or above what the page usually charges, whether its "was" price was ever charged, and which other retailers have the same build for less, with a buy_url for each. Pass the full product page URL. Pass price and was when the user can see them on the page, because the page may have changed since the last daily check. When builds come back, the page sells builds at different prices: ask which one the user wants and call again with its variant_id. Give the user receipt_url to see or share the check.

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": {
      "url": "<url>",
      "context": "<context>"
    },
    "name": "check_deal_link"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Full URL of one product page at a UK golf retailer
`was`	No	The "was" or RRP price the page shows next to it, in GBP
`price`	No	Today's price shown on the page in GBP, if the user can see it
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`variant_id`	No	A variant_id from builds in an earlier answer, to check that build

Output Schema

Name	Required	Description
`was`	Yes	The "was" price the page shows
`build`	Yes	The build the figures are for. Null when they are for the cheapest of several builds
`model`	Yes	The model at every retailer, sent when the page is too new to judge
`notes`	Yes	Which build the figures are for, and what the same-build match does not check
`price`	Yes	Today's price on the page
`answer`	Yes	The verdict in plain English, ready to quote
`builds`	Yes	The builds on the page when their prices differ. Pass a variant_id back to check that build
`status`	Yes	ok when Caddence has a record of the page. The other values say why it has none
`outcome`	Yes	Today's price on the page against what the same page usually charges
`product`	Yes
`retailer`	Yes
`usual_low`	Yes	Low end of the usual price, null when the record is too short
`checked_on`	Yes	ISO date of the latest price check
`comparison`	Yes	The lowest price for this build at other retailers, as a sentence
`usual_high`	Yes
`real_saving`	Yes	Usual price minus today's price, negative when dearer
`receipt_url`	Yes	The same check as a page on caddence.golf, to share with the user
`price_source`	Yes	"observed" by Caddence, or "pasted" from the price argument
`tracked_since`	Yes
`was_last_seen`	Yes	Last ISO date the page charged the "was" price, if ever
`claimed_saving`	Yes	"Was" price minus today's price
`days_on_record`	Yes
`cheaper_elsewhere`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real behavioral context beyond them — that data is a daily check which may be stale relative to the live page, that builds may come back requiring a second call, and that receipt_url exists to share the result. It does not mention rate limits, auth, or caching behavior, which keeps it off 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?

Front-loads the core question, then layers the input rules and the variant follow-up flow in short declarative sentences with no filler. The builds sentence is slightly dense and could be split, but every sentence carries actionable content.

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

Completeness5/5

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

For a five-parameter tool with a full output schema and solid annotations, the description covers what an agent needs: input prerequisites, the staleness caveat that motivates optional price/was, the two-step variant workflow, and what to do with receipt_url. Nothing essential is left to inference.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond it: price/was are optional freshness inputs the user must physically see on the page, and variant_id is a round-trip identifier from a prior builds answer that triggers a re-check of a specific build. That rationale is not derivable from the schema alone.

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?

States a specific verb and resource — checking a UK golf retailer product page against that page's own price record — and frames the question it answers ("is this deal real?") with the three concrete outputs: today vs. usual price, whether the "was" price was ever charged, and cheaper alternative retailers. This is clearly distinguishable from siblings like get_price_history or get_market_deals.

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

Usage Guidelines4/5

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

Gives explicit procedural guidance: pass the full product page URL, pass price and was when visible because the page may have changed since the last daily check, and on multi-build responses ask the user which build then re-call with variant_id. It never explicitly contrasts against sibling tools such as get_price_history, so the when-to-use-vs-alternative dimension is implied rather than stated.

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

All Caddence 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.

Resources

Need Help?