Skip to content

Adding an overload of McpClientExtensions::CallToolAsync taking Dictionary<string, JsonElement> tool argument #641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

anuchandy
Copy link

Adding McpClientExtensions::CallToolAsync overload that takes tool parameters in the form Dictionary<string, JsonElement> .

Motivation and Context

Please see #640

How Has This Been Tested?

yes, and added the unit tests.

Breaking Changes

this is a non-breaking change.

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

Additional context

public static ValueTask<CallToolResult> CallToolAsync(
this IMcpClient client,
string toolName,
IReadOnlyDictionary<string, JsonElement> arguments,
Copy link
Member

@eiriktsarpalis eiriktsarpalis Jul 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are many ways in which you could represent tool arguments in STJ: IDictionary<string, JsonElement>, IDictionary<string, object?>, JsonElement, JsonObject, IReadOnlyDictionary<string, JsonNode?>, so singling out an overload for this particular representation feels oddly specific. Rather than exposing overloads for each and every one of them, I would be inclined to just ask users to populate the one representation picked by the library (or author extension methods that perform the conversion under wraps).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants