Skip to content

fix(#10): emit ToolCall events for meta-tool invocations#12

Open
doobidoo wants to merge 1 commit intoModernOps888:masterfrom
doobidoo:fix/meta-tool-toolcall-events
Open

fix(#10): emit ToolCall events for meta-tool invocations#12
doobidoo wants to merge 1 commit intoModernOps888:masterfrom
doobidoo:fix/meta-tool-toolcall-events

Conversation

@doobidoo
Copy link
Copy Markdown

Closes #10.

Summary

handle_meta_find_tools and handle_meta_list_categories previously emitted no EventType::ToolCall, so invocations through those dispatch paths never landed in /api/metrics. Clients whose MCP flow is biased toward mcplex_find_tools (e.g. Claude Desktop/Code via the stdio bridge on macOS) would see a permanently empty Tool Statistics dashboard pane.

handle_meta_call_tool already routes through dispatch_real_tool, which records under the real upstream tool name — left alone.

Changes

  • src/protocol/transport.rs:
    • handle_meta_find_tools: start-time capture at function entry. EventType::ToolCall emitted on the success return path. Also emitted with success: false on the empty-query error branch so error rates don't silently hide.
    • handle_meta_list_categories: same pattern for the success return (no user-input error branch here).
    • Both events set tool_name = "<meta_tool_name>", server_name = "mcplex".

Verified

  • cargo build --release — clean
  • cargo fmt --all -- --check — clean
  • Tested live (will follow up with a repro transcript in a comment)

No behavior change for mcplex_call_tool, no schema change, no config change. Minimum-surface fix for the reported regression.

Bug A from ModernOps888#10. `handle_meta_find_tools` and `handle_meta_list_categories`
previously emitted no `EventType::ToolCall`, so gateway activity driven
through meta-tool dispatch never landed in `/api/metrics` and the
dashboard's Tool Statistics pane stayed permanently empty for clients
whose MCP flow (e.g. Claude Code via the stdio bridge on macOS) favors
`mcplex_find_tools` discovery.

`handle_meta_call_tool` already goes through `dispatch_real_tool`, which
records under the real upstream tool name — unchanged.

Each affected handler now times itself from entry and emits a ToolCall
event under `tool_name = "mcplex_find_tools"` or `"mcplex_list_categories"`
with `server_name = "mcplex"`. The empty-query error branch in
`find_tools` also records a `success: false` event so error rates are
tracked.

Verified: `cargo build --release` clean, `cargo fmt --check` clean.

Fixes: ModernOps888#10
@doobidoo
Copy link
Copy Markdown
Author

Live verification

Built PR branch locally and ran against a minimal config (/tmp/mcplex-test.toml: port 3199 gateway / 9099 dashboard, one context-provider backend, cache disabled, RBAC off). Issued three calls and diffed /api/metrics before/after.

```
=== BEFORE ===
tools: []

=== CALLS ===
mcplex_find_tools {"query":"instincts"} -> OK
mcplex_list_categories {} -> OK
mcplex_find_tools {"query":""} -> ERR (expected, empty-query)

=== AFTER ===
tools:
{ name: "mcplex_list_categories",
invocations: 1, successes: 1, errors: 0 }
{ name: "mcplex_find_tools",
invocations: 2, successes: 1, errors: 1 }
```

Matches the expected behavior from the PR description:

  • handle_meta_list_categories success path emits a ToolCall event → 1 invocation / 1 success / 0 errors. ✅
  • handle_meta_find_tools success path emits on valid query → 1 success. ✅
  • handle_meta_find_tools empty-query error branch emits with success=false → +1 invocation / +1 error on the same mcplex_find_tools tool row. ✅

The dashboard's Tool Statistics section now populates for any client that drives the gateway through meta-tool discovery (which is the dominant pattern on macOS via the stdio bridge). Closes #10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Dashboard 'Tool Statistics' empty on macOS — meta-tools skip ToolCall metric

1 participant