Loading ToolBench
LDP — LLM Delegate Protocol: identity-aware communication for multi-agent LLM systems
LDP Protocol server exhibits significant definition quality gaps. Tool names lack consistent verb-noun structure (e.g., 'handle_identity_request' vs 'discover'). Most tools have minimal descriptions (10-50 chars, well below the 194-char baseline). Input schemas are present but sparse: many parameters lack type definitions or descriptions. Tools 1-9 are HTTP endpoint handlers with generic descriptions; tools 10-17 are SDK/router functions with better structure but still incomplete schemas. No output schemas documented. Error handling descriptions absent. The server appears to be a protocol implementation rather than an MCP server, with tool definitions inferred from code rather than explicitly registered.
Close an active session with a delegate
Fetch a delegate's identity card from a remote URL
Discover delegates from a list of URLs. Returns only the delegates that responded successfully
Run the full LDP handshake (HELLO → SESSION_PROPOSE → SESSION_ACCEPT) and return session_id
Handle a GET /ldp/capabilities request
Handle HELLO message — respond with CAPABILITY_MANIFEST
Handle a GET /ldp/identity request
HTTP endpoint handlers (tools 1-9) use 'handle_*' prefix instead of action verbs (get_, post_, create_). Names do not convey intent to LLMs. 'handle_identity_request' should be 'get_identity' or 'fetch_identity'.
Most tool descriptions are under 50 characters (e.g., 'Handle a GET /ldp/identity request'). Baseline is 194 chars. Descriptions lack context on WHEN to use the tool, WHAT it returns, and prerequisites. LLMs cannot reliably select tools with such sparse descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Handle a POST /ldp/messages request. Processes incoming LDP envelope and returns a response envelope
Handle SESSION_CLOSE message — close an active session
Handle SESSION_PROPOSE message — accept or reject the session based on trust domain validation
Handle TASK_CANCEL message — cancel a submitted task
Handle TASK_UPDATE message — query task status
Handle TASK_SUBMIT message — execute task via pluggable handler and return result with provenance
List all discovered delegates, optionally filtered by skill
Select the best delegate and submit a task in one call
Select the best delegate for a skill using the given strategy (quality, cost, latency, or balanced)
Submit a task to a delegate and return the result with provenance
Input schemas present but incomplete. Many parameters lack type definitions or descriptions. E.g., 'envelope' parameter in handle_hello has type 'object' but no nested schema. Parameters like 'config' in handle_session_propose are undescribed. No output schemas documented for any tool.
No error handling guidance in tool descriptions. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., handle_session_propose may reject sessions but does not explain rejection reasons or recovery steps.
Tool definitions appear inferred from code rather than explicitly registered via MCP tool registration. No evidence of formal MCP tool schema declarations in source.