UAT: MCP adapter `register_tools()` infers resource slots but never wires them into domain `Tool` objects — resource binding metadata lost #6147

New issue

Open

opened 2026-04-09 15:33:40 +00:00 by HAL9000 · 0 comments

HAL9000 commented

2026-04-09 15:33:40 +00:00

Owner

Bug Report

Feature Area: MCP Adapter Integration
Milestone Scope: v3.3.0 (MCP tool integration)
Severity: Non-critical (resource binding metadata silently dropped)

What Was Tested

The MCPToolAdapter.register_tools() method in src/cleveragents/mcp/adapter.py and whether inferred resource slots are persisted to the domain Tool objects.

Expected Behavior (from spec)

When MCP tools are registered via MCPToolAdapter.register_tools(), the inferred resource slots (file, directory, repository bindings) should be persisted to the domain Tool objects so that:

agents tool show <name> displays the resource slots
The resource binding system can enforce access controls
The tool registry database stores the bindings in tool_resource_bindings

Actual Behavior

The register_tools() method correctly infers resource slots via infer_resource_slots(), but then stores them only in source_metadata — NOT in the domain Tool object's resource_slots field:

# In MCPToolAdapter.register_tools():
inferred_slots = self.infer_resource_slots(desc.name, desc.input_schema)
slot_dicts = [
    {
        "name": slot.name,
        "resource_type": slot.resource_type,
        "access": slot.access.value,
        "binding": slot.binding.value,
    }
    for slot in inferred_slots
]

# 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.
spec = ToolSpec(
    name=tool_name,
    ...
    source_metadata={
        "server": self._config.name,
        "resource_slots": slot_dicts,  # ← stored here only
        ...
    },
)

The ToolSpec constructor does NOT receive resource_slots as a direct parameter — the slots are buried in source_metadata where no downstream code reads them.

Impact

agents tool show <mcp-namespace/tool-name> shows empty resource slots even when the tool has file/directory/repository parameters
The resource binding enforcement system cannot apply access controls to MCP tools
The tool_resource_bindings database table is never populated for MCP tools
The agents tool list --source mcp output is missing resource binding information

Code Location

src/cleveragents/mcp/adapter.py — MCPToolAdapter.register_tools() method, the TODO(#882) comment block.

Steps to Reproduce

Configure an MCP server with a tool that has file_path parameter
Register the MCP server tools via the adapter
Run agents tool show <mcp-namespace/tool-name>
Observe: Resource Slots section shows "(none)" despite the tool having file parameters

Fix

Pass the inferred ResourceSlot objects directly to the ToolSpec constructor's resource_slots parameter (if it exists), or create the domain Tool object with the resource slots populated before registering it in the registry.

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

## Bug Report **Feature Area**: MCP Adapter Integration **Milestone Scope**: v3.3.0 (MCP tool integration) **Severity**: Non-critical (resource binding metadata silently dropped) --- ## What Was Tested The `MCPToolAdapter.register_tools()` method in `src/cleveragents/mcp/adapter.py` and whether inferred resource slots are persisted to the domain `Tool` objects. ## Expected Behavior (from spec) When MCP tools are registered via `MCPToolAdapter.register_tools()`, the inferred resource slots (file, directory, repository bindings) should be persisted to the domain `Tool` objects so that: 1. `agents tool show <name>` displays the resource slots 2. The resource binding system can enforce access controls 3. The tool registry database stores the bindings in `tool_resource_bindings` ## Actual Behavior The `register_tools()` method correctly infers resource slots via `infer_resource_slots()`, but then stores them only in `source_metadata` — NOT in the domain `Tool` object's `resource_slots` field: ```python # In MCPToolAdapter.register_tools(): inferred_slots = self.infer_resource_slots(desc.name, desc.input_schema) slot_dicts = [ { "name": slot.name, "resource_type": slot.resource_type, "access": slot.access.value, "binding": slot.binding.value, } for slot in inferred_slots ] # 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. spec = ToolSpec( name=tool_name, ... source_metadata={ "server": self._config.name, "resource_slots": slot_dicts, # ← stored here only ... }, ) ``` The `ToolSpec` constructor does NOT receive `resource_slots` as a direct parameter — the slots are buried in `source_metadata` where no downstream code reads them. ## Impact 1. `agents tool show <mcp-namespace/tool-name>` shows empty resource slots even when the tool has file/directory/repository parameters 2. The resource binding enforcement system cannot apply access controls to MCP tools 3. The `tool_resource_bindings` database table is never populated for MCP tools 4. The `agents tool list --source mcp` output is missing resource binding information ## Code Location `src/cleveragents/mcp/adapter.py` — `MCPToolAdapter.register_tools()` method, the `TODO(#882)` comment block. ## Steps to Reproduce 1. Configure an MCP server with a tool that has `file_path` parameter 2. Register the MCP server tools via the adapter 3. Run `agents tool show <mcp-namespace/tool-name>` 4. Observe: Resource Slots section shows "(none)" despite the tool having file parameters ## Fix Pass the inferred `ResourceSlot` objects directly to the `ToolSpec` constructor's `resource_slots` parameter (if it exists), or create the domain `Tool` object with the resource slots populated before registering it in the registry. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 15:39:51 +00:00

HAL9000 referenced this issue

2026-04-09 19:37:03 +00:00

[AUTO-UAT-POOL] UAT Testing Report (Cycle 2) #6263