aris-mcp

Aris Export Aml

aris_export_aml

Read-onlyIdempotent

Export a specified model from the current ARIS repository as AML text using its model ID.

Instructions

Export one model of the current repository as AML text.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model_id": "<model_id>"
    },
    "name": "aris_export_aml"
  }
}

Input Schema

Name	Required	Description	Default
`model_id`	Yes	Model GUID (or AML Model.ID).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 7, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds the format context (AML text) and single-model scope, but says nothing about whether the result is inline text or a file artifact, or about repository-state dependencies.

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?

A single short sentence with no wasted words and the key constraint ('one model', 'current repository') front-loaded. It is efficient rather than padded, though the terseness leaves gaps elsewhere.

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 simple one-parameter read tool with annotations and an output schema, little more is strictly required. Still, the definition does not clarify the distinction from the canonical-workflow export sibling or what the returned AML text represents, leaving a modest gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so model_id is fully documented in the schema (including the AML Model.ID alternative). The description adds no additional meaning about identifier format or resolution beyond what the schema provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (export) and resource (one model), plus the output format (AML text) and the scoping qualifier 'current repository'. This contrasts adequately with aris_import_aml and aris_export_canonical_workflow, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this over aris_export_canonical_workflow or aris_get_model, and no prerequisites or exclusions are stated. Usage is only inferable from the tool name and the word 'export'.

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

Deploy Server