Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Aegis MCP has 21 tools with visible schemas and descriptions in server/main.py. However, multiple critical issues reduce quality significantly: (1) All tools require a 'token' parameter exposed as an input parameter, violating secret-injection pattern, credentials should be server-side injected, not parameters. (2) Descriptions are present but vary in quality: most are 50-150 chars (acceptable), but lack actionable guidance on WHEN to use each tool or dependencies between tools. (3) Parameter descriptions are generic ('Bearer token for authorization' repeated 21 times) and don't explain formats/constraints. (4) No output schemas documented in the source code, we see function signatures but no explicit schema definitions for return types. (5) Error handling is absent from the visible code, no guidance for LLMs on recovery paths. (6) Several tools have concerning security implications (port_scan, semgrep_scan, security_scan_secrets accessing local filesystem) with warnings in descriptions but no auth/permission gates shown in code. (7) Tool composition is reasonable (each does one thing) but chaining references are missing, e.g., k8s_list_pods returns pods but unclear if pod names/IDs match what k8s_security_audit expects.
All 21 tools expose 'token' parameter (Bearer token) as an input parameter. Credentials should NEVER appear in tool parameters, they are logged in agent traces, prompt history, and audit logs. This is a critical security violation affecting all tools.
CRITICAL: Remove 'token' parameter from all 21 tools. Implement server-side secret injection via environment variables (e.g., AWS_ACCESS_KEY_ID) or a vault. Update _authorize() to fetch credentials from secure context, not function parameters. Agent traces will no longer leak credentials.
CRITICAL: Document output schemas for all tools. For each tool, add a schema describing response field names, types, and cardinality. Example for aws_list_ec2_instances: return {instances: [{instance_id: string, state: string, instance_type: string, tags: {key: string, value: string}[]}]}. This enables LLM planning and chaining.
HIGH: Add enum constraints to parameter schemas. Replace 'severity: {type: string, description: "..."}' with 'severity: {type: string, enum: ["CRITICAL", "HIGH", "MEDIUM", "LOW"]}'. Do this for security_scan_terraform, security_semgrep_scan, and jenkins parameters.
HIGH: Implement error handling and recovery guidance. When a tool fails, return structured errors: {error: "Invalid region: us-west-9. Valid regions: us-east-1, us-west-1, eu-west-1, ..."} with actionable suggestions. For destructive operations (jenkins_delete_job), require explicit confirmation or add a dry_run parameter.
HIGH: Add pagination to list tools (aws_list_ec2_instances, k8s_list_pods, jenkins_list_jobs). Introduce 'limit' (default 20, max 100) and 'cursor'/'offset' parameters. Return {items: [...], total: number, next_cursor: string | null} so LLMs can iterate over large result sets without context explosion.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 13 points across a rubric change (v1 → v2)
49/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
49
<=2025-11-25
v2
2026-03-09
C
62
-
v1
65/100
Get information about a specific Jenkins build including result, duration, and status.
Scan local files or directories for exposed secrets (API keys, tokens, passwords). This tool runs locally and has full access to the user's local filesystem (e.g. C:\... paths).
Scan Terraform (.tf) files for security misconfigurations (S3, IAM, RDS, EC2, networking, encryption, credentials). Optionally filter by severity (CRITICAL, HIGH, MEDIUM, LOW). This tool runs locally and has full access to the user's local filesystem.
Run a Semgrep SAST scan on a local directory or file. This tool runs locally and has full access to the user's local filesystem (e.g. C:\... paths). Config can be 'auto', 'p/python', 'p/javascript', etc.
No output schemas documented. Function signatures show return types (list[dict], dict) but actual field names, types, and structure are not documented in visible code. LLMs cannot plan downstream tool calls or extract the right data without knowing what fields to expect.
Parameter descriptions lack actionable constraints. 'token' is described identically 21 times as 'Bearer token for authorization' without format, encoding, or validation guidance. Other parameters like 'severity' (CRITICAL, HIGH, MEDIUM, LOW) have enums mentioned in tool descriptions but not in parameter schemas. Schemas visible in code show 'type:string' with no enum constraints.
No error handling guidance in visible code. If a tool fails (e.g., aws_list_ec2_instances with invalid region, jenkins_delete_job on missing job), there's no indication of whether the error is retryable, what the LLM should do next, or what invalid input caused the failure. Agents have no recovery path.
Destructive tools (jenkins_create_job, jenkins_trigger_build, jenkins_delete_job) lack confirmation/dry-run steps. An agent can delete a job or trigger an unintended build without a checkpoint. No evidence of confirmation_request pattern or permission gates in visible code.
Tool composition gaps: k8s_list_pods returns 'list[dict]' but no specification of whether keys are 'pod_name', 'name', 'namespace', or something else. If k8s_security_audit expects 'pod_name' and k8s_list_pods returns 'name', the agent must infer the mapping. Broken chains force discovery detours.
Security tools with filesystem access (security_scan_secrets, security_semgrep_scan, security_scan_terraform) accept arbitrary 'path' parameters without validation or sandboxing. Descriptions warn of 'full access to user's local filesystem' but no code-level guards, ACLs, or path traversal checks are visible. An agent could be tricked into scanning sensitive directories.
No pagination support documented. Tools returning lists (aws_list_ec2_instances, k8s_list_pods, jenkins_list_jobs) have no limit, offset, or cursor parameters visible. A region with 1000s of EC2 instances would return all at once, exhausting context window and inviting hallucination.
Parameter naming inconsistency: Jenkins tools accept 'api_token' but most other tools accept 'token'. Also, some parameters like 'hostname' (security_check_ssl_certificate) and 'host' (network_port_scan) use different names for the same semantic concept. LLMs conflate similar names and may pass wrong values.
Tool descriptions mention examples and enums in prose ('CRITICAL, HIGH, MEDIUM, LOW') but JSON schemas show only 'type: string' with no enum constraint. Descriptions state 'config can be auto, p/python, p/javascript' for security_semgrep_scan but no schema enum prevents invalid values like 'p/java' from being passed.
security_scan_terraformsecurity_semgrep_scan
HIGH: Document tool chaining. Add notes in descriptions: 'Use k8s_list_pods first to discover pod names, then pass pod_name to k8s_security_audit for per-pod audits.' Ensure output field names match downstream tool parameter names (e.g., k8s_list_pods returns pod_name, k8s_security_audit accepts pod_name).
HIGH: Add path validation and sandboxing to filesystem-access tools. For security_scan_secrets, security_semgrep_scan, and security_scan_terraform, reject absolute paths outside a safe root (e.g., /home/appuser/projects), deny traversal (../) and symlink access, and log all filesystem operations for audit.
MEDIUM: Standardize parameter names across tools. Use 'token' consistently (or 'api_token' for external APIs), 'host' for network targets (not hostname), and 'region' for AWS. Consistency reduces LLM confusion and parameter mapping errors.
MEDIUM: Move enum definitions from prose descriptions into schema. For security_semgrep_scan config, add enum: ["auto", "p/python", "p/javascript", "p/typescript", ...]. For security_scan_terraform severity, add enum: ["CRITICAL", "HIGH", "MEDIUM", "LOW"].
MEDIUM: Add tool annotations (readOnlyHint, destructiveHint) to the FastMCP tool registration. Mark read-only tools (list_pods, check_ssl_certificate) with readOnlyHint=true. Mark destructive tools (jenkins_delete_job, jenkins_create_job) with destructiveHint=true. This helps agents and clients reason about risk.
MEDIUM: Add permission gates and audit logging. The code shows an _authorize() function but it's unclear if permission checks are actually enforced. Ensure each tool validates the 'token' (when used as a capability token, not a secret) against role_policies and scope_policies before execution. Log successful and failed authorization attempts with tool name, timestamp, and principal.
MEDIUM: Reduce parameter cardinality for Jenkins tools. jenkins_list_jobs, jenkins_get_job_info, and others repeat url, username, api_token in every call. Consider storing Jenkins connection details server-side and using a connection_name parameter instead, or accept a single 'jenkins_connection_id' and load credentials from config.
LOW: Add request timeouts and circuit breakers. External service calls (AWS, K8s, Jenkins, Trivy) need explicit timeouts (e.g., 30s). If a service is unresponsive, return a clear timeout error instead of hanging, so agents can retry or escalate.
LOW: Improve parameter descriptions. Instead of 'Bearer token for authorization', describe the format: 'JWT-encoded bearer token with scopes read:aws-ec2. Base64-decode and verify signature with the JWKS endpoint at /auth/.well-known/jwks.json.' This helps debugging and enables security audits.