Atlas Przetargów

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. For example, get_buyer retrieves buyer profiles, get_tender fetches specific tender details, and search_tenders performs broader searches, each targeting different resources and actions. The descriptions explicitly differentiate their functions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern, such as get_buyer, search_tenders, and get_category_stats. This uniformity enhances readability and predictability, with no deviations in naming conventions across the set.
Tool Count5/5
With 8 tools, the count is well-scoped for the server's purpose of Polish public procurement analysis. Each tool earns its place by covering distinct aspects like entity profiles, tender searches, and statistical data, avoiding both thinness and overload.
Completeness5/5
The tool set provides complete coverage for the domain, including CRUD-like operations such as fetching entities and tenders, searching with filters, and retrieving statistical insights. There are no obvious gaps, as it supports due diligence, market analysis, and competitive benchmarking workflows.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return data structure (name, location, wins, value, buyers) which is helpful, but doesn't mention error handling, rate limits, authentication needs, or whether this is a read-only operation. The description adds some behavioral context but leaves gaps for a tool with no 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?
Single sentence efficiently conveys purpose, resource, key parameter, and return data. Every element earns its place with zero wasted words. The structure is front-loaded with the core action and progressively adds details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read tool with no annotations and no output schema, the description provides adequate purpose and return data overview but lacks details on error cases, data freshness, or response format. It's minimally viable but could better address the gaps left by missing structured fields.
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 the schema already fully documents both parameters. The description mentions NIP as the identifier and implies include_winning_buyers controls buyer data inclusion, but adds no additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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 clearly states the specific action ('Fetch a profile'), resource ('Polish tender contractor'), and key identifying attribute ('by its NIP'). It distinguishes this tool from siblings like get_buyer or get_tender by focusing on contractor profiles rather than buyers, categories, or tenders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing contractor profile data by NIP, but provides no explicit guidance on when to use this versus alternatives like search_entities or other get_* tools. It mentions what data is returned but doesn't specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return content (name, location, statistics, recent tenders, top winning contractors) and the tool's purpose (due diligence). However, it lacks details on error handling, rate limits, authentication needs, or data freshness, which are important for a tool fetching entity profiles.
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 front-loaded with the core purpose and efficiently uses two sentences: one for the tool's function and return values, and another for its usage context. Every sentence adds value without redundancy, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (fetching entity profiles with two parameters) and no output schema, the description provides a good overview of return content and usage context. However, it lacks details on output structure (e.g., format of statistics or tender lists) and behavioral aspects like errors or limits, leaving some gaps for an agent to invoke it correctly without additional context.
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?
The schema description coverage is 100%, so the schema already fully documents both parameters (nip and include_winning_contractors). The description adds no additional parameter semantics beyond what the schema provides, such as explaining the significance of the NIP or the impact of the boolean flag, so it meets the baseline for high 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?
The description clearly states the specific action ('Fetch a profile'), the resource ('Polish public procuring entity'), and the key identifier ('by its NIP'). It distinguishes from sibling tools by focusing on buyer profiles rather than statistics, contractors, tenders, or searches.
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?
The description provides clear context for when to use this tool ('for due diligence on who buys what and from whom'), which implicitly differentiates it from tools like get_contractor or get_tender. However, it does not explicitly state when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool retrieves aggregate statistics (implying read-only, non-destructive behavior) and specifies the data sources (historical BZP+TED data). However, it lacks details on permissions, rate limits, error handling, or output format, leaving behavioral gaps for a tool with no output 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 front-loaded with the core purpose, followed by specific metrics and context. Every sentence adds value: the first defines the action and metrics, the second specifies data sources, and the third states use cases. It is efficiently structured with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers purpose, data sources, and use cases adequately, but lacks details on output format, error conditions, or behavioral constraints, which are important for a statistical tool with no structured output documentation.
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 the schema fully documents both parameters (cpv and window). The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints. The baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 clearly states the specific verb 'retrieve' and resource 'aggregate statistics for a CPV category', listing concrete metrics (count, average/median value, etc.). It distinguishes from siblings by focusing on statistical aggregation rather than individual entity retrieval (e.g., get_tender, get_buyer) or search operations (e.g., search_cpv).
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?
The description provides clear context for when to use this tool: 'useful for market sizing and competitive benchmarking' based on 'historical BZP+TED data'. It implies usage for aggregated insights rather than detailed searches, but does not explicitly state when not to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the tool's statistical aggregation behavior and the hierarchical drill-down capability (province → city). However, it doesn't mention performance characteristics, data freshness, or potential limitations like result size constraints.
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 tightly constructed sentences with zero waste: first establishes core purpose, second explains parameter hierarchy, third clarifies default behavior. Every sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only statistical tool with good schema coverage, the description provides adequate context about scope and behavior. The main gap is lack of output format information (no output schema), but the description compensates somewhat by specifying what statistics are returned (ranking, top buyers, top CPV categories).
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 the schema already documents both parameters thoroughly. The description adds marginal value by explaining the hierarchical relationship between province and city parameters and clarifying the default behavior when no arguments are provided.
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 clearly states the verb 'retrieve' and resource 'aggregate tender statistics', specifies geographic scope (Polish provinces/cities), and distinguishes from siblings by focusing on statistical aggregation rather than individual entity lookup or search operations.
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?
The description provides clear context about when to use different parameter combinations (no arguments for full ranking, province for province-level, city for city-level details). However, it doesn't explicitly state when NOT to use this tool versus alternatives like get_category_stats or search_tenders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool returns (buyer, location, deadlines, etc.), mentions optional AI-generated summaries, and notes the ATLAS_API_KEY requirement for that feature. However, it doesn't address error conditions, rate limits, or authentication needs beyond the API key mention.
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 efficiently structured in two sentences: the first states the core purpose and return data, the second covers the optional feature. Every element serves a purpose with zero wasted words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no annotations and no output schema, the description does a good job explaining what information is returned. It could be more complete by describing the response format or structure, but it adequately covers the tool's purpose and behavior given the context.
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?
With 100% schema description coverage, the schema already documents both parameters thoroughly. The description adds marginal value by mentioning the AI-generated summary feature in context, but doesn't provide additional parameter semantics beyond what's in the schema descriptions.
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 clearly states the specific action ('Retrieve detailed information'), resource ('Polish public tender'), and scope ('by its ID'). It distinguishes from siblings like get_buyer or search_tenders by focusing on full details for a single tender rather than entity-specific data or search functionality.
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?
The description provides clear context for when to use this tool (to get full details of a specific tender by ID). It doesn't explicitly mention when not to use it or name alternatives, but the context implies this is for detailed retrieval rather than searching or getting partial data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('list with NIP, location and volume'), which is helpful, but lacks details on behavioral traits like pagination, rate limits, error handling, or authentication needs. It's adequate but has gaps.
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?
Two sentences, zero waste. The first sentence states the purpose and output, the second provides usage guidance. It's front-loaded with essential information and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by explaining the return format and usage context. However, it could improve by mentioning potential limitations (e.g., search scope, data freshness) or error cases. It's mostly complete but not exhaustive.
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 the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'name (or fragment)' for the query and hinting at the output fields, but doesn't provide additional syntax or format details. Baseline 3 is appropriate.
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 clearly states the verb ('Search') and resource ('Polish public procurement entities or contractors'), specifies the search criteria ('by name'), and distinguishes it from siblings by explaining its role in finding NIPs for get_buyer/get_contractor tools. It's specific and avoids tautology.
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?
It explicitly states when to use this tool ('Useful to find the NIP for get_buyer / get_contractor tools'), providing clear guidance on its purpose in the workflow and distinguishing it from sibling tools like get_buyer or get_contractor that require NIPs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the return format (list with titles, buyers, locations, etc.) and suggests Polish terms work best, but doesn't mention rate limits, authentication requirements, pagination behavior beyond parameters, or error handling.
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?
Two well-structured sentences: first states purpose and return format, second provides usage examples. Every word earns its place with zero waste, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 14-parameter search tool with no annotations and no output schema, the description provides good purpose clarity and usage examples. However, it could better address behavioral aspects like result limitations, authentication needs, or error scenarios given the tool's complexity.
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 the schema already documents all 14 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3.
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 clearly states the tool searches public procurement tenders from specific sources (BZP and TED via Atlas Przetargów) and returns a list with specific fields. It distinguishes from siblings by focusing on search functionality rather than getting specific entities or statistics.
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?
The description explicitly provides when to use this tool with concrete query examples ('aktywne przetargi budowlane w Warszawie', 'zamówienia IT powyżej 500k PLN', 'co kupuje ZUS'), giving clear context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return format ('Returns code, name, division, and historical tender count') and implies a read-only lookup operation, though it doesn't mention potential limitations like rate limits or authentication needs.
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 efficiently structured in three sentences: purpose, usage guidance, and return values, with zero wasted words. It's front-loaded with the core functionality and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no annotations, and no output schema, the description is largely complete. It covers purpose, usage, and return format, though it could benefit from mentioning any error conditions or the format of the historical tender count.
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 the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by reinforcing the Polish keyword requirement and the purpose of finding CPV filters, but doesn't provide additional syntax or format details.
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 clearly states the specific action ('Look up CPV codes'), resource ('CPV codes'), and scope ('by Polish keyword'), distinguishing it from siblings like search_tenders by focusing on code lookup rather than tender search. It explicitly mentions the EU procurement category context.
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?
The description provides explicit guidance on when to use this tool ('Use this before search_tenders to find the right CPV filter') and distinguishes it from the sibling search_tenders tool, offering clear context for its application in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/atlasprzetargow/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/atlasprzetargow/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/atlasprzetargow/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/atlasprzetargow/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/atlasprzetargow/mcp-server'

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