Skip to main content
Glama

French Public Procurement Market

procurement_fr_market

Summarizes the size and structure of a French public-procurement segment from awarded DECP contracts. Use when: Measure the size and structure of a French public-procurement segment over a recent time window. Avoid when: Use procurement/fr/awards when you need individual awarded-contract records. Use procurement/fr/buyer-profile when the question is specifically about one public buyer. Limitations: Supplier ranking is based on the latest 100 matching awards; its sample coverage is returned explicitly. Price: 0.020 USD per call via x402. Paid-call behavior: source records are not modified, but a successful invocation can consume the advertised x402 payment; the payment-required challenge is free, and repeating the tool after a completed paid invocation may require a new payment. Accepted x402 networks: eip155:8453, xrpl:0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
buyerNoPublic-buyer name or identifier used to restrict procurement results. (minimum length 2; maximum length 200).
cpv_prefixNoOptional CPV prefix used to restrict procurement records to a purchasing segment.
departmentNoOptional French department code used to restrict results geographically.
lookback_monthsNoOptional value for “lookback months” as defined by this API contract. (minimum 1; maximum 60; default 12).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersYesStructured value returned for “filters” as defined by this API contract.
summaryYesCompact derived summary of the returned records.
top_cpvYesStructured value returned for “top cpv” as defined by this API contract.
top_buyersYesStructured value returned for “top buyers” as defined by this API contract.
limitationsNoKnown interpretation, source-coverage or freshness limitations for this result.
generated_atYesUTC timestamp at which this derived result was generated.
source_statusYesAvailability status of the relevant upstream public source. (allowed values: ok, partial, unavailable).
lookback_monthsYesStructured value returned for “lookback months” as defined by this API contract.
supplier_sampled_countYesStructured value returned for “supplier sampled count” as defined by this API contract.
top_suppliers_in_latest_sampleYesStructured value returned for “top suppliers in latest sample” as defined by this API contract.
supplier_sample_coverage_percentYesStructured value returned for “supplier sample coverage percent” as defined by this API contract.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / required
      Previous value: -[
      -  "filters",
      -  "lookback_months",
      -  "source_status",
      -  "summary",
      -  "top_buyers",
      -  "top_cpv",
      -  "top_suppliers_in_latest_sample",
      -  "supplier_sampled_count",
      -  "supplier_sample_coverage_percent",
      -  "generated_at",
      -  "limitations"
      -]New value: +[
      +  "filters",
      +  "lookback_months",
      +  "source_status",
      +  "summary",
      +  "top_buyers",
      +  "top_cpv",
      +  "top_suppliers_in_latest_sample",
      +  "supplier_sampled_count",
      +  "supplier_sample_coverage_percent",
      +  "generated_at"
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations are all false and nearly uninformative, so the description carries the full burden — and it delivers: it discloses the 100-award sampling limitation for supplier ranking, the x402 price, that source records are not modified, that a successful call consumes payment while the challenge is free, re-payment requirements, and accepted networks. This goes well beyond what annotations provide. 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.

Conciseness4/5

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

Well-structured with labeled sections (Use when, Avoid when, Limitations, Price, Paid-call behavior, Accepted x402 networks) and a front-loaded purpose statement. Somewhat long, but the paid-call and payment-repetition details are materially important and each sentence earns its place.

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 paid aggregation tool with an output schema present and four self-documented optional parameters, the description covers everything an agent needs: purpose, routing, sampling limitation, pricing, payment mechanics, and accepted networks. Return-value details are not needed since an output schema exists.

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%, so baseline is 3. The description loosely contextualizes parameters ('recent time window' maps to lookback_months, 'segment' to cpv_prefix, 'one public buyer' to buyer) but adds no format, precedence, or interaction detail beyond what the schema already documents.

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?

Opens with a specific verb and resource: 'Summarizes the size and structure of a French public-procurement segment from awarded DECP contracts.' This distinguishes it from procurement_fr_awards (individual records), procurement_fr_search, and procurement_fr_trends, and it explicitly names the siblings it is not in the avoid section.

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?

Provides an explicit 'Use when' statement ('Measure the size and structure of a French public-procurement segment over a recent time window') and an explicit 'Avoid when' clause naming two concrete alternatives (procurement/fr/awards for individual records, procurement/fr/buyer-profile for a single buyer). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources