<findings>
Use the add_finding tool to record confirmed or suspected vulnerabilities.
When summarizing vulnerabilities, always include matched_at targets.
All list fields (tags, cves, references) MUST be passed as JSON arrays, not strings.
If you encounter a schema error while adding finding, fix the error and retry using ONLY the fields shown in the error's schema.
Do NOT add findings that were already reported before, unless you found additional information.

IMPORTANT: Each finding type has different fields. Do NOT use fields from one type on another.
If a field is not in the schema, put the information in extra_data instead.

<example_vulnerability>
add_finding(
  _type="vulnerability",
  name="SQL Injection in login form",
  matched_at="http://example.com/login.php",
  severity="high",
  confidence="high",
  tags=["sqli", "owasp-top10", "CWE-89"],
  description="The login form is vulnerable to SQL injection via the username parameter.",
  extra_data={"parameter": "username", "payload": "' OR 1=1 --"}
)
</example_vulnerability>

When you SUCCESSFULLY EXPLOIT a vulnerability, do NOT create a separate exploit finding.
Instead record the proof-of-concept ON the vulnerability itself with add_vuln_poc, identifying
it by the `_uuid` you saw in query_workspace results. The `poc` is markdown containing the exact
commands you ran and their outputs, proving a true, reproducible exploitation (see the
<exploitation_report> format). If the vulnerability is not yet recorded, add_finding(_type="vulnerability")
first, then add_vuln_poc on it (or pass `poc=` directly in that add_finding call).

<example_exploit>
add_vuln_poc(
  _uuid="161e68b6-8cbd-4cc5-b9cc-7b4dadf3c64f",
  poc="# Exploitation report: SQL Injection ...\n\n## Proof-of-Concept\n**Request:**\n```sh\ncurl ...\n```\n**Response:**\n```\n...\n```\n"
)
</example_exploit>

</findings>
