Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

A tool with a *args or **kwargs parameter is registered with a schema it can never satisfy

Open
#3,514 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
68/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python

Research direction

Start at MCPServer.tool registration, where function signatures become tool schemas, and compare its handling with resource templates that legitimately accept **kwargs. Confirm the InvalidSignature path for both *args and **kwargs, then verify that variadic tool parameters are rejected at registration while resource templates remain supported.

Written by the indexing model from the issue text.

Description

v1 v2

Initial Checks

  • I confirm that I'm using the newest release of my line (2.x, main at 6affe5c)
  • I confirm that I searched for my issue in the issue tracker before opening this issue

Release line

2.x (current stable)

Description

Registering a tool whose function signature has a *args or **kwargs
parameter succeeds, and the tool shows up in list_tools, but it can never
actually be called: the generated JSON schema lists args/kwargs as a
required parameter of a plain scalar type, which doesn't match how the
function actually receives those values.

Expected: either the decorator rejects a signature it can't turn into a
schema (it already does this for a leading underscore in a parameter name),
or the schema reflects what the function accepts.

Actual: the tool is silently registered and permanently uncallable. Calling
it with only the named parameters filled in fails schema validation because
args/kwargs is "missing"; there's no way to actually supply it, since a
JSON object has no way to express "and then also a variable number of
positional values" for a single scalar field.

Example Code

from mcp.server.mcpserver import MCPServer

server = MCPServer("demo")


@server.tool()
def with_kwargs(x: int, **kwargs: str) -> str:
    return f"{x} {kwargs}"

Listing tools shows:

{'type': 'object', 'properties': {'x': {'title': 'X', 'type': 'integer'}, 'kwargs': {'title': 'Kwargs', 'type': 'string'}}, 'required': ['x', 'kwargs'], 'title': 'with_kwargsArguments'}

Calling it with {"x": 1} (the only arguments a caller could reasonably
guess) fails:

Error executing tool with_kwargs: 1 validation error for with_kwargsArguments
kwargs
  Field required [type=missing, input_value={'x': 1}, input_type=dict]

Same shape with *args instead of **kwargs.

Python & MCP Python SDK

Python 3.14.7, mcp-python-sdk main @ 6affe5c0d3588fd1705713b3703dc68015cfe3eb

I have a patch that raises InvalidSignature for a *args/**kwargs tool
parameter at registration time, scoped so it doesn't affect resource
templates (which legitimately use **kwargs for runtime-determined URI
variables); happy to open a PR against this issue if that's the direction
you'd want.

Dominant language
Python
Stars
24.3k
Forks
4k
Avg merge
1d 11h
Merged PRs (30d)
30

Contributor guide

Open the contributing guide

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 modelcontextprotocol/python-sdk

All issues in modelcontextprotocol/python-sdk

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.