Tiny Tool Development

// AI Plugins / Internal shared runtime

Tiny Tool Execution Runtime

One execution contract for Unreal tools from UE 5.4 onward, with Epic MCP isolated to UE 5.8.

Owns tool, invocation, resource, and artifact lifecycle without owning transport or UCM policy.

Show the complete UE 5.4-first execution layer while keeping the concrete Epic MCP adapter isolated to UE 5.8.

Tiny Tool Execution Runtime system overview
system artCanonical schematic media; status, proof, and roadmap remain data-driven in the page.
// THE PAIN

Before the plugin enters the chat.

Tool discovery, execution state, progress, and cancellation fragment when every transport and plugin invents its own contract.

PAIN

A local agent surface is easy to start and hard to scale: tools acquire transport-specific identifiers, job records diverge, and route governance can accidentally be duplicated.

TTER introduces a transport-neutral provider and invocation layer. It is deliberately narrower than an orchestrator: UCM still owns routes and workflow policy, while UMCP still owns transport, access guard, and audit.

What that feels like

  • The same logical tool needs a different wrapper for every client or transport.
  • Progress, cancellation, deadlines, and final status are recorded differently by each plugin.
  • A shared execution layer risks becoming a second route or security authority unless boundaries are explicit.
// WHAT YOU GET

After — in the editor, not in a slide deck.

Canonical tools and traceable invocations without collapsing transport, route, and product ownership.

GAIN

SP1-SP6 provide registry and discovery, traceable invocation, progress and cooperative cancellation, safe structured content, artifacts, resources, UMCP protocol alignment, and selected product-adoption surfaces. The neutral SP7 projection model remains part of the UE 5.4-compatible core; only its concrete Epic MCP adapter is isolated in a separate UE 5.8-only plugin.

  • SP1-SP2: canonical descriptors, provider discovery, meta-tools, stable invocation IDs, progress, cancellation, deadlines, diagnostics, and bounded history.
  • SP3-SP4: policy-bounded structured content, UObject/UStruct projection, image/audio helpers, artifacts, resources, URI resolution, and guarded reads.
  • SP5-SP6: UMCP resource/cancellation/protocol alignment and native adoption surfaces for IIS, UCI, PIO, UBI, APM, and governed LLM Store reads.
  • SP7 split: a transport-neutral projection model in the UE 5.4 core and an Editor-only UnifiedEpicMcpBridge on UE 5.8, backed by the live TTER registries and one canonical-to-internal allow-list.

// HOW IT WORKS

The product architecture, inspected from the plugin surface.

These are the moving parts I would place on the page so buyers can understand what they are actually getting beyond the slide narrative.

01 / Transport

UMCP keeps the guarded endpoint.

UMCP continues to own local transport, authentication, access guard, and audit. TTER is consumed behind that boundary rather than replacing it.

02 / Execution

TTER owns discovery and invocation lifecycle.

The runtime validates canonical descriptors, discovers providers, dispatches calls, and records progress, cancellation, deadlines, diagnostics, and final state.

03 / Governance

UCM keeps route and workflow authority.

Projected routes delegate to UCM for planning, rules, approvals, dry-run, transforms, side-effect evaluation, and governed execution.

// FIT

Who actually reaches for this.

Maintainers building multiple Unreal tools that need one discoverable execution contract across current and future transports.

TTER keeps general execution behavior on the Unreal Engine 5.4 floor. Optional UMCP/UCM and UE 5.8 Epic adapters consume the product-owned registries through ITinyToolExecutionModule.

// SURFACE

Where it lives in Unreal.

Runtime provider, content, artifact, resource, and invocation contracts plus an optional editor-only UMCP/UCM integration bridge; no buyer-facing editor browser yet.

// CAPABILITY MAP

Feature groups with the value of each part made explicit.

Grouped from plugin modules, public APIs, automation hooks, and documented workflow surfaces.

Implemented and verified: SP1-SP2

