Index mounted child tools in reverse hash map

_enumerate_tools only pulls tools from LocalProvider and FastMCPApp._local, so providers created by FastMCP.mount(...) (FastMCPProvider) contribute no entries to reverse_hash_map. In a mounted-server setup, hashed backend names from app-only tools cannot be resolved by the outer server and call_tool("<hash>_<name>") falls through to NotFoundError, which breaks backend routing for mounted apps.

Useful? React with 👍 / 👎.

Rebuild hash maps when tool sets change

The reverse hash map is memoized after first access and only rebuilt when add_provider() runs, so adding tools to an already-mounted provider after the cache is populated leaves reverse_hash_map/callable_map stale. Newly registered backend tools then have no hash entry, causing hashed dispatch and synthesized prefab URI lookup to fail until process restart or manual cache reset.

Useful? React with 👍 / 👎.

Avoid overwriting callable map for multi-mount apps

The callable index stores a single HashEntry per id(fn), so mounting the same app instance at multiple addresses collapses distinct tool addresses into the last one seen. Resolver lookups by callable identity then produce a hash for the wrong mount point, which can route peer tool calls to a different mounted app instance than the UI/tool that emitted the reference.

Useful? React with 👍 / 👎.

Traverse mounted FastMCPProvider in prefab tool walk

synthesize_prefab_resource_by_uri() depends on _walk_prefab_tools(), but this walker only collects tools from LocalProvider/FastMCPApp and only recurses through AggregateProvider. Mounted child servers are wrapped as FastMCPProvider, so their prefab tools are skipped. In a parent server that mounts a child with Prefab tools, clients can receive a ui://prefab/tool/<hash>/renderer.html URI from the mounted tool metadata, but read_resource on that URI cannot synthesize the resource and falls through to NotFoundError.

Useful? React with 👍 / 👎.

Support hash lookup for FastMCPApp.add_tool tools

Hash-based dispatch now resolves app-only calls through get_tool_by_hash(), but this matcher only accepts tools with meta.fastmcp._tool_hash. FastMCPApp.add_tool() still stamps only meta.fastmcp.app, so programmatically added app tools no longer match hashed backend names and become unreachable through call_tool("<hash>_<name>"). This is a regression for existing apps that register backend tools via add_tool.

Useful? React with 👍 / 👎.

Preserve Prefab permissions on synthesized resources

The synthesized renderer metadata only carries csp, so any PrefabAppConfig fields like permissions (and other non-CSP UI settings) are dropped from the wire entirely once list_tools strips them from tool metadata. In practice, a tool configured with permissions=... will never expose those permissions to clients, so hosts cannot grant the requested capabilities.

Useful? React with 👍 / 👎.

Avoid hash collisions for prefab tools without app tags

For prefab tools that don't carry meta.fastmcp.app (e.g., FastMCP.tool(app=True) / PrefabAppConfig on non-FastMCPApp providers), the fallback hash is computed from only tool.name. Two mounted providers with the same prefab tool name will therefore get the same ui://prefab/tool/<hash>/renderer.html, and synthesize_prefab_resources dedupes to a single resource, causing one tool to resolve to the other tool's renderer metadata.

Useful? React with 👍 / 👎.

Preserve already-addressed CallTool names in resolver

When FastMCPApp context is present, _prefix now hashes every string unconditionally, so callers can no longer pass an already-addressed tool name through unchanged. This breaks any UI action that intentionally targets a pre-resolved backend identifier (for example cross-app references or precomputed hashed names), because the resolver rewrites it to a second hash and call_tool cannot find the intended target.

Useful? React with 👍 / 👎.

Include non-local providers in prefab tool synthesis walk

_walk_prefab_tools only inspects LocalProvider storage (_components) and FastMCPApp._local, so prefab tools served by other Provider implementations are never discovered. Those tools still get prefab resourceUri values on the wire, but list_resources/read_resource cannot synthesize matching renderer resources, leading to NotFoundError for valid prefab URIs from custom providers.

Useful? React with 👍 / 👎.

Apply enable/session filtering to synthesized resources

Synthetic prefab resources are appended after apply_session_transforms and is_enabled filtering, so they bypass the same visibility controls as normal resources. In practice, disable/session transforms cannot hide these renderer resources, and clients can still see prefab resource entries that should have been filtered out with the rest of the resource list.

Useful? React with 👍 / 👎.

Avoid double-synthesizing prefab resources on mounts

In FastMCP.list_resources, prefab renderer resources are appended unconditionally after super().list_resources(), but mounted providers already return inner.server.list_resources() through FastMCPProvider._list_resources, which includes those same synthesized prefab URIs. In a mounted-server setup this produces duplicate ui://prefab/tool/<hash>/renderer.html entries from the parent API path, so direct FastMCP.list_resources() consumers (and middleware running on that list) see repeated resources even though MCP wire handlers dedupe later.

Useful? React with 👍 / 👎.

Enforce resource visibility checks for synthesized prefab reads

read_resource returns synthesized prefab resources before normal resource resolution, so this code path skips the standard filtering/authorization flow that get_resource applies (session transforms, enabled checks, and auth gating). As a result, if a client can derive a prefab URI (ui://prefab/tool/<hash>/renderer.html), it can read renderer resources even when the corresponding tool/resource would be hidden by normal server filters.

Useful? React with 👍 / 👎.

Do not treat hash-like local names as already-addressed

The resolver currently skips hashing whenever a local reference parses as <12hex>_<name>, which misclassifies valid backend tool names like deadbeefcafe_save as pre-addressed. In that case the UI emits the raw name, call_tool parses it as hash deadbeefcafe + local name save, and lookup fails because the stored hash was computed from (app_name, deadbeefcafe_save). This makes a subset of explicitly named backend tools unreachable from Prefab peer references.

Useful? React with 👍 / 👎.

Rewrite prefab resource URIs in get_tool results

Prefab URI rewriting is only applied in list_tools, so FastMCP.get_tool(...) still returns tools with the placeholder ui://prefab/renderer.html. After this change that placeholder is no longer a concrete resource, so code that does tool = await get_tool(...); await read_resource(tool.meta['ui']['resourceUri']) now fails with NotFoundError even though the same tool works via list_tools.

Useful? React with 👍 / 👎.