A C# implementation of the Model Context Protocol (MCP) server and client framework
MCPSharp has 2 tools with severely deficient definitions. Both tools have empty input schemas ({}), no parameter documentation, minimal descriptions (under 20 chars in semantic context), and no output schema documentation. The framework provides reflection-based tool registration via McpToolAttribute and KernelFunctionAttribute, but the actual tool definitions in ExternalTool.cs are bare stubs. Tool names are vague ('dll-tool', 'SemanticTest') and do not follow verb_noun convention. Error handling exists in ToolHandler.HandleAsync but error messages are generic stack traces with no recovery guidance. No tool composition, no idempotent markers, no permission gates, and no resource reference chaining. The codebase shows tooling infrastructure but zero production-grade tool definition practices.
test semantic kernel integration
attempts to use a tool that is loaded from an external assembly dll. should return 'success'
Both tools have empty input schemas ({}). No parameter types, constraints, or descriptions are defined.
Tool descriptions are minimal and provide no context for LLM tool selection. 'dll-tool' = 'attempts to use a tool that is loaded from an external assembly dll. should return success' (99 chars, but vague about what it does, when to use it, or what happens). 'SemanticTest' = 'test semantic kernel integration' (34 chars, under 20-char hard cap threshold).
Tool names do not follow verb_noun convention. 'dll-tool' is a hyphenated noun (not an action). 'SemanticTest' is a name, not a verb. LLMs rely on action verbs to infer intent. Should be 'call_external_tool', 'test_semantic_kernel', or similar.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | 2024-11-05+ | v1 |
No output schema documented. ToolHandler.HandleAsync returns CallToolResult with Content array, but clients have no schema definition to parse responses. Cannot plan downstream tool calls without knowing output structure.
Error handling in ToolHandler.HandleAsync returns raw stack traces (split by Environment.NewLine, filtered for Reflection). These provide no recovery guidance to LLMs. A 'null' result also returns IsError=true, but the LLM gets no hint about what to do next.
No tool composition support. Tools do not return IDs or references that could chain to other tools. No pagination, no batching, no idempotent markers.