Skip to main content
Glama

Uk Contracts

by io.github.pipeworx-io

Get Notice

get_notice
Read-onlyIdempotent

Get the full detail for a single UK Contracts Finder notice by the id returned by search_notices or recent_notices. Returns the complete (untruncated) description, buyer, contract value, awarded supplier, CPV classification, region, tender period and contact where published. Accepts either id form — search_notices returns a bare GUID and recent_notices an OCDS release id ("{guid}-{seq}"); they are separate id spaces on separate endpoints, and this tool routes to the right one for you. Keyless.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe `id` from a search_notices result (a bare GUID, e.g. "5295555c-7556-4726-bd59-7895f51a3c3a") or from recent_notices (an OCDS release id, e.g. "a42239ac-faef-4245-ad0f-16b3a787675b-901561"). Either works.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description adds meaningful behavior: it returns untruncated fields, accepts two distinct ID forms from separate endpoints, routes to the correct endpoint, and notes that authentication is keyless. 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?

Three sentences deliver the core purpose, return contents, ID-form nuance, and authentication requirement without fluff. Critical information is front-loaded.

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 single-parameter read-only lookup with no output schema, the description sufficiently enumerates return fields, explains accepted IDs, and signals no credentials are needed. No critical gap remains for an agent to invoke it correctly.

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% and already documents both ID forms with examples. The description adds value by explaining that the two forms are separate ID spaces and that the tool handles routing, going slightly beyond the schema's 'either works' note.

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 states a specific verb ('Get') and resource ('full detail for a single UK Contracts Finder notice') keyed by `id`, and enumerates the returned fields. It clearly distinguishes itself from the search/recent tools it consumes IDs from.

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 explains when to use the tool: when you have an `id` from search_notices or recent_notices and want the full, untruncated notice. It does not explicitly state 'use X instead when ...', but the contextual routing and ID-form guidance make the call boundary clear.

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

All Uk Contracts toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation2/5

Several tools occupy nearly identical roles (ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, discover_tools), and ask_pipeworx_beta is explicitly the same router as ask_pipeworx. Company-data tools (entity_profile, compare_entities, recent_changes, validate_claim) and the Polymarket family also overlap heavily, making selection error-prone despite detailed descriptions.

Naming Consistency5/5

Tool names are consistently lowercase snake_case with a verb_noun pattern (search_notices, get_notice, find_a_tender_recent, validate_claim). Even longer names like polymarket_edge_tracker and ask_pipeworx_grounded follow a predictable style with no camelCase or mixed conventions.

Tool Count2/5

36 tools is already excessive for a focused server, and the 'Uk Contracts' name covers only five of them (search_notices, recent_notices, get_notice, find_a_tender_recent, find_a_tender_notice). The remaining 31 are unrelated Pipeworx/Polymarket/AI-marketing utilities, so the count badly mismatches the apparent scope.

Completeness4/5

For UK public procurement, the five relevant tools provide search, recent listing, and full-detail retrieval for both Contracts Finder and Find a Tender Service, covering the core workflows well. Minor gaps include no tender-specific alert/subscription support and no server-side keyword search for the high-value FTS feed.

Resources