Skip to main content
Glama
VladyslavMykhailyshyn

Prozorro.Sale MCP Server

Earliest possible auction date for a new listing

get_publication_constraints
Read-onlyIdempotent

Check how soon an auction can start after publishing a lot. Enter the selling method to get the earliest allowed auction date and notice period for planning.

Instructions

Seller-side planning: if a lot is published today, how soon may the auction itself run.

WHEN TO USE: the user is preparing to list something and needs to plan dates — "how far ahead do I need to publish", "what is the minimum notice period", "can we hold the auction before the 20th". This is the only forward-looking tool here; everything else describes auctions that already exist.

KEY PARAMETERS

  • procedure_type (required): a selling method such as "smallPrivatization-english". A family name such as "smallPrivatization" is also accepted and every format it supports is checked at once, which is useful for comparing notice periods before choosing a format.

EXAMPLE — notice period for one format: {"procedure_type":"landRental-english"}

EXAMPLE — compare every format of a programme: {"procedure_type":"smallPrivatization"}

RETURNS: per selling method, earliestAuctionStart (the soonest auctionPeriod.startDate the platform would accept for a procedure published now) and noticeDays, that gap in days. The value is computed live and moves with the calendar, so it is not cached.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
procedure_typeYesSelling method to check, e.g. "landRental-english" or "smallPrivatization-english". A family name is accepted and every format it supports is checked.
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior; the description adds valuable context that the value is computed live and not cached. It also clarifies that a family name checks all supported formats at once, which is non-obvious behavior beyond the schema.

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 well-organized with clear headers, key parameters, examples, and return structure. Every sentence adds value, and the format makes it easy to scan for purpose, usage, and behavior.

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?

Despite having no output schema, the description fully explains return values (earliestAuctionStart and noticeDays) and their behavior. It covers parameter semantics, examples, and placement within the tool family, making it self-sufficient for correct invocation.

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?

The schema only describes procedure_type as a selling method, but the description enriches it significantly by documenting family-name support, the ability to compare formats, and concrete examples. This goes well beyond baseline schema coverage.

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?

Clearly states the tool's purpose as seller-side planning for the earliest possible auction date. The description explicitly identifies it as the only forward-looking tool among siblings, effectively distinguishing it from tools that describe existing auctions.

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?

Provides an explicit WHEN TO USE section with concrete user queries and contrasts with siblings by noting everything else describes existing auctions. However, it does not name a specific alternative tool, leaving the exclusion slightly less direct than naming search_auctions or get_auction.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/VladyslavMykhailyshyn/prozorro-sale-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server