MCP server for managing folders and resources via HTTP API, built for .NET Conference 2025
This server presents a STDIO-only transport with 12 tools managing folders and resources. While all tools are explicitly registered with descriptions and parameter annotations via C# attributes, there are critical shortcomings: (1) Output schemas are undocumented, responses return raw JSON strings from an HTTP API with no structured schema declaration for LLMs; (2) Parameter descriptions lack actionable constraints (format, range, valid values), relying instead on vague English; (3) Error handling is minimal, catch-all returns generic messages like 'Error al obtener los recursos {e.Message}' instead of recovery guidance; (4) No pagination or result limits declared despite returning potentially large JSON arrays; (5) Tool naming uses camelCase instead of snake_case convention, and some names are overly specific (e.g., 'getSubFoldersIds' vs 'get_folder_children'); (6) Descriptions are brief and do not clarify WHEN to use one tool over a similar one (e.g., getFolderByName vs getSubFoldersById); (7) No evidence of input validation, idempotency hints, or permission gating for destructive operations like deleteFolder. The server is functional but falls well short of production-grade agent tool quality.
Crear una nueva carpeta
Crear un nuevo recurso. Type: 0=Url, 1=Code, 2=Text
Eliminar una carpeta y sus subcarpetas
Obtener todas las carpetas disponibles de la unidad
Obtener todos los recursos disponibles
Obtener una carpeta por su id
Buscar carpetas por el nombre
Obtener un recurso especifico por su id
Obtener una o varias carpetas por el id de la carpeta padre, si se quiere buscar por las subcarpetas a partir de una id
No output schemas documented. All tools return raw JSON strings from the HTTP API with no structured response schema for LLMs to parse. This violates pattern:tool and makes downstream tool composition impossible.
Parameter descriptions lack actionable constraints. For example, 'id' params use English descriptions (e.g., 'id de la carpeta, similar a un valor del tipo Guid (ejemplo: 681d0aa3f03a81ee9f9e53b6)') instead of formal constraints like 'type: string, pattern: ^[a-f0-9]{24}$'. LLMs cannot reliably extract constraints from prose.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Obtener los ids de las subcarpetas de una carpeta especifica
Actualizar el nombre de una carpeta
Actualizar la referencia del ParentFolderId de una carpeta
Error handling is generic and non-actionable. All tools catch exceptions and return a raw message (e.g., 'Error al obtener los recursos {e.Message}'). No recovery guidance, no categorization (retryable vs. user-fixable vs. fatal), no suggestion of alternative tools.
No pagination or result limits. Tools like getAllFolder, getAllResources, and getSubFoldersById can return arbitrarily large JSON arrays with no limit. This risks context-window exhaustion and violates pattern:paginated-result.
Naming convention inconsistency. Tools use camelCase (getAllFolder, getFolderById) instead of the agent-tool standard snake_case (get_all_folder, get_folder_by_id). This reduces clarity and violates naming baseline conventions used in 90% of A+ tools.
Destructive operation (deleteFolder) lacks confirmation or dry-run capability. No indication of irreversibility or permission checks. Violates pattern:confirmation-request.
Similar tool names without disambiguation. getFolderByName, getFolderById, getSubFoldersById, and getSubFoldersIds are all similar, LLMs will struggle to pick the right one. Descriptions should clarify: 'Use getFolderByName to search by display name; getFolderById when you have the ID; getSubFoldersById to list children; getSubFoldersIds to get only the child IDs.'
No idempotency declarations. Tools like addFolder, addResource, updateFolderName should include idempotency hints or notes about retry behavior. Agents retry on network failures, non-idempotent tools risk duplicate records or double-writes.