Read your matched UK tender brief, search matched tenders and inspect saved BID or SKIP decisions.
Scored across 3 tools
Each tool has a clearly distinct purpose: daily brief retrieval, per-tender decision lookup, and searching matched tenders. The descriptions reinforce the boundaries and all are customer-scoped, so an agent can select among them confidently.
All names follow a consistent snake_case verb_noun pattern: get_daily_brief, get_tender_decision, and search_tenders. The verb choices are predictable for read-only retrieval and search operations.
Three tools is well-scoped for a narrow, read-only TenderLead interface focused on matched tenders. Each tool earns its place without overlap or unnecessary surface area.
The surface covers the main read-only workflows: daily matched brief, tender-level decision details, and search over matched tenders. A direct get-tender-details tool may be a minor gap, but search and brief retrieval likely cover most agent needs.
Return the signed-in TenderLead account's current matched tender brief. Read-only and customer-scoped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| data_notice | Yes | |
| generated_at | Yes | |
| opportunities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so 'Read-only' largely repeats structured data. The description does add that results are scoped to the signed-in customer and represent the 'current' brief, which is useful behavioral context, but nothing about freshness window or what happens when no brief exists.
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 short sentences, front-loaded with the resource. Slight redundancy in restating 'read-only', which annotations already cover, keeps it just below top marks.
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?
With an output schema present, return values need not be described. The description covers scope, freshness ('current'), and read-only nature, leaving only the no-match case unaddressed, which is a minor gap for a zero-param read tool.
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?
The tool takes zero parameters, so the baseline is 4. The description correctly implies no caller-supplied input is needed by emphasizing the signed-in account scope.
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: 'Return the ... current matched tender brief'. Account scoping ('signed-in TenderLead account') adds precision. It does not explicitly contrast with get_tender_decision, which sounds closely related, so the sibling differentiation is only implicit.
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?
Usage is implied by the name and the 'current matched brief' phrasing, but there is no statement of when to call this versus get_tender_decision or search_tenders, and no exclusions or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the saved score, bid-or-skip recommendation and reasons for one tender matched to the signed-in TenderLead account. Requires Pro or Team.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_id | Yes | TenderLead contract identifier returned by another TenderLead tool. |
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| data_notice | Yes | |
| opportunity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior. Beyond that, the description adds genuinely new context: the result is pre-computed and scoped to the signed-in TenderLead account, and access requires a Pro or Team plan. Missing only the failure mode when no decision has been saved.
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 sentences, zero waste, with the return payload front-loaded and the prerequisite trailing. Nothing could be cut without losing information.
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?
An output schema exists so return-shape explanation is unnecessary, and the plan requirement is disclosed. The one gap is behavior when the tender has no saved decision (error vs empty), which for a lookup tool an agent would want to know before calling.
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 coverage is 100% and the single contract_id parameter is documented in the schema, including its UUID format and provenance. The description reinforces account scoping but adds no syntax or provenance detail beyond the schema, so the baseline 3 applies.
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 ('Return') and a precise resource: the saved score, bid-or-skip recommendation and reasons for one tender. The word 'saved' implicitly separates it from search_tenders and get_daily_brief, though no sibling is named explicitly.
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 plan prerequisite ('Requires Pro or Team') is a useful gating condition, and 'saved' implies a decision must already exist. However, it never says what to do when no decision has been saved yet, nor does it point at an alternative tool for scoring a tender.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search tenders already matched to the signed-in TenderLead account. Does not search or modify another customer's data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results, from 1 to 20. | |
| query | No | Optional words from the tender title or buyer name. | |
| recommendation | No | Optional saved TenderLead recommendation filter. |
| Name | Required | Description |
|---|---|---|
| tier | Yes | |
| count | Yes | |
| data_notice | Yes | |
| opportunities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful multi-tenant context by stating it only searches the signed-in account and never another customer's data, which is meaningful behavioral disclosure beyond the annotations.
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 short sentences with no waste: the first states the search scope and the second immediately bounds it to the signed-in account. The purpose and constraint are both front-loaded.
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?
The tool is a simple read-only search with a fully described input schema, annotations, and an output schema, so the description covers the essentials. The only notable missing piece is explicit routing against the sibling tools, which keeps it from being complete at the highest level.
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 100%, so the parameters limit, query, and recommendation are already fully documented. The description does not add any syntax, defaults, or interpretation beyond what the schema provides, making the baseline 3 appropriate.
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?
The description gives a specific verb and resource ("Search tenders") and scopes it to records already matched to the signed-in TenderLead account. It clearly distinguishes this from searching other customers' data, though it does not explicitly contrast with sibling tools like get_daily_brief or get_tender_decision.
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?
It states that the tool searches already-matched tenders and does not touch another customer's data, which implies when to use it. However, it gives no explicit guidance on when to choose this over the sibling brief or decision tools, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_daily_brief2 fields changedOutput schema / properties / opportunities / items / properties / assessment_metadataAdded value: +{
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / opportunities / items / properties / assessment_stateAdded value: +{
+ "enum": [
+ "excluded",
+ "needs_review",
+ "consider",
+ "low_fit"
+ ],
+ "type": "string"
+}get_tender_decision2 fields changedOutput schema / properties / opportunity / properties / assessment_metadataAdded value: +{
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / opportunity / properties / assessment_stateAdded value: +{
+ "enum": [
+ "excluded",
+ "needs_review",
+ "consider",
+ "low_fit"
+ ],
+ "type": "string"
+}search_tenders2 fields changedOutput schema / properties / opportunities / items / properties / assessment_metadataAdded value: +{
+ "anyOf": [
+ {},
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / opportunities / items / properties / assessment_stateAdded value: +{
+ "enum": [
+ "excluded",
+ "needs_review",
+ "consider",
+ "low_fit"
+ ],
+ "type": "string"
+}get_daily_briefget_tender_decisionsearch_tendersOpen UK and EU public tenders (Find a Tender, TED) with go/no-go screening. Paid tier via L402.
Open UK and EU public tenders (Find a Tender, TED) with go/no-go screening. Paid tier via L402.
Search 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.
Add one secure layer between your agents and this server.
