Loading ToolBench
A Model Context Protocol server that dynamically fetches and registers tools from an Asgard endpoint, executing tool requests via HTTP and supporting file uploads
The server dynamically registers tools fetched from an external Asgard manifest endpoint. While the architecture is sound, the tool definitions themselves are not visible in the source code, tool names, descriptions, and schemas come entirely from the manifest, which is retrieved at runtime from a remote API. Since I cannot verify the actual tool definitions (names, descriptions, input schemas, output schemas) in the provided code, I must score conservatively. The code shows proper handler registration and JSON schema unmarshaling, but without seeing the actual manifest format or example tools, I cannot assess naming clarity, description quality, parameter documentation, or output structure. Additionally, the dynamic registration approach means each tool's quality depends entirely on the external manifest, which is outside the MCP server's control and not auditable from this codebase.
Server dynamically registers tools fetched from the Asgard toolset manifest endpoint. Each tool is registered with its name, description, and input schema from the manifest.
Tool definitions are not visible in source code. Tools are dynamically loaded from external Asgard manifest endpoint at runtime. Cannot verify tool names, descriptions, parameter documentation, or output schemas.
No evidence of input parameter descriptions. Handler accepts arbitrary JSON arguments from manifest schema but does not document what each parameter controls, expected formats, valid ranges, or constraints. LLMs cannot infer parameter meaning from names alone.
No evidence of output schema documentation. Tool responses are returned as indented JSON blobs (line 132: `json.MarshalIndent(responseObj, "", " ")`), but no schema documents what fields agents should expect, what types they are, or how to chain results into downstream calls.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 20 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 12 | - | v1 |
Tool descriptions are fetched from manifest, but no validation or enhancement occurs. If manifest provides empty or generic descriptions, tools will be non-discoverable by LLMs. No fallback descriptions or quality gatekeeping is visible.
Error handling returns generic error strings ('Tool execution failed: %v') without recovery guidance. LLMs cannot determine if an error is retryable, user-fixable, or fatal, or what corrective action to take.
No pagination support visible. If a tool returns a large result list, the response will be fully materialized in a single JSON blob, risking context window exhaustion. No limit enforcement or pagination parameters (offset, limit, cursor) are documented.
No input validation or sanitization visible beyond JSON unmarshaling. If manifest schemas accept free-form strings, LLMs could pass malformed values, SQL injection payloads, or command injection attempts without server-side filtering.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. LLMs cannot determine which tools have side effects, which are safe to retry, or which only read data. This is critical for agent planning.