Preset Feature Feedback
What is the problem or goal you're trying to solve or accomplish?
The customer is connecting their Preset workspace's MCP server to Google Gemini Enterprise as a custom MCP data store, and needs the individual Preset operations to register as callable actions their agent skills can bind to.
The Preset MCP server's tools/list response advertises only four top-level operations — call_tool, search_tools, get_instance_info, health_check. The 42 actual operations (query_dataset, list_datasets, list_dashboards, get_dashboard_info, get_chart_data, get_chart_sql, execute_sql, and others) are reachable only via dispatch through call_tool.
This blocks the customer in two distinct ways, both confirmed against Google's first-party documentation (https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server, updated 2026-09-04):
(a) Registration. Gemini Enterprise's Actions list is populated exclusively from tools/list — its "Reload custom actions" control performs a tools/list call and displays whatever is returned. There is no dynamic-discovery path in the connector. The customer's Actions tab therefore shows four generic entries and none of the real Preset capabilities. Google treats the terms as interchangeable: MCP "tools" are called "actions" in Gemini Enterprise data stores, so "expose discrete tools" and "register actions natively" are the same request.
(b) Every operation requires manual user confirmation, including reads. Gemini Enterprise inspects tool annotations to decide whether confirmation is needed. By default every call requires it, because Gemini assumes any operation may be destructive; readOnlyHint bypasses the prompt, destructiveHint preserves it.
Our inner tool definitions already carry these annotations (verified: discovery tools return readOnlyHint: true, destructiveHint: false). Gemini never sees them, because it only sees call_tool — which is generic and must be treated as potentially destructive. The result is that read-only work like listing datasets prompts the user on every call. Our annotation metadata is effectively stranded behind the meta-layer.
This is client-agnostic in origin. Support reproduced the four-tool surface independently from a different MCP client with no Gemini involvement.
How are you solving it currently?
Two-step dynamic dispatch: search_tools to discover the operation, then call_tool with the operation name and arguments. Confirmed working from Claude — call_tool(name="list_databases") returned a normal response.
This is only viable in clients supporting dynamic tool discovery and invocation at runtime. For Gemini Enterprise's custom MCP data store connector there is no workaround for (a) — the operations cannot be surfaced to the Actions list at all — and no workaround for (b) short of accepting a confirmation prompt on every call.
What is your recommended solution?
Expose discrete, first-class tools directly in tools/list, e.g. preset_query_dataset, preset_list_datasets, preset_get_dashboard, rather than nesting them behind call_tool, so each registers natively under the Actions tab.
Support notes on feasibility (not customer-stated):
Gemini's own ceiling is not the constraint. Google recommends limiting enabled actions in a custom MCP data store to 100 at a time, all off by default. Our 42 fit comfortably, so "the client won't cope with that many tools" does not apply here.
The real cost is model-side context. The full 42-tool catalog with complete JSON schemas is roughly 237 KB. Declaring all of it would push a large payload into every client's context on every request, which is plausibly why the meta-tool pattern exists.
Suggested middle path: an opt-in per-workspace toggle, or a curated subset of high-value tools exposed as first-class while the long tail stays behind call_tool. That resolves both (a) and (b) for this customer without imposing the context cost on every client. Even a dozen read-annotated tools would fix the confirmation-prompt problem on the common read paths.
