[Feature]: Scope MCP tool discovery to a server

Open
  • Is something wrong?
#7,172 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
search

Research direction

Trace the MCP find_mcp_tools implementation, REST POST /api/v1/mcps/find, and the Python SDK’s sync and async discovery calls. First read the existing registration validation and authorization rules for private and account-shared tool roots. Implement the optional server_name filter before ranking and limiting; done means coverage for both roots, unknown and invalid names, omitted parameters, and the limit=1 regression described in the issue.

Written by the indexing model from the issue text.

Description

agent-plugins enhancement kernel
Issue Origin

Inferred by an AI agent and not observed or reproduced

Problem Statement

find_mcp_tools ranks tools across the caller’s visible catalog. An agent that already knows the server it wants cannot scope discovery to that server. With a small result limit, tools from other servers can fill the result set.

Proposed Solution

Add an optional server_name to the MCP find_mcp_tools tool and REST POST /api/v1/mcps/find. Expose it as an optional keyword in the Python SDK’s existing sync and async discovery calls.

  • Validate names using the existing registration rules and match the complete name case-sensitively.
  • Filter the candidate set within each authorized tool root before ranking and applying limit. With the default scope, an exact name may match both the caller’s private root and the account-shared root. The existing REST target_uri can still narrow discovery to one authorized root.
  • Return an empty result for a valid name with no visible matches, and a validation error for an invalid name. Omitting the field preserves the existing request behavior and response shape.
Alternatives Considered

No response

Feature Area

Retrieval/Search

Use Case

An agent configured to use the weather MCP server can discover a forecast tool from that server without losing its result slots to similarly described tools registered on other servers.

Example API (Optional)
find_mcp_tools(query="forecast", limit=3, server_name="weather")

# Equivalent JSON body for POST /api/v1/mcps/find
{"query": "forecast", "limit": 3, "server_name": "weather"}
Additional Context

A regression should put a higher-scoring tool on a different, similarly named server and verify that the selected server still supplies the result with limit=1. Also cover the private and shared roots, an unknown name, and requests that omit the parameter.

I’d like to implement this once the API scope is confirmed. Does the proposed behavior for the same name in both visible roots match the intended discovery contract?

Contribution
  • I am willing to contribute to implementing this feature
Dominant language
Python
Stars
41.8k
Forks
3.4k
Avg merge
19h 29m
Merged PRs (30d)
500

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from volcengine/OpenViking

All issues in volcengine/OpenViking

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.