Skip to main content
Glama

Scoutee

by org.scoutee

Search public tenders

search_tenders
Read-onlyIdempotent

Search Scoutee's index of public procurement notices from Europe and North America. Returns a page of notices, the total number of matches, a per-country breakdown of the same match set (by_country, useful to suggest where else to look) and what the caller's hourly quota has left. Open notices only and newest first unless asked otherwise; notices published on several portals appear once, the other portals listed in also_on. Each search consumes one quota unit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree text over title, buyer and description. Every word must match the *start* of a word in the notice ('nettoy' finds 'nettoyage'); a substring inside a word does not match. Accent- and case-insensitive.
pageNo1-based page number.
sortNo'newest' (publication descending, the default), 'oldest' (publication ascending) or 'deadline' (soonest submission deadline first).newest
countryNoCountries of the publishing portal, by their English name as Scoutee stores it ('France', 'Belgium', 'Germany'; 'Europe' for TED). Several countries add up. Omit to search everywhere — the `by_country` map of any result lists the exact values in use.
keywordNoKeywords matched as whole words (plural tolerated) in title, buyer or description, plus the cached translations of each keyword on the portals of that language — the way to search across countries without translating anything yourself. Several keywords widen the search (a notice matching any of them is returned).
max_valueNoMaximum estimated value.
min_valueNoMinimum estimated value, in the currency of the notice. Notices without a published value are excluded when this is set.
page_sizeNoNotices per page, 1 to 200 (capped by the plan). Kept modest by default because a notice is a large object; raise it when you need to sweep a whole result set.
source_idNoRestrict to a single portal, by its Scoutee source identifier.
seen_afterNoKeep only notices first collected by Scoutee after this instant (ISO 8601). The way to poll for what is new since a previous run.
include_closedNoInclude notices whose consultation is already closed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
itemsYes
pagesYes
totalYes
by_sectorNo
page_sizeYes
by_countryNo
quota_planYes
quota_limitYes
quota_remainingYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changed
    • addedOutput schema / $defs / TenderOut / properties / sectors
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Sectors",
+  "type": "array"
+}
    • changedOutput schema / $defs / TenderOut / required
      Previous value: -[
-  "id",
-  "source_id",
-  "external_id",
-  "title",
-  "buyer",
-  "description",
-  "url",
-  "location",
-  "procedure",
-  "cpv_codes",
-  "estimated_value",
-  "currency",
-  "published_at",
-  "deadline_at",
-  "first_seen_at",
-  "last_seen_at",
-  "closed_at"
-]New value: +[
+  "id",
+  "source_id",
+  "external_id",
+  "title",
+  "buyer",
+  "description",
+  "url",
+  "location",
+  "procedure",
+  "cpv_codes",
+  "sectors",
+  "estimated_value",
+  "currency",
+  "published_at",
+  "deadline_at",
+  "first_seen_at",
+  "last_seen_at",
+  "closed_at"
+]
    • addedOutput schema / properties / by_sector
      Added value: +{
+  "additionalProperties": {
+    "type": "integer"
+  },
+  "title": "By Sector",
+  "type": "object"
+}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

While annotations already indicate read-only and idempotent, the description adds behavioral details beyond them: it always returns open notices unless include_closed is set, sorting defaults to newest, and each search consumes a quota unit. These are relevant side effects and state changes not covered by 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.

Conciseness5/5

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

The description is dense but every sentence adds value. It opens with the core purpose, then details return fields, defaults, and the key parameter behaviors. No fluff or repetition.

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?

The description covers the tool's purpose, return payload (page, total, by_country, quota), the main behavioral defaults, and gives usage guidance (polling, multilingual search, page_size). It also notes the effect of setting min_value on notices without a value. This is complete for a search tool, especially given the output schema is present.

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

Parameters5/5

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

Every parameter in the schema has a description, and the tool description adds extra semantic nuance: the keyword parameter is explained as matching whole words with plural tolerance and cached translations, seen_after is framed as a polling mechanism, and the by_country map is described as the source for exact country values. This goes beyond the schema text.

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 ('Search') and a specific resource ('Scoutee's index of public procurement notices'), and distinguishes from the sibling get_tender by describing the list/page behavior. The scope (Europe and North America) is clear.

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?

Explains when to use the tool (polling new notices via seen_after, cross-country keyword search, sweeping with page_size) and describes the default behavior (open notices, newest first). It also notes the quota consumption, giving practical guidance for repeated calls.

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

All Scoutee 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

A4.5/5.0
Disambiguation5/5

search_tenders finds and lists tenders, while get_tender retrieves a single specific tender by its identifier. The purposes are completely distinct with no overlap.

Naming Consistency5/5

Both tools follow a clear verb_noun pattern: search_tenders and get_tender. The singular/plural difference is logical since one searches multiple results and the other gets one.

Tool Count4/5

Only two tools is slightly minimal, but it fully covers the core read-only purpose of searching and retrieving tender notices. The count feels appropriate for the narrow scope.

Completeness5/5

For a read-only tender search service, search and get-by-id cover the essential workflow. There are no obvious missing operations that would prevent an agent from completing a typical task.

Resources