Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Critical failures across all 11 tools. No input schemas are visible in the provided source code. All tool descriptions are extremely minimal (5-10 chars), far below the 10-1024 character baseline and well below the 20-character minimum threshold. Tool names lack action verbs and are inconsistently prefixed with 'clawd_' without clear semantic distinction. No parameter descriptions, no output schemas documented, and no error handling guidance visible. The source code shows tool registration via imports in server.py but does not expose the actual tool definitions, parameter schemas, or return types. This appears to be a stub or incomplete implementation where tools are registered but their metadata is either missing or defined elsewhere not provided.
NO INPUT SCHEMAS VISIBLE, All 11 tools lack any visible JSON Schema definitions for input parameters. Cannot verify parameter types, constraints, defaults, or required/optional status.
DESCRIPTIONS CRITICALLY SHORT, All tool descriptions are 5-10 characters (e.g., 'Agent management tool from agent module'). These fall in the 0 range. LLMs cannot determine when/why to select these tools without substantive descriptions.
URGENT: Add comprehensive input schemas to all 11 tools. Each schema must define parameter types, descriptions, constraints (min/max, enums, patterns), and required/optional flags. Use JSON Schema with 'type', 'description', 'enum', 'minimum', 'maximum' fields.
URGENT: Expand all tool descriptions from 5-10 chars to 100-250 chars. State WHAT the tool does, WHEN to call it (vs. similar tools), and what it returns. Example: 'clawd_channels' → 'Retrieve and manage communication channels in the OpenClaw ecosystem. Call this to list available channels, get channel metadata, or configure channel properties. Returns channel ID, name, type (public/private), member count, and creation date.'
Rename all tools to start with clear action verbs: 'clawd_get_agent_status', 'clawd_create_bastion_rule', 'clawd_list_channels', 'clawd_delete_openclaw_connection', etc. This helps LLMs parse intent from the name alone.
Document output schemas for every tool. Specify what fields are returned, their types, and what the agent can expect. Include chaining IDs (e.g., if a tool returns a session, also return the session_id for downstream tools).
Add per-parameter descriptions. For each parameter, explain: what it controls, valid values (enum), format (regex or pattern), constraints (min/max length), and whether it's required. Example: 'channel_id (required, string): The unique identifier of the channel (36-char UUID). Use list_channels() to discover valid IDs.'
Add error handling guidance. Document common failure modes (e.g., 'User not found', 'Permission denied', 'Timeout') and suggest recovery actions: 'If user not found, try search_users() with a partial name.' Categorize errors as retryable (network timeout) vs. user-fixable (invalid input) vs. fatal (permission denied).
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 20 points across a rubric change (v1 → v2)
18/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
18
<=2025-11-25
v2
2026-03-09
F
38
2.14+
v1
Routing/message routing tool from routing module
clawd_securityread onlyauthsource verified8/100
Security audit and management tool from security module
INCONSISTENT/UNCLEAR NAMING, Tool names are prefixed 'clawd_' but lack clear action verbs. 'clawd_bastion' does not signal whether it reads, writes, or modifies security state. 'clawd_openclaw_disconnect' is longer and confusing (disconnect what? from what?). Names should start with action verbs (get_, create_, update_, delete_, search_) to help LLMs infer intent before reading descriptions.
NO PARAMETER DESCRIPTIONS, Tool definitions do not include parameter-level documentation. LLMs cannot understand parameter meaning, valid values, constraints, or formats.
NO OUTPUT SCHEMAS DOCUMENTED, Cannot verify what fields tools return, their types, or whether they include chaining IDs needed by downstream tools. LLMs cannot plan multi-step operations without knowing response structure.
DESTRUCTIVE TOOL LACKS CONFIRMATION, 'clawd_openclaw_disconnect' marked DESTRUCTIVE but no evidence of dry-run, confirmation, or recovery guidance. Agents should not execute irreversible operations without explicit confirmation.
NO ERROR HANDLING GUIDANCE, No visible error responses, recovery suggestions, or categorization (retryable vs. fatal). LLMs will not know what to do if a tool call fails.
For destructive tools (clawd_openclaw_disconnect, clawd_bastion if it modifies security state), add a dry-run parameter or confirmation step. Agents should see what will be deleted before executing, or require explicit user confirmation.
Add idempotency hints. If a tool is safe to call multiple times with the same inputs (e.g., 'create session if not exists'), document this. Agents retry on failures, non-idempotent tools risk duplicate side effects.
Add permission/scope declarations to tools that modify state (WRITE/DESTRUCTIVE). Example: 'Requires: write:channels, admin:security'. This enables least-privilege agent configurations and audit trails.
Review tool composition. If 'create_and_send_email' logic exists, split into separate tools. Each tool should do one thing. Verify that outputs from one tool contain IDs/references the next tool needs (e.g., channel_id returned by list_channels should be accepted by send_message).