Loading ToolBench
An MCP server providing tools for file system management, project management, item hierarchy, models, and object hierarchy operations
DaemonsMCP has 19 tools with explicit schema definitions and descriptions derived from C# attributes via MCPSharp. However, critical gaps significantly limit production readiness. All tools have descriptions (positive), but many are generic (1-2 sentences) and lack actionable context for LLM tool selection. Parameter descriptions exist but are inconsistent in depth. Output schemas are not explicitly documented, responses are JSON-serialized McpOpResult objects, but the shape of the 'result' field is undocumented, forcing LLMs to infer structure. No output schema documentation for any tool. Critical naming and composition issues: several tools conflate responsibilities (add-update-item, add-update-model combine insert and update logic), no confirmation patterns for destructive operations (delete-model, delete-model-property are unguarded), and no idempotency guarantees documented. Error handling returns McpOpResult with a message field, but does not categorize errors as retryable or guide recovery. Parameter validation is weak, no enum constraints for type/status IDs (LLMs must guess valid values), and no documented ranges for pagination parameters (pageNo/pageSize). Security: no mention of permission gating or scope declarations, credentials are assumed to be server-injected but not verified.
Add a new item or update an existing item
Add a new model or update an existing model
Add or update a property on a model
Create a new file in the project
Create a new directory in the project
Delete a model by its ID
Delete a model property by its ID
Get the contents of a specific file from the file system
Combined insert/update tools violate single-responsibility principle. 'add-update-item', 'add-update-model', 'add-update-model-property' bundle two distinct operations (create and modify) into one tool, forcing LLMs to reason about conditional logic that should be explicit. Agents cannot safely plan around idempotency, and error recovery is ambiguous.
No output schemas documented. All tools return JSON-serialized McpOpResult objects with a generic 'result' field, but the structure of result is undocumented and type-dependent on the tool. LLMs cannot infer what fields to extract or pass downstream. Violates pattern:response-shaper and forces trial-and-error data extraction.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get a specific item by its ID
Get all available item types
Get a specific model by its ID
Get the README content
Get all available status types
List all projects
Search the file system for files and directories matching criteria
Search for items in the hierarchy based on various criteria
Search for models in a project matching specified criteria
Search the object hierarchy for code objects
Update the contents of an existing file
Destructive operations (delete-model, delete-model-property) have no confirmation pattern, dry-run step, or permission gates. An LLM can permanently delete models and properties with a single call, with no recovery mechanism documented. Violates pattern:confirmation-request.
Parameters using magic IDs (itemTypeId, statusTypeId, modelTypeId, propertyValueTypeId, identifierTypeId) with no enum constraints or lookup guidance. LLMs must guess valid values or call discovery tools (get-item-types, get-status-types). This is inefficient and error-prone. Discovery tool descriptions ('Get all available item types') lack guidance on when to call them.
Pagination parameters (pageNo, pageSize) lack documented constraints. No min/max specified; no guidance on default behavior if pageNo exceeds total pages. 'pageNo' starting at 1 is non-standard (most APIs use 0-based offset). No documentation of whether results are total count, next_cursor, or nothing.
Error handling is generic. All failures return McpOpResult with a message string, but no categorization (retryable vs user-fixable vs fatal). No guidance on recovery actions. E.g. 'Failed: Item not found' tells an LLM nothing about whether to retry, search first, or give up.
Discovery tools (get-item-types, get-status-types, list-projects, get-readme) have minimal descriptions (10-15 chars). Descriptions state WHAT but not WHEN or WHY to use them. LLMs cannot determine if calling these first is necessary before other operations.
No permission gates or scope declarations documented. Tools like delete-model suggest they can permanently destroy data, but no evidence of permission checks (e.g., verify user has 'delete:model' scope). Violates pattern:permission-gate and pattern:scope-declaration.
No idempotency guarantees documented. 'add-update-item', 'add-update-model' claim to handle both insert and update, but it is unclear if the same input produces the same result on retry or if duplicates/errors occur. Violates pattern:idempotent-operation.
Parameter 'maxDepth' (used in search-items, get-item-by-id, search-models, get-model) defaults to 1 but is not explained. LLM does not understand the impact of this setting or when to override it. Description should clarify 'maxDepth: 1 returns only direct children; increase to traverse deeper hierarchies.'
Tool composition chains are not documented. After search-filesystem returns a fileSystemNodeId, calling get-file with that ID is the natural next step, but this relationship is not documented. Violates pattern:tool-chain, tool outputs must contain the IDs that downstream tools need.