EU AI Act and SB 942 obligations for AI systems: each date, the article setting it, signed sources
Scored across 5 tools
Each tool targets a distinct task: applicability (does a deployment trigger obligations), obligations (what exists/in force), cite (citation block for one obligation), verify (business certification), integrity (document provenance). The closest pair is applicability vs obligations and cite vs obligations, but their descriptions clearly separate 'evaluate a deployment' from 'list instruments' from 'format a single citation'.
All names share a predictable lunara_ prefix, giving a consistent namespace and readable pattern. The suffix mixes nouns (applicability, integrity, obligations) with verbs (cite, verify), a minor deviation but not confusing in practice.
Five tools is well within the ideal 3-15 range and each earns its place with a clear, non-redundant role in the regulatory workflow. Nothing feels padded or missing at the count level.
The surface covers the core lifecycle: discover obligations, check applicability, cite a specific obligation, verify certification, and validate document provenance. Minor gaps exist (e.g., no explicit search/browse across instruments beyond the obligations listing), but agents can work around them.
Runs Lunara's published applicability model against a description of an AI deployment and returns which obligations reach it, which do not, and why. Answer only what you actually know — every input accepts "unsure", and an unsure is never resolved in the direction that manufactures an obligation. The model can and does conclude that nothing binds the asker.
| Name | Required | Description | Default |
|---|---|---|---|
| eu_exposure | No | Does anyone in the EU use it, or its output? The Act binds on output, not on where you are incorporated. | |
| generates_content | No | Does it produce text, images, audio or video? | |
| california_exposure | No | Is it available to people in California? | |
| interacts_with_people | No | Does the system exchange words with a person? | |
| monthly_users_over_1m | No | More than one million monthly users? This threshold decides the California Act entirely. | |
| on_market_before_art50 | No | Was it placed on the market before 2 August 2026? | |
| hosts_or_distributes_models | No | Do you host third-party generative models or distribute their output at scale? | |
| generates_images_audio_or_video | No | Does it produce images, audio or video, as opposed to only text? Decides whether the prohibition applying from 2 December 2026 can reach it at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose meaningful behavioral traits: unsure answers are never resolved in the direction that manufactures an obligation, and the model can conclude that nothing binds the asker. It also sketches the return content ('which obligations reach it, which do not, and why'). It does not cover authorization needs, limits, or the result's authoritative/legal status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, and each sentence adds something distinct: what it does, how to answer, and the consequence of uncertainty. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter, fully documented, all-optional tool with no output schema, the description adequately covers purpose, input discipline, and the shape of the result. It stops short of describing how to read or act on the output, which is the main remaining gap given there is no output schema to lean on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter is an enumerated yes/no/unsure with its own explanatory text, so the schema does the heavy lifting. The description adds only the cross-cutting note that every input accepts 'unsure', which is already visible in the enums. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it runs Lunara's published applicability model against a described deployment and returns which obligations reach it. It is distinguishable from the sibling lunara_obligations by being the assessment step rather than the obligation listing, though it never names or contrasts with any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear guidance on how to supply answers ('answer only what you actually know', every input accepts 'unsure'), but that is input-completion guidance rather than when-to-use-this-vs-alternatives guidance. There is no statement of when an agent should call this instead of lunara_obligations, lunara_verify or lunara_integrity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a citation block for one obligation: status, effective date, instrument, article, penalty, primary source, amending act, evidence classification and the time the tense was computed. Use this when you are about to state a regulatory date or requirement to someone, so the claim carries its source.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Corpus id, e.g. "eu-art50". Use lunara_obligations to list them. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Returns" correctly signals a read-only retrieval, and the enumerated field list is genuinely useful since there is no output schema. However, it says nothing about permissions, rate limits, or whether citing mutates/records anything, leaving real behavioral gaps for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return payload and followed by the usage trigger. The field enumeration is long but earns its place because no output schema exists to carry it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe the return shape, and it does so concretely (status, effective date, instrument, article, penalty, sources, tense computation time). Combined with the complete single-parameter schema, an agent has enough to call it correctly; only behavioral caveats are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter (id) at 100% schema coverage, and the schema fully documents it with an example ("eu-art50") and a pointer to lunara_obligations for discovery. The description adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ("Returns a citation block for one obligation") and enumerates exactly what the block contains, so the agent knows this is a citation/evidence-retrieval tool rather than a listing or verification one. It does not name any sibling (e.g. lunara_obligations or lunara_verify) to sharpen the boundary, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when you are about to state a regulatory date or requirement to someone, so the claim carries its source" gives a clear situational trigger. It does not name an alternative tool or state when NOT to use this one, so it lacks the exclusion/alternative element required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports whether the documents this server fetched carry a valid Ed25519 signature from Lunara Society, and returns the digests and key material needed to check that independently. Use it when the answer matters enough that the provenance of the source does: a corpus served from a mirror, a cache or a snapshot is not covered by the transport security of the original fetch, and this is what covers it instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: it is a reporting/read operation, it returns the digests and key material so the caller can verify independently rather than trusting the server's verdict, and it explains the threat model (mirror/cache/snapshot paths). It omits failure semantics (does it throw or report invalid) and any auth or rate-limit requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action followed by the usage condition. Every clause carries information, though the second sentence is somewhat indirect ('when the answer matters enough that the provenance of the source does') before it reaches the concrete mirror/cache case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description does the heavy lifting well by naming the returned artifacts (digests, key material) so the agent knows what to expect. Given the tool is a parameterless read/report operation, what remains missing is mostly edge behavior: what an invalid signature looks like in the response and whether it can fail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema covers nothing and the baseline of 4 applies. The description correctly implies the server already knows which corpus to inspect, requiring no caller-supplied identifiers, which is consistent with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it reports whether the server's fetched documents carry a valid Ed25519 signature from Lunara Society, and what it returns (digests and key material). The scoping to 'documents this server fetched' is precise. It does not, however, differentiate itself from the potentially overlapping sibling lunara_verify, which an agent could easily confuse with a signature-integrity check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition: use it when the provenance of the source matters, specifically for a corpus served from a mirror, cache, or snapshot, because transport security from the original fetch does not cover those paths. No alternative sibling is named as a when-to-use-this-instead, so routing against lunara_verify is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The regulatory obligations Lunara Society tracks, with tense computed at the moment of the call. Each carries the instrument, the article that sets the date, a link to primary law, and any amending act. Use this to answer "what is in force", "what is coming", or "what does instrument X require" rather than recalling dates from training data — several of these have been amended, one of them five days before it would have applied.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Return a single obligation by corpus id, e.g. "eu-art50". | |
| status | No | Default all. | |
| jurisdiction | No | Filter, e.g. "European Union" or "California". Case-insensitive substring. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that status/tense is computed live at call time and that results may reflect recent amendments — a meaningful freshness warning that explains the tool's core value. It omits auth requirements, pagination, and result-set size limits, so it is not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, purpose and freshness caveat front-loaded, no filler. The closing anecdote ("five days before it would have applied") is evocative and motivates the currency claim, though it is slightly long for the information it adds.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, so the description must sketch the return shape — and it does (instrument, article setting the date, primary-law link, amending act). Combined with the live-computation note, that is enough for a low-complexity, zero-required-parameter list tool, though pagination and total-count behavior are unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents id, status, and jurisdiction (including the default). The description adds no parameter-level guidance such as how jurisdiction substrings interact with status, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (regulatory obligations tracked by Lunara Society) and a distinctive behavioral trait (tense computed at call time). An agent can tell it is a listing/retrieval tool, but the description never contrasts it against the siblings lunara_verify, lunara_cite, lunara_applicability, or lunara_integrity, so sibling differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger questions ("what is in force", "what is coming", "what does instrument X require") and an explicit alternative to avoid (recalling dates from training data). It stops short of 5 because it names no sibling tool as the alternative for adjacent questions, so routing between Lunara tools remains unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a business carries Lunara Shield certification. Returns verified, not_registered or revoked. IMPORTANT: not_registered is not a negative signal about the business — it means the verification process has not been completed, which is true of most organisations. Do not present it as a warning. Reading the registry is free and unauthenticated by design.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Business domain, e.g. "example.com". | |
| public_id | No | Lunara public id, e.g. "SHIELD-2026-0001". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the three possible return states, the non-obvious meaning of not_registered, and that reads are free and unauthenticated. It does not address failure modes (e.g., neither parameter supplied, unknown domain), keeping it out of the 5 band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly packed sentences: purpose first, return values second, the crucial caveat third, and the access model last. Every sentence earns its place and nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming the three return states. The access model is covered. The remaining gap is that zero parameters are marked required, and the description never clarifies whether domain, public_id, or either is needed to resolve a business.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description adds no format or precedence detail for domain vs public_id (e.g., whether one is preferred or required), so it does not exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (checks whether a business carries Lunara Shield certification) and even enumerates the possible outcomes. It is immediately distinguishable in substance from registry-adjacent siblings, but it never names or contrasts with any of them, so it falls just short of the sibling-aware 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the agent learns the lookup is free and unauthenticated, but there is no explicit 'use this when' and no alternatives (applicability, integrity, obligations) are contrasted. The 'do not present as a warning' note is interpretational guidance rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lunara_applicabilitylunara_citelunara_integritylunara_obligationslunara_verifyEU AI Act obligations and updates from ten official sources, incl. the national layer.
Audited AI-regulation data: laws, bills, news and obligations across US, EU and 62 jurisdictions
EU AI Act and GDPR checks with sources: classify an AI system, trace each duty, find the supervisor.
UAE Corporate Tax, CSRD scope, EU AI Act risk class and CBAM cost, each line citing its source law
Add one secure layer between your agents and this server.
