Tool Reference

Fourteen tools, grouped below by what they act on. Your assistant picks them itself — you describe what you want in plain language and it chooses the calls. This page is here for when you want to know what it is capable of, or why it did something.

Every record is addressed by UUID, never by name. That is why almost every session starts with search-projects.

Projects

Tool	What it does
search-projects	Searches the projects you can access and returns each one’s UUID. The starting point for everything else.
get-project	Reads one project in full — client, assessment types, status, and finding counts by severity.
list-project-statuses	Lists the status columns defined in your instance, with their slugs.
set-project-status	Moves a project to a different status column.

Statuses are defined per instance, so set-project-status requires a slug from list-project-statuses rather than a guess. If your assistant invents one, the tool rejects it and tells it to go and read the list.

Findings

Tool	What it does
search-findings	Lists findings on a project, optionally filtered by text, status, or severity. Returns summaries.
get-finding	Reads one finding in full — description, impact, CVSS, proof of concept, remediation, affected hosts.
list-finding-statuses	Lists the finding status slugs defined in your instance.
get-finding-writing-instructions	Returns your instance’s house style for finding fields — what a description, proof of concept, or remediation should look like.
report-finding	Creates a finding, optionally inheriting everything from a vulnerability template.
update-finding	Changes fields on an existing finding. Only the fields passed are touched.
update-finding-remediation	Changes only the remediation guidance — the common edit during a retest.

search-findings deliberately omits proof of concept and remediation from its results. Those are long, and returning them for every finding on a project would fill the assistant’s context with text it did not ask for. It fetches the full record with get-finding when it needs the detail. Filtering by status requires a slug from list-finding-statuses — the same pattern as project statuses. An invented slug is rejected and the assistant is told to read the list.

get-finding-writing-instructions is worth knowing about for the same reason as templates: it changes the quality of what gets filed. Your instance’s field-level tooltips (description, impact, proof of concept, remediation, and so on) are returned as instructions the assistant is told to follow before writing. If your team has house style in those tooltips, findings created over MCP will reflect it; if they are empty, the assistant writes freehand.

Templates

Tool	What it does
search-templates	Searches your reusable vulnerability templates.

Worth knowing about, because it changes the quality of what gets filed. If you ask for a finding to be created from a template, it inherits your house description, remediation text, and CVSS vector, and only the engagement-specific details get written fresh. Ask for a finding without one and the assistant writes the whole thing from scratch.

Comments

Tool	What it does
add-comment	Adds a comment to a finding or a project.

Comments made this way behave exactly like ones typed into the web UI: they appear in the activity feed, notify the same people, and — on findings — sync to Jira if you have the integration configured.

Instance

Tool	What it does
get-instance-details	Returns the instance’s name, URL, and version, plus the acting user’s name, email, and roles.

Handy when you have more than one PentestPad instance connected (say, staging and production, or two tenants) and want the assistant to confirm which one it is about to act on before a write.

A worked example

A retest pass, end to end:

Find the Acme External Pentest project.

search-projects → returns the project and its UUID.

Show me the open SQL injection findings on it.

search-findings with a text filter → returns summaries.

Read the first one.

get-finding → returns the full record including the original proof of concept.

I’ve retested it and the fix works. Update the remediation to note that parameterised queries are now in use, and add a comment saying it was retested today and is resolved.

update-finding-remediation, then add-comment.

Limits worth knowing

• No deletions. There is no tool to remove a finding, project, client, user, or report. Do that in the web UI.
• No report generation. Reports are still produced from the Reports page.
• No client, user, or team management.
• No CSV import. Use the CSV import API or the web UI.
• update-finding will not change affected hosts. The underlying operation replaces the whole host list rather than adding to it, so a partial list would silently delete hosts. Edit hosts in the web UI.
• Task comments are not supported — only findings and projects.

Why the list is short

Every tool’s name, description, and full input schema is sent to the model on every turn, and assistants get measurably worse at picking the right tool as the list grows. The surface is kept deliberately small and shaped around real workflows rather than mirroring the REST API. report-finding, for example, takes a template and the engagement-specific details and does the lookup, creation, and field merging in one call, instead of making the assistant chain three requests and hoping it gets the order right.

If you need something not listed here, the REST API covers the full surface.