swiss-procurement-mcp

Server Quality Checklist

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

Latest release: v0.18.3
Disambiguation5/5
Each tool has a distinct role: search_procurements returns summaries, search_procurements_detailed expands top hits, search_awards focuses on awards, get_procurement_details retrieves a full record, get_publication_history traces project lifecycle, while code/office/status lookups serve as support functions. The overlap between search_procurements and search_procurements_detailed is clearly explained and intentional.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern with snake_case: search_* for searches, get_* for retrievals, find_* for lookups. The only deviation is source_status, which uses noun_noun instead of an imperative verb, but it is still readable and fits the overall style.
Tool Count5/5
With 9 tools, the set is well-scoped for a Swiss procurement search domain. Each tool covers a clear need without redundancy, from searching and filtering to resolving classification codes and checking source health. The count is within the ideal 3-15 range.
Completeness5/5
The tool set provides comprehensive coverage for a read-only procurement platform: compound search with details, award-only search, individual detail lookup, publication history, CPV and construction code resolution, office lookup, and source status. This covers the full user journey from finding a tender to understanding its full record and lifecycle.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 65 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the use-case context but does not elaborate on behavioral details like return format, pagination, or error handling. 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?
The description is structured and mostly concise, with a use_case tag, a one-sentence summary, an Args list, and a brief context paragraph. Each section adds relevant context, though the final paragraph could be tightened without losing 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?
The tool has an output schema and annotations that cover safety, so the description adequately explains the purpose and domain. It does not discuss optional parameters like limit and language, but the schema fills that gap, making it complete enough for an agent to select and invoke the tool correctly.
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 input schema provides descriptions for all four parameters (system, query, limit, language), including enum values. The tool description redundantly lists system enum values and describes query as 'Keyword,' but omits limit and language, adding minimal semantic value beyond the schema.
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 translates a keyword into Swiss construction cost codes (BKP, NPK, eBKP, OAG, CPC). It uses specific verbs like 'search' and 'translate' with a well-defined resource, distinguishing it from sibling tools like search_cpv_codes by the Swiss classification context.
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?
It provides strong context that this is for Swiss construction cost standards used in building tenders, relevant for school-building procurement. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity compared to similar sibling tools.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context about what the record contains (order description, CPV, BKP/NPK codes, deadlines, procurement office) and highlights the joinability of BKP codes with construction cost data. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a use case but contains redundancy: 'Retrieve the full record' and 'Return the full record' say the same thing. The second paragraph adds useful detail, but the opening could be tightened without losing meaning.
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?
The description explains the source of the IDs, the specific fields included in the record, and even a downstream use (joining with construction cost data). With an output schema present, return-value documentation isn't needed. This is comprehensive for a single-record retrieval tool, though it could mention error behavior.
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 input schema provides comprehensive descriptions for both project_id and publication_id (e.g., 'Project id from a search_procurements result'), giving near-total schema coverage. The description's mention that both IDs come from a search result largely repeats the schema, adding no new parameter-level syntax or constraints.
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's function: 'Return the full record for one procurement publication' and specifies the required inputs ('once you have its ids'). It distinguishes itself from sibling search tools by focusing on a single record's full details, including specific content like CPV codes and the procuring body.
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 explicitly notes that 'Both ids come from a search_procurements result', establishing a clear prerequisite and usage context. It doesn't enumerate alternatives or exclusions, but given the sibling list, the intended workflow (search first, then retrieve full record) is clear enough.
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?
Annotations already indicate a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond annotations: it returns only earlier publications, models the tender→correction→award lifecycle, and notes that an empty list is normal for a first publication. This helps set expectations without contradicting any annotation.
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 description is brief and front-loaded with a use case. It contains a slight redundancy: the lifecycle is stated in both the use case ('tender to award to correction') and the second sentence ('tender → correction → award'). Otherwise, it is tight and scannable.
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 has an output schema, return values need not be described in detail. The description covers the main purpose, lifecycle stages, and an important edge case (empty list on first publication). It is complete enough for a simple single-ID history lookup, though it could mention ordering or pagination if relevant.
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 tool description does not add parameter-level detail beyond what the input schema already provides. The schema describes `publication_id` as the ID whose earlier publications are returned and `language` as the preferred language for localized fields with a default and enum, so the description's value is contextual rather than semantic. Baseline 3 is appropriate since the schema covers the parameter meanings.
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's purpose: 'Return earlier publications of the same procurement project' and frames it as tracing a project's lifecycle (tender → correction → award). The explicit use case question — 'what happened to this procurement?' — sets it apart from sibling search/detail tools, making the resource and action unambiguous.
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 gives an explicit trigger: 'Use when the question is "what happened to this procurement?"' and clarifies the lifecycle scope. It does not explicitly name alternatives or exclusions, but the context makes it clear this is for historical tracing rather than general search, which earns a 4.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the tool's role in the overall search pipeline but does not disclose additional behavioral traits like matched/unmatched behavior, result ordering, or rate limits. It is adequate, but not rich beyond 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 concise and well-structured, starting with a clear use_case tag, followed by a one-sentence summary, and then context about CPV and integration. Every sentence contributes to understanding the tool's purpose and usage. No redundant or fluff content.
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 search tool, the description covers purpose, usage timing, and integration with `search_procurements`. It does not explain the return format, but an output schema is present. It also doesn't address edge cases like no matches, but given the tool's simplicity and the presence of annotations/schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the tool description does not explain any parameters. Although the schema itself provides detailed descriptions for `query`, `limit`, and `language`, the instruction states that with low coverage the description must compensate. It only gives a single example keyword ('Metall') but does not explain the other parameters or their constraints, so it fails to add meaningful value beyond the schema.
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's function: 'Search CPV classification codes by keyword.' It also specifies that it translates a keyword into CPV codes for filtering `search_procurements`, which differentiates it from sibling tools like `search_construction_codes`. The verb 'search' + resource 'CPV classification codes' is specific and unambiguous.
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 use_case explicitly states when to call this tool: 'Call this first when the user names a subject rather than a code.' It also explains the workflow: resolve keyword to code, then pass to `search_procurements(cpv_codes=[...])`. This provides clear when-to-use guidance and distinguishes it from the procurement search tools.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: the office list is large (~1 MB), fetch-once and client-side filtering, and the returned fields (id, type, linked institution id). This goes beyond annotations without contradicting them.
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 description is concise and front-loaded with a use_case tag, then a clear function statement and two additional useful details (performance, return fields). Every sentence earns its place. Minor redundancy between the use_case and first sentence, but it is efficient overall.
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 simple filtered-list tool with strong annotations and a detailed input schema, the description is complete. It covers the use case, behavior, performance note, and key return fields. The output schema exists, so return-value detail is optional; the description provides enough context for correct selection and invocation.
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 input schema already provides descriptions for all parameters (name_contains, limit, language), so the baseline is 3. The description's mention of '(partial) name' aligns with name_contains but does not add semantics beyond the schema. No ambiguity or gap that requires compensation.
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 states a clear, specific purpose: find public procurement offices by partial name. It explicitly distinguishes this tool from sibling tools that search procurements/awards by noting it resolves an authority name rather than a project. The use_case tag adds valuable context.
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 includes a clear when-to-use clause ('when the user names an authority rather than a project'), which guides selection. It does not explicitly name alternative tools, but the context strongly implies the distinction. This is clear context without formal exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses two important behavioral traits: uneven canton coverage (absence is not proof of no award) and the fact that the filter matches the newest publication, so corrected projects drop out. These are non-obvious and useful for interpretation, adding value beyond the structured hints.
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-structured with a use_case tag, a concise summary, and two clearly labeled caveats. Every sentence adds value: it identifies the tool's niche, explains its wrapper nature, and provides practical caveats. No fluff or repetition.
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?
The description covers purpose, usage, and key limitations. It does not mention pagination behavior or response structure, but an output schema exists to cover that. For a tool with this complexity, it is sufficiently complete, though a brief note on pagination (like the canton_match 'both' mode giving up pagination) would elevate it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The context signal indicates schema description coverage is 0%, so the description carries the burden. However, it only explains one parameter (canton_match), saying it 'works exactly as in search_procurements' and defaults to procuring body. The other five parameters (canton, cursor, language, published_from, published_until) are not elaborated in the description text, leaving a significant gap if the schema descriptions are not reliable.
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's purpose: 'Find who won, not what is open — all four award types at once' and 'Search only awarded contracts (who won).' It distinguishes itself from sibling tools like search_procurements by framing it as a convenience wrapper for completed procurement, making it immediately clear when this tool is appropriate.
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?
Explicit usage guidance is provided: 'Use when the question is about completed procurement rather than current opportunities.' It also names an alternative (get_publication_history) for cases where awards might be missed due to the newest-publication filter, and explains the coverage caveats. This goes beyond simple 'when to use' to include when not to rely on it.
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?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds context beyond annotations by clarifying that the tool reports reachability and latency, and by explaining the semantic importance of distinguishing source failures from empty results. This is useful behavioral context without contradicting any 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 concise and well-structured. It begins with an XML-like use_case tag conveying the scenario, then a direct statement of what the tool reports. Every sentence is meaningful, with 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 tool is simple: it checks reachability and latency, with no parameters. The description explains both purpose and usage context, while annotations cover safety and idempotency. An output schema exists (not shown), so return-value details are not required in the description. The description is fully complete for this tool.
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?
The tool takes no arguments (StatusInput has no properties, and the optional 'args' defaults to null). With 0 parameters, the baseline score is 4. The description does not repeat schema details, and no parameter explanations are needed since none exist.
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 explicitly states the tool's function: 'Check whether simap.ch is reachable and how fast it is responding.' It specifies the resource (simap.ch read API) and the action (checking reachability and latency), clearly distinguishing it from sibling tools that search or retrieve procurement data.
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 a clear scenario for when to use the tool: 'Call this when a search returns nothing and you need to distinguish "no matching tenders" from "the source could not be asked".' This explains the context and decision point, though it does not explicitly mention alternative tools or when not to use it.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: it runs a search then fetches get_procurement_details in parallel for top_n hits, and each result carries CPV/BKP codes, deadlines, and office. This goes beyond basic safety disclosure to explain the composite behavior.
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?
Longer than typical, but well-structured with a <use_case> tag, a one-sentence summary, explanation of aggregation, and an Args block. Every sentence contributes value; no redundancy from the schema.
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 composite tool with one parameter and a sibling reference, the description covers use case, internal behavior, result contents, alternatives, and parameter semantics. The presence of an output schema lowers the burden for return-value details, making this complete.
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 description coverage is 0% for the single 'args' parameter, but the description explicitly defines top_n as 'How many of the top hits to expand to full detail (1-5)' and states all other params are 'identical to search_procurements', linking to a sibling for full semantics. This compensates for the schema gap well.
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?
Description opens with 'Search publications and return the FULL record for the top matches at once' – a specific verb+resource+scope statement. It also explicitly contrasts with sibling search_procurements, clarifying its unique aggregation behavior.
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 explicit when/when-not guidance: 'Prefer this over search_procurements followed by N detail calls' and 'Prefer search_procurements when you only need the summaries or want to paginate'. This disambiguates tool selection clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only/idempotent behavior, but the description adds substantial non-obvious context: simap indexes projects rather than publications, a project appears once under its newest publication, filterless queries return nothing, and place_of_delivery misses ~60% of publications. It also discloses that canton_match='both' costs two upstream calls and disables cursors.
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 description is long, but it is well-organized with a use-case tag, summary paragraphs, and an Args block. Virtually every sentence adds operational value—coverage, update frequency, project-indexing model, required filters, and parameter caveats—though a bit more trimming would make it even more concise.
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 is complete for a complex search tool: it covers scope, update cadence, the project-vs-publication model, required filters, pagination behavior, parameter quirks, and links to related tools. Given the output schema is present and the description provides deep operational context, an agent can invoke this tool reliably.
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?
Even though the context signal claims 0% schema description coverage, the schema actually includes property descriptions, and the tool description's Args section goes much further. It explains bare canton format (NOT CH-ZH), the meaning and caveats of each canton_match value, the exact award pub_type strings, and the fact that a plain 'award' is rejected by the API.
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 opens with a clear use case: 'Find open tenders matching a topic, canton, CPV code or date window — the default entry point...' and explicitly states it searches Swiss public procurement projects on simap.ch. This specific verb-plus-resource framing distinguishes it from siblings like get_procurement_details and get_publication_history.
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 labels itself as the default entry point for 'what is being tendered?' and directs the agent to use get_procurement_details for full records and get_publication_history for earlier publications. It also references search_cpv_codes for resolving CPV names, providing concrete alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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/malkreide/swiss-procurement-mcp'

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