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., "@Allotrope MCP Server list all available ASMs"
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 Model Context Protocol (MCP) server that provides tools for working with Allotrope Simple Model (ASM) data formats. This server enables AI assistants to validate instrument data files against ASM schemas and discover available ASMs.
Allotrope is a data standards framework for laboratory and analytical instrument data. The Allotrope Simple Model (ASM) provides a standardized JSON format for representing instrument data, making it easier to integrate, analyze, and share scientific data across different systems and organizations.
Related MCP server: iso20022-mcp
This MCP server provides the following tools:
describe_asm: Retrieve full metadata for a specific ASM model by name, including its description, manifest URL, JSON schema URL, and data instance example URLs
fetch_asm_document: Download a raw ASM JSON document from purl.allotrope.org to the local filesystem at a path mirroring the URI structure
list_asms: List all available Allotrope Simple Models (ASMs) with their descriptions from a bundled reference file
validate_asm_schema: Validate ASM JSON documents against their corresponding JSON schemas to verify data compliance
validate_field_map: Validate a field mapping file produced by a custom converter script, comparing source values against ASM values to confirm data integrity
Python 3.10 or higher
uv package manager
Add the following configuration to your MCP client to download and install the server.
{
"mcpServers": {
"allotrope-mcp-server": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/aws-samples/sample-laboratory-data-transformation-mcp.git",
"allotrope-mcp-server"
],
"disabled": false,
"autoApprove": [],
"disabledTools": []
}
}
}# Clone the repository
git clone <your-repo-url>
cd allotrope-mcp-server
# Install dependencies
uv sync
# Run the server
uv run allotrope-mcp-serversequenceDiagram
participant Client as MCP Client<br/>(AI Assistant / IDE)
participant Server as allotrope-mcp-server<br/>(FastMCP / stdio)
participant FS as Local Filesystem
participant Ref as model_reference.json<br/>(bundled)
participant PURL as purl.allotrope.org<br/>(HTTPS)
Note over Client,Server: Trust Boundary: stdio (no auth)
Client->>Server: list_asms()
Server->>Ref: read model_reference.json
Ref-->>Server: ASM name → description map
Server-->>Client: JSON result
Client->>Server: describe_asm(model_name)
Server->>Ref: lookup model_name
Ref-->>Server: metadata (URIs, description)
Server-->>Client: JSON result
Client->>Server: validate_asm_schema(asm_document_path, asm_schema_path)
Note over Server,FS: Path traversal risk (T1) — sanitised by M1
Server->>FS: read asm_document_path
FS-->>Server: ASM JSON document
Server->>FS: read asm_schema_path
FS-->>Server: JSON Schema
Server->>Server: validate document against schema
Server-->>Client: validation result
Client->>Server: fetch_asm_document(asm_document_uri, output_dir)
Note over Server: URI prefix check (PURL_ORIGIN allowlist — A002)
Note over Server,PURL: TLS encrypted (CN001) — MitM risk (T5)
Server->>PURL: GET asm_document_uri (HTTPS)
PURL-->>Server: ASM JSON document
Note over Server,FS: Arbitrary write risk (T2) — sanitised by M1
Server->>FS: write to output_dir/<path>
Server-->>Client: saved file pathThis repo includes a Kiro Power in the power-instrument-data-to-allotrope/ folder. The power bundles the MCP server configuration and a guided workflow for converting laboratory instrument data into valid ASM JSON.
Open Kiro and go to the Powers panel (click the Powers icon in the sidebar, or run View: Show Powers from the command palette).
Click Add Custom Power and then Import power from a folder. Select the power-instrument-data-to-allotrope/ directory from this repo.
Kiro will register the allotrope-mcp-server MCP server automatically using the bundled mcp.json.
Once installed, open a new chat and type / to browse available powers. Select Instrument Data to Allotrope and provide:
input_path — path to your instrument data file
asm_model — the target ASM model name (e.g. plate-reader)
output_path (optional) — destination for the generated ASM JSON (defaults to <input_path>.asm.json)
Kiro will guide you through schema discovery, data parsing, code generation, and validation against the ASM schema.
The repo also includes an Agent Skill at .agents/skills/instrument-data-to-allotrope/SKILL.md. Skills follow an open standard and can be imported into Kiro (or any compatible AI tool) independently of the Power.
Note: The skill requires the
allotrope-mcp-serverMCP server to be connected. Use the Power (above) to configure it automatically, or add the server manually via the MCP settings.
Once configured in Kiro, you can use natural language to interact with the tools:
"List all available ASMs"
"Describe the plate-reader ASM model"
"Validate this ASM document against the plate reader schema"
"Check if my instrument data file is valid ASM format"
"Fetch the plate reader embed schema document to my project"
You: Validate tests/testdata/plate_reader_weyland_yutani_valid.json
against tests/testdata/plate_reader.embed.schema.jsonKiro will use the validate_asm_schema tool to check the document and report any validation errors.
You: Download the plate reader schema document to my projectKiro will use the fetch_asm_document tool to download the raw JSON document from purl.allotrope.org and save it locally at a path that mirrors the URI structure.
Returns the full metadata for a specific ASM model by name. Looks up the model in the bundled model_reference.json and returns its description, manifest URL, JSON schema URL, and data instance example URLs as a JSON string.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | The ASM model identifier to look up (e.g., |
Returns: A JSON object with the model metadata on success, or an object with an error key and a valid_model_names list if the model name is not recognised.
Example response (success):
{
"description": "...",
"asm_manifest": "http://purl.allotrope.org/manifests/...",
"asm_json_schema": "http://purl.allotrope.org/json-schemas/...",
"asm_data_instance_examples": ["http://purl.allotrope.org/test/..."]
}Downloads a raw ASM JSON document from the Allotrope PURL repository (purl.allotrope.org) and saves it to the local filesystem at a path that mirrors the URI structure. $ref references are not resolved — the document is saved exactly as received.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Fully-qualified URI starting with |
| string | No | Base directory for saving the document. Defaults to the current working directory. |
Behavior:
Rejects URIs that do not start with http://purl.allotrope.org (case-sensitive) — no network call is made on rejection
If the file already exists at the derived local path, returns the path immediately without re-downloading
Downloads the document and validates it is well-formed JSON before writing
Creates parent directories as needed and saves the document as UTF-8 JSON with 2-space indentation
Returns a JSON object with a path key on success, or an error key on failure
Example response (success):
{"path": "/absolute/path/to/json-schemas/adm/plate-reader/REC/2025/12/plate-reader.embed.schema"}Lists all available Allotrope Simple Models (ASMs) with their descriptions. Reads from the bundled model_reference.json file and returns a mapping of ASM IDs to descriptions.
Parameters: None
Returns: A JSON object mapping ASM identifiers to their descriptions, or an error key on failure.
Validates an ASM JSON document against its corresponding JSON schema.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Path to the ASM JSON document to validate |
| string | Yes | Path to the ASM JSON schema to validate against |
Validates a field mapping file produced by a custom converter script. Reads the JSON file and compares each entry's source_value against its asm_value using string equality (primary) and numeric float equality (fallback). Returns a structured result with match counts, mismatches, and a summary message.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Path to the field mapping JSON file (the |
Returns: A JSON object with matched, total, mismatches, and message keys on success, or an error key on failure.
Example response (all match):
{
"matched": 19,
"total": 19,
"mismatches": [],
"message": "The conversion script accurately reproduced all 19 field(s) from the raw data file."
}Example response (with mismatches):
{
"matched": 17,
"total": 19,
"mismatches": [
{
"source_field": "Recorded",
"source_value": "2023-10-26:11:15:40",
"asm_field": "measurement time",
"asm_value": "2023-10-26T11:15:40+00:00",
"unit": ""
}
],
"message": "The conversion script needs to be updated to address 2 mismatched field(s)."
}Note: Entries where
asm_valueis an ISO 8601 normalised form ofsource_value(e.g. timestamp conversion) will appear as mismatches. This is intentional — the tool surfaces all value divergences so the developer or AI agent can review whether they are acceptable.
Path traversal protection — validate_asm_schema and fetch_asm_document resolve and sanitise all caller-supplied file paths. Paths that escape the intended working directory are rejected before any file I/O occurs.
HTTPS-only external requests — fetch_asm_document enforces a hard-coded http://purl.allotrope.org URI prefix check. Any URI that does not match this origin is rejected without making a network call.
File size limits — validate_asm_schema enforces a maximum file size before reading documents or schemas into memory, preventing resource exhaustion from oversized inputs.
Recursive schema depth limit — JSON Schema validation caps recursion depth to guard against stack overflow or CPU exhaustion from schemas with circular $ref cycles.
Error message sanitisation — internal filesystem paths and stack traces are stripped from error responses returned to the MCP client.
Securing your local environment — the server runs as a local process with the same filesystem permissions as the invoking user. Ensure your machine, user account, and any Docker container running the server are appropriately hardened.
Validating AI assistant behavior — the server trusts all tool arguments passed by the MCP client without authenticating the caller. A compromised or misbehaving AI assistant could supply malicious file paths or URIs. Review tool invocations in your IDE and treat unexpected calls as suspicious.
Prompt injection awareness — content fetched from purl.allotrope.org or read from local files is returned to the AI assistant. Malicious content in those files could attempt to influence subsequent assistant actions (indirect prompt injection). Only point the server at files and URIs you trust. See Prompt Injection below for details.
Supply chain hygiene — install the package from the official PyPI release and pin dependency versions using uv.lock. Verify that your Python environment has not been tampered with before running the server.
No authentication layer — the MCP stdio interface has no built-in authentication. If you expose the server beyond a local process (e.g. via a network socket), you are responsible for adding appropriate access controls.
The MCP server passes tool arguments supplied by an AI assistant directly to filesystem and network operations. Because the server cannot distinguish a legitimate assistant request from one that has been manipulated by malicious content, all MCP tool arguments must be treated as untrusted input.
Indirect prompt injection can occur when:
A document or schema file read by validate_asm_schema contains embedded instructions that the AI assistant interprets as commands.
A JSON document fetched from purl.allotrope.org by fetch_asm_document contains text that causes the assistant to invoke further tool calls with attacker-controlled arguments.
An AI agent loop passes the output of one tool call as the input path or URI of the next without human review.
Recommended mitigations for MCP client operators:
Review tool invocations before approving them, especially calls that supply file paths or URIs you did not explicitly request.
Avoid chaining tool outputs directly into subsequent tool inputs without inspecting the intermediate content.
Restrict the working directory available to the server so that even a successful path traversal attempt cannot reach sensitive files outside the project.
Treat any unexpected or unsolicited tool call as a potential injection attempt and abort the session.
uv run pytest --cov --cov-branch --cov-report=term-missinguv run ruff check .
uv run ruff format .uv run pyrightThis project is licensed under the MIT-0 license. See the LICENSE file for details.
The Allotrope Foundation® Simple Models (“ASM”) and other data is collectively licensed under three licenses, depending on intended usage and membership status. Please visit https://gitlab.com/allotrope-public/asm/-/blob/main/LICENSE.md for more information.
Return the metadata for a specific ASM model by name.
Args:
model_name: The key identifying the ASM model (e.g. 'automated-reactors').
Returns:
JSON string containing the model metadata on success, or an error object
with the unrecognized name and a list of valid model names on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| model_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the success return value (JSON string) and failure behavior (error object with list of valid names), which is helpful and goes beyond the schema. It does not mention permissions or side effects, but for a read-only describe operation this is acceptable, so 4.
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 and well-structured, with a clear purpose sentence followed by Args and Returns sections. Every part adds value, and it fits in a small space, so 5.
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?
The description is complete for the tool's complexity: it states the purpose, explains the parameter, and explicitly specifies success and failure return formats. The presence of an output schema is not strictly necessary because the returns are described, and the tool is simple, so 5.
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 schema provides only a type and requirement for model_name with no description. The description's Args section adds semantic meaning by labeling it as 'the key identifying the ASM model' and providing an example, which compensates for the 0% schema coverage, so 4.
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 'Return the metadata for a specific ASM model by name,' using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like fetch_asm_document or list_asms, so it earns a 4 rather than 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?
There is no guidance on when to use this tool versus alternatives. The description only explains what it does, not when to choose it over siblings like fetch_asm_document or list_asms, so it scores 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a raw ASM JSON document from purl.allotrope.org.
Downloads the document identified by ``asm_document_uri`` from the Allotrope
PURL repository and saves it to the local filesystem at a path that mirrors
the URI structure. If the file already exists it is returned immediately
without re-downloading. ``$ref`` references are
NOT resolved — the document is saved exactly as received.
Args:
asm_document_uri: Fully-qualified URI starting with
``http://purl.allotrope.org``.
output_dir: Base directory for saving the document. Defaults to the
current working directory when empty.
Returns:
JSON string with a ``path`` key containing the absolute path to the
saved file, or an ``error`` key with a description on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| output_dir | No | ||
| asm_document_uri | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it downloads, saves to a path mirroring the URI, returns a cached result immediately, and does NOT resolve $ref references. This goes beyond basic purpose and is highly transparent about side effects and limitations.
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 well-structured with a one-line summary, followed by details on behavior and parameters. Every sentence adds valuable information without redundancy, and it is front-loaded with the core 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?
Given the tool's complexity (local file write, caching, URI handling) and lack of annotations, the description covers all essential aspects: what it does, how it saves, caching behavior, $ref limitation, parameter formats, and return structure. It is complete for an agent to select and invoke the tool 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 coverage is 0%, so the description must compensate. It does so by explaining asm_document_uri as a fully-qualified URI starting with http://purl.allotrope.org, and output_dir as the base directory defaulting to the current working directory. This adds meaning beyond the bare 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 tool fetches and downloads a raw ASM JSON document from purl.allotrope.org, saving it to the local filesystem. The verb 'Fetch' and resource 'document' are specific, and it distinguishes itself from sibling tools like validate_asm_schema or list_asms by focusing on raw retrieval.
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 provides clear context about when to use the tool (to fetch raw documents) and important caveats (caching, $ref not resolved), but it does not explicitly mention alternatives or when-not-to-use scenarios. The context is strong enough to guide usage without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Allotrope Simple Models (ASMs).
Retrieves ASM identifiers and descriptions from the local
model_reference.json file bundled with the package.
Returns:
JSON string with ASM IDs mapped to descriptions, or an
error key with a description on failure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It reveals that data comes from a local bundled model_reference.json, describes the return format as a JSON string mapping IDs to descriptions, and notes the error-key fallback. This provides a solid behavioral profile for a simple read-only list operation, though it does not explicitly state non-mutating behavior (implied by 'list').
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 compact and front-loaded: a one-sentence summary, a single clarifying sentence about the data source, and a concise Returns block. Every sentence adds value, with 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 parameterless listing tool, the description is complete: it states what is listed, where the data comes from, and what the output looks like including error behavior. The presence of an output schema is not an issue because the description already covers the return value, and no additional context is needed.
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 has zero parameters, so schema coverage is effectively 100%. The description has no parameter details to add, and the baseline of 4 applies because there is nothing to compensate for. No ambiguity exists.
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 opens with a clear, specific verb+resource: 'List all available Allotrope Simple Models (ASMs).' It further clarifies scope by mentioning it retrieves identifiers and descriptions from a local file, and the sibling tool names (validate, fetch, describe) contrast with this listing function.
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 the tool is for enumerating available ASMs and their metadata, but it does not explicitly state when to use this over sibling tools like fetch_asm_document or describe_asm, nor does it mention any exclusions or alternatives. The usage context is clear from the purpose, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an ASM JSON document against an Allotrope JSON Schema.
Args:
asm_document_path: File path to the ASM JSON document.
asm_schema_path: File path to the ASM JSON Schema.
Returns:
JSON string with validation result.
| Name | Required | Description | Default |
|---|---|---|---|
| asm_schema_path | Yes | ||
| asm_document_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | 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 states the tool returns a JSON string with validation result but does not disclose whether the operation is read-only or has side effects, nor any error behavior.
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 compact docstring with clear Args and Returns sections. Every line serves a purpose and there is no redundant text.
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 validation tool with an output schema, the description covers purpose, parameters, and return type. However, it lacks usage context relative to sibling tools, though that is more of a usage guideline issue.
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 adds 'File path to' for both parameters, clarifying that they are file paths beyond the schema's titles. This is minimal but meaningful for a simple two-string 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 'Validate an ASM JSON document against an Allotrope JSON Schema,' using a specific verb and resource. It distinguishes from siblings like validate_field_map which targets a different resource.
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 vs alternatives like validate_field_map or fetch_asm_document. Usage is implied by the description but no alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a field mapping file produced by a custom converter script.
Reads the JSON file at ``field_map_path`` and compares each entry's
``source_value`` against its ``asm_value`` using string equality (primary)
and numeric float equality (fallback). Returns a structured JSON result
with match counts, mismatches, and a summary message.
Args:
field_map_path: File path to the field mapping JSON file.
Returns:
JSON string with ``matched``, ``total``, ``mismatches``, and
``message`` keys on success, or an ``error`` key on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| field_map_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, and it excels. It details the exact comparison logic (string equality primary, numeric float fallback), the file format (JSON), the return structure (match counts, mismatches, summary message), and error handling ('error' key on failure). This gives an agent a comprehensive understanding of the tool's behavior.
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 well-structured with a purpose statement, a detailed behavior section, and an Args/Returns breakdown. It is concise, front-loaded with the core purpose, and every sentence contributes valuable information without redundancy. This is a model of clear, efficient documentation.
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 moderate complexity with one parameter and an output schema, the description provides all essential context: what the tool does, how it operates, what it returns, and error behavior. The presence of an output schema means return values are additionally specified, but the description already covers them. No significant gaps remain.
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%, so the description must explain the parameter, and it does: 'field_map_path: File path to the field mapping JSON file.' This adds meaning beyond the bare schema definition by specifying what the path refers to and that it is a JSON file. While comprehensive for one parameter, it leaves out details like file size limits or path format, so a 4 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 opens with 'Validate a field mapping file produced by a custom converter script,' which clearly specifies the verb (validate) and resource (field mapping file). This distinguishes it from siblings like validate_asm_schema, which validates schemas rather than field maps. The purpose is explicit and unambiguous.
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 provides clear context that this tool is intended for files produced by a custom converter script, indicating when it is appropriate to use. However, it does not explicitly mention alternatives or when not to use it, such as if the user needs to validate an ASM schema (validate_asm_schema). This is a minor omission, hence a 4 rather than 5.
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.0describe_asmfetch_asm_documentlist_asmsvalidate_asm_schemavalidate_field_mapEach tool targets a distinct resource and action: validate_field_map checks field mappings, validate_asm_schema validates an ASM document against a schema, fetch_asm_document downloads a raw ASM document, list_asms enumerates models, and describe_asm provides metadata for a specific model. There is no meaningful overlap in purpose.
All tool names follow a consistent verb_noun pattern with snake_case: validate_field_map, validate_asm_schema, fetch_asm_document, list_asms, describe_asm. The minor difference in singular/plural (asm/asms) is natural and does not create confusion.
Five tools is well within the ideal 3-15 range and each tool serves a clear, non-redundant function. The count feels appropriately scoped for a server focused on ASM validation and metadata retrieval.
The server covers the core workflows of discovering ASM models, fetching documents, validating schemas, and validating field maps. A minor gap is the lack of a tool to fetch schemas directly, but this can be worked around since validate_asm_schema accepts a local schema path.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Schema modeling in JSON, JSON-LD, and other formats with CoreModels platform.
Seven tools over the tabnas parsing engine: parse, validate, diagnose, fixtures, compare.
JSON Schema catalog (SchemaStore.org)
Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aws-samples/sample-laboratory-data-transformation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server