UAT: MCP tool resource slots inferred but not wired into domain Tool objects or persisted to DB — downstream consumers cannot access binding metadata #4461

New issue

Open

opened 2026-04-08 13:11:53 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-08 13:11:53 +00:00

Owner

Metadata

Milestone: (none — backlog)
Parent Epic: (MCP tool integration / resource bindings)

Bug Report

What Was Tested

The MCPToolAdapter.register_tools() method was analyzed against the spec's resource binding requirements for MCP tools.

Expected Behavior (from spec)

Per docs/specification.md (Tools & Skills section):

Resource Binding: The association between a tool and the resources it operates on, declared via typed resource slots. Slots resolve through contextual binding (from the plan's project), static binding (hardcoded at registration), or parameter binding (passed at invocation).

The spec also states:

MCP tools can be composed into skills and used as tool nodes in actor graphs.

For MCP tools to participate in resource binding resolution (e.g., for sandbox isolation, validation attachment, and project-scoped resource resolution), their inferred resource slots must be accessible via the domain Tool objects and persisted to the database (tool_resource_bindings table).

Actual Behavior

In src/cleveragents/mcp/adapter.py, the register_tools() method:

Correctly infers resource slots via infer_resource_slots() (e.g., file_path → file resource slot)
Stores the inferred slots in source_metadata["resource_slots"] of the ToolSpec
BUT does NOT wire the slots into the domain Tool objects

The code contains an explicit TODO acknowledging this gap:

# TODO(#882): resource_slots are stored in source_metadata but
# nothing downstream reads them yet.  The ToolRegistry persists
# resource bindings via domain Tool.resource_slots, and the DB
# migration (c1_001) stores them in tool_resource_bindings.
# A follow-up ticket should wire inferred slots into the domain
# Tool objects so the registry and DB actually consume them.

Issue #882 was closed (merged) but this TODO was NOT resolved — the code still has this comment and the wiring is still missing.

Code Location

src/cleveragents/mcp/adapter.py — register_tools() method (line ~330-380): slots stored in source_metadata only
src/cleveragents/tool/registry.py — find_tools_for_resource(): reads source_metadata["resource_bindings"] (different key than what MCP stores as "resource_slots")
src/cleveragents/domain/models/core/tool.py — Tool.resource_slots: never populated for MCP tools

Impact

ToolRegistry.find_tools_for_resource() cannot find MCP tools when searching by resource type — it reads source_metadata["resource_bindings"] but MCP stores under "resource_slots" with a different schema
Validation attachment cannot scope to MCP tools via resource bindings
Sandbox isolation cannot apply resource-specific strategies to MCP tool invocations
DB persistence of MCP tool resource bindings is broken — tool_resource_bindings table is never populated for MCP-sourced tools

Steps to Reproduce (Code Analysis)

In MCPToolAdapter.register_tools(), observe that slot_dicts is built but only stored in source_metadata["resource_slots"]
In ToolRegistry.find_tools_for_resource(), observe it reads source_metadata.get("resource_bindings", []) — a different key
The key mismatch means MCP tools are never returned by find_tools_for_resource() even when they have matching resource slots

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Metadata - **Milestone**: *(none — backlog)* - **Parent Epic**: *(MCP tool integration / resource bindings)* ## Bug Report ### What Was Tested The `MCPToolAdapter.register_tools()` method was analyzed against the spec's resource binding requirements for MCP tools. ### Expected Behavior (from spec) Per `docs/specification.md` (Tools & Skills section): > **Resource Binding**: The association between a tool and the resources it operates on, declared via typed resource slots. Slots resolve through **contextual binding** (from the plan's project), **static binding** (hardcoded at registration), or **parameter binding** (passed at invocation). The spec also states: > MCP tools can be composed into skills and used as tool nodes in actor graphs. For MCP tools to participate in resource binding resolution (e.g., for sandbox isolation, validation attachment, and project-scoped resource resolution), their inferred resource slots must be accessible via the domain `Tool` objects and persisted to the database (`tool_resource_bindings` table). ### Actual Behavior In `src/cleveragents/mcp/adapter.py`, the `register_tools()` method: 1. Correctly infers resource slots via `infer_resource_slots()` (e.g., `file_path` → file resource slot) 2. Stores the inferred slots in `source_metadata["resource_slots"]` of the `ToolSpec` 3. **BUT** does NOT wire the slots into the domain `Tool` objects The code contains an explicit TODO acknowledging this gap: ```python # TODO(#882): resource_slots are stored in source_metadata but # nothing downstream reads them yet. The ToolRegistry persists # resource bindings via domain Tool.resource_slots, and the DB # migration (c1_001) stores them in tool_resource_bindings. # A follow-up ticket should wire inferred slots into the domain # Tool objects so the registry and DB actually consume them. ``` Issue #882 was closed (merged) but this TODO was NOT resolved — the code still has this comment and the wiring is still missing. ### Code Location - `src/cleveragents/mcp/adapter.py` — `register_tools()` method (line ~330-380): slots stored in `source_metadata` only - `src/cleveragents/tool/registry.py` — `find_tools_for_resource()`: reads `source_metadata["resource_bindings"]` (different key than what MCP stores as `"resource_slots"`) - `src/cleveragents/domain/models/core/tool.py` — `Tool.resource_slots`: never populated for MCP tools ### Impact 1. **`ToolRegistry.find_tools_for_resource()`** cannot find MCP tools when searching by resource type — it reads `source_metadata["resource_bindings"]` but MCP stores under `"resource_slots"` with a different schema 2. **Validation attachment** cannot scope to MCP tools via resource bindings 3. **Sandbox isolation** cannot apply resource-specific strategies to MCP tool invocations 4. **DB persistence** of MCP tool resource bindings is broken — `tool_resource_bindings` table is never populated for MCP-sourced tools ### Steps to Reproduce (Code Analysis) 1. In `MCPToolAdapter.register_tools()`, observe that `slot_dicts` is built but only stored in `source_metadata["resource_slots"]` 2. In `ToolRegistry.find_tools_for_resource()`, observe it reads `source_metadata.get("resource_bindings", [])` — a different key 3. The key mismatch means MCP tools are never returned by `find_tools_for_resource()` even when they have matching resource slots --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added this to the v3.5.0 milestone

2026-04-08 17:42:23 +00:00

HAL9000 added the