Skip to main content
Glama
CarlxsMG

UEAgent

by CarlxsMG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

find_tools

Read-onlyIdempotent

Search Unreal Engine tools by keyword or domain to find the right tool name and parameters before calling. Use it when you don't know a tool's exact name.

Instructions

Searches this server's 1547 Unreal Editor tools and returns the best matches, each with its name, domain, parameters (* marks a required one) and the first sentence of its description. Use it before guessing a tool name or writing Python; when you already know the name, skip it: describe_tool and call_tool take the name directly.

Examples: {"query": "material parameter"} searches every tool, {"query": "landscape", "domain": "Level"} searches one domain, and {"domain": "Water"} lists a domain's tools. Each query word scores on a whole word of a tool's name first, then the start of one, then the domain, then the description, and a tool that matches more of the words ranks higher, so a query that spells a tool's name, such as "spawn actor", puts it first. limit (default 25, up to 300) caps the list; more then says how many matched beyond it, and a query that matches nothing gets next, with what to try.

With no arguments it lists the 55 domains, each with what it covers and its size, and the packs with their tools. It only reads the catalog, so it is cheap to repeat. Then describe_tool gives a match's full schema and call_tool runs it, or enable_toolset adds its pack or domain to your tool list.

Returns: { success, matches: int, tools: [{ name, domain, params?, summary }], more?: string, next?: string } -- with no arguments { success, total_tools, domains: [{ domain, description, tools }], packs: [{ pack, description, tools }], next }. An unknown domain is an error that lists the domains.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many tools to return (default 25, at most 300).
queryNoWords from the tool's name or purpose, e.g. "spawn actor" or "material parameter". A plural also finds the singular.
domainNoOnly this domain's tools; without a query, lists them all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.5.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds real behavioral context: it 'only reads the catalog, so it is cheap to repeat', it explains the internal ranking order (exact name word > word prefix > domain > description, more matched words ranks higher), and it states the failure mode (unknown domain is an error listing the domains; no matches return `next` with what to try). The only weakness is mild repetition of the 'read-only' idea already in annotations.

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?

Front-loaded with purpose and the skip condition, then examples, then return shape. Every paragraph carries information, but the three dense paragraphs with inline return-schema notation are heavier than needed for a 3-parameter search tool.

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?

There is no output schema, and the description compensates by documenting both return shapes (matches list and the no-argument domain/pack listing) including `more` and `next`. Combined with the follow-up path to describe_tool/call_tool/enable_toolset, an agent has everything needed to call it and act on the result.

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 would be 3, but the description adds genuine semantics the schema does not: that `domain` with no query lists the whole domain, that plurals match singulars, that a query spelling a tool's name puts it first, and the interaction between `limit` and the returned `more` count. Most of this is additive rather than restated.

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?

States a specific verb and resource ('Searches this server's 1547 Unreal Editor tools and returns the best matches') plus the shape of the result. It explicitly differentiates from siblings by naming describe_tool and call_tool as the right tools once a name is known.

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 an explicit when-to-use ('before guessing a tool name or writing Python'), an explicit when-not-to ('when you already know the name, skip it'), and names the alternatives with the condition that selects them. It also documents the no-argument discovery path, which is a distinct usage mode an agent would otherwise never find.

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

Deploy Server

Other Tools