Dynamic Tool Discovery and Session Activation

Expose only native tools at session start, then activate proxied tools on demand through a searchable discovery layer.

architecture

Quality

👁️0 views

docs

>Payload Data

Editable Format

# Dynamic Tool Discovery and Session Activation

Imported from curated first-party documentation sources.

## What this covers
Use this skill when you need smaller tool payloads, exact-name compatibility, and session-scoped tool activation.

## Use this when
- Reducing tool-list bloat for focused sessions
- Preserving exact-name tool calls while hiding noise
- Activating proxied tools only when a task requires them

## Expected outcomes
- Discovery changes listing visibility without breaking routing
- Session-scoped activation keeps tools relevant to the task
- Operators can trade compatibility against payload size intentionally

## Source synthesis
- EVOKORE-MCP/docs/TOOLS_AND_DISCOVERY.md (https://github.com/mattmre/EVOKORE-MCP/blob/main/docs/TOOLS_AND_DISCOVERY.md)

## Dedupe notes
Uses the canonical EVOKORE-MCP discovery doc instead of duplicating the same concept from walkthrough and migration docs.

## Source excerpts

### EVOKORE-MCP/docs/TOOLS_AND_DISCOVERY.md
This page explains how EVOKORE presents tools, how proxy names are built, and how `discover_tools` changes the visible tool surface.

## Two tool populations

### Native EVOKORE tools

These tools are defined by EVOKORE itself:

- `docs_architect`
- `skill_creator`
- `resolve_workflow`
- `search_skills`
- `get_skill_help`
- `discover_tools`

Properties:

- always available
- always visible
- not subject to proxy prefixing

### Proxied child-server tools

These come from child servers in `mcp.config.json`.

Current configured sources:

- `github`
- `fs`
- optional `elevenlabs`

Properties:

- fetched from child servers at startup
- renamed with server prefixes
- governed by `permissions.yml`
- routed through `ProxyManager`

## Prefixing and compatibility

EVOKORE rewrites proxied tool names to:

```text
${serverId}_${tool.name}
```

Why this exists:

- prevents tool-name collisions across child servers
- makes origin obvious during execution and review
- keeps exact-name routing deterministic

Examples:

| Upstream tool | EVOKORE-exposed tool |
|---|---|
| `read_file` from `fs` | `fs_read_file` |
| `create_issue` from `github` | `github_create_issue` |

### Duplicate-prefixed name policy

If two child registrations would create the same final prefixed name:

- the first registration wins
- later duplicates are skipped
- EVOKORE logs a warning and duplicate summary

## Discovery modes

| Mode | What `tools/list` returns | Best for |
|---|---|---|
| `legacy` | all native + proxied tools | maximum compatibility |
| `dynamic` | native tools + session-activated proxied tools | smaller initial tool payloads |

Environment toggle:

```bash
EVOKORE_TOOL_DISCOVERY_MODE=legacy
EVOKORE_TOOL_DISCOVERY_MODE=dynamic
```

## Dynamic discovery lifecycle

In `dynamic` mode, EVOKORE uses a session-scoped activation set.

Lifecycle:

1. session starts with only native tools visible
2. user/model calls `discover_tools`
3. `ToolCatalogIndex` searches the merged native + proxied catalog
4. matching proxied tools are activated for that session
5. EVOKORE emits `sendToolListChanged()` best-effort
6. client re-runs `tools/list` or auto-refreshes

```mermaid
flowchart TD
    A[Session starts in dynamic mode] --> B[tools/list shows native tools]
    B --> C[discover_tools query]
    C --> D[ToolCatalogIndex searches merged catalog]
    D --> E[Matching proxied tools added to session activation set]
    E --> F[sendToolListChanged best-effort]
    F --> G[Client refreshes tools/list]
    G --> H[Activated proxied tools now visible]
    D --> I[Exact-name proxied call still works eve
...

Source

https://github.com/mattmre/EVOKORE-MCP/blob/main/docs/TOOLS_AND_DISCOVERY.md

SIMILAR_PROMPTS

SCANNING_SIMILARITY...