Skip to main content
Glama

Ansvar: EU Compliance & Legal Intelligence

by eu.ansvar

List Coverage

list_coverage
Read-only

Show which countries, frameworks, and legal domains are available. Use this BEFORE calling search when the user's topic doesn't name a jurisdiction (e.g., 'what does the law say about consumer protection'); then present the returned jurisdictions to the user or ask which applies. Examples: • 'Which countries do you cover?' → list_coverage() • 'Do you have German law?' → list_coverage(jurisdiction='DE') • 'What jurisdictions for NIS2?' → list_coverage(domain='cybersecurity') • 'Which countries have drone law?' → list_coverage(domain='aviation') (also accepts 'drone' / 'uas') Returns a jurisdictions array (each with code, name, region, laws, provisions, domains, counts_complete, and uncounted_sources) plus framework and source listings. An incomplete-count row also carries coverage_note explaining why. NOTE: laws/provisions are WHOLE-JURISDICTION corpus totals — the response's count_scope is whole_jurisdiction. Under a domain filter the jurisdiction list is narrowed to that domain but the counts are NOT domain-scoped; do not report them as a per-domain count. The domain-specific signal is the (domain-filtered) sources/frameworks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoLegal domain to narrow the jurisdiction list to, such as 'cybersecurity' or 'aviation' ('drone' and 'uas' are accepted for the latter). The law and provision counts stay whole-jurisdiction; the domain-scoped signal is the returned sources and frameworks.
regionNoGeographic region to narrow the jurisdiction list to, such as 'europe'. Empty returns every region.
jurisdictionNoISO-2 code to report on alone, such as DE. Empty returns every jurisdiction in scope.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.9/5.0
Behavior5/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 covered. The description adds substantial behavior beyond that: whole-jurisdiction counts, the count_scope value, the meaning of coverage_note, and the important caveat that domain-filtered counts are NOT domain-scoped. This prevents a likely misinterpretation.

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 thorough but efficient: it front-loads the core purpose and usage rule, then uses bullet examples, and ends with a precise 'NOTE' about count scoping. Every section earns its place, and no sentence is redundant with the schema or annotations.

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 the tool's complexity—optional filters, domain-scoped vs whole-jurisdiction semantics, and a rich output schema—the description is complete. It tells the agent when to call it, how to pick parameters, what the response shape will be, and how to interpret domain-filtered results, leaving no critical gap.

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?

Input schema coverage is 100%, so the baseline is 3. The description adds value on top by providing concrete usage examples for jurisdiction and domain, and by restating the critical domain-count caveat in a way that links directly to the parameters. It does not introduce new undocumented parameters, but the examples and caveat push it above the baseline.

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 specific verb and resource: 'Show which countries, frameworks, and legal domains are available.' It clearly distinguishes this tool from its sibling `search` by positioning it as the pre-search discovery step, and the examples reinforce what inputs map to what outputs.

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 states when to use this tool: 'Use this BEFORE calling `search` when the user's topic doesn't name a jurisdiction.' It also gives concrete example queries and corresponding invocations, and clarifies what to do with the returned jurisdictions, making the decision boundary between `list_coverage` and `search` unambiguous.

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

All Ansvar: EU Compliance & Legal Intelligence toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, but a few pairs overlap: get_current_step vs get_progress, search_cve vs search_by_product, and describe_capabilities vs get_my_capabilities. The descriptions provide enough detail to differentiate them, but agents could still occasionally misselect.

Naming Consistency4/5

Names overwhelmingly follow a verb_noun snake_case pattern (get_*, list_*, search_*, start_*, etc.). Minor deviations like 'diff' and 'search' (single-word) and 'batch_search' (compound modifier) are predictable and don't disrupt the overall consistency.

Tool Count3/5

With 30 tools, the server is on the heavier side. The broad scope (legal intelligence, CVE data, full workflow engine) justifies many tools, but some are internal or niche (probe_corpus, recommend_subagents) and could be hidden. It's borderline between well-scoped and excessive.

Completeness4/5

The legal and CVE domains are well-covered: search, provision lookup, validation, diff, coverage, and detailed CVE enrichment. Workflow management is end-to-end. However, get_regulatory_deadlines is referenced by get_regulatory_intelligence_status but not exposed in the toolset, leaving a notable gap.

Resources