Skip to main content
Glama
uk-tenders-mcp

uk-tenders-mcp

by atz1man

score_tenders

Read-only

Scores this week's open UK public-sector tenders as GO, MAYBE, or NO-GO against a bid profile, with reasons, helping users identify which tenders are worth bidding.

Instructions

Score this week's open tenders GO / MAYBE / NO-GO against a bid profile, with reasons.

Use when the user asks which tenders are worth bidding for. Call list_profiles for valid names. Searches Find a Tender and Contracts Finder. Returns GO then MAYBE, highest score first, at most limit (1-50), each with buyer, value, deadline, days_left, reasons and a source_url. NO-GO results are counted but left out unless include_no_go is true.

Input Schema

NameRequiredDescriptionDefault
daysNo
limitNo
profileNorail_civils
regionsNo
include_no_goNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds real context beyond that — it names the two external corpora searched (Find a Tender and Contracts Finder), the result ordering (GO then MAYBE, highest score first), the hard cap of 50, and the non-obvious behavior that NO-GO results are counted but omitted unless include_no_go is set.

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, then trigger, then source/return behavior — a sensible progression with no filler sentences. Slightly dense in the final sentence, where return fields and the NO-GO exception are packed together.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so enumerating GO/MAYBE fields is a bonus rather than a requirement. However, for a five-parameter, zero-coverage schema the description should account for every input, and `regions` is never mentioned anywhere, leaving an agent unable to use it confidently.

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 0%, so the description must carry the load. It documents limit's range (1-50), the exact effect of include_no_go, and how to obtain valid profile values, but leaves `regions` completely unexplained and only implies `days` through the phrase "this week's" despite a default of 7.

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 ("Score this week's open tenders") plus the exact output classification (GO / MAYBE / NO-GO against a bid profile, with reasons). The scoring/ranking framing makes it clearly distinct from search_tenders, and it names list_profiles as a dependency.

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 ("Use when the user asks which tenders are worth bidding for") and a prerequisite workflow step ("Call list_profiles for valid names"). It does not explicitly say when to prefer search_tenders instead, so the exclusion half of the guidance is missing.

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