Skip to main content
Glama

record_declaration

Record an EU declaration of conformity (EU AI Act Art. 47) with Annex V details: system info, provider, standards, conformity procedure, place, date, signer, and CE marking.

Instructions

Record an EU declaration of conformity (EU AI Act Art. 47) with the Annex V items: the system's name, type and reference; the provider's name and address; the standards or common specifications used; the Art. 43 procedure (annex_vi_internal_control or annex_vii_notified_body, the latter with the notified body's {name, id, certificate}); the place, date and signer. annex_iv_sha256 pins the technical documentation the declaration rests on; ce_marking is {digital_access, affixed_to, notified_body_id} (Art. 48). The assessment itself is the provider's or the notified body's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYes
placeYes
issue_tsNo
ce_markingNo
signed_forYes
signer_nameYes
system_nameYes
system_typeYes
notified_bodyNo
personal_dataNo
provider_nameYes
annex_iv_sha256No
other_union_lawNo
signer_functionYes
provider_addressYes
system_referenceYes
conformity_procedureYes
harmonised_standardsNo
common_specificationsNo
authorised_representativeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.5.1

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses the regulatory content and the two conformity procedure options, and clarifies that the assessment is the provider's or notified body's. However, it does not disclose side effects (e.g., whether this creates a persistent record, whether it overwrites, whether it requires prior technical documentation), which would be valuable for a write operation.

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 dense paragraph that front-loads the core purpose and then lists the key fields. It is information-dense but not bloated; every sentence adds regulatory or parameter context. It could be slightly more scannable with bullet points, but it earns its length.

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 20-parameter tool with no output schema and no annotations, the description covers the main regulatory fields but leaves several parameters unexplained (actor, personal_data, other_union_law, authorised_representative, issue_ts). It also does not describe the return value or side effects. It is adequate for a domain expert but incomplete for an agent needing full invocation confidence.

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?

Schema description coverage is 0%, so the description must compensate. It does: it explains the meaning of annex_iv_sha256, ce_marking, conformity_procedure values, and the notified_body object. However, several parameters (actor, personal_data, other_union_law, authorised_representative, issue_ts) are not explained in the description, leaving some gaps.

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 specific verb ('Record') and resource ('an EU declaration of conformity (EU AI Act Art. 47)'), and enumerates the Annex V items. It clearly distinguishes this from siblings like record_oversight or record_lifecycle by naming the exact regulatory artifact and article.

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 when to use it: when recording an EU declaration of conformity under Art. 47. It does not explicitly state when not to use it or name alternatives (e.g., declaration_document, technical_documentation, record_attestation). The context is clear but exclusions and alternative routing are absent.

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

Deploy Server

Other Tools