Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Huntaway: SailPoint ISC MCP who can see the Onboard Contractor launcher"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for SailPoint Identity Security Cloud that lives inside VS Code. Once a tenant is added, Copilot Chat (and any other MCP client the editor hosts) can search identities, read workflows with their diagnostics, replay what a workflow actually did, trace a launcher to the people who can see it, inspect form instances, list accounts on a source, use SailPoint's hosted access-request tools, and compare two tenants for drift.
Nothing to install beside the extension. The server runs on the editor's own Node.js.
Open the Huntaway view in the activity bar and choose Add Tenant.
Give it a short key (dev, prod, sandbox), a label, and its API host, https://<tenant>.api.identitynow.com.
Enter a client id and secret. Prefer a Personal Access Token: an API client has no user context, so workflows, forms, launchers and work-items return 403 through it whatever its scopes.
In chat, ask for something: "list the workflows on dev", "who can see the Onboard Contractor launcher", "compare transforms between dev and prod".
Credentials go to VS Code's secret storage (the operating system keychain) and reach the server only as an environment variable of its own process, at start. They are never written to settings.json, so Settings Sync and a committed .vscode folder cannot carry them.
Test Connection on a tenant proves the credential and tells you whether it has user context; the result stays on the tenant's row.
Related MCP server: Azure DevOps MCP Server
Each tenant in the Huntaway view opens into its object types: sources, identity profiles, identity attributes, transforms, workflows, launchers, forms, access profiles, roles, governance groups, non-employee sources, campaign templates and SoD policies, with a count per type. Click an object to open its JSON read-only in an editor. The listing is read once per session; Refresh re-reads it. Nothing here writes to the tenant.
Tool | What it does | Writes? |
| Lists tenants and measures each credential's reach by probing the four user-context endpoints. | No |
| Search queries against the search index. | No |
| Reads identities directly, so values are current, with an optional sweep for unresolved templates. | No |
| Lists workflows, or reads one with step count against the licence cap, OAuth bind state per http step, and unreachable steps. | No |
| Recent executions and, on request, every step's real input, output and error. | No |
| Launchers, and for one launcher the whole gate chain: workflow, forms, entitlement, access profile, role and member count. | No |
| Form instances with their | No |
| Accounts on a source, with an optional sweep for unresolved templates. | No |
| Logic drift between two tenants for one object type, with ids, timestamps, owners, email addresses and each tenant's environment tokens masked. | No |
| SailPoint's hosted access-request tools, through the tenant's own endpoint. | create and cancel |
| The tenant's data-flow diagram and attribute-level source-to-target map, in Huntaway's DFD model: sources, identity profiles with transforms dereferenced, CREATE policies, attribute sync, correlation, and the issues found on the way. | No |
| Bulk-create non-employee records from a tab-separated export with the notice workflows held off until every identity has settled. | apply, restore, rollback |
| A SIT case register (JSON) with its verdict log (JSONL): list what is open, read a case, record a verdict with redacted evidence. | the results log only |
| What a workflow actually did since a time, optionally for one identity: steps run, every send with recipients tagged (never a raw address), subject and body redacted, a leak check, cards, the failing step. | No |
| Run a launcher as a person would: launch, follow its own execution, submit each form in turn, optionally cancel, return the evidence. Guarded by the SIT profile. | Yes |
| Any method, any path. The escape hatch. | Any method but GET |
Read tools are marked read-only. The two that can write require confirm: true, which the assistant may set only after you have agreed to that specific change, and the editor asks before running them.
The step cap is enforced on enable, not on save. A workflow already above it was grandfathered in while enabled and cannot be re-enabled once disabled. isc_workflow says so before you touch it. Set your licence's cap in Settings: Huntaway ISC: Workflow Step Cap (20, 50 or 100).
An http step's OAuth binding is builder-only. Writing param_oauth/refID through the API leaves an unbound shell that fails at runtime. isc_workflow reports bound: false per step.
Launcher visibility is an entitlement, not an admin level. The gate entitlement matches on the launcher's id as its value, never its name. isc_launchers walks the chain and reports the two usual causes: no gate entitlement, or a gate role matching zero identities.
A 200 on a form submit does not mean it was submitted. A validation failure leaves the instance IN_PROGRESS; isc_form_instances shows the formErrors.
The search index lags. When the answer drives a decision, confirm with isc_identity.
isc_nonemployee_load is the contractor loader generalised. Nothing about a tenant is in the extension: a load profile JSON you keep beside the data names the non-employee source, how a login, uid and address are formed, which file columns feed which record fields, which reference sources hold the codes, the form whose option lists validate values, the notice workflows to hold off, the lifecycle timing and the quiet windows. resources/examples/nonemployee-profile.example.json is a complete starting point.
The sequence is plan (a dry run: every line comes back LOAD or SKIP with the reason, plus a PLAN DIGEST), then apply with confirm: true and that digest. The apply runs as a job inside the server: it snapshots the identities it watches, disables the notice workflows (the STATE file on disk names them before the first write), creates one record at a time with a write-ahead entry in the RESULTS file, waits for every created identity to settle, and only then re-enables the workflows. If anything is not right they stay off and the reply names the restore to run. rollback deletes what a results file created, the same way. Work files live under ~/.huntaway-isc/<tenant> (override with HUNTAWAY_ISC_WORK_DIR).
A POST whose answer was lost is never re-sent: the record is found by login. A record counts as gone only on two 404 reads. A workflow whose definition changed while it was off is never re-enabled by the tool.
Three tools carry a SIT: isc_sit_cases keeps the register and the verdicts (PASS, FAIL, NOTE, KNOWN, NA, ERROR, BLOCKED; latest wins, evidence redacted on write), isc_launch runs a case's launcher through its forms, and isc_workflow_evidence reads what the workflows then did. A SIT profile JSON (optional) names the role mailboxes so recipients come back as tags such as IS or CAM rather than addresses, the suffix of generated mailboxes, the launchers and form keys the harness must refuse, and a fixture token every onboarding name must carry. resources/examples/sit-profile.example.json is a starting point. The case handlers themselves, what to launch with which data and what to assert, are yours; these tools are the primitives every one of them needs.
Objects pair by name. Each tenant can carry environment tokens (set on the tenant, for example DEV, dev-tenant on one side and UAT, uat-tenant on the other). They are masked to <ENV> before the diff, as are ids, timestamps, owners, health, run counters and email addresses. enabled is deliberately not masked. Recipient fields are counted separately, because a build tenant routes mail to a test address on purpose.
VS Code 1.101 or later. Nothing else.
The extension talks only to the tenant hosts you configure. Responses are returned to the chat you are in and are not stored by the extension. Every result names the tenant that answered.
npm ci
npm test # builds, then unit tests and a stdio round trip against a fake API
npm run package # builds, gates, packages, unzips the .vsix and gates its contentsThe leak gate (scripts/leak-gate.mjs) fails packaging on email addresses, object ids, tenant hosts, credential-looking values and a private term list that is never committed. Put yours in .leak-gate.local (gitignored) and in the LEAK_GATE_TERMS repository secret.
No token publishes from CI: global Marketplace PATs retire on 1 December 2026. A v<version> tag runs the Release workflow, which builds and gates the .vsix (as a pre-release for every 0.x version) and attaches it to a GitHub Release. Then:
Download the .vsix and install it locally once: code --install-extension <file> --force.
Upload it at https://marketplace.visualstudio.com/manage/publishers/huntaway.
The same by hand: npm run package -- --pre-release. When publishing should be automatic, the route is Azure Pipelines with a managed identity and vsce publish --azure-credential.
MIT. SailPoint and Identity Security Cloud are trademarks of SailPoint Technologies. This extension is not affiliated with SailPoint.
This server cannot be deployed
mtdt.io MCP: Salesforce DevOps platform connector (metadata deployments, backups and more)
One OAuth connector for your team's remote MCP servers, with Tool Packs, guardrails and logs.
Remote MCP for 1,500+ APIs. Vault-managed credentials; OAuth or API key. Search, load, and execute.
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
