feat(client): return empty lists when server lacks capability

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.

[PederHP]

Motivation and Context

Going through logs of an MCP server not advertising prompts during capabilities negotiation, I noticed listPrompts requests from a client causing a lot of noise. I was about to create an issue with the client, but on second thought, I think the SDK shouldn't require clients to check capabilities manually before calling list methods. I can't think when it would ever be a good idea to send the request to a server that doesn't advertise the capability, so the SDK should make it easy to call the methods without causing server noise and just get an empty list anyway.

Per the MCP spec, "Both parties SHOULD respect capability negotiation." Previously, calling listPrompts/listResources/listTools on a server that didn't advertise those capabilities would still send the request, causing servers to log warnings and creating unnecessary traffic.

Now the Client respects capability negotiation by default:

• listPrompts() returns { prompts: [] } if server lacks prompts capability
• listResources() returns { resources: [] } if server lacks resources capability
• listResourceTemplates() returns { resourceTemplates: [] } if server lacks resources capability
• listTools() returns { tools: [] } if server lacks tools capability

Each logs a debug message when this occurs for visibility. Let me know if you want this removed - I was unsure whether to add it.

The existing enforceStrictCapabilities option is preserved - when set to true, these methods will still throw errors as before.

Also fixed three subtle test bugs with incorrect capability declaration.

How Has This Been Tested?

Added tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

[changeset-bot]

🦋 Changeset detected

Latest commit: c65684c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/client	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/client@1386

@modelcontextprotocol/server

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/server@1386

@modelcontextprotocol/express

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/express@1386

@modelcontextprotocol/hono

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/hono@1386

@modelcontextprotocol/node

npm i https://pkg.pr.new/modelcontextprotocol/typescript-sdk/@modelcontextprotocol/node@1386

commit: c65684c

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

[PederHP]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.

The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

[felixweinberger]

Should we use console.warn instead of console.debug? With debug, developers would need to explicitly enable debug logging to see these messages, which could hide the fact that they're calling methods for unadvertised capabilities.
The client package doesn't have precedent for either, but core uses console.warn for similar "heads up" situations (tool name validation, deprecation warnings).

I would personally prefer console.debug when developing a client host, as I think one can consider it an SDK convenience to be able to call these and not have to manually check if the server supports it. For most client hosts I think the difference between whether a server has 0 primitives or doesn't support a capability isn't really relevant to the user or agent, so the warning wouldn't prompt me to change the code and do the capability check on the outside unless I explicitly need to know if the server supports it, and that case I probably already have the check or the enforce flag set.

But I don't mind changing it to console.warn if you prefer that for consistency and/or other reasons. My main reason for this PR was to reduce the log spam in C# servers being called by TypeScript clients that don't do the capability checks, which even some relatively major agentic clients seem to not do. So I don't have strong opinions on the client developer experience.

Makes sense, I think debug is fine. We can always change it if we do end up wanting more verbosity.