> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enginy.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Supported Tools
> See what Enginy MCP can do today, how its tools are generated, and which capability families are currently exposed.
## What this page covers
This page answers a simple question: what can an AI assistant realistically help with in Enginy today?
Enginy MCP does not ship a separate hand-written tool catalog. Instead, the MCP server reads Enginy's public API document and turns supported API operations into MCP tools. That means the MCP surface stays aligned with the public API.
The current MCP server also exposes one native tool:
* `mcp_whoami`, which returns the authenticated user, client, and granted scopes
## What an assistant can help with today
The current surface is broad enough for real operator workflows. Representative capability families include:
| Capability family | Representative things you can do |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Workspace | Read workspace metadata, credits, saved views, and validation helpers; create, read, and delete saved filters |
| Identities | Inspect sender identities and identity performance |
| Owners | Look up CRM owners for routing and assignment flows |
| Campaigns | Read campaigns and folders, create campaigns, clone campaigns, and change campaign state |
| Contacts | Search contacts, read contact fields, create contacts, and update contacts |
| Companies | Search companies, read company fields, create companies, and update companies |
| Lists | Read lists and folders, create, update, or delete lists, and move members |
| AI variables | Read AI variables and folders, create or update them, and delete them |
| Analytics | Read analytics exports and campaign analytics |
| AI Finder | Preview, refine, and import new prospect lists; use `identityId` only for explicit identity-specific LinkedIn searches |
| Actions | Inspect action-run state and trigger action-style workflows such as imports |
| Messaging | Read inbox threads, tags, and conversation messages; send replies; mutate thread state |
| Webhooks | Read webhook subscriptions and logs, and create, update, delete, or test webhooks |
| Workflows | Build, validate, publish, run, and monitor advanced (graph) workflows — see the [agent guide](/mcp/workflows) |
In practice, what the assistant can successfully do depends on two things: whether the action exists in the
public API, and whether the approved permissions allow it. If a tool exists but your permissions are too
narrow, the call will be blocked when the assistant tries to use it.
## Advanced: how tool inputs are shaped
OpenAPI-derived tools follow a simple input pattern:
```json theme={null}
{
"pathParams": {
"id": "123"
},
"query": {
"limit": 25,
"includeArchived": false
},
"body": {
"name": "Example"
}
}
```
In practice:
* `pathParams` holds route parameters; numeric values are accepted for string-typed ID parameters and are serialized into the path as strings
* `query` holds query-string arguments
* `body` holds JSON request bodies
The tool name usually comes from the OpenAPI summary. If names would collide, Enginy falls back to a method-plus-path style name. Tool names are always 64 characters or fewer.
## Tool annotations
Every tool advertised in `tools/list` carries MCP annotations so clients can reason about safety before calling:
* `title`: a human-readable label.
* `readOnlyHint`: `true` for tools that only read data, `false` for tools that create, update, or delete data.
* `destructiveHint`: `true` on write tools that modify or remove data.
* `idempotentHint`: `true` when repeating the call with the same arguments has no additional effect.
Read versus write is derived from the operation's required scope (for example, a `*_write` scope marks a tool as a write), so the hints stay aligned with what the public API actually does.
## What is not guaranteed yet
* Tool names can change if the OpenAPI summary changes.
* Coverage changes whenever Enginy's public API surface changes.
* Some operations may not be available if they are not part of the public contract.
* `mcp_whoami` is the only native MCP tool today; the rest are generated from OpenAPI.
* The MCP server is remote Streamable HTTP only. It is not a local stdio server.
## What to try first
If you are deciding whether MCP is useful for your workflow, start with:
1. `mcp_whoami` to confirm the connection and granted scopes.
2. The [overview page](/mcp/overview) to understand the transport and policy model.
3. The [scopes page](/mcp/scopes) to see which permission families unlock which tools.
4. The [client setup page](/mcp/custom-clients) if you need Claude, Codex, Cursor, or VS Code wiring.
Review the hosted server model, OpenAPI-derived tool generation, and runtime policy enforcement.
See how to connect Enginy MCP from Claude, Codex, Cursor, VS Code, ChatGPT developer mode, and more.
Match the tool families above to the scope groups that unlock them.
Debug auth, scope, and compatibility problems before assuming the server is broken.