MCP Framework Tool Invocation Fails Based on Method Name Despite Identical Implementation

[w4mhi]

Describe the bug
The Model Context Protocol (MCP) framework exhibits a critical bug where renaming an MCP tool method causes invocation failures despite identical implementation - specifically, a method AnalyzeLogicAppJson that simply calls return await AnalyzeLogicAppTemplate(jsonContent); works perfectly, but when renamed to AnalyzeLogicAppTemplateSummary with the exact same single-line implementation, the MCP client returns "An error occurred invoking 'AnalyzeLogicAppTemplateSummary'", indicating the framework has an internal name-based conflict or validation issue that prevents certain method names from being invoked regardless of their implementation.

To Reproduce
Steps to reproduce the behavior:
Looking at the simplified code, we've created a minimal reproduction case with two MCP tool methods in the same class: [AnalyzeLogicAppTemplate] (which works and returns an empty [LogicAppAnalysis] object as JSON) and [AnalyzeLogicAppJson] (which simply calls [return await AnalyzeLogicAppTemplate and also works perfectly), demonstrating that the bug occurs purely based on method naming since both methods have identical functionality but different names, with the problematic name AnalyzeLogicAppTemplateSummary causing failures while [AnalyzeLogicAppJson] works fine.

LogicAppAnalysis class could be any simple class with couple of properties. Here is the code. This fails. Rename the AnalyzeLogicAppTemplateSummary in AnalyzeLogicAppJson and will work. Same error if the method is renamed to AnalyzeLogicAppTemplateJson.

[McpServerToolType]
public sealed class LogicAppAnalyzerTools
{
[McpServerTool, Description("Analyze a Logic App template to extract parameters and their dependencies")]
public static async Task AnalyzeLogicAppTemplate(
[Description("The path to the Logic App template JSON file")] string filePath)
{
try
{
LogicAppAnalysis analysis = new LogicAppAnalysis();

        return JsonSerializer.Serialize(analysis, new JsonSerializerOptions
        {
            WriteIndented = true,
            PropertyNamingPolicy = JsonNamingPolicy.CamelCase
        });
    }
    catch (UnauthorizedAccessException)
    {
        return $"❌ Access denied: Cannot read file '{filePath}'. Check file permissions.";
    }
    catch (DirectoryNotFoundException)
    {
        return $"❌ Directory not found: The directory containing '{filePath}' does not exist.";
    }
    catch (JsonException ex)
    {
        return $"❌ Invalid JSON in file '{filePath}': {ex.Message}\n" +
               $"💡 Tip: Validate your JSON file using a JSON validator.";
    }
    catch (IOException ex)
    {
        return $"❌ I/O Error reading file '{filePath}': {ex.Message}";
    }
    catch (Exception ex)
    {
        return $"❌ Unexpected error analyzing Logic App template '{filePath}': {ex.Message}\n" +
               $"🔍 Exception type: {ex.GetType().Name}";
    }
}

[McpServerTool, Description("Get a clean summary of Logic App analysis with key parameters and dependencies only")]
public static async Task<string> AnalyzeLogicAppTemplateSummary(
[Description("The JSON content of the Logic App template")] string jsonContent)
{
   return await AnalyzeLogicAppTemplate(jsonContent);
}

}

Expected behavior
The AnalyzeLogicAppTemplate and AnalyzeLogicAppTemplateSummary should coexist without any problem as the idea is to have a full report and a summary.

Logs
The MCP client only shows the generic error message "An error occurred invoking 'AnalyzeLogicAppTemplateSummary'" without any stack traces, exception details, or server logs that would help diagnose the root cause, which makes this bug particularly difficult to troubleshoot since the MCP framework appears to be swallowing the actual exception information and only returning a generic failure message to the client.

Additional context
Please contact me if you want the whole code (MCP Server/Client). Thank you!

[PederHP]

AnalyzeLogicAppTemplate has return type Task but you're returning a string inside it? I think you must've pasted the wrong code, because this shouldn't compile.

I am somewhat skeptical of the naming being a source of errors. Can you re-check that this is actually the failing example?

[PederHP]

@w4mhi
Can you confirm whether this is still an issue and provide a code sample (without the signature issue mentioned above)? Alternatively, if it is no longer an issue, then please feel free to close it.