A C# MCP server for the Model Context Protocol with support for file system operations, data transformation, datetime utilities, environment variables, and extensible plugin architecture.
The server defines 7 tools with input schemas present for all. However, quality is uneven. Tools have reasonable descriptions (most 60-200 chars), but parameter schemas suffer from weak typing and missing descriptions. The `filesystem` tool has critical path traversal vulnerabilities. The `document` tool's parameter descriptions are sparse. Naming is functional but not optimal (e.g., 'data_transform' lacks a verb-first pattern). No output schemas are documented. Error handling is minimal, tools return basic error messages but lack recovery guidance. The greeting tools are trivial examples. Overall, the server is competent but falls short of production-grade tooling standards.
Transform data between formats: JSON query, CSV/JSON/XML conversion, base64 encode/decode, and hashing. Use this for data format conversions.
Get current date/time or convert between timezones. Use this when you need to know the current time or convert times between different timezones.
Read and analyze enterprise documents. Supports PDF, Word (.docx), Excel (.xlsx), and PowerPoint (.pptx). Extract text, metadata, tables, and search within files. Paths must be within configured allowed directories.
Check environment variables: get values, list variables, check existence. Sensitive variables are automatically masked for security.
Read files, list directories, and search for files within allowed directories. Use this for accessing local files and folder contents.
Returns a personalised greeting. Action: 'greet' (required param: name).
Returns a configurable greeting. Prefix is read from Plugins:Config:greeting_prefix in appsettings.json.
CRITICAL: filesystem tool exposes path traversal risk. No evidence of validation against `../` or absolute paths outside allowed_directories. Malicious agents can read arbitrary files.
No output schemas documented for any tool. LLMs cannot predict response structure, forcing them to guess field names and types. This breaks multi-tool composition and wastes tokens on exploratory calls.
Parameter descriptions weak or missing. 'recursive' in filesystem is documented as 'true/false' but is type string, mismatch between description and schema. 'pattern' in data_transform lacks context (what search syntax? regex? glob?). Parameters 'case_sensitive', 'pages', 'sheet' in document have no descriptions in the source shown.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Naming lacks verb-first consistency. 'data_transform' is not a verb, should be 'transform_data'. 'filesystem' is a noun, should be 'read_file' or 'list_files'. 'document' is vague, could be 'read_document' or 'analyze_document'. This violates the verb_noun pattern and makes it harder for LLMs to disambiguate intent.
Error handling is minimal. Tools return basic error text but do not guide recovery (e.g., 'file not found' vs 'File not found. Use list_files to find available files'). No error categorization (retryable vs fatal). Agents cannot reliably self-correct.
Greeting tools are trivial examples in production config. 'greeting' and 'greeting_configurable' add no value and clutter the tool namespace. Remove from production or clearly mark as demo-only.
data_transform has weak input validation. No validation shown for CSV delimiter, hash algorithm enum enforcement, or XML well-formedness. The 1 MB cap is good but error message for exceeding it is not documented.
document tool's 'pages' parameter accepts '1-5' or '3' syntax but description does not explain this format clearly. LLMs may pass invalid formats like '1 to 5' or '1,2,3'.