Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Laravel MCP SDK provides 2 tools with explicit schemas and basic descriptions. Both tools have complete input schemas with type definitions and parameter descriptions, meeting the minimum bar for structure. However, descriptions are generic and lack LLM-optimized guidance on when/why to use each tool. The 'command' tool exposes dangerous functionality without required safety scaffolding (confirmation, dry-run, or destructive_hint annotation). Output schemas are undocumented, forcing LLMs to infer result structure. Error handling is minimal, no recovery guidance or classification. Security concerns: command execution without input sanitization hints, HTTP tool lacks timeout/retry documentation. Average across 2 tools: (command: 58, http: 66) = 62.
Tool descriptions are generic and lack LLM-optimized guidance. 'Executes shell commands' (28 chars) and 'Makes HTTP requests to external APIs' (36 chars) do not explain WHEN/WHY to use each tool vs alternatives, expected return format, or prerequisites. Baseline for A-grade tools is 50 - 200 chars with clear decision context.
No output schema documentation visible. LLMs cannot infer result structure, what fields does 'command' return? Is output a string, object with stdout/stderr, or structured record? Baseline for A-grade tools is 100% documented return types.
commandhttp
Recommendations
Enhance tool descriptions: 'Executes shell commands' → 'Execute arbitrary shell commands on the server. Use to automate system tasks (backups, deployments, data processing). WARNING: This is destructive, verify command syntax before use. Returns: {"stdout": string, "stderr": string, "exitCode": int}. Example: ls -la /app/logs.',
Add destructiveHint and readOnlyHint annotations to tool metadata. In src/Procedures/ToolProcedure.php list() method, include tool['handler']->getAnnotations() returning {destructiveHint: true} for command, {readOnlyHint: true} for http GET variants.
Add confirmation workflow for 'command' tool: Create an optional 'dry_run' boolean parameter. When dry_run=true, return what would execute without running it. Document in description: 'Set dry_run=true to preview command before execution (prevents accidental destruction).'
Enhance 'command' parameter descriptions: cwd → 'Working directory for command execution (absolute or relative to server CWD; must exist). Defaults to server working directory.'. Add validation: 'LLM must not include shell metacharacters without explicit escaping.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
'command' tool lacks input sanitization guidance. Parameter descriptions do not warn against command injection risk or document how LLM-provided 'command' strings are escaped. Users could pass 'rm -rf /' via agent reasoning without safeguard.
'http' tool description does not document timeout behavior, retry logic, rate-limit handling, or what happens on network failure. Baseline for A-grade tools includes dependency hints and failure mode guidance.
No error handling guidance. Tools do not document error responses, recovery paths, or how to classify failures (retryable vs fatal). Baseline requires each error response to tell the LLM what to do next.
Tool annotations (destructiveHint, readOnlyHint, idempotentHint) not present in tool metadata. Current MCP spec (2026-07-28) rewards tool annotations for LLM safety classification. 'command' should declare destructiveHint=true; 'http' should declare readOnlyHint=true for GET requests.
'command' tool 'cwd' parameter description is minimal ('The working directory for the command'). Does it support relative paths? Must it exist? Does it default to the server's working directory? Baseline requires format/range/constraints stated in description.
'http' tool 'data' parameter lacks type clarity. Description says 'The data to send with the request' but does not specify: is it form-encoded, JSON, multipart? How should LLMs provide it? Baseline requires actionable format guidance.
http
Document 'http' timeout and error behavior: 'timeout: Request timeout in seconds (default: 30, range: 1-300). Returns network error with message if exceeded.' Add retry guidance: 'Transient failures (5xx, network) are retryable; 4xx client errors are not.'
Add per-parameter examples using enums or patterns, not free text. For 'http' method, schema already uses enum (good). For 'command', add pattern constraint if possible.
Add error handling examples in documentation: 'command' tool errors → 'Command not found: Try full path. Permission denied: Run with sudo. Timeout: Increase timeout parameter or split into smaller commands.'
Validate 'command' input for injection risk. In execute() method, document or implement escaping: 'All shell metacharacters in command are shell-escaped automatically; LLM need not quote.' Consider adding a 'shell_escape' option.
For 'http' tool, document SSL/cert validation, redirect limits, and body size caps. Example: 'Follows up to 5 redirects. Max response body: 10 MB. SSL cert validation: enabled by default (no option to disable).'
Add per-item success/failure for batch-like scenarios if 'http' supports multiple endpoints. Current schema suggests single URL, document if multi-request patterns are supported.
Include chaining IDs in 'command' output. If command returns a resource ID, include it so downstream tools can reference it.