remove just about everything bad coming from broker

This commit is contained in:
lda
2026-05-19 23:35:08 +07:00 Verified
parent 53a9e7f85d
commit 5bda3e3770
19 changed files with 99 additions and 371 deletions
+3 -3
View File
@@ -17,9 +17,9 @@
`PersistentSessionFactory` exist, and config-built services use the runtime
pool for generated workflow node execution while discovery/catalog refreshes
still use short-lived SDK adapter sessions.
- Remaining work starts at hiding/removing unsafe raw public `call_tool`
surfaces and then renaming the legacy `transparent_proxy` package to the
clearer proxy/provider-layer package.
- Unsafe raw public `call_tool` surfaces have been deleted. Remaining work starts
at renaming the legacy `transparent_proxy` package to the clearer
proxy/provider-layer package.
---
+3 -4
View File
@@ -41,13 +41,12 @@ The broker keeps two related catalog views:
- `get_catalog()` is the backend MCP catalog. It only includes enabled upstream
connection snapshots loaded from storage.
- `get_planner_catalog()` is the workflow-planning catalog. It includes backend
connection snapshots plus broker-local system sources such as `wf.std` and
`wf.mcp`.
connection snapshots plus broker-local system sources such as `wf.std`.
Broker-local sources are not fake MCP backend connections. They are registered
as service spec sources so raw workflow plans can address nodes like
`wf.std.runtime_error` and `wf.mcp.call_tool` without polluting connection status,
auth, adapter lookup, or persisted backend catalog snapshots.
`wf.std.runtime_error` without polluting connection status, auth, adapter lookup,
or persisted backend catalog snapshots.
The longer-term source model is described in
[`wf_mcp_capability_sources.md`](wf_mcp_capability_sources.md). In that model,
+13 -25
View File
@@ -20,7 +20,7 @@ connections into that model rather than owning the model itself.
```text
CapabilitySource
id: "wf.std" | "wf.docs" | "wf.mcp" | "wf.admin" | "<server>.<account>"
id: "wf.std" | "wf.docs" | "wf.admin" | "<server>.<account>"
kind: "system" | "connection"
enabled: bool
visibility:
@@ -94,25 +94,14 @@ Expected capabilities:
### `wf.mcp`
Workflow runtime helpers for interacting with MCP backends.
Reserved for future workflow-safe MCP helpers.
- Planner-visible: yes, for workflow node specs.
- MCP-client-visible: maybe, for docs/prompts/resources, not admin mutation.
- Admin-dashboard-visible: yes, for inspection and source toggling.
- MCP tools: normally none.
- Workflow safety: mixed. Individual capabilities must be marked.
Expected capabilities:
- `node_specs`: currently `wf.mcp.call_tool`.
- Near-term node specs may include `wf.mcp.read_resource` and
`wf.mcp.get_prompt`.
- Advanced/escape-hatch node specs may include:
`wf.mcp.invoke_method`, `wf.mcp.send_notification`.
- `prompts/resources`: docs for building MCP-backed workflows.
`wf.mcp` is not the admin namespace. It should mean "workflow can interact with
MCP capabilities."
`wf.mcp` currently owns no public NodeSpecs. The previous raw
`wf.mcp.call_tool` helper was deleted because it duplicated the proxy tool
surface and used the wrong abstraction for stateful servers. Workflow authors
should use generated connection NodeSpecs, saved wrappers, or
`wf.workflow.call_capability` when they need to test a workflow-facing
capability.
### `wf.admin`
@@ -128,7 +117,7 @@ Expected capabilities:
- `tools`: list sources, enable source, disable source, refresh catalog, list
connections, add/update/remove connections, view config, reload config, inspect
events, inspect proxy tools, call/debug upstream capabilities.
events, and inspect proxy tools.
- `prompts/resources`: admin documentation may be useful later.
This source is privileged. A normal client LLM should not automatically see
@@ -174,7 +163,6 @@ and capability is safe or explicitly allowed for workflow
Examples:
- include `wf.std.runtime_error`
- include `wf.mcp.call_tool`
- include `everything.default.echo`
- exclude `wf.admin.disable_source`
@@ -200,7 +188,7 @@ Examples:
- `wf.std.workflow_manual`
- `wf.std.error_handling_guide`
- `wf.mcp.mcp_workflow_guide`
- MCP workflow guides under `wf.docs`
These are MCP-visible without implying the source exposes MCP tools.
@@ -241,8 +229,8 @@ The code now has the first capability-source layer in place.
directly; the old `SpecSource` compatibility layer has been removed.
- `wf.std` owns current `wf_authoring.ops` workflow node specs under
`wf.std.*`.
- `wf.mcp` owns workflow MCP runtime node specs, currently
`wf.mcp.call_tool`.
- `wf.mcp` is reserved for future workflow-safe MCP helpers and currently owns
no public NodeSpecs.
- `wf.admin` owns privileged admin capability metadata and is not planner-visible
by default.
- Transparent proxy admin tools now use dotted `wf.admin.*` names through
@@ -266,7 +254,7 @@ Current code has several useful pieces but the boundaries are blurred.
| --- | --- | --- |
| `wf_authoring.ops` | reusable workflow node specs | `wf.std.node_specs` |
| `wf_core` built-in reducers | reusable workflow state reducers | `wf.std.reducers` |
| `wf_mcp.broker.service.builtins` | local workflow specs | `wf.std`, `wf.mcp` |
| `wf_mcp.broker.service.builtins` | local workflow specs | `wf.std` |
| `wf_mcp.broker.tools` | compatibility wrapper over shared service-admin registration | `wf.admin.tools` |
| `wf_mcp.admin_surface.tools` | shared service-backed admin tool registration | `wf.admin.tools` |
| `wf_mcp.transparent_proxy.admin` | proxy-backed public admin tools | `wf.admin.tools` |
+5 -4
View File
@@ -191,10 +191,9 @@ Not all of these need workflow semantics immediately, but they should still have
The broker also needs a more protocol-native mode than the current generic broker tools.
The current broker tools are useful:
The current broker tools are useful for catalog and control-plane inspection:
- `get_catalog`
- `call_broker_tool`
- `read_broker_resource`
- `render_broker_prompt`
- `invoke_broker_method`
@@ -235,7 +234,9 @@ Example desired tool entry:
}
```
This is different from `call_broker_tool`. `call_broker_tool` is a convenience wrapper. Mirrored tools are actual MCP tools exposed by the broker.
Mirrored tools are actual MCP tools exposed by the broker/proxy surface. Do not
reintroduce a generic `call_tool` wrapper for upstream tools; it duplicates the
proxy plane and is the wrong abstraction for stateful MCP servers.
### Official protocol boundary
@@ -333,7 +334,7 @@ For a client like Inspector to show an elicitation form from an upstream server,
Near-term stance:
- mirror normal tools/resources/prompts first
- keep `call_broker_tool` and raw method invocation as debugging fallbacks
- keep raw method invocation only for explicit protocol/admin diagnostics
- test the Everything Reference Server elicitation tool as the first serious proxy pressure test
- only claim elicitation/sampling support once a live Inspector flow works end to end
+1 -4
View File
@@ -401,15 +401,12 @@ Local system sources use the same binding mechanism. For example:
```text
artifact reference: wf.std.replace
runtime binding: wf.std -> wf.std
artifact reference: wf.mcp.call_tool
runtime binding: wf.mcp -> wf.mcp
```
These self-bindings are not external account choices. They keep dependency
resolution uniform across local system sources and upstream connection sources.
They may become implicit later, but today deployments should include them when
validation reports `binding_missing` for `wf.std` or `wf.mcp`.
validation reports `binding_missing` for `wf.std`.
or: