Warmlink

Vouch for a product

vouch

Idempotent

Save the user's own vouch, recommend or avoid for a software product on Warmlink, with their why in a sentence. Only use it when the user asks to vouch, recommend or avoid something, in their own words. A vouch or recommend shows their name unless they ask otherwise; an avoid is never public. Warmlink also shows how long they have used it, whether they still use it, and their role, all optional. If they have not said these, you may ask once, in one short question, before saving. If you save first, the result lists the missing details: tell the user it is saved and offer to add them. Calling vouch again for the same product adds details without changing anything else.

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": {
      "product": "<product>",
      "rank": "<rank>",
      "why": "<why>"
    },
    "name": "vouch"
  }
}

Input Schema

Name	Required	Description
`why`	Yes	The user's why: why they rank it, in a sentence, 140 characters at most
`rank`	Yes	vouch (stand behind it), recommend (good, with caveats) or avoid
`role`	No	Their role, if they said ("Founder, 5-person agency"), 80 characters at most
`product`	Yes	Product name or website URL
`how_long`	No	How long they have used it, if they said
`show_name`	No	Show their name on it. Default: yes for vouch and recommend, no for avoid
`still_using`	No	Whether they still use it, if they said
`confirm_rank`	No	Only after a previous call said the why reads like a different rank and the user chose to keep this rank

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / confirm_rank

Added value: +{
+  "description": "Only after a previous call said the why reads like a different rank and the user chose to keep this rank",
+  "type": "boolean"
+}

First observedOct 21, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses visibility rules (vouch/recommend show the name unless asked otherwise; avoid is never public), which extra details Warmlink surfaces, and that the result enumerates missing details so the agent can offer to add them. It also explains that a repeat call only adds details without changing anything else, which corroborates idempotentHint=true and destructiveHint=false.

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-loaded with purpose and trigger, then conditional detail; nearly every sentence carries actionable information. It is a dense single block rather than clearly sectioned, which slightly hurts scannability for an eight-parameter tool.

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?

With eight parameters, no output schema, and rich annotations, the description covers what an agent needs: visibility, the optional-detail protocol, and the post-save follow-up. It leaves the sibling relationship (recommend vs vouch, and how to undo via withdraw) unaddressed, which is the remaining gap.

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 is 3, but the description adds real meaning: the default show_name behavior per rank, the ask-once rule for role/how_long/still_using, and the conditions under which confirm_rank applies (a prior call flagged a rank mismatch and the user kept their choice). It stops short of explaining the rank enum distinctions beyond what the schema already says.

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

Purpose4/5

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

States a specific verb and resource: saving the user's own vouch/recommend/avoid for a software product on Warmlink, including the required 'why'. The scope is clear, but it never distinguishes itself from the sibling `recommend` tool, which overlaps with rank=recommend here, leaving a real ambiguity an agent must resolve on its own.

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 an explicit trigger ('Only use it when the user asks to vouch, recommend or avoid something, in their own words') and a pre-call protocol (ask once, in one short question, if optional details are missing). It also tells the agent what to do after a save. What it lacks is routing guidance against alternatives such as `recommend` and `withdraw`.

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

All Warmlink 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?