> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.method.security/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.method.security/_mcp/server. # Operator-defined Tools > Bring your own tradecraft into Method through evidence collection, existing security tools, proof-of-concept workflows, AI preprocessing, and Courier. Bring Your Own Tool (BYOT) lets teams expand Method's capabilities with their own tradecraft, turning scripts, command-line utilities, and custom workflows into reusable Tools. Tools can take Ontology Objects as inputs, using their properties and relationships alongside parameters such as strings, numbers, and options. Authors validate their implementation and publish a version for operators and Agents to use. Results can become Ontology Objects, relationships, and supporting evidence, using what one Tool discovers to guide the next action. #### [Tools](/platform/core-platform/tools) Learn the concepts behind Tools, their inputs, execution, and results. #### [Create and publish a Tool](/guides/tools/create-and-publish-a-tool) Build a capability in the code editor, validate it, publish, and test the results. ## Use cases and examples ### Use case: Enrich Objects with collected evidence Tools can collect files and other data, then preserve them as attachments on the relevant Ontology Objects. This keeps evidence connected to its source and available for review, reporting, and follow-up investigation. The Tool returns the collected contents for processing. Its Processor creates an `Attachment` with the contents, filename, and MIME type, then adds it to the corresponding Object. Users can revisit that Object to inspect or download its attachments. **Example: Investigate exposed credentials** Application configuration files can contain database passwords, API keys, and service credentials that reveal access to other systems. A Tool can bring those files into Method and attach them to the Host they came from, so an operator can investigate the exposure with the original evidence at hand. An operator can inspect a suspicious configuration, see which Host exposed it, and retain the evidence for reporting or follow-up investigation. ### Use case: Bring existing security tools into Method Artifacts let teams bring their existing tradecraft and community tools into Method. Authors can use these executables and supporting files in Tools, then turn the resulting data into Ontology Objects and relationships that inform future operations. **Using Artifacts in Tools** Artifact families group versions and platform-specific variants of an executable or resource. Tools can use them in two ways: * **[CLI Tools](/platform/core-platform/tools/tool-authoring-reference#cli-tool)** reference an Artifact family. Method selects a compatible executable, downloads it to the Jackal host, runs it, and removes the temporary copy. * **[Courier Tools](/platform/core-platform/courier#how-do-you-use-workflows)** use a Compiler that defines workflow steps directly. They can resolve Artifacts and download them through workflow actions; the author controls how the files are used and when they are removed. **Executing an Artifact** Method-managed Tools such as Port Scan use this same workflow to select, download, and execute an Artifact. **Turning results into Ontology Objects** The Tool must return the executable’s relevant results for its Processor to interpret. Depending on the executable, this may mean capturing console output or collecting generated files. **Example: Investigate exposures with Nuclei** A team could upload the Nuclei executable as a Method Artifact and reference it in a Tool that runs a selected set of scanning templates and returns JSONL results. A custom Processor could map detected exposures to the relevant Ontology Objects and relationships, while preserving the scan output as an attachment. The structured results and supporting evidence give operators context for further investigation and subsequent Tool runs in Method. ### Use case: Turn a proof of concept into operational Tools BYOT lets teams turn a proof of concept into reusable Tools that work with their environment in Method. Authors define the inputs, execution logic, and result processing, connecting vulnerability research to findings and follow-up actions. These three NetScaler Tools show how the same proof of concept can support different stages of an investigation. #### Example 1: Confirm an exposure The **NetScaler CVE-2026-88772 Probe** uses a Script Tool to run Bash and existing utilities such as `curl` on the Linux Jackal host. This living-off-the-land approach avoids downloading a separate scanner executable. Operators can test a WebApplication already modeled in Method without re-entering its server details. When the probe confirms execution, the Tool records a CVE Instance linked to that application, preserving the finding as a starting point for follow-up investigation and Tool runs. #### Example 2: Investigate the impact The **NetScaler CVE-2026-88772 Execute** Tool is also a **Script Tool**, using Bash and existing utilities on the Linux Jackal host without downloading a separate scanner executable. This living-off-the-land approach supports follow-up investigation from the same execution environment. It takes the CVE Instance created by the probe as its input. The Compiler follows its relationships to resolve the target and prepares the operator’s selected action: system information, a network snapshot, or scoped TCP enumeration. The Processor validates the returned evidence, with results available in the execution Signal. Operators can move from confirming an exposure to investigating its impact without re-entering target details. #### Example 3: Run a command with evidence and cleanup checks The **NetScaler CVE-2026-88772 WebShell** Tool is a **Script Tool** that runs from a Linux Jackal. Its script coordinates temporary installation of an HTTP command endpoint on the affected appliance, submits an operator-supplied command, captures its response, and attempts cleanup. This lets operators investigate what the vulnerability makes accessible and demonstrate its practical impact. The Compiler uses an existing CVE Instance to resolve the target and populate the script’s inputs. Response evidence stays available in Method, while a custom Processor requires a validated response and checks that the endpoint is no longer accessible before reporting the run as successful. Together, these examples show how authors can connect **confirmation, investigation, and command execution** through shared Ontology Objects, with each Tool defining the evidence required to assess its results. *These Tools support NetScaler build **`14.1-73.30.nc`** and deliberately fault its packet-processing engine, which can interrupt traffic. The Probe and Execute Tools submit cleanup attempts; the WebShell Tool additionally checks endpoint absence.* ### Use case: Make unstructured output usable in Method with AI AI preprocessing lets authors extract structured data from text output without writing a custom parser for every format. An assistant returns the fields the Processor expects, which the Processor uses to create Ontology Objects. **Example: Normalize DNS lookup results** The **Courier AI DNS Lookup** Tool runs `nslookup` for a selected FQDN. Its output can vary across platforms and include DNS server details, aliases, and multiple answers. An AI assistant can be instructed to distinguish the queried domain’s addresses from the DNS server’s address and return the domain name and IP addresses as structured JSON. The Processor uses those fields to create FQDN and IP Address Objects in Method, making the results available for investigation and subsequent Tool runs. ### Use case: Coordinate multi-step operations with a Courier compiler Courier compilers give authors control over how a Tool executes. They can combine actions, pass values between steps, and declare outcomes that Method tracks, allowing one Tool to prepare resources, perform an operation, and establish new capabilities for follow-up work. Available actions include: * **Run shell commands**, including Bash, Zsh, and PowerShell. * **Download files**, including executables and supporting Artifacts. * **Exfiltrate files** from the Jackal’s host. * **Configure execution environment variables** for subsequent steps. * **Invoke custom Courier actions** supported by the Jackal. Steps can declare outcomes such as generated signals, created files, and newly deployed Jackals. Courier Tool authors can also use Method services to resolve Artifacts and create enrollment credentials for new Jackals. **Example: Combine an executable with a Jackal drop** You can build a Tool that runs an executable and deploys a new Jackal in the same Courier workflow. Its Compiler resolves the executable and Courier Artifacts, creates enrollment credentials, and prepares the steps to run them. The workflow can collect execution output for the Processor and declare a dropped-Jackal outcome so Method associates the newly enrolled Jackal with the Tool run. Once that Jackal checks in, you can select it for subsequent Tool runs, connecting follow-up work to the workflow that deployed it. ## Build a Tool for your use case Choose the result you want to produce, identify its inputs and execution requirements, and use the corresponding Compiler approach. Validate the implementation with representative inputs and output, publish a version, and test the published behavior. See the [Tool authoring FAQs](/platform/core-platform/tools#tool-authoring-faqs) for compatibility, Rules of Engagement, and supported integrations. #### [Create and publish a Tool](/guides/tools/create-and-publish-a-tool) Follow the authoring workflow with examples drawn from these use cases. #### [Tool authoring reference](/platform/core-platform/tools/tool-authoring-reference) Look up the definition fields, Compiler interfaces, and output processing details.