tendfeed-mcp

Name: tendfeed-mcp
Author: tendfeed-eu

Official

by tendfeed-eu

Overview Schema Related Servers Score Discussions

JavaScript

Remote

TendFeed — Bid/No-Bid Intelligence MCP Server

Should you bid? Every open EU tender, scored against 592,000 real award outcomes.

Language: English · Deutsch

MCP Registry License: MIT Data

MCP server for bid/no-bid intelligence on EU public tenders, built on 592,000 real TED contract awards: observed competition density (median bidders, single-bidder share), price corridor, SME fit and beachhead ranking for every open tender. It answers "can I win this?", not just "what is out there?".

Why this exists

Tender portals list what is out there — they don't tell you whether bidding is worth it. Most losing bids die on competition and price, and that information exists: it is in the award notices of tenders already decided. TendFeed benchmarks every open EU tender against 592,000 real award outcomes (bidder counts, winning prices, SME shares per CPV sector × country) and returns a verdict with its evidence — the score, the reason, and the number of awards it is based on. An agent (or a human) can check the basis instead of trusting a guess. Works in Claude Code, Claude Desktop, Cursor, and any other MCP-capable harness.

Related MCP server: oro-intel-mcp

Two ways to use it

1. Connect to the hosted server (recommended) — no installation, always current data:

claude mcp add --transport http tendfeed https://tendfeed.eu/api/mcp/tendfeed

For stdio-only clients (Claude Desktop, Cursor) via mcp-remote:

{
  "mcpServers": {
    "tendfeed": {
      "command": "npx",
      "args": ["mcp-remote", "https://tendfeed.eu/api/mcp/tendfeed"]
    }
  }
}

2. Run the bundled stdio wrapper — zero dependencies; initialize/tools/list answer offline, tool calls reach the hosted endpoint:

node index.js

Or with Docker:

docker build -t tendfeed-mcp .
docker run -i --rm tendfeed-mcp

Add to an MCP client config:

{
  "mcpServers": {
    "tendfeed": {
      "command": "node",
      "args": ["/path/to/tendfeed-mcp/index.js"],
      "env": { "TENDFEED_API_KEY": "cfm_live_…  (optional, unlocks the live board)" }
    }
  }
}

Tools

Tool	What it answers
`find_low_competition_lanes`	"Where is competition thinnest right now?" — ranks CPV sector lanes by observed competition density (median bidders, single-bidder share, bid rate, beachhead score)
`search_tenders`	Open EU tenders with a bid/no-bid verdict: Worth-It score, reason, competition density, price corridor, deadline, SME fit — filterable by sector, country, score
`get_verdict`	One versioned verdict object for a single tender (decision, score, per-channel evidence)
`find_winnable_lanes`	Deprecated alias of `find_low_competition_lanes`, kept for existing clients

Free tier and API key

Guests need no key: the expired-tender board is fully usable and every search returns a live_matched count of current hits. An API key (created at tendfeed.eu, active subscription) unlocks the live, still-biddable board — sent as a header:

claude mcp add --transport http tendfeed https://tendfeed.eu/api/mcp/tendfeed \
  --header "Authorization: Bearer cfm_live_YOUR_KEY"

Agent skill

