Skip to main content
Glama
mm6502

Enterprise Architect MCP Server

by mm6502

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
EA_LOCALENoBCP 47 locale tag (e.g., 'sk', 'pl', 'hu', 'de') used for locale-aware name ordering in ea_get_scenarios. Defaults to the host system locale.
EA_QEA_PATHNoPath to the .qea file (or directory containing the newest .qea file) to open. If not provided, the server will prompt for a path when first queried.
EA_MCP_CONFIG_DIRNoDirectory where the server stores remembered answers and configuration. Defaults to platform-specific application data directory.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
ea_searchA

Search Enterprise Architect model elements by name, alias, notes, attribute names/notes, operation names/notes, or constraint notes. Matching is case- and diacritic-insensitive across European Latin alphabets and sees through entity-encoded text. requiredTerms is a list of terms every one of which must occur somewhere in an element's searchable text (conjunction) — terms need not share a field, but sharing one ranks higher; each term is matched as a contiguous substring exactly as a single term is, so a term carrying whitespace is a phrase and is never split. A one-entry list behaves exactly as a single search term always has. boostAnyOf is an optional list of further terms: a result also matching at least one of them ranks ahead of one that does not, but nothing is ever excluded on that basis — for narrowing to only elements matching an alternative too, use ea_search_and_any_of instead. When no element matches, termMatches reports, per supplied term, whether that term matched anywhere in the corpus at all — so a caller can tell which term emptied the result rather than re-guessing the whole call. Matching elements are returned in results, strongest match first, each with a decoded note preview and a truncation flag; equally strong matches fall back to the model's internal identity, a stable but artificial order. Each result also carries matches, the evidence for why it was returned: the field that matched, the id and name of the attribute, operation or constraint it came from, and a snippet of the author's own text around the match. Evidence is strongest-first and capped, and _meta.matches on the result reports how many matches were found and how many were withheld. The note preview centres on the match when the element's own note is what matched. packageScope restricts results to a package (given as its id or its name) and its descendants. Walk a large result set with offset rather than a larger limit; while rows remain, continuation names the next call. When far more elements match than one window can hold, breakdown reports how they distribute — by objectType, stereotype, or, unless already scoped, by packageScope (reported as the matching package's id, which the next call can pass straight back) — so the next call can narrow instead of paging.

ea_search_and_any_ofA

Search Enterprise Architect model elements the same way ea_search does, plus andAnyOf: a required-and-alternative filter. requiredTerms still works exactly as it does on ea_search (conjunction, contiguous substring, terms need not share a field). andAnyOf is an optional list of further terms; when supplied, a result must contain requiredTerms AND at least one andAnyOf term, so it can only ever narrow — it never returns a result requiredTerms alone would not. An empty andAnyOf array applies no filter. For promoting rather than narrowing, use ea_search instead, which offers the same alternatives idea as a rank boost. When no element matches the required terms at all, termMatches reports, per supplied term, whether it matched anywhere in the corpus. Matching elements are returned in results, strongest first, each with a decoded note preview, a truncation flag, and matches — the evidence for why it was returned, capped and strongest-first, with _meta.matches reporting how many were found and withheld. packageScope restricts results to a package and its descendants. Walk a large result set with offset; while rows remain, continuation names the next call. When far more elements match than one window can hold, breakdown reports how they distribute by objectType, stereotype, or packageScope.

ea_get_elementA

Get full details of an Enterprise Architect element by its ID, including its Note, attributes, operations, the diagrams it appears on, and its constraints. Attribute multiplicity supports a requiredness inference only when the element uses multiplicities contrastively; read _meta.attributes.multiplicityIsUniform before making that inference — when it is true the element's attributes carry no multiplicity contrast, so a value like 1..1 is not evidence of requiredness. Attributes and operations are capped inline: attributesTruncated/operationsTruncated say whether the returned list is partial, and attributesTotal/operationsTotal give the full counts, so never infer a count from the inline list alone.

ea_list_elementsA

List elements within a package, optionally filtered by object type. elements is a lightweight list (ID, type, name, alias, stereotype), grouped by element type and then ordered by the model's internal identity. That order is stable but artificial — neither alphabetical nor the analyst's tree order — so adjacency carries no meaning. Walk a large package with offset rather than a larger limit; while rows remain, continuation names the next call. When far more elements match than one window can hold, breakdown reports how many each type holds, so the next call can narrow by objectType instead of paging.

ea_get_connectorsA

Get all relationships (connectors) for a given element. connectors lists what the element is connected to and how (Realisation, Dependency, Association, etc.), each entry naming its source and dest ends. For Generalization connectors, source is always the specific (child) type and dest the general (parent) type — each end also carries a role making this explicit without needing to reason about direction. Filter by connectorType and direction to list an element's direct children (incoming Generalization) or direct parent(s) (outgoing Generalization) without a diagram. Feature links show which specific attribute or operation each end attaches to.

ea_get_package_treeA

Navigate the package hierarchy. Without parameters, returns top-level packages. With a packageId, returns that package's children up to the specified depth. Each node carries id, name, parentId, and elementCount.

ea_get_diagram_elementsA

Get all elements and connectors placed on a specific diagram: the diagram itself, plus elements and connectors. elements already includes free-text Note diagram objects, which often carry a legend or abbreviation definitions an agent would otherwise miss. Connectors include feature-link resolution showing which attribute or operation each end attaches to. The connector list is the union of explicit t_diagramlinks rows and implied connectors (both ends on the diagram).

ea_list_diagramsA

List diagrams in the model, optionally filtered by package, diagram type, and/or name substring. Each entry in results carries diagramId, name, type, packagePath, and eaGuid. Diagrams are ordered by the model's internal identity — stable but artificial, neither alphabetical nor the analyst's tree order — so adjacency carries no meaning. Walk a large result set with offset rather than a larger limit; while rows remain, continuation names the next call. When far more diagrams match than one window can hold, breakdown reports how many each type holds, so the next call can narrow by diagramType instead of paging.

ea_get_scenariosA

Get use case scenario flows for an element. scenarios holds the parsed flows; each has name, type, notes, and steps, and each step carries stepNumber plus its attributes (trigger, uses, result, state, link). Steps are numbered within each scenario. Scenarios ordered by type: Basic Path first, then Alternate, then Exception. A step's uses may name a business rule or constraint by code; that code is not independently searchable or resolvable — look it up among this same elementId's own constraints via ea_get_element, not by a separate lookup.

ea_get_schemaA

List the model's database tables in tables, or pass a tableName to get that table's columns and indexes instead. That form echoes the table name and adds rowidAlias — the INTEGER PRIMARY KEY aliasing SQLite's rowid, so the fastest lookup path, or null when the table has none — with rowidNote saying which case applies. Use this to discover what data the model holds beyond what the typed ea_* tools return. See ea_get_model_info for the export's identity.

ea_get_model_infoA

Report which .qea export file the server has open: fileName is the citable identity, alongside fileSizeBytes, lastModified, and the serverVersion that produced the answer. The full local path is also returned as resolvedPath, with resolvedPathNote explaining why it is environment detail rather than something to cite. configuration says where that path came from — source in words, sourceId as one of argument/environment/dotenv/remembered/prompt, and the configured value behind it — plus any skipped settings, each with the reason it could not be opened, and shadowed ones a higher-priority source outranked; configurationNote says how much of that is safe to repeat.

ea_resolveA

Resolve an analyst reference (braced GUID or plain name) to model candidates: the input is echoed as reference and the hits are in candidates. A braced GUID is matched exactly. A plain name is matched against the full name first; only if nothing matches exactly is the reference retried as a name prefix, which resolves analyst codes like UC_ABC_2079 or OA_ABC_2280 to elements named 'CODE: description'. An exact hit is returned alone and is never diluted by prefix hits. Each candidate reports its type (element, diagram, package), id, name, fullPackagePath, eaGuid, and a match field that is always present with value "guid", "exact", or "prefix" — a "prefix" candidate is an inexact match and must not be treated as a confirmed identity. Use the optional kind filter to narrow results.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 12 tools

Disambiguation4/5

Most tools map cleanly to distinct actions and resources: get vs list vs search vs resolve are easy to separate, and the descriptions carefully explain each tool's role. The only real ambiguity is between ea_search and ea_search_and_any_of, which are near-duplicates differing only in how alternatives are applied, and ea_resolve can overlap with search in intent.

Naming Consistency5/5

All tools share the ea_ prefix and use snake_case with a consistent verb-first style: get_, list_, search_, and resolve. ea_search_and_any_of is the only name that breaks the simple verb_noun shape, but it is a coherent extension of the existing search name rather than a convention violation.

Tool Count5/5

Twelve tools is well within the ideal range and each tool serves a distinct read-only exploration workflow: navigation, element detail, search, diagrams, connectors, scenarios, schema, and model info. The count feels deliberate rather than bloated, and no tool appears redundant enough to remove.

Completeness4/5

The read-only Enterprise Architect model surface is well covered: package hierarchy, element details, search, relationship and diagram retrieval, scenarios, schema discovery, and model identity are all present. Minor gaps exist, such as package-level details beyond tree metadata and certain EA extension data like tagged values, but the core exploration workflows have no dead ends.

Maintenance

ActivityNo data
ResponsivenessNo issues