Skip to main content
Glama
mm6502

Enterprise Architect MCP Server

by mm6502

ea_search_and_any_of

Read-only

Search Enterprise Architect elements by required terms, optionally narrowing to those also matching at least one 'andAnyOf' term. Returns ranked results with match evidence, pagination, and breakdowns.

Instructions

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.

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.
andAnyOfNoTerms a result must also contain at least one of, in addition to requiredTerms; never adds results. Use ea_search's boostAnyOf to only reorder 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. Addedv3.0.0

TDQS

A5/5.0
Behavior5/5

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

Even with readOnlyHint=true, the description adds substantial behavioral context: fallback `termMatches`, strongest-first ordering, truncation flags, capped and withheld match counts, continuation behavior, and breakdown distribution. None of this contradicts the annotations, and it gives the agent a clear model of how the tool behaves beyond the annotation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely packed with operational value; every clause covers either purpose, filtering semantics, alternatives, result interpretation, or pagination. It is front-loaded with the core distinction from `ea_search` and has no filler or tautological repetition.

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?

For a 7-parameter search tool with no output schema, the description covers input semantics, result shape, fallback behavior, ordering, pagination, and aggregation breakdown. The only parameters not individually expanded in prose are `objectType` and `stereotype`, but their schema descriptions are already clear enough, so nothing essential is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond field names: it defines `requiredTerms` as conjunctive contiguous substrings that need not share a field, clarifies `andAnyOf` narrows and is inert when empty, and ties `offset` to `continuation` and `packageScope` to descendant packages. This materially helps an agent construct correct calls.

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?

The description opens with a specific verb and resource: searching Enterprise Architect model elements, and immediately differentiates itself from the sibling `ea_search` by naming `andAnyOf` as the added filter. It clearly explains the relationship to `ea_search` so an agent can tell the two tools apart without inspecting the schema.

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?

It explicitly says when to use `ea_search` instead ('For promoting rather than narrowing'), and explains that `andAnyOf` can only ever narrow results. It also gives practical guidance for large result sets via `offset` and `continuation`, making the use conditions unambiguous.

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