> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neo.projectdiscovery.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Tools

> Tools you write yourself to wrap internal APIs, proprietary tooling, and repeatable team workflows

When the built-in and pre-installed tools do not cover something specific to your team, you can create **custom tools** of your own. A custom tool is a small TypeScript or Python function with a defined input and output schema. It is stored in your account and runs inside your sandbox, so it can call internal APIs, wrap proprietary tooling, or encode a repeatable step in your methodology.

## When to create a custom tool

**You have an internal API or service.** If a step in your workflow means calling an internal endpoint, a ticketing system, or a proprietary data source, a custom tool gives the agent a typed, reliable way to do it instead of hand-written curl commands.

**You repeat the same multi-step operation.** Recurring logic like normalizing scan output, enriching a finding, or querying an asset inventory is more reliable as a single tool than as instructions the agent re-derives each time.

**You want to wrap proprietary tooling.** Custom tools let you expose your own scanners or scripts to the agent with a clear contract, so it knows exactly what inputs to pass and what to expect back.

## Anatomy of a custom tool

Every custom tool Neo builds has the same structure:

* **Source code**: a TypeScript or Python function that contains the tool's logic and runs inside your sandbox.
* **Input schema**: the typed parameters the agent must provide when it calls the tool.
* **Output schema**: the shape of the result the tool returns, so the agent can reason about it.
* **When to use**: a description of the situations this tool is for, so the agent knows when to reach for it.
* **Timeout**: how long the tool is allowed to run before it is stopped.

Custom tools are grouped into **toolkits**, which carry the shared setup their tools depend on:

* **Language**: whether the toolkit's tools are written in TypeScript or Python.
* **Dependencies**: packages the tools need, installed when the toolkit is set up.
* **Setup code**: initialization that runs before the tools, such as configuring a client.
* **Environment variables**: configuration and credentials made available to the tools at runtime.
* **Metadata**: tags and descriptions for organizing and discovering toolkits.

## How to create a custom tool

You create and manage custom tools through Neo itself by describing what you want: the operation the tool should perform, its inputs, and what it should return. Neo writes the function, defines the input and output schema, registers it inside a toolkit, and tests it to confirm it runs. You can be as specific or as high-level as you like, and Neo fills in the gaps based on your description.

For example:

```text theme={"system"}
Create a tool that takes a hostname and returns its owner, environment, and
criticality by calling our internal asset inventory API at
https://inventory.internal/api/assets. Read the API token from an env var.
The agent should use it to enrich findings before reporting them.
```

The result is saved as a reusable tool in your account, ready for your agents to use.

## How tools are loaded

Once created, a custom tool can reach your agents in three ways:

* **On-demand**: the agent discovers and calls the tool only when a task needs it.
* **Pinned**: the tool loads automatically on every task.
* **Attached**: the tool is scoped to a specific [custom agent](/platform/agents/custom-agents), so only that agent sees it.

Pinning and attaching let you keep a large library of tools without crowding every agent with all of them at once. Combined with [custom agents](/platform/agents/custom-agents), custom tools let you adapt Neo to workflows the built-in capabilities do not already cover.