A ready-made skill that teaches an agent to use the server well (lane before single tender, always cite the verdict's reason and data basis) is served at tendfeed.eu/skill.md.

Discovery

MCP manifest: tendfeed.eu/.well-known/mcp.json
Official MCP registry: eu.tendfeed/tendfeed
Glama connector: glama.ai/mcp/connectors/eu.tendfeed/tendfeed
OpenAPI: tendfeed.eu/api/v1/openapi.json

Data

Raw data: TED — Tenders Electronic Daily (CC BY 4.0). The scoring, benchmarks and verdicts are TendFeed's own. No guarantee of award.

TendFeed is a service of AnalystHAUS GmbH — tendfeed.eu

Available Tools

4 tools

find_low_competition_lanesA

Read-only

Rank CPV sector "lanes" by OBSERVED competition density from the full corpus of 592,000 real EU awards: median bidders, single-bidder share, bid-rate, median value, beachhead score. Answers "where is competition thinnest right now". It does NOT estimate the user's probability of winning — thin competition is a selection signal, not a win forecast. Returns the top-ranked lanes only (see "limit"); the total count is in coverage.lanes_ranked. Data/research tool over TED (Tenders Electronic Daily, CC BY 4.0). No guarantee of award.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many top-ranked lanes to return (sorted by beachhead_score)
`min_n`	No	Drop lanes thinner than this (honest: small n = noise)

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context: it does not estimate win probability, returns only top-ranked lanes (with limit), provides total count in coverage.lanes_ranked, sources data from TED with CC BY 4.0, and gives no guarantee. No contradiction with annotations.

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

Conciseness5/5

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

The description is concise—three sentences covering purpose, exclusion, and output details. It is front-loaded with the key function and uses parentheses effectively. No wasted words.

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?

Despite lacking an output schema, the description sufficiently explains the return shape (top-ranked lanes, total count in coverage.lanes_ranked). It covers metrics, data source, and limitations (no guarantee). For a read-only data tool with two parameters, this is complete.

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% with descriptions for both parameters. The description enhances meaning by explaining 'limit' as number of top lanes and adding context for 'min_n' with 'honest: small n = noise'. It goes beyond the schema by framing these parameters in the tool's purpose.

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 description clearly states the verb 'Rank' and the resource 'CPV sector lanes', and defines the specific metrics (median bidders, single-bidder share, etc.). It answers the question 'where is competition thinnest right now', distinguishing it from the sibling tool 'find_winnable_lanes' which focuses on win probability.

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?

The description explicitly states what the tool does (rank by competition density) and what it does NOT (estimate win probability). It gives context that this is a data/research tool and mentions the limit parameter. However, it does not explicitly say when to use this versus alternatives, though sibling tools are listed and the purpose distinction is clear.

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

find_winnable_lanesA

Read-only

DEPRECATED — use find_low_competition_lanes instead; this alias behaves identically and stays available for existing clients. The old name wrongly implied a win forecast: TendFeed measures observed competition density, not the probability that you win. Data/research tool over TED (Tenders Electronic Daily, CC BY 4.0). No guarantee of award.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many top-ranked lanes to return (sorted by beachhead_score)
`min_n`	No	Drop lanes thinner than this (honest: small n = noise)

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds critical behavioral context: deprecation, identical behavior to replacement, measured competition density not win probability, data source and no guarantee. This far exceeds what annotations provide.

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

Conciseness5/5

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

The description is concise and front-loaded with the deprecation warning. Every sentence adds value: deprecation, reorientation, correction of misconception, data provenance, and disclaimer. No fluff.

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 simple data retrieval tool with two well-documented parameters and clear annotations, the description covers purpose, deprecation, behavioral nuance, and limitations. Return values are trivial (list of lanes), so no output schema needed.

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

Parameters3/5

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

Schema description coverage is 100% (both parameters have descriptions). The description does not add extra detail about the parameters themselves, so baseline 3 is appropriate.

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 description clearly states the tool is deprecated and points to the replacement find_low_competition_lanes. It explains the actual function (measuring competition density) and corrects the misleading name, distinguishing it from other sibling tools.

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?

Explicitly instructs to use find_low_competition_lanes instead, and clarifies when not to trust the name (win implication). Provides context on data source and constraints, offering clear guidance on usage.

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

get_verdictA

Read-only

Pull one versioned verdict object by tender id (decision, score, per-channel evidence, price status, reason). Requires an API key (Authorization: Bearer cfm_live_…) with an active TendFeed subscription; without one you get a machine-readable key-required or subscription-required answer. Data/research tool over TED (Tenders Electronic Daily, CC BY 4.0). No guarantee of award.

ParametersJSON Schema

Name	Required	Description	Default
`tender_id`	Yes	Tender publication id

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context: authentication failure behavior ('machine-readable key-required or subscription-required answer'), data source (TED with CC BY 4.0), and a disclaimer ('No guarantee of award').

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?

The description is front-loaded with the primary purpose, followed by prerequisites, data source, and disclaimer. It is informative without being overly verbose, though the final sentence 'No guarantee of award' is somewhat extraneous given the tool's read-only nature.

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?

For a simple single-parameter read-only tool with good annotations, the description covers purpose, auth requirements, failure modes, and data provenance. It lacks details about response format, but since no output schema exists, the description could be more explicit about what is returned. Still, it is largely complete.

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

Parameters3/5

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

Schema coverage is 100% with a clear description for 'tender_id'. The description merely echoes 'by tender id' without adding new details about format, validation, or constraints beyond the schema. Baseline 3 is appropriate as the schema already sufficiently explains the parameter.

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 description clearly states the action ('Pull one versioned verdict object') and the resource ('by tender id'), listing the fields returned (decision, score, per-channel evidence, price status, reason). This distinguishes it from sibling tools that focus on searching or finding lanes/tenders.

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?

The description specifies prerequisites ('Requires an API key with an active TendFeed subscription') and behavior when those are missing. However, it does not explicitly mention when not to use this tool or provide alternatives among siblings, though the context implies it is the sole retrieval tool for verdicts.

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

search_tendersA

Read-only

Open EU tenders with a bid/no-bid verdict (Worth-It score, reason, competition density, price corridor where robust, deadline, SME-fit). Filter by sector (CPV division), country (NUTS), SME-only, min score. Guests (no key) get the expired-tender board plus a live_matched count; an API key (Authorization: Bearer cfm_live_…) with an active TendFeed subscription unlocks the live, still-biddable board. Data/research tool over TED (Tenders Electronic Daily, CC BY 4.0). No guarantee of award.

ParametersJSON Schema

Name	Required	Description
`cpv`	No	CPV division prefix, e.g. 45 (construction), 72 (IT), 33 (medical)
`nuts`	No	Country prefix, e.g. DE, FR, PL
`limit`	No
`sme_only`	No
`min_score`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description adds context about the data source (TED, CC BY 4.0), authentication tiers (guest vs. API key), and a disclaimer about no guarantee of award. This goes beyond what annotations provide, but does not cover rate limits or pagination.

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?

The description is a single paragraph but packs essential information: purpose, output fields, filters, authentication, and data source. It could be improved by breaking into bullet points for readability, but it is not overly verbose.

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?

Given the absence of an output schema, the description reasonably explains what the tool returns (list of tenders with verdict details) and covers authentication differences. However, it omits pagination details and does not mention ordering or other common search parameters, leaving some gaps.

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

Parameters3/5

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

The input schema already includes descriptions for all 5 parameters, so baseline is 3. The description echoes these filters (sector, country, SME-only, min score) without adding new semantics or usage details for each parameter, so it does not significantly enhance understanding.

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 description clearly states it searches open EU tenders with a bid/no-bid verdict, listing specific output fields like Worth-It score, reason, competition density etc. This distinguishes it from sibling tools like find_winnable_lanes or get_verdict which have different scopes.

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

Usage Guidelines3/5

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

The description explains the tool's purpose and notes that guests get expired tenders while API key holders get live ones, but it does not explicitly contrast with sibling tools or specify when not to use this tool. The usage context is implied but not fully directed.

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. Dates show when Glama detected each change.

4 tool updatesv0.1.0Jul 29, 2026
- First observedfind_low_competition_lanes
- First observedfind_winnable_lanes
- First observedget_verdict
- First observedsearch_tenders

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation2/5

Two tools (find_low_competition_lanes and find_winnable_lanes) are explicitly identical, causing ambiguity. The other two are distinct, but the duplication lowers clarity.

Naming Consistency3/5

Two tools use 'find_*_lanes' pattern, but the others use 'search_tenders' and 'get_verdict'. The pattern is mixed, making it less predictable.

Tool Count4/5

With 4 tools, the set is compact yet covers key functions for a tender intelligence service. Not too few or too many.

Completeness3/5

Core capabilities are present (finding lanes, searching tenders, retrieving verdicts), but missing features like listing all sectors or user account management create minor gaps.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

tendfeed A
eu.tendfeed
Bid/no-bid verdicts for open EU tenders, from 592,000 real TED contract awards.
Government Data Open Data
42
TedScoutOAuth
io.github.SDMcC
Search EU public tenders across TED and 8 national portals. Monitor, match, and analyse procurement.
Government Data Open Data
2
mcp-ted B
io.github.lexsocket
TED MCP Server: Real-time EU public tenders access. https://www.lexsocket.ai/
Government Data Search Open Data
2
GlobalGov — Government Procurement Intelligence A
io.globalgov
9.9M+ tenders, RFPs & grants. 60 countries with a national procurement source, 193 with any record.
Government Data Search Open Data
52

Related MCP Servers

LexSocket MCP Server
Government Data Search
lexsocket
A
license
Not graded
quality
D
maintenance
Enables 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.
Updated 6 months ago (2026-03-19 20:54 UTC)
MIT
oro-intel-mcpofficial
Government Data Search
oro-intel
A
license
Not graded
quality
B
maintenance
UK public procurement data for AI agents. Tenders, contracts, buyer and supplier profiles over MCP and REST. 250 free credits.
Updated 2 months ago (2026-07-04 05:20 UTC)
MIT
Polish Public Tenders (e
Government Data Search
NectiaAutomation
A
license
Not graded
quality
C
maintenance
Find, analyze, and score Polish public tenders (BZP): parsed requirements, deadlines, certificates, and bid-fit scoring against your company profile.
Updated 2 months ago (2026-07-20 04:23 UTC)
17
MIT
Tender MCP
Government Data Search
OjasKord
A
license
A
quality
B
maintenance
Enables AI agents to find, score, and monitor government contract opportunities across UK, EU, and US with AI-powered relevance scoring.
Updated 13 days ago (2026-08-24 04:22 UTC)
2
169
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tendfeed-eu/tendfeed-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

TendFeed — Bid/No-Bid Intelligence MCP Server

Why this exists

Two ways to use it

Tools

Free tier and API key

Agent skill

Discovery

Data

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

oro-intel-mcpofficial

Latest Blog Posts

MCP directory API