Stonewake

Tender matches

tender_matches

Read-onlyIdempotent

The public procurement notices the caller team's tender profiles matched, newest first, one row per procedure citing its newest matching notice. Each match explains every criterion its profile sets (CPV code, NUTS region, value band in EUR, keyword, procedure type, buyer legal type, notice kind, days to the tender deadline) with the outcome hit, the notice field it read, what the notice states there and what the profile asks, and carries the notice itself with its source_url and record_id as the citation. A notice is a match only when it hits every criterion its profile sets, so an unknown is never a match. Winners are never shown, and a buyer whose legal type may name a natural person is withheld (buyer_withheld). Filter by status (new, dismissed or in_deal_book) or profile_id, page with limit and offset, or pass match_id alone to read one match. A match outside the caller team answers not_found. A match can also cite a notice of the team's own portal lane (portal_notice, an export the bank uploaded or an alert of one of its portal accounts), chosen by a profile or by the portal's own saved search (decided_by portal_search). Pass deal_id alone for the matches an analyst took into that deal of the Deal Book (status in_deal_book), where the notice is cited on the deal.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size, default 50, maximum 100.
`offset`	No	Rows to skip, default 0.
`status`	No	Only matches in this status.
`deal_id`	No	The matches a deal of the Deal Book holds, by its deal id.
`match_id`	No	One match by its id, as list rows carry it in id.
`profile_id`	No	Only matches of this tender profile.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 17, 2026

addedInput schema / properties / deal_id

Added value: +{
+  "description": "The matches a deal of the Deal Book holds, by its deal id.",
+  "maxLength": 16,
+  "minLength": 1,
+  "pattern": "^[0-9A-Za-z]+$",
+  "type": "string"
+}

Changed3 schema fields changedOct 12, 2026
- addedInput schema / properties / match_id / maximum
```
Added value: +2147483647
```
- addedInput schema / properties / offset / maximum
```
Added value: +9223372036854776000
```
- addedInput schema / properties / profile_id / maximum
```
Added value: +2147483647
```
AddedOct 11, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Even though annotations already declare readOnly/idempotent/non-destructive, the description adds substantial behavioral context: a notice matches only when every criterion hits, unknowns are never matches, winners are never shown, buyers naming natural persons are withheld (buyer_withheld), out-of-team matches return not_found, and the portal_notice lane is disclosed.

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

Conciseness3/5

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

The purpose is front-loaded and most sentences carry information, but the description is a dense wall of long run-on sentences (e.g. the portal lane and deal_id sentences) that is hard for an agent to parse quickly. Information density is high, yet readability and structure suffer.

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?

With no output schema, the description carries the full burden and does so: it describes the returned match structure, the per-criterion explanation fields, source_url/record_id citations, and the portal_notice variant. Nothing an agent needs to interpret results 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 100%, so a baseline of 3 applies, but the description adds real meaning: match_id alone reads a single match, deal_id alone scopes to Deal Book matches, and status enumerates new/dismissed/in_deal_book. limit/offset add nothing beyond the schema, keeping it below a 5.

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?

The opening sentence names the specific resource and scope: the procurement notices the caller team's tender profiles matched, one row per procedure with newest-first ordering. It distinguishes clearly from siblings like tender_profiles and tender_export_preview by explaining exactly what a returned match is.

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?

It gives explicit invocation modes: filter by status or profile_id, page with limit/offset, pass match_id alone to read one match, or pass deal_id alone for Deal Book matches. It doesn't name sibling tools as alternatives, but the selection conditions among its own modes are spelled out clearly.

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

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