Tenderfix
Server Details
Open UK and EU public tenders (Find a Tender, TED) with go/no-go screening. Paid tier via L402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
TDQS
Scored across 1 tool
With only one tool, there is no possibility of selecting the wrong tool or confusing it with another operation. Its purpose is clear from the name and description.
The single tool uses a clear verb_noun snake_case pattern, search_tenders. There are no competing names or mixed conventions to create inconsistency.
A single tool is borderline thin for a tender-discovery server. It covers only one operation, leaving little surface for a realistic workflow.
The tool only returns a free sample of up to five tenders, while full results and go/no-go scores are available only through a paid external endpoint. Agents have no MCP tool to retrieve full tender details, paginate results, or access scoring, creating significant workflow gaps.
Available Tools
1 toolsearch_tendersBInspect
Free sample: up to 5 open UK/EU public tenders matching filters. Full results and go/no-go scores are paid via L402 at /v1.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| cpv | No | ||
| country | No | ||
| min_value | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two meaningful traits: a hard 5-result sample cap and a paid L402 tier for full results. However, it omits the payment/auth flow details, error behavior, and result ordering, leaving significant behavioral gaps for a gated endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the free-sample limit front-loaded and the paid tier as a second beat. Nearly zero waste, though the '/v1' path fragment is of marginal use to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is too thin. It covers the sample cap and paywall but leaves the filter semantics and the shape of returned tenders entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters, so the description must compensate—yet it only says 'matching filters'. It never explains what 'q' searches, what 'cpv' is (domain jargon for Common Procurement Vocabulary), the format of 'country', or the currency/unit of 'min_value'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('search... open UK/EU public tenders') plus an explicit result cap ('up to 5'). The scope is clear enough for an agent to know this is a free, limited search endpoint, though it doesn't mention the filter dimensions themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (free sample searching with filters, full results gated behind L402 payment at /v1) but gives no explicit guidance on when to call this versus other approaches, nor how to pick among the filters. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
search_tenders
Related MCP Connectors
Open UK and EU public tenders (Find a Tender, TED) with go/no-go screening. Paid tier via L402.
11Search official UK tenders and create source-linked, deterministic supplier-fit assessments.
Search EU public tenders across TED and 8 national portals. Monitor, match, and analyse procurement.
Search public procurement notices from 17 sources across Germany, the EU and the UK. Read-only.
Related MCP Servers
- AlicenseAqualityBmaintenanceEnables AI agents to find, score, and monitor government contract opportunities across UK, EU, and US with AI-powered relevance scoring.221 npm1MIT
- AlicenseAqualityFmaintenanceEnables searching for EU public-procurement tenders, analyzing cross-border risk, and understanding tender details through tools for CPV code lookup, EU threshold checks, red-flag scanning, and SME fit scoring.7MIT
- AlicenseNot gradedqualityDmaintenanceFind, analyze, and score Polish public tenders (BZP): parsed requirements, deadlines, certificates, and bid-fit scoring against your company profile.5 npmMIT
- AlicenseNot gradedqualityDmaintenanceEnables search and analysis of European public procurement tenders, including EU above-threshold (TED) and below-threshold from 11 national sources, with hybrid search and filtering.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.