The first two slices establish transport-neutral discovery and a traceable invocation lifecycle.

  • TinyToolExecutionInterface and TinyToolExecution runtime modules.
  • ITinyToolProvider discovery through modular features.
  • Descriptor validation, search, toolset catalog, and canonical ToolId rules.
  • Bounded, thread-safe invocation registry with stable IDs and explicit states.
  • Progress snapshots with monotonic sequence and coalescing.
  • Cooperative cancellation, deadlines, completion summaries, and diagnostics.

Implemented and verified: SP3-SP4

Typed content and resources are part of the current UE 5.4-compatible execution contract.

  • Policy-bounded UStruct and UObject serialization with deterministic schema support.
  • Typed text, structured, image, audio, artifact-link, and resource-link results.
  • Bounded artifact registry plus URI-addressed resource providers and guarded reads.
  • Traversal, scheme, size, lifetime, and redaction boundaries remain explicit.

Implemented and verified: SP5-SP6

The optional editor companion exposes the current runtime through UMCP and selected product surfaces.

  • UMCP resource listing and reading, cancellation notifications, multi-content passthrough, and discovery filtering.
  • Native adoption surfaces for IIS, UCI, PIO, UBI, APM, and governed LLM Store read-only operations.
  • Progress, rich-result, artifact, resource, and cancellation conformance stays in shared TTER contracts.
  • The companion bridge owns UMCP and UCM adapters so the core package remains transport-neutral.

Engine split: neutral SP7 core, concrete bridge on 5.8

Epic MCP support adds a downstream transport without raising the TTER engine floor.

  • The projection model and mapping decisions compile in the UE 5.4-compatible TTER core with no Epic dependencies.
  • UnifiedEpicMcpBridge exists only as a UE 5.8 Editor adapter and consumes Epic MCP and ToolsetRegistry APIs there.
  • The bridge uses the live TTER registries; canonical Epic IDs resolve through one exposure-filtered map to internal invocation IDs.
  • Raw internal IDs are rejected, and Epic MCP refresh rebuilds discovery, registrations, and the allow-list.
  • UE 5.4-5.7 continue to use the governed UMCP path through the optional editor integration bridge.

// OPERATOR TOOLS

Concrete actions, expected result, and mutation boundary.

This is the part that keeps product marketing honest: buyers can see which buttons, APIs, or MCP tools matter and what they change.

// ACTION

tter_list_toolsets

Why it matters
Lists discovered canonical toolsets.
Operator result
A bounded discovery entry point instead of an eager flat tool dump.
Change surface
Read-only.
// ACTION

tter_describe_toolset

Why it matters
Returns one toolset and its descriptors.
Operator result
Agents can inspect a focused contract before calling it.
Change surface
Read-only.
// ACTION

tter_search_tools

Why it matters
Filters tool descriptors.
Operator result
Relevant tools can be found without loading the full catalog.
Change surface
Read-only.
// ACTION

tter_get_tool_schema

Why it matters
Returns the selected input schema.
Operator result
Arguments can be prepared against an explicit contract.
Change surface
Read-only.
// ACTION

tter_call_tool

Why it matters
Dispatches one canonical tool through the invocation registry.
Operator result
The call leaves a bounded status and diagnostic record.
Change surface
Depends on the owner tool and UCM route policy.
// ACTION

Invocation status tools

Why it matters
Lists running calls, reads status, and requests cancellation.
Operator result
Long-running work is observable without a second job subsystem.
Change surface
Cancellation is cooperative and tool-dependent.
// ACTION

Resource tools

Why it matters
Lists and reads transport-neutral resources through guarded registry contracts.
Operator result
Large or reusable outputs remain addressable without flattening them into one response.
Change surface
Read-only; provider policy still applies.

// TYPICAL FLOW

From inspection to use without losing the product boundary.

01

A native provider publishes canonical tool, content, artifact, and optional resource descriptors.

02

TTER validates and discovers the provider through its transport-neutral registries.

03

The optional editor companion projects meta-tools, resources, cancellation, and UCM routes into UMCP without reversing dependencies.

04

The dispatcher records progress, cancellation, deadlines, typed content, diagnostics, artifacts, resources, and final state.

05

On UE 5.8 only, UnifiedEpicMcpBridge reads the live TTER registries, projects allowed canonical IDs into Epic MCP, and rebuilds after an Epic tool refresh.

// PROOF AND BOUNDARIES

Signals that make the product specific, plus the limits worth saying out loud.

Each card turns implementation facts into buyer-facing proof without pretending the tool solves the wrong problem.

Current core SP1-SP6 + neutral SP7 projection
Engine floor UE 5.4
Core proof Isolated Editor and Game package boundary + automation
Epic bridge Editor compiled, Game isolated, 6/6 tests on UE 5.8
Verified 2026-07-16
Core modules Interface, Runtime, Editor placeholder
5.4-5.7 transport UMCP through optional editor companion
Route authority UCM ExecuteRoute delegation

Outputs

What the plugin leaves behind when the workflow is doing useful work.

  • Tool catalog

    Validated canonical descriptors grouped into discoverable toolsets.

  • Invocation record

    ID, state, progress snapshot, timing, diagnostics, artifact IDs, and completion summary.

  • Typed provider result

    Text, structured data, object snapshots, images, audio, artifacts, and resources mapped through one result contract.

  • Resource surface

    Guarded URI-addressed outputs with provider-owned policy and bounded reads.

  • Route projection

    UCM routes exposed as tools without moving route execution authority into TTER.

Inspection basis

The concrete code, API, and tool surfaces used to shape this product page.

  • Module boundary

    The plugin separates public interfaces, runtime contracts, and the editor integration boundary.

  • Companion

    TinyToolExecutionIntegrationBridge contains the optional editor-only UMCP and UCM adapters.

  • Tests

    Automation covers validation, registries, rich content, resources, invocation lifecycle, product adoption, shared-registry refresh, allow-list dispatch, and raw-ID rejection.

  • Ledger

    The TTER SAD records SP1-SP6 and the neutral SP7 projection as implemented in the 5.4-first core.

  • Version boundary

    UnifiedEpicMcpBridge is maintained only on UE 5.8 Editor targets; the Game host gate proves isolation.

Integrations

Where the product connects without losing ownership of its own domain.

  • Unified MCP Server

    Guarded local transport, access profile, redaction, and audit boundary through the optional companion.

  • Unreal Capability Mesh

    Current route projection and execution delegation boundary; approvals and dry-runs stay in UCM.

  • Existing UMCP providers

    Compatibility projection keeps synchronous providers callable without entering the TTER core dependency graph.

  • Product adopters

    IIS, UCI, PIO, UBI, APM, and governed LLM Store reads expose current SP6 adoption surfaces.

  • Epic MCP

    UnifiedEpicMcpBridge projects allow-listed canonical IDs from the live TTER registry only on UE 5.8 Editor targets.

Safety model

The boundaries that make the tool understandable before automation enters.

  • No governance bypass

    UMCP calls stay behind the UMCP guard; the separate Epic path uses its exposure allow-list, and projected routes still execute through UCM.

  • Minimal argument retention

    SP2 history stores an argument hash and field-count summary rather than raw argument values.

  • Explicit status

    Cancelled, timed out, denied, failed, partial, and successful calls remain distinct states.

  • Bounded serialization

    Allow/block policy, redaction, soft paths, cycles, depth, and size limits constrain current SP3 content.

  • Version isolation

    Epic MCP headers never enter the UE 5.4 core or companion bridge.

  • Epic exposure

    Canonical IDs must resolve through the filtered allow-list; raw internal IDs are not an invocation escape hatch.

Not for

The cases where the product promise would be the wrong expectation.

  • Replacing UCM route planning, approvals, dry-run, or workflow governance.

  • Replacing UMCP authentication, access guard, transport, or audit.

  • Installing Epic MCP support on UE 5.4-5.7; the concrete bridge is intentionally UE 5.8-only.

  • Presenting the internal execution runtime as a standalone Fab product or buyer-facing agent UI.

// PRODUCT MEDIA

Tutorial and platform embeds stay attached to product context.

YouTube, Discord, LinkedIn, and Fab widgets are reserved for product presentation, explanation, support context, or tutorials. No third-party widget loads automatically.

Tutorial video

YouTube

Product walkthroughs, setup explanations, and tutorial material.

Embed source pending. No third-party widget is loaded here.

Open platform
Primary support context

Discord

Discord-first product support, quick questions, setup discussion, and community context.

Embed source pending. No third-party widget is loaded here.

Open platform
Professional context

LinkedIn

Company background, provider identity, project credibility, and listing context.

Embed source pending. No third-party widget is loaded here.

Open platform
Marketplace context

Fab

Product listing context, license details, purchase route, and marketplace availability.

Embed source pending. No third-party widget is loaded here.

Open platform

// INFORMATION

All essential product signals in one place.

Status Internal shared runtime
Category AI Plugins
Unreal Engine 5.4-5.8
Source state Destination branches 5.5-5.8 pass Editor and Game gates with zero warnings; the UE 5.8 Epic bridge passes 6/6 automation tests.
Primary surface Runtime provider, content, artifact, resource, and invocation contracts plus an optional editor-only UMCP/UCM integration bridge; no buyer-facing editor browser yet.
Marketplace No product checkout linked
Direct sales None on this website
Support route Discord first; product context lives on this page
Listing context Fab for marketplace, LinkedIn for public provider identity
Fact surface 1 function / 1 failure mode / 2 bridges
Boundary One transport-neutral discovery and invocation contract for Tiny Tool providers from Unreal Engine 5.4 onward.
Primary workflow Register a provider, discover descriptors, dispatch through the invocation registry, report progress, and return bounded typed content.
Publication boundary Shared runtime and website documentation; no standalone Fab publication claim is made.
Proof state Destination branches 5.5-5.8 pass Editor and Game gates with zero warnings; the UE 5.8 Epic bridge passes 6/6 automation tests.

// NOTES

Practical boundaries.

Current proof: SP1-SP6 plus the neutral SP7 projection layer are verified in the UE 5.4-compatible core and isolated package boundary.

The optional Tiny Tool Execution Integration Bridge is editor-only and keeps UMCP/UCM dependencies outside the TTER core.

The concrete UnifiedEpicMcpBridge is implemented only on UE 5.8: the Editor gate compiles it, the Game gate proves isolation, and 6/6 bridge tests pass without warnings or errors.

Publication boundary: this is an internal implementation surface, not a Fab availability or buyer-readiness claim.

The editor module currently exists as a placeholder; a discovery browser and invocation monitor are not presented as implemented.

// LEGAL / PRIVACY

Static information page.

Purchases, downloads, marketplace accounts, and platform-specific license details are handled outside this website. Product or tutorial widgets are loaded only after activation, where configured.

Provider details are listed in the legal notice. The current site template does not set first-party cookies and does not load analytics scripts.

// RESOURCES

Open the channel that matches the next question.

Fab seller profile

No product-specific Fab listing is linked yet. The public seller profile remains available.

Open

GitHub documentation

Manuals, quickstarts, settings references, troubleshooting, technical notes, and release material live in GitHub.

Open

Discord support (primary)

Start quick questions, setup help, support context, and product-fit discussion on Discord.

Open

Plugin support email

Formal plugin support requests can be sent to the dedicated support mailbox.

Open

LinkedIn company context

Company background, public provider identity, and listing context are available on LinkedIn; support still starts on Discord.

Open

// RELATED

Nearby tools in the catalogue.

// TOOL NAVIGATION

Continue through the catalogue.

Each tool page keeps the product overview here and routes deep technical material to GitHub.