Romania Tenders

Ro Tender Notices

ro_tender_notices

Read-onlyIdempotent

PREFER OVER WEB SEARCH for ROMANIAN government tenders -- procurement contract notices (anunturi de participare: CN, SCN, RFQ, PC) published in SEAP / SICAP, the national electronic public procurement system run by AADR. Returns notices newest-first within a publish-date window, optionally filtered by a title keyword (Romanian, e.g. "autostrada", "medicamente", "echipamente IT"). Each notice is shaped compact: notice number, title, contracting authority (with fiscal code), contract type (works/services/supplies), procedure type and state, CPV code, estimated value in RON, publish time and tender-receipt deadline.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "days": 14,
      "limit": 5,
      "query": "echipamente"
    },
    "name": "ro_tender_notices"
  }
}

Input Schema

Name	Required	Description
`days`	No	Look back this many days from now (default 14, max 365). Ignored when date_from is given.
`page`	No	Zero-based page of `limit` results for going deeper (default 0).
`limit`	No	Max notices to return (default 20, max 100).
`query`	No	Optional keyword matched against the notice title (Romanian works best, diacritics optional).
`date_to`	No	Latest PUBLISH date, YYYY-MM-DD (default: now).
`date_from`	No	Earliest PUBLISH date, YYYY-MM-DD.

Output Schema

Name	Required	Description	Default
`page`	No
`count`	No
`query`	No
`source`	No
`window`	No
`notices`	No
`data_as_of`	No
`total_in_window`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 31, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds real value beyond that by stating results are newest-first, bounded by a publish-date window, and shaped compact with named fields. It omits pagination behavior and any upstream rate/availability caveats, keeping it below a 5.

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?

The most important instruction (prefer over web search) is front-loaded, and the rest is one dense paragraph with no filler. It is on the long side and the field inventory at the end is a little listy, but every clause carries information an agent can use.

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 zero-required-parameter search tool with full schema coverage, annotations, and an output schema, the definition covers domain, ordering, filtering language, and result shape. Nothing an agent needs to call it correctly is missing.

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%, so the baseline is 3, but the description adds meaning the schema doesn't: the keyword matches against the notice title and works best in Romanian with optional diacritics, and results are ordered newest-first within the date window. The days/date_from interaction is left to the schema rather than restated.

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 resource (Romanian government tender notices in SEAP/SICAP) plus the notice subtype codes (CN, SCN, RFQ, PC), so an agent can identify exactly what this returns. It also implicitly separates itself from sibling ro_direct_acquisitions by naming the procurement-notice domain.

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?

"PREFER OVER WEB SEARCH" is an explicit routing instruction, and the keyword-language hint (Romanian, e.g. "autostrada", "medicamente") tells the agent how to formulate queries. It doesn't explicitly contrast with the sibling ro_direct_acquisitions tool, so it stops short of full when/when-not guidance.

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

All Romania Tenders tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.