Skip to main content
Glama
Ansvar-Systems

Slovenian Competition MCP

by Ansvar-Systems
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Slovenian Competition MCP

The Slovenian competition corpus is now served through the Ansvar Gateway. Connect your AI assistant (Claude, Copilot, Cursor, custom MCP client) to https://gateway.ansvar.eu/mcp — one OAuth connection, free tier available, covering this corpus plus EU regulations, national law across dozens of audited jurisdictions (Europe + the US), and CVE/security intelligence, every result with a verbatim source citation. Start at https://ansvar.eu/docs/quickstart

Connect

Claude Code (one line):

claude mcp add ansvar --transport http https://gateway.ansvar.eu/mcp

Claude Desktop / Cursor — add to claude_desktop_config.json (or mcp.json):

{
  "mcpServers": {
    "ansvar": {
      "type": "url",
      "url": "https://gateway.ansvar.eu/mcp"
    }
  }
}

Claude.ai — Settings → Connectors → Add custom connector → paste https://gateway.ansvar.eu/mcp

First request opens an OAuth signup flow (setup details: ansvar.eu/docs/quickstart). After signup, your client is bound to your account; tier (free / premium / team / company) determines fan-out, quota, and which downstream MCPs are reachable.

Self-host this MCP

You can also clone this repo and build the corpus yourself. The schema, fetcher, and tool implementations all live here. What is not in the repo is the pre-built database — TDM and standards-licensing constraints on the upstream sources mean we host the corpus on Ansvar infrastructure rather than redistribute it as a public artifact.

Build your own: run this repo's ingestion script (entry-point varies per repo — typically scripts/ingest.sh, npm run ingest, or make ingest; check the repo root).

Slovenian competition data for AI compliance tools.

License CI

Query Slovenian competition data -- regulations, decisions, and requirements from AVK (Slovenian Competition Protection Agency) -- directly from Claude, Cursor, or any MCP-compatible client.

Built by Ansvar Systems -- Stockholm, Sweden

Related MCP server: irish-competition-mcp

Available Tools (6)

Tool

Description

si_comp_search_decisions

Full-text search across AVK (Agencija za varstvo konkurence) enforcement decisions covering abuse of dominance, carte...

si_comp_get_decision

Get a specific AVK decision by case number (e.g.,

si_comp_search_mergers

Search AVK merger control decisions (nadzor koncentracij). Returns merger cases with acquiring party, target, sector,...

si_comp_get_merger

Get a specific AVK merger control decision by case number (e.g.,

si_comp_list_sectors

List all sectors with AVK enforcement activity, including decision counts and merger counts per sector.

si_comp_about

Return metadata about this MCP server: version, data source, coverage, and tool list.

All tools return structured data with source references and timestamps.

Data Sources and Freshness

All content is sourced from official Slovenian regulatory publications:

  • AVK (Slovenian Competition Protection Agency) -- Official regulatory authority

Data Currency

  • Database updates are periodic and may lag official publications

  • Freshness checks run via GitHub Actions workflows

  • Last-updated timestamps in tool responses indicate data age

See sources.yml for full provenance metadata.

Security

This project uses multiple layers of automated security scanning:

Scanner

What It Does

Schedule

CodeQL

Static analysis for security vulnerabilities

Weekly + PRs

Semgrep

SAST scanning (OWASP top 10, secrets, TypeScript)

Every push

Gitleaks

Secret detection across git history

Every push

Trivy

CVE scanning on filesystem and npm dependencies

Daily

Docker Security

Container image scanning + SBOM generation

Daily

Socket.dev

Supply chain attack detection

PRs

Dependabot

Automated dependency updates

Weekly

See SECURITY.md for the full policy and vulnerability reporting.

Important Disclaimers

Not Regulatory Advice

THIS TOOL IS NOT REGULATORY OR LEGAL ADVICE

Regulatory data is sourced from official publications by AVK (Slovenian Competition Protection Agency). However:

  • This is a research tool, not a substitute for professional regulatory counsel

  • Verify all references against primary sources before making compliance decisions

  • Coverage may be incomplete -- do not rely solely on this for regulatory research

Before using professionally, read: DISCLAIMER.md | PRIVACY.md

Confidentiality

Queries go through the Claude API. For privileged or confidential matters, use on-premise deployment. See PRIVACY.md for details.

Development

Setup

git clone https://github.com/Ansvar-Systems/slovenian-competition-mcp
cd slovenian-competition-mcp
npm install
npm run build
npm test

Running Locally

npm run dev                                       # Start MCP server
npx @anthropic/mcp-inspector node dist/index.js   # Test with MCP Inspector

Data Management

npm run build:db       # Rebuild SQLite database from seed data
npm run check-updates  # Check for new regulatory data

More Ansvar MCPs

Full fleet coverage at ansvar.eu/coverage.

Contributing

Contributions welcome! See CONTRIBUTING.md for guidelines.

License

Apache License 2.0. See LICENSE for details.

Data Licenses

Regulatory data sourced from official government publications. See sources.yml for per-source licensing details.

About Ansvar Systems

We build AI-powered compliance and legal research tools for the European market. Our MCP fleet provides structured, verified regulatory data to AI assistants -- so compliance professionals can work with accurate sources instead of guessing.

ansvar.eu -- Stockholm, Sweden

Available Tools

6 tools
si_comp_aboutA

Return metadata about this MCP server: version, data source, coverage, and tool list.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

No annotations, but the description is straightforward: a read-only query returning metadata. It doesn't mention side effects, which are absent. Could list exact metadata fields but sufficiently transparent.

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, front-loaded with the verb 'Return', no wasted words. Perfectly 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?

For a simple metadata tool with no parameters and no output schema, the description is complete. It explains purpose and output, and the sibling list provides context.

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?

No parameters exist, so schema coverage is 100%. The description adds value by explaining what the output includes, which is beyond what the empty schema provides.

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 returns metadata about the server, listing specific items (version, data source, coverage, tool list). This distinguishes it from sibling tools that deal with specific data like decisions or mergers.

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?

No explicit when-to-use or alternative guidance, but the context makes it clear this is for server metadata, while siblings are for specific data queries. The use case is obvious.

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

si_comp_get_decisionB

Get a specific AVK decision by case number (e.g., '306-35/2023', '306-12/2022').

ParametersJSON Schema
NameRequiredDescriptionDefault
case_numberYesAVK case number (e.g., '306-35/2023', '306-12/2022')

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. However, it only states the core function and does not mention permissions, error handling, response format, or any side effects. This is insufficient for safe and effective agent decision-making.

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 a single, clear sentence with an example. It is front-loaded and easy to parse. While it could benefit from more detail, it remains appropriately concise without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should provide more context about the returned decision object. It also lacks behavioral or usage context, making it incomplete for a tool with one critical input and no output schema.

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 coverage is 100% for the single parameter, so the description adds little beyond the schema. It provides an example case number format, but this is already implied by the schema description. Baseline moderate score 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 tool retrieves a specific AVK decision by case number and provides an example format. This distinguishes it from sibling tools like si_comp_search_decisions (which searches) and si_comp_get_merger (which gets mergers), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus its alternatives, such as si_comp_search_decisions. No explicit context for usage or exclusion is given, leaving the agent to infer based solely on the name and sibling list.

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

si_comp_get_mergerB

Get a specific AVK merger control decision by case number (e.g., '306-K-1/2023').

ParametersJSON Schema
NameRequiredDescriptionDefault
case_numberYesAVK merger case number (e.g., '306-K-1/2023')

TDQS

B3.3/5.0
Behavior3/5

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

Description indicates a retrieval operation but does not disclose any behavioral traits such as error handling, authentication requirements, or rate limits. Since annotations are absent, more detail would be beneficial, but the simplicity of a 'get' tool mitigates the gap.

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, no wasted words, front-loaded with purpose. Very concise.

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 simple tool with one parameter and no output schema, the description is mostly adequate but lacks mention of what is returned or any usage context. It does not cover potential errors or alternative tools, leaving some gaps.

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 coverage is 100%, so baseline is 3. The description provides an example ('306-K-1/2023') that adds modest value beyond the schema description. No other parameter details are missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Get' and resource 'specific AVK merger control decision' with an example case number. While it distinguishes from siblings implicitly by specifying 'by case number', it does not explicitly differentiate from si_comp_search_mergers or si_comp_get_decision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like si_comp_search_mergers or si_comp_get_decision. The context is implied by the case number parameter but no explicit when/when-not advice is given.

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

si_comp_list_sectorsA

List all sectors with AVK enforcement activity, including decision counts and merger counts per sector.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses that the tool lists all sectors and includes decision and merger counts, providing sufficient behavioral context. No contradictions with annotations (none provided), though it could mention if there are any limits or data freshness.

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 a single, well-formed sentence that efficiently conveys the tool's function without unnecessary words.

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?

Given no parameters and no output schema, the description fully informs the agent of what to expect: a list of sectors with enforcement activity, decision counts, and merger counts. The sibling tools handle specific entity lookups.

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?

No parameters exist, so the description does not need to add param information. Schema coverage is 100% (trivially), and the baseline for 0 params is 4.

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 uses specific verbs and resources ('List all sectors') and clearly distinguishes the tool from sibling tools which focus on specific decisions, mergers, or general information.

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 implicitly indicates use when sector-level aggregate data is needed, and sibling tools are for specific entities, making the usage context clear. However, it does not explicitly state when not to use.

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

si_comp_search_decisionsA

Full-text search across AVK (Agencija za varstvo konkurence) enforcement decisions covering abuse of dominance, cartel enforcement, and sector inquiries under Slovenian competition law (ZPOmK-2). Returns matching decisions with case number, parties, outcome, fine amount, and ZPOmK articles cited.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoFilter by decision type. Optional.
limitNoMaximum number of results to return. Defaults to 20.
queryYesSearch query (e.g., 'zloraba prevladujocega polozaja', 'kartelni sporazum', 'koncentracija')
sectorNoFilter by sector ID (e.g., 'energy', 'telecommunications', 'retail'). Optional.
outcomeNoFilter by outcome. Optional.

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only describes the search functionality and return fields, but fails to mention whether the tool is read-only, any authentication requirements, rate limits, or idempotency. This is insufficient for a search tool.

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 two sentences: first states the core functionality and scope, second lists return fields. No redundant information, efficient and front-loaded.

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?

With 5 parameters, no output schema, and no annotations, the description explains what the tool does and returns. However, it lacks behavioral info (read-only, idempotency), default limits, pagination, and error handling. Somewhat incomplete but covers essential purpose.

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 coverage is 100% with descriptions for all 5 parameters. The description adds minimal extra value beyond the schema, only mentioning return fields that are not directly about parameter usage. Baseline score of 3 is appropriate as the schema already explains parameters 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?

The description clearly specifies the tool's purpose: full-text search across AVK enforcement decisions. It explicitly mentions the scope (abuse of dominance, cartel, sector inquiries) and return fields (case number, parties, outcome, fine amount, ZPOmK articles), distinguishing it from sibling tools like si_comp_search_mergers.

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 for searching enforcement decisions but does not explicitly state when to use this tool versus alternatives like si_comp_get_decision for retrieving a single decision or si_comp_search_mergers for mergers. No explicit when-not-to-use guidance is provided.

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

si_comp_search_mergersA

Search AVK merger control decisions (nadzor koncentracij). Returns merger cases with acquiring party, target, sector, and outcome.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return. Defaults to 20.
queryYesSearch query (e.g., 'prevzem energetika', 'telekomunikacije koncentracija', 'maloprodaja zdruzitev')
sectorNoFilter by sector ID (e.g., 'energy', 'telecommunications', 'retail'). Optional.
outcomeNoFilter by merger outcome. Optional.

TDQS

A3.6/5.0
Behavior2/5

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

No annotations are provided, and the description only mentions return fields. It does not disclose behavior such as whether the tool is read-only, authentication requirements, rate limits, or any side effects. For a tool with no annotations, more transparency is needed.

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 two sentences, concise and front-loaded. Every word provides value, with no unnecessary detail.

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 complexity (4 parameters, no output schema), the description adequately covers what it returns. However, it could mention pagination behavior or result limits, which are implied by the 'limit' parameter but not explained. Overall it is mostly complete.

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?

All 4 parameters are described in the schema with 100% coverage. The description adds no extra meaning beyond the schema; it only lists some return fields. Baseline score of 3 is appropriate as the schema already conveys parameter semantics.

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 this tool searches AVK merger control decisions and specifies the return fields (acquiring party, target, sector, outcome). It is distinct from sibling tools like si_comp_search_decisions, which likely covers broader decisions.

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?

Usage is implied by the tool name and description, but there is no explicit guidance on when to use this over si_comp_search_decisions or other siblings. The description does not mention when not to use the tool or provide alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updatesv0.1.0
    • First observedsi_comp_about
    • First observedsi_comp_get_decision
    • First observedsi_comp_get_merger
    • First observedsi_comp_list_sectors
    • First observedsi_comp_search_decisions
    • First observedsi_comp_search_mergers
Deploy Server
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

TDQS

A4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: searching vs retrieving by ID for decisions and mergers, listing sectors, and server metadata. No overlap.

Naming Consistency5/5

All tools follow a consistent 'si_comp_verb_noun' pattern in snake_case, with clear verbs (search, get, list) and objects (decisions, mergers, sectors, about).

Tool Count5/5

6 tools is well-scoped for a competition law database, covering search and retrieval for two categories plus sector listing and metadata. Not excessive or insufficient.

Completeness5/5

Core CRUD operations for a read-only legal database are covered: search, retrieve by ID, and list sectors. No obvious gaps given the server's purpose.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers