Winquill

Watch for tenders

watch_tenders

Use this when the user wants alerts for new tenders or upcoming notices that match a search, or for changes to one tender they follow (clarifications, new deadlines, the award). Saves a watch and gives its watchId: matches show in get_tender_updates and, with notify, in the workspace's Slack or Teams channels that get changes. Needs a Winquill account. Not for seeing the user's watches (use list_watches) or stopping one (use stop_watch). Example: {"query":"office cleaning","include_upcoming":true}

Input Schema

Name	Required	Description
`query`	No	What to watch for, e.g. "office cleaning".
`notify`	No	Also post what the watch finds to the user's workspace's Slack or Teams channels, where they get changes. Only when the user asks for it there.
`region`	No	Where the work or delivery happens: a UK nation or English region, e.g. "North West" for Manchester or Liverpool; a Canadian province or territory, e.g. "Ontario" for Toronto; a US state, e.g. "Virginia"; a German Land by its German name, e.g. "Bayern" for Munich; a French region, e.g. "Île-de-France" for Paris; or another EU member state, e.g. "Poland". Omit for nationwide contracts or when the user names no place.
`country`	No	The country to look in, when the user names one, e.g. "Canada", "UK" or "Spain" (an EU member state searches the rest of the EU there). Omit to use the user's own countries (the UK when they aren't signed in). Winquill covers the UK, Canada, the United States, Germany, France and the rest of the EU.
`buyer_type`	No	Kind of public buyer, e.g. "local_authority" for councils, "nhs" for NHS trusts and ICBs, "education" for schools, academy trusts and universities.
`include_upcoming`	No	Also alert on pipeline and preliminary market engagement notices, to hear about work before it is tendered.
`tender_reference`	No	Watch one tender for clarifications, deadline changes and the award instead of a search, e.g. "012345-2026".

Output Schema

Name	Required	Description	Default
`found`	No
`credit`	No
`notify`	No
`created`	No
`summary`	Yes
`watchId`	No
`channels`	No
`workspace`	No
`alreadyOpen`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedInput schema / properties / country / description

Previous value: -"The country to look in, when the user names one, e.g. \"Canada\", \"UK\" or \"Spain\" (an EU member state searches the rest of the EU there). Omit to use the user's own countries (the UK when they aren't signed in). Tenda covers the UK, Canada, the United States, Germany, France and the rest of the EU."New value: +"The country to look in, when the user names one, e.g. \"Canada\", \"UK\" or \"Spain\" (an EU member state searches the rest of the EU there). Omit to use the user's own countries (the UK when they aren't signed in). Winquill covers the UK, Canada, the United States, Germany, France and the rest of the EU."

First observedOct 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses the created artifact and its return (a watchId), where matches surface (get_tender_updates and, with notify, Slack/Teams), and the account prerequisite. This is the useful context a non-destructive mutation needs, and it does not conflict with readOnlyHint=false/openWorldHint=true.

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 the trigger, then the outcome, prerequisites, exclusions, and an example — no filler. The single long sentence for the notify/Slack-Teams behavior is slightly dense but still earns its place.

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 7-parameter mutation tool with an output schema and full schema coverage, the description covers trigger, side effects, auth, and routing of results. Nothing an agent needs to invoke it correctly is missing.

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 already 100%, so baseline is 3; the description adds mode semantics by distinguishing a search watch from a tender_reference follow, and the example shows query plus include_upcoming usage. It could say slightly more about how query and tender_reference interact when both are supplied.

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 (saves a watch for tender alerts) and explicitly covers both modes: a search-based watch and a single-tender follow. It is immediately distinguishable from list_watches, stop_watch, and get_tender_updates.

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?

Gives trigger conditions ('when the user wants alerts for new tenders... or for changes to one tender'), names the alternatives for adjacent intents ('Not for seeing the user's watches (use list_watches) or stopping one (use stop_watch)'), and includes a concrete example invocation.

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

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