Description is not required field of Tool

[abcsnowwolf]

Describe the bug
Description is not a required field of Tool. Some framework such as fastmcp will not carry this field when there is no description for a tool when return list tools request. This will result in an error called TypeMismatchError, but the semantics of this error are rather vague, making it difficult to pinpoint the problem.

To Reproduce
respond list tools request without description field.

Expected behavior
We should allow description field to be absent from the response of the list tools request.

[stallent]

Can you link to the spec where it says it’s optional? I may be looking at an out of date one but it’s not showing as optional

[abcsnowwolf]

@stallent Here is the IDL of Tool from modelcontextprotocol. It seems only name and inputSchema is required.

interface Tool {
  _meta?: { [key: string]: unknown };
  annotations?: ToolAnnotations;
  description?: string;
  inputSchema: {
    properties?: { [key: string]: object };
    required?: string[];
    type: “object”;
  };
  name: string;
  outputSchema?: {
    properties?: { [key: string]: object };
    required?: string[];
    type: “object”;
  };
  title?: string;
}

https://modelcontextprotocol.io/specification/2025-06-18/schema?

[mattt]

It looks like this is indeed the case for both the current 2025-06-18 spec as well as 2025-03-26 and 2024-11-05. Thanks for pointing this out, @abcsnowwolf.

[mattt]

@abcsnowwolf I just noticed that you also opened up a resolving PR (#159). Thank you!

Before seeing that, I opened my own PR, #160, which took a different approach.

Between the two, I think #160 is probably the correct fix. The Swift SDK incorrectly models the spec, and we should fix that rather than try to workaround it. Decoding null or omitted "description" key in the JSON representation and defaulting to "" makes it so that API consumers can't know discern whether the description was blank or unspecified.

What do you think?

[abcsnowwolf]

@mattt Yes, i agree we should also fixed spec. But it seems if we still use description = try container.decode(String.self, forKey: .description) to decode request which not contain description field still throw exception. The protocol allow it to be absent we should make sure Tool will be decode successfully without throwing exception.

I give you my case, i tried to read tool list from a fastmcp server. I have some fixed api which don't want add description for them. In this case, fastmcp dont return description field and decode the response throw an exception. The whole work flow failed just bucause fastmcp server don't transmit an optional field.

Can we merge all these two fix?

[mattt]

Can we merge all these two fix?

@abcsnowwolf Yes! That seems like the right course of action. You're totally right that #160 doesn't handle the server omitting the key. The only change I'd ask for #159 is for you to rebase on top of #160 and update to not default to "".

[mattt]

Resolved by #159 🤝 #160

Thanks again for your help, @abcsnowwolf!