Lexiara

Ask Lexiara to acquire a missing law

request_ingestion

Idempotent

When a lookup returns coverage with requestable: true, ask for the missing instrument instead of stopping or guessing. Give the CELEX (or an EU ELI), the language and the version point; say WHY in one or two sentences; state any testable expectations. Lexiara validates the target, fetches the publisher's own bytes, reads them through the same parser and the same fail-closed checks every other act goes through, and returns handles you repeat your original lookup with.

WHAT THIS TOOL IS NOT. It never fetches a URL you supply — the target must resolve to a publisher identifier this service derives itself, and proposed_sources is recorded as a note for a human and is never dereferenced. It states nothing about what the law means: acquiring an act makes the publisher's text addressable and does nothing else.

EXPECTATIONS ARE HYPOTHESES, NOT INSTRUCTIONS. has_article, has_annex, mentions (three words or more), min_provisions, language_is are checked against the stored rows after publication and reported as matched, contradicted or not_verifiable. A contradicted expectation is reported and the publisher's text is left exactly as published — nothing is invented, translated or back-dated to satisfy one.

Identical targets from different callers JOIN one acquisition; your rationale stays private to your account. Re-send the same idempotency_key to get the same request back rather than a second one. Jobs are asynchronous: read retry_after, then poll get_ingestion_request. This tool creates a request: an OAuth grant with only read cannot call it; reconnect and approve the explicit ingestion:request consent. Existing read grants remain read-only.

Input Schema

TableJSON Schema

Name	Required	Description
`eli`	No	An EU ELI on the Publications Office's own domain, if you have no CELEX.
`role`	No	'law' (default) or 'guidance' for a Commission notice.
`celex`	No	CELEX id of the act, e.g. '32024L0825', or a dated consolidation '02005L0029-20220528'.
`intent`	Yes	What kind of gap this is. `derived_references` refreshes derived references for a held work; missing_component and repair against an act already held re-read THAT expression rather than creating a second one beside it.
`origin`	No	Lexiara handles you started from (work, eId, expression id). Private.
`version`	No	'as-adopted' (default), the publisher's consolidation date as YYYY-MM-DD, or 'unresolved' when you genuinely do not know — which returns a question, not a job.
`language`	No	ISO 639-3 language wanted, e.g. 'eng', 'fra'. Default 'eng'.
`rationale`	No	One or two sentences: the question, and why this evidence is needed. Private to your account.
`expectations`	No	Up to ten predicates, each naming exactly one of has_article, has_annex, mentions, min_provisions, language_is.
`evidence_path`	No	The shortest path from held material to the missing target: each step a { from, relationship, to } you observed. Private, and evidence for a human, never an instruction.
`idempotency_key`	No	Your own key for this request. The same key returns the same request.
`proposed_sources`	No	Official identifiers or locators you believe serve this act. RECORDED AS TEXT AND NEVER FETCHED.
`requested_bounds`	No	maxBytes / maxSeconds you are willing to spend. May only NARROW the server's budget; a larger number is ignored.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 19, 2026

changedInput schema / properties / intent / description

Previous value: -"What kind of gap this is. missing_component and repair against an act already held re-read THAT expression rather than creating a second one beside it."New value: +"What kind of gap this is. `derived_references` refreshes derived references for a held work; missing_component and repair against an act already held re-read THAT expression rather than creating a second one beside it."

changedInput schema / properties / intent / enum

Previous value: -[
-  "new_work",
-  "missing_component",
-  "language_counterpart",
-  "version",
-  "repair"
-]New value: +[
+  "new_work",
+  "missing_component",
+  "language_counterpart",
+  "version",
+  "repair",
+  "derived_references"
+]

AddedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the annotations: it discloses that the target is validated, fetched from the publisher's own bytes, run through the same fail-closed checks, and returned as handles for repeating the original lookup. It also clarifies that expectations are hypotheses, not instructions, and that contradicted expectations leave the publisher's text untouched. The idempotent behavior, async retry_after polling, and auth consent limitations are all disclosed, and nothing in the description contradicts the 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 long, but it earns most of its length with clearly separated sections: core usage, what the tool is not, expectations semantics, and operational caveats. Front-loading the main invocation scenario helps an agent quickly understand the tool's purpose. Some repetition exists around `proposed_sources` never being dereferenced, which also appears in the schema, so it is not perfectly lean.

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 — 13 parameters, enums, nested objects, async behavior, auth boundaries, and idempotency — the description is remarkably complete. It covers when to call, what will happen, what will not happen, how expectations are handled, how idempotency works, how to poll, and what auth is required. The output schema exists, so the description need not restate return shapes, and nothing critical for correct invocation is missing.

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 cooverage is 100%, so the baseline is 3 and the description does not need to compensate for undocumented parameters. The prose adds helpful cross-cutting context like idempotent keys, private rationale, and expectations being checks rather than instructions, but it does not systematically add per-parameter meaning beyond whatthe schema already provides. This is a solid 3 rather than higher because the extra value lies in behavioral context, not 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 states a very specific verb and resource: when a lookup returns `coverage` with `requestable: true`, ask Lexiara to acquire the missing law by creating an ingestion request. It clearly distinguishes this from siblings like get_ingestion_request, get_ingestion_result, and list_ingestion_requests by emphasizing that this tool creates a request rather than reading or listing one.

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 gives explicit when-to-use guidance: only after a lookup indicates `requestable: true`, and explicitly says not to stop or guess. It also names exclusions: it never fetches a user-supplied URL, never interprets law, and requires `ingestion:request` consent beyond a read-only OAuth grant. It even points to the polling flow with get_ingestion_request, making the alternative workflow clear.

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

All Lexiara tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?