Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.CE-RISE-software/dpawb assess my digital passport model against the latest evolution profile"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Python toolkit and thin CLI for SHACL-based assessment of digital passport data models, pairwise comparison of composed solutions, and SHACL-only use-case coverage analysis.
This README is primarily a repository and development entry point. The user-facing conceptual and usage reference is at the published documentation site. The repository-source docs remain available in docs/.
A publishable Python package with a CLI entry point: dpawb
A thin stdio MCP server entry point: dpawb-mcp
Contract-aligned input schemas for composition profiles, use cases, and alignments
Built-in vocabularies and templates exposed through discovery commands
Synthetic local fixtures used only for tests and validation
A progression-based examples tree for human and AI-agent tutorials
Related MCP server: attestix
The tool is designed primarily as an agent-usable analytical toolkit with a thin CLI. The core command surface is:
assess
coverage
compare
prioritize
recommend-composition
schema
vocabulary
template
capabilities
summarize
The intended primary integration mode is an AI agent orchestrating the analytical pipeline through the package API or the CLI. In practice, this means:
deterministic file-based inputs
JSON outputs suitable for agent parsing and chaining
explicit analytical steps instead of a chat-oriented interface
The CLI remains useful for direct human invocation, but the main product shape is an analytical engine that can be called by agent skills, workflow runners, or tool adapters.
The package also ships a thin stdio MCP server over the same deterministic command surface:
assess
coverage
compare
prioritize
recommend-composition
schema
vocabulary
template
capabilities
summarize
The MCP surface stays intentionally thin:
keep dpawb as the core Python package
expose the same operations through dpawb-mcp
ship the MCP runtime as both a local Python entry point and a GitHub Container Registry image
publish registry metadata from the GitHub mirror
The MCP runtime and publication shape are documented in the published MCP server page.
The public Python API is documented in the published API reference.
The MCP server is published with this identity:
registry name: io.github.CE-RISE-software/dpawb
OCI image pattern: ghcr.io/ce-rise-software/dpawb-mcp:<release-version>
transport: stdio
official registry base: https://registry.modelcontextprotocol.io/
The server is discoverable in the official MCP Registry under the name io.github.CE-RISE-software/dpawb.
Registry discovery page:
https://registry.modelcontextprotocol.io/?q=dpawb
Local client configuration example:
{
"mcpServers": {
"dpawb": {
"command": "dpawb-mcp"
}
}
}OCI-oriented registry metadata is declared in server.json. The publish workflow fills in the release version and image tag when publishing.
python -m venv .venv
. .venv/bin/activate
pip install -e .Published package name:
pip install dpawbThe installed MCP server command is:
dpawb-mcpIf you are working in a restricted environment, the package is configured to build with setuptools so editable installs do not depend on fetching an extra build backend.
If build isolation or wheel support is unavailable locally, use:
python -m pip install --no-build-isolation -e .In constrained environments where editable installation is blocked by local Python packaging tooling, the repository still supports a repo-native execution path:
./scripts/run-local.sh capabilities
./scripts/test-local.sh
make smoke
make test
make validateMinimal local MCP runtime command:
python -m dpawb.mcp_serverdpawb assess --profile fixtures/profiles/synthetic_evolution_latest.yaml
dpawb coverage --profile fixtures/profiles/synthetic_evolution_latest.yaml --use-case fixtures/use_cases/product_identity_lookup.yaml
dpawb compare --left left_assessment.json --right right_assessment.json
dpawb recommend-composition --left left_assessment.json --right right_assessment.json --comparison comparison_result.json
dpawb summarize --result comparison_result.json --format markdown
dpawb capabilitiesBefore wiring PyPI CI/CD, run the local packaging check in an environment with wheel available:
make release-checkThis builds a wheel and sdist, installs the wheel into a clean temporary environment, and runs installed CLI smoke checks.
There are two distinct input areas in this repository:
fixtures/
Synthetic, repository-local test data only.
These files are used by tests, smoke checks, and CI validation.
examples/01-source-ingestion/
Live-source example inputs intended for manual runs.
These are the first step in the tutorial progression and are not part of CI validation.
The full examples tree is organized by analytical task, not by input data model:
examples/01-source-ingestion/
Load and assess declared profiles.
examples/02-structural-comparison/
Compare two profile assessment results.
examples/03-reduced-use-case-comparison/
Run the first aligned use-case comparison.
examples/04-extended-use-case-comparison/
Run a broader aligned use-case comparison.
examples/05-composition-recommendation/
Recommend a combined profile from two assessed model sets.
Each example is usable by humans as a step-by-step command tutorial and by AI agents as a deterministic recipe over explicit files.
Example profiles for live SHACL sources are included at:
examples/01-source-ingestion/profiles/battery_dpp_representation_live.yaml
examples/01-source-ingestion/profiles/battery_product_identification_live.yaml
examples/01-source-ingestion/profiles/dp_record_metadata_live.yaml
examples/01-source-ingestion/profiles/traceability_and_life_cycle_events_live.yaml
examples/01-source-ingestion/profiles/metadata_focused_composition_live.yaml
examples/01-source-ingestion/profiles/metadata_and_traceability_live.yaml
examples/02-structural-comparison/profiles/metadata_slice_left_live.yaml
examples/02-structural-comparison/profiles/metadata_slice_right_live.yaml
If you want a single live source, the metadata-oriented example is the main starting point:
./scripts/run-local.sh assess --profile examples/01-source-ingestion/profiles/dp_record_metadata_live.yamlIf you want a composed profile, use:
./scripts/run-local.sh assess --profile examples/01-source-ingestion/profiles/metadata_and_traceability_live.yamlYou can also run the traceability-only example:
./scripts/run-local.sh assess --profile examples/01-source-ingestion/profiles/traceability_and_life_cycle_events_live.yamlFor manual coverage runs, example use cases are included at:
examples/01-source-ingestion/use_cases/battery_dpp_representation.yaml
examples/01-source-ingestion/use_cases/battery_product_identification.yaml
examples/01-source-ingestion/use_cases/battery_passport_metadata_and_classification.yaml
examples/01-source-ingestion/use_cases/record_identity_lookup.yaml
examples/01-source-ingestion/use_cases/provenance_actor_lookup.yaml
Example:
./scripts/run-local.sh coverage \
--profile examples/01-source-ingestion/profiles/dp_record_metadata_live.yaml \
--use-case examples/01-source-ingestion/use_cases/record_identity_lookup.yamlThe main real comparison-driver use case is:
examples/01-source-ingestion/use_cases/battery_dpp_representation.yaml
It intentionally stays narrow. It requires:
passport identity
battery identity
passport version or revision
one responsible actor
one battery type or classification signal
and the joins needed to treat those as one battery-DPP representation slice.
The matching starting composition for that use case is:
examples/01-source-ingestion/profiles/battery_dpp_representation_live.yaml
It currently composes:
dp_record_metadata
traceability_and_life_cycle_events
This is the current broader baseline for the battery-DPP comparison work.
For the first reduced real pass, the narrower identity-focused comparison slice is:
canonical example folder:
examples/03-reduced-use-case-comparison/
use case:
examples/03-reduced-use-case-comparison/use_cases/use_case.yaml
left profile:
examples/03-reduced-use-case-comparison/profiles/left_profile.yaml
right profile:
examples/03-reduced-use-case-comparison/profiles/right_profile.yaml
This reduced slice composes:
dp_record_metadata
product_profile
traceability_and_life_cycle_events
and is the first validated product-identification comparison slice against the BatteryPass General Product Information model.
A second broader validated slice is also included:
canonical example folder:
examples/04-extended-use-case-comparison/
use case:
examples/04-extended-use-case-comparison/use_cases/use_case.yaml
left profile:
examples/04-extended-use-case-comparison/profiles/left_profile.yaml
right profile:
examples/04-extended-use-case-comparison/profiles/right_profile.yaml
This slice adds passport version/revision and battery type/classification while keeping the same CE-RISE composed model set.
The two current cross-ecosystem validation notes are:
examples/03-reduced-use-case-comparison/notes/comparison_note.md
examples/04-extended-use-case-comparison/notes/comparison_note.md
The step-by-step user reference for these examples is in the published example applications guide.
For manual comparison runs, a comparison-ready live pair is included with the same declared scope label:
examples/02-structural-comparison/profiles/metadata_slice_left_live.yaml
examples/02-structural-comparison/profiles/metadata_slice_right_live.yaml
examples/02-structural-comparison/alignments/metadata_slice_alignment.yaml as a starting-point alignment example
Typical flow:
./scripts/run-local.sh assess --profile examples/02-structural-comparison/profiles/metadata_slice_left_live.yaml --output /tmp/left.json
./scripts/run-local.sh assess --profile examples/02-structural-comparison/profiles/metadata_slice_right_live.yaml --output /tmp/right.json
./scripts/run-local.sh compare --left /tmp/left.json --right /tmp/right.jsonWith an explicit analyst-authored alignment:
./scripts/run-local.sh compare \
--left /tmp/left.json \
--right /tmp/right.json \
--alignment examples/02-structural-comparison/alignments/metadata_slice_alignment.yamlWhen an alignment file is provided, the comparison result now includes two alignment-oriented views:
evaluated_pairs
Full per-pair presence status for every declared equivalence.
ranked_alignment_observations
Review-oriented gaps for any declared pair that is only present on one side or missing on both sides.
So the main things to inspect in an alignment-aware comparison result are:
alignment_coverage_ratio
evaluated_pairs
ranked_alignment_observations
If that comparison result is then passed into prioritize, those alignment gaps can also appear directly as ranked improvement targets.
The current analytical core is still conservative by design, but it now goes beyond token matching alone:
contradiction detection covers direct cardinality conflicts and datatype-versus-object-reference conflicts
item coverage uses SHACL path, owner-shape, and target-class evidence
join coverage can be satisfied by a shared owner shape, an explicit cross-shape object-reference path, or record-level retrieval context when that is the intended analytical interpretation
src/dpawb/: package, CLI, and analytical operations
src/dpawb/data/: bundled schemas, vocabularies, and templates
fixtures/: synthetic repository-local models, profiles, use cases, and alignments for tests only
examples/01-source-ingestion/: source-ingestion profiles, use cases, and alignments for manual runs
examples/03-reduced-use-case-comparison/: self-contained aligned use-case comparison examples
examples/05-composition-recommendation/: self-contained composition recommendation example
scripts/: repo-native execution and test helpers
.github/workflows/validate.yml and .forgejo/workflows/validate.yml: CI validation via the repo-native path
Licensed under the European Union Public Licence v1.2 (EUPL-1.2).
This repository is maintained on Codeberg — the canonical source of truth. The GitHub repository is a read mirror used for release archival and Zenodo integration. Issues and pull requests should be opened on Codeberg.
Funded by the European Union under Grant Agreement No. 101092281 — CE-RISE.
Views and opinions expressed are those of the author(s) only and do not necessarily reflect those of the European Union or the granting authority (HADEA).
Neither the European Union nor the granting authority can be held responsible for them.
© 2026 CE-RISE consortium.
Licensed under the European Union Public Licence v1.2 (EUPL-1.2).
Attribution: CE-RISE project (Grant Agreement No. 101092281) and the individual authors/partners as indicated.
Developed by NILU (Riccardo Boero — ribo@nilu.no) within the CE-RISE project.
Assess one composition profile and return one assessment_result document.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | Local path to one composition profile YAML file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states it returns a document but does not explain side effects, permissions, or other behavioral traits. Insufficient for a tool with no annotations.
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?
The description is extremely short with no wasted words, but it is too terse to be fully informative. It effectively front-loads the core purpose but lacks depth.
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?
Given the simplicity (1 simple parameter, no output schema), the description minimally covers the essentials. However, it does not explain the return document or any side effects, leaving gaps for a new user.
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 coverage is 100% with a clear description of the 'profile' parameter. The tool description adds no additional meaning beyond the schema, so baseline score of 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 clearly states the verb 'assess' and the resource 'composition profile', and specifies a single document return. It distinguishes from siblings like 'coverage' or 'compare' by focusing on assessing one profile, but lacks explicit differentiation.
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?
No guidance on when or when not to use this tool. No mention of prerequisites, alternatives, or typical use cases. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the deterministic command and artifact capability catalog.
| 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 must carry the full burden of behavioral disclosure. It only describes the return value, not side effects, auth requirements, or any other behavioral traits.
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?
The description is a single, concise sentence with no superfluous words. It front-loads the core purpose effectively.
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?
Given the tool's simplicity (no parameters, no output schema), the description is minimally adequate but lacks details on what the 'capability catalog' contains or how it relates to sibling tools.
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?
With zero parameters and 100% schema description coverage, the description adds no param info, which is acceptable. Baseline score of 4 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?
The description clearly states the action ('Return') and the resource ('deterministic command and artifact capability catalog'). It distinguishes from siblings like 'coverage' and 'compare' by focusing on capabilities.
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?
No explicit guidance on when to use this tool versus alternatives is provided. However, the simple nature of the tool (zero parameters) makes the purpose self-evident, earning a baseline score for adequacy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare exactly two assessment_result documents and optionally apply an analyst-authored alignment file.
| Name | Required | Description | Default |
|---|---|---|---|
| alignment | No | Optional local path to one alignment YAML file. | |
| left_assessment | Yes | Local path to the left assessment_result JSON document. | |
| right_assessment | Yes | Local path to the right assessment_result JSON document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is read-only, what side effects occur, or if special permissions are needed. The optional alignment file context is mentioned but no behavioral constraints are given.
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?
A single, well-structured sentence that front-loads the core action. Every word adds value; no redundancy or fluff.
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 a simple comparison tool without output schema, the description covers the basic operation. However, it omits what the output or result looks like (e.g., diff, pass/fail), which could be important for the agent to use correctly.
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%, but the description adds beyond schema by specifying 'exactly two' assessments and that the alignment file is optional and 'analyst-authored'. This gives practical meaning to the parameters.
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 clearly states the verb 'compare' and the resource 'assessment_result documents', specifying 'exactly two'. It also mentions an optional alignment file. However, it does not differentiate from sibling tools like 'coverage' or 'assess', leaving potential ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or when not to use it. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess one use case against one composition profile and return one coverage_result document.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | Yes | Local path to one composition profile YAML file. | |
| use_case | Yes | Local path to one use-case YAML file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the return type ('coverage_result document') but lacks any mention of side effects, permissions required, or whether the operation is read-only. The description could also benefit from noting if the assessment modifies any files or state.
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?
The description is a single, concise sentence that front-loads the essential information. Every word serves a purpose without redundancy or 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?
Given that there is no output schema, the description mentions the return value ('coverage_result document') but does not elaborate on its structure or fields. The tool is simple with two string parameters, so the description is mostly adequate, but a bit more detail on the output would improve completeness.
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 input schema covers 100% of parameters with descriptions, so the description adds no extra meaning beyond 'local path to YAML files'. A score of 3 is appropriate as the schema already handles the parameter documentation adequately.
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 clearly states the verb 'Assess' and the specific resources: 'one use case' against 'one composition profile'. It explicitly mentions the return of 'one coverage_result document', which distinguishes it from sibling tools like 'compare' or 'prioritize' that have different purposes.
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?
The description implies usage when needing to assess coverage of a use case against a profile, but provides no explicit guidance on when not to use it or alternatives among the sibling tools. For example, it does not clarify when one should use 'assess' versus 'compare' or 'recommend_composition'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank improvement targets from one assessment_result document plus optional downstream result documents.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | No | Optional list of local coverage_result JSON document paths. | |
| assessment | Yes | Local path to one assessment_result JSON document. | |
| comparison | No | Optional local path to one comparison_result JSON document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states a ranking operation but does not disclose whether it depends on external state, has side effects, requires permissions, or returns a specific format. Minimal transparency beyond the basic action.
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?
Single sentence, front-loaded with verb and resource, no redundant information. Every word earns its place.
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 a tool with 3 parameters and no output schema, the description covers the main action but omits output format or behavior (e.g., does it return a ranked list?). Sibling differentiation is absent, which reduces completeness.
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 coverage is 100% with each parameter described. The description adds conceptual context by linking 'assessment_result document' and 'downstream result documents' to the parameters, but doesn't provide additional meaning beyond the schema. 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 clearly states the action ('rank') and the resource ('improvement targets from assessment_result documents'). It distinguishes from siblings like 'coverage' and 'compare' by specifying this is a prioritization step. However, the term 'downstream result documents' is vague and doesn't explicitly map to the optional parameters coverage and comparison.
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?
No explicit guidance on when to use this tool versus alternatives like 'assess' or 'compare'. The description implies it follows assessment but doesn't provide when-not or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend a deterministic combined composition from two assessment results.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | No | Optional list of local coverage_result JSON document paths. | |
| comparison | No | Optional local path to one comparison_result JSON document. | |
| left_assessment | Yes | Local path to the left assessment_result JSON document. | |
| right_assessment | Yes | Local path to the right assessment_result JSON document. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'deterministic' but omits details on side effects, idempotency, error conditions, or required permissions. The description is too brief to adequately convey behavioral traits.
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?
The description is a single, concise sentence that front-loads the key action. While it lacks bullet points or structured formatting, every word serves a purpose and there is no redundancy. Could provide more detail without being verbose.
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?
Given the tool has 4 parameters and no output schema, the description is insufficiently complete. It does not explain return values, validation rules, or how this tool fits into the workflow with siblings like 'coverage' and 'compare'. More context is needed for effective agent use.
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 coverage is 100% with clear descriptions for each parameter. The tool description adds no extra semantic value beyond aligning 'two assessment results' with the required parameters. Baseline score of 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 clearly states the tool recommends a deterministic combined composition from two assessment results, specifying the verb (recommend), resource (composition), and required inputs (two assessment results). It effectively distinguishes from sibling tools like 'compare' and 'assess' by focusing on composition.
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?
The description does not provide any guidance on when to use this tool versus alternatives like 'compare' or 'prioritize'. It only implies usage when two assessment results are available, but lacks explicit when-to-use, when-not-to-use, or alternative contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one bundled JSON Schema.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the basic function. It does not disclose error behavior, authentication needs, or read-only nature. For a tool with no annotations, this is insufficient transparency.
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?
The description is one short sentence, which is concise, but it sacrifices necessary detail. It is appropriately front-loaded but incomplete.
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?
Given one parameter with nine enum values and no output schema or annotations, the description is too brief. It does not explain what each name returns or the format of the JSON Schema. The tool is not fully documented.
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 0%, but the description does not mention the 'name' parameter at all, despite it being required with an enum. The description adds no meaning beyond the 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?
The description 'Return one bundled JSON Schema.' clearly states the verb (Return) and resource (bundled JSON Schema). However, 'bundled' is ambiguous, and it does not explicitly connect to the parameter 'name' which selects which schema. It distinguishes from sibling tools that perform different operations.
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?
No guidance on when to use this tool versus alternatives. Sibling tools like coverage, compare, etc., are not mentioned. No context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create one deterministic summary_result document from one or more existing result JSON documents.
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | One or more local paths to result JSON documents. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'deterministic' but lacks details on side effects, permissions, or what the summary contains. For a mutation tool, more transparency is needed.
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?
The description is a single sentence of 14 words, efficiently conveying the purpose without unnecessary detail. It is front-loaded and every word serves a purpose.
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 and no annotations, the description minimally explains input but omits details on the output structure or behavior. Given the low complexity, it is adequate but could be improved by describing what the summary contains or its format.
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 parameter 'result' is an array of strings with schema description. The description adds context that it expects 'result JSON documents', which goes beyond the schema's 'local paths to result JSON documents' by specifying the type of documents. This adds meaningful semantic value.
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 clearly states the tool creates a deterministic summary_result document from one or more result JSON documents, specifying the verb 'create', the resource 'summary_result document', and the inputs. It distinguishes from sibling tools like 'compare' or 'prioritize' by focusing on summarization.
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?
The description implies usage for combining multiple result documents into a summary but does not explicitly state when to use this tool versus alternatives like 'coverage' or 'compare'. No guidance on when not to use or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one bundled YAML template document.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits (e.g., read-only, error handling, side effects). For a retrieval tool, it does not state if it modifies state or requires specific permissions.
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?
The description is concise (one sentence) and front-loaded, but it sacrifices necessary detail. It is not overly verbose, but the extreme brevity undermines its usefulness.
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?
Given the low complexity (one enum parameter, no output schema), the description should still explain what templates are and how the 'name' parameter selects them. It is incomplete for effective tool use.
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 description does not mention the 'name' parameter or its enum values ('profile', 'use_case', 'alignment'). With 0% schema description coverage, the agent gets no additional meaning beyond the raw schema, which is insufficient for correct invocation.
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 clearly states the verb 'Return' and the resource 'one bundled YAML template document', making the basic purpose understandable. However, it does not differentiate from sibling tools like 'schema' or 'vocabulary', which could also return documents.
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?
No guidance is provided on when to use this tool versus its siblings (e.g., 'schema', 'coverage'). The description lacks context for selection, such as prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one bundled controlled vocabulary document.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it returns a document, but omits behavioral traits like idempotency, side effects, or error handling. No disclosure of read-only nature or permission 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?
The description is very concise (one sentence) and front-loaded with the action 'Return'. However, it sacrifices informativeness for brevity.
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 a tool with one parameter, no annotations, and no output schema, the description is insufficient. It lacks details about return structure, possible values, and usage context.
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 0%. The description does not explain the meaning of the parameter 'name' or its enum values ('item_categories', 'join_kinds'). It adds no semantic value beyond the raw 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?
The description clearly states the verb 'Return' and the resource 'bundled controlled vocabulary document'. It specifies the tool's purpose, but does not differentiate from sibling tools like 'coverage' or 'compare'.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or comparison to sibling tools.
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. Dates show when Glama detected each change.
v0.1.2assesscapabilitiescomparecoverageprioritizerecommend_compositionschemasummarizetemplatevocabularyMost tools have distinct purposes, but coverage and assess could be confused as they both produce assessment-related results; however, their inputs differ (use case vs composition profile). Overall clear.
Tool names are a mix of verbs (compare, prioritize, assess) and nouns (coverage, schema, vocabulary), with one snake_case verb_noun (recommend_composition). No consistent pattern.
10 tools is appropriate for a specialized assessment toolkit; not too many or too few.
Missing basic CRUD for profiles or results (e.g., no get_result, delete_result), but the core assessment workflow (assess, compare, prioritize, recommend, summarize) is covered. Minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Command your AI agents: verifiable passports, credential injection, full audit, revoke in 60s.
Governance maturity assessment, compliance gap analysis, and evidence-linked briefs for AI agents.
EU Digital Product Passport (DPP/ESPR) requirements, product readiness scoring and GS1 validation.
EUDI Wallet MCP — EU Digital Identity Wallet under eIDAS 2.0 for AI agent authentication via
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CE-RISE-software/dp-assessment-workbench'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
