Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
CargoShipper provides 6 CloudFlare tools with basic parameter schemas and descriptions, but suffers from critical gaps in documentation and parameter clarity. All tools have descriptions, but they are terse (10-50 chars for most), lack actionable context for LLM selection, and omit prerequisites. Parameter descriptions exist but are often generic (e.g., 'CloudFlare zone ID' repeated verbatim across tools). No output schemas are documented, LLMs cannot predict response structure or plan downstream calls. Error handling is absent from tool definitions; no recovery guidance is provided. The server implements 3 API clients (Docker, DigitalOcean, CloudFlare) but only CloudFlare tools are visible in the submission, making broader assessment difficult. Security is partially addressed via environment-variable secret injection in the server config, but tool definitions themselves do not declare required permissions. Tool naming is reasonable (verb_noun pattern, e.g., cf_list_zones, cf_create_zone) but lacks human-friendly identifier support, all tools demand zone_id and account_id, forcing extra lookup calls when users have only domain names. Composition is acceptable; tools are single-responsibility. Overall, the server is functional but falls short of production readiness, it reads like an early-stage API wrapper rather than an LLM-optimized tool suite.
cf_delete_zone lacks confirmation step or dry-run option. Destructive operations should require explicit user approval before execution to prevent catastrophic errors.
Tool descriptions are too brief (18-68 chars) and lack context on when to select each tool, prerequisites, and downstream dependencies. Descriptions should be 50-200 chars and answer WHAT, WHEN, and WHAT IT RETURNS.
Document output schemas for all tools. For cf_list_zones, specify: returns [{zone_id, name, status, plan, name_servers, updated_at}, ...], total_count, next_page_token. Use JSON Schema in tool definition or in a separate docs file referenced by the tool.
Expand tool descriptions to 50-200 characters. Example: 'cf_list_zones: List all zones in your CloudFlare account. Use this first to discover zone IDs when you have only domain names. Supports filtering by name or status. Returns paginated results.',
Add formal enum constraints to record_type parameters. Instead of relying on prose 'A, AAAA, CNAME, etc.', declare: record_type enum=[A, AAAA, CNAME, MX, NS, TXT, SRV, CAA, PTR, ...] in the schema.
Add confirmation step to cf_delete_zone. Offer a dry_run parameter (default=true) or require an additional confirm_delete=true flag. Error message on destructive operations should state: 'Zone deletion is irreversible and will remove all DNS records. Call cf_delete_zone again with confirm_delete=true to proceed.'
Support human-friendly identifiers. Modify cf_get_zone, cf_delete_zone, cf_list_dns_records, cf_create_dns_record to accept either zone_id OR domain_name. Inside the tool, resolve domain_name to zone_id using cf_list_zones.
Add error recovery guidance to each tool description. Example for cf_create_zone: 'If the zone already exists, error will indicate duplicate. Call cf_list_zones to find the existing zone_id and cf_get_zone to inspect it.'
Document pagination strategy for cf_list_zones and cf_list_dns_records. Specify: 'Results default to per_page=50 (max allowed). If more than 50 items exist, use page parameter to iterate. Last page indicated by count < per_page.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling or recovery guidance. Tools lack descriptions of failure modes, invalid input examples, and what the LLM should do on error (retry, ask user, use alternative tool).
No human-friendly identifier support. All tools demand zone_id (opaque UUID/string) or account_id, forcing extra lookup calls when users have only domain names or account names.
Enum constraints for record_type in cf_list_dns_records and cf_create_dns_record are implicit (mentioned in description text) rather than formally declared in schema. LLMs cannot parse prose enums reliably.
cf_list_dns_records and cf_list_zones lack result limits and pagination guidance. No max_results parameter, no cursor/next_page documentation. Unbounded results risk blowing context window.
No tool-level permission declarations (e.g., 'read:zones', 'write:dns'). Cannot audit what capabilities each tool requires or implement least-privilege agent configurations.
Declare permissions for each tool in its description or add a separate permissions field. Example: cf_delete_zone should note 'Requires: zone:write, account:admin'. cf_list_zones requires 'zone:read'.
Add parameter validation examples to descriptions. For zone_type in cf_create_zone: 'Must be "full" (nameservers managed by CloudFlare) or "partial" (CNAME setup). Most users should choose "full".'
For cf_create_dns_record, add validation rules: 'record_type determines required fields: A/AAAA require valid IPv4/IPv6 content; CNAME requires a domain target; MX requires priority; TXT can contain any string. If content is invalid for record_type, operation will fail.'
Add idempotency guidance. Note which tools are idempotent (cf_list_*, cf_get_*) vs. state-changing (cf_create_*, cf_delete_*). LLMs retry on network failures, idempotent tools are safe to retry without side effects.