Skip to main content
Glama

Ansvar: EU Compliance & Legal Intelligence

by eu.ansvar

Probe Corpus

probe_corpus
Read-only

Test whether a specific data source contains information about a topic before running a full search. Single-MCP diagnostic dispatch for fleet-quality probes. Not for customer use — requires mcp:probe scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch terms, forwarded verbatim to the selected corpus backend (no gateway-side sanitization — the corpus's own FTS semantics apply). Keep to plain concept terms in the corpus language.
mcp_idYesExact fleet id of the single MCP to dispatch to, such as 'swedish-law'. No fan-out and no alias resolution — an unknown id is an error.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful constraints: 'Single-MCP diagnostic dispatch' (no fan-out) and the mcp:probe scope requirement. It does not detail error behavior, but the schema covers the unknown-id error.

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 three sentences, front-loaded with the core purpose, then providing scope and restriction. Every sentence earns its place with no redundancy or filler.

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 is simple with only two required parameters, and an output schema exists. The description conveys the essential purpose, timing, and access restriction, which is sufficient given the rich schema and annotations. It could mention error behavior, but that is already in the 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 description coverage is 100%, so the baseline is 3. The tool description itself contains no parameter-level guidance; all parameter semantics are already in the input schema. The extra 'Keep to plain concept terms' note appears in the schema, not the tool description, so no additional value is added.

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 with a specific verb ('Test') and resource ('a specific data source'), and explicitly contrasts it with 'running a full search'. This distinguishes it from sibling tools like search and batch_search.

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 on when to use the tool ('before running a full search') and includes an important restriction ('Not for customer use — requires mcp:probe scope'). It does not explicitly name alternative tools, but the timing and scope are well specified.

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