MCP InputSchema and empty Properties

[manusa]

We're progressively migrating Kubernetes MCP Server to the go-sdk.

As a first step, we've decoupled the MCP tool definitions from any MCP implementation by describing them using jsonschema (this implementation).

We've noticed some users having issues with how the inputSchema is marshalled for tools definitions with no arguments (see containers/kubernetes-mcp-server#340).

I understand that the issue is with:

jsonschema-go/jsonschema/schema.go

Line 99 in 11a1c83

Properties map[string]*Schema `json:"properties,omitempty"`

Since it's configured to omitempty the field is not marshalled.

I implemented a workaround to add the field manually here:
https://github.com/containers/kubernetes-mcp-server/blob/c69e90c70dca03fee3b910c2a3580a1187a2e470/pkg/mcp/m3labs.go#L33-L39

Have you faced this issue in any of you MCPs?

I see that go-sdk might be facing a similar issue for this case: https://github.com/modelcontextprotocol/go-sdk/blob/07f6c490c68284a1f152ec9c0f71e2861b0e687d/mcp/server.go#L210-L213

I'm not sure if we can find a way to deal with this problem.

[findleyr]

@manusa we're discussing decoupling the schema type from its usage, in modelcontextprotocol/go-sdk#518, for the reasons enumerated there. Would that make it easier for you to solve this problem? (You can just set whatever you want as the empty schema). In other words, the workaround you use for mark3labs would still be available to you.

Your prompt confirmation would really help inform our decision to land #518. Thanks.

[manusa]

Hi @findleyr

This works for me but I don't have strong opinions about it.
The use of reflection to infer the jsonschema seemed like something useful, but forcing it into users did seem like a problem for our specific use case.

I guess that developer-experience-wise this might be worse, but I'm sure that it can be mitigated with additional tooling.

[findleyr]

@manusa to be clear, we'd still use google/jsonschema-go for inference and validation, you just wouldn't be tied to it for setting the schema manually.

So both instances in the following code would still work:

// case 1: manual schema
mySchema, _ := jsonschema.For[MyType](nil)
mySchema.Required = []string{} // remove all requirements
tool := &mcp.Tool{
  Name: "mytool",
  InputSchema: mySchema,
}
mcp.AddTool(server, tool, myHandler)

// case 2: implicit infererence
mcp.AddTool(server, &mcp.Tool{Name: "mytool2"}, myHandler)

// case 3: raw schema
tool3 := &mcp.Tool{
  Name: "mytool3",
  InputSchema: jsonRawMessage(`{"type":"object", "properties":{}}`)
}
mcp.AddTool(server, tool3, myHandler)

Does that seem like a worse developer experience? The only thing that changed from the server side is a loss of type safety in the InputSchema type, but we will of course document that it must be something that marshals to JSON schema, and recommend using jsonschema.For or relying on the implicit schema that is automatically inferred.

[manusa]

Thanks for the detailed example.

OK, sorry I misunderstood.

Then I think it's a great solution.
It provides the freedom to specify the jsonschema in any way that suits the downstream developers.
While preserving a good developer experience by providing the convenience method.

👍

[jba]

@manusa is this resolved to your satisfaction?

[manusa]

Hi, for the reported case it is fixed for me (used in combination with mark3labs) by adding a workaround.
https://github.com/containers/kubernetes-mcp-server/blob/f3a446676fccc8d198b0383e2227e6f38978fb86/pkg/mcp/m3labs.go#L33-L39

We're on our way to migrate to go-sdk (containers/kubernetes-mcp-server#385) where we'll likely have to port a similar fix.

Regarding go-sdk, I know that this is an issue there too since https://github.com/kagenti/mcp-gateway has the same issue when LlamaStack (Python) loads a tools schema which contains a tool with no arguments.

I'm not sure if you want to keep this issue for tracking this problem.
From my side it's fine to close.