Skip to main content
Glama
mm6502

Enterprise Architect MCP Server

by mm6502

ea_search

Read-only

Search Enterprise Architect model elements by name, notes, attributes, operations, or constraints; get ranked matches with evidence and refine by type, stereotype, or package.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return (default 25)
offsetNoZero-based index of the first result to return (default 0). Page by re-calling with the offset carried in continuation.
boostAnyOfNoTerms that promote a result's rank when also present; never excludes. Use ea_search_and_any_of to narrow instead.
objectTypeNoFilter by object type (e.g., Class, UseCase, Activity, Screen, Requirement, Interface, Component)
stereotypeNoFilter by stereotype
packageScopeNoRestrict results to this package and its descendants, given as a package id or name
requiredTermsYesTerms every one of which must occur somewhere in the element's searchable text (names, notes, aliases, attributes, operations, constraints); terms need not share a field; capped at 10

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv3.0.0
    • addedInput schema / properties / boostAnyOf
      Added value: +{
      +  "description": "Terms that promote a result's rank when also present; never excludes. Use ea_search_and_any_of to narrow instead.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 10,
      +  "type": "array"
      +}
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Zero-based index of the first result to return (default 0). Page by re-calling with the offset carried in continuation.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / packageScope
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "string"
      +    }
      +  ],
      +  "description": "Restrict results to this package and its descendants, given as a package id or name"
      +}
    • removedInput schema / properties / query
      Removed value: -{
      -  "description": "Search term to find across all model text (names, notes, aliases, attributes, operations, constraints)",
      -  "type": "string"
      -}
    • addedInput schema / properties / requiredTerms
      Added value: +{
      +  "description": "Terms every one of which must occur somewhere in the element's searchable text (names, notes, aliases, attributes, operations, constraints); terms need not share a field; capped at 10",
      +  "items": {
      +    "type": "string"
      +  },
      +  "maxItems": 10,
      +  "minItems": 1,
      +  "type": "array"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "query"
      -]New value: +[
      +  "requiredTerms"
      +]
  2. First observedv2.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only carry readOnlyHint=true and openWorldHint=false; the description carries the full burden of behavior and delivers far beyond it. It discloses case/diacritic-insensitive matching, entity-encoded text handling, conjunction and phrase semantics, ranking promotion without exclusion, per-term failure diagnostics, ordering fallback, evidence capping with withheld counts, truncation flags, and descendant-scope traversal. No contradiction with the read-only annotation.

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?

Dense but disciplined — roughly 300 words with every sentence carrying new behavioral information and no restatement of schema content. It is front-loaded with the core search scope and matching semantics before moving to ranking, evidence, and pagination. A slight deduction for being one continuous block that could benefit from paragraph breaks given the breadth of topics covered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must explain return values and it does thoroughly: results ordering, per-result match evidence with source field and snippet, truncated note preview, termMatches diagnostics, continuation tokens, and breakdown distributions. For a 7-parameter search tool with conjunction semantics, ranking, and paging, nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds real value on top: contiguous-substring matching rules, whitespace-as-phrase never being split, the one-entry-list behavior, per-term diagnostic reporting, and the boost-promotes-but-never-excludes ranking nuance — none of which appear in the schema. It does not need to repeat the schema's basic field semantics, so 4 is appropriate rather than 5.

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

Purpose5/5

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

Opens with a specific verb and resource — 'Search Enterprise Architect model elements' — and enumerates precisely which searchable fields are covered (name, alias, notes, attribute/operation/constraint names and notes). It also differentiates itself from the sibling `ea_search_and_any_of` by explicitly stating what this tool does not do (never narrows via boost terms).

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

Usage Guidelines5/5

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

Gives explicit when-to-use guidance with a named alternative and the exact condition selecting it: 'for narrowing to only elements matching an alternative too, use ea_search_and_any_of instead.' It also advises operational strategy — walk large results with offset, use breakdown to narrow instead of paging — so the agent knows how to steer the call sequence.

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