Provides tools for interacting with the Intigriti bug bounty platform, allowing users to list programs, retrieve scope details, diff scope changes over time, and receive program recommendations based on a personal skills profile.
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., "@intigriti-mcp What programs should I target based on my skills?"
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.
MCP server for the Intigriti bug bounty platform. Lists programs, pulls scope details, diffs scope changes over time, and recommends the best-fit programs based on your skills profile — with a boost for programs whose scope was recently updated.
Implements the Intigriti Researcher API v1.
Endpoint paths (/v1/programs, /v1/programs/{id}), response shapes
(pagination envelope, enum/money view-models), and field mappings are verified
against Intigriti's published OpenAPI spec.
Tool | Description |
| All programs visible to your token, with status, rewards, confidentiality level, and industry. |
| Full asset list with endpoint, type, tier, description, and in/out-of-scope flag + scope version timestamp. |
| Fetch current scope, diff against the last stored snapshot (added/removed/modified), update snapshot. |
| Score all active programs against your skills manifest, ranked best-fit first. |
Related MCP server: VulneraMCP
npm install
npm run buildSet environment variables:
export INTIGRITI_API_TOKEN="your-researcher-api-token" # required
export INTIGRITI_SKILLS_PATH="./skills.json" # optional, default shown
export INTIGRITI_SNAPSHOT_PATH="./data/scope-snapshots.json" # optional, default shownGenerate a Personal Access Token (PAT) from your Intigriti profile:
Personal access tokens. Auth is Authorization: Bearer <PAT>.
Copy skills.example.json to skills.json and edit it to reflect your
strengths — each entry is a skill/vuln-class, a confidence weight (0–1), and
the asset types it applies to:
{ "skill": "ssrf", "weight": 0.8, "appliesTo": ["api", "url"] }skills.json is git-ignored since it's personal.
Standalone:
npm startAs an MCP server in your client config (point at the built entry point with the env vars above):
{
"mcp": {
"intigriti": {
"type": "local",
"command": ["node", "/path/to/intigriti-mcp/dist/index.js"],
"enabled": true,
"environment": {
"INTIGRITI_API_TOKEN": "{env:INTIGRITI_API_TOKEN}",
"INTIGRITI_SKILLS_PATH": "/path/to/skills.json",
"INTIGRITI_SNAPSHOT_PATH": "/path/to/scope-snapshots.json"
}
}
}
}recommend_program fetches every active program's scope, then for each skill
in your manifest counts how many in-scope assets match that skill's declared
asset types (appliesTo):
score = Σ(skill weight × matching asset count) / total in-scope assetsNormalizing by asset count means a program isn't favored just for being
bigger. See src/scoring.ts; the matching logic is intentionally simple to
start — extend it there as your manifest gets richer.
Intigriti publishes a scope version timestamp per program
(domains.createdAt). If it's within the recency window (default 14 days),
the score is multiplied by a factor that decays linearly from a max boost
(default 1.25× for a just-updated scope) down to 1.0 at the window edge.
This surfaces freshly-changed programs before they cool off. Boosted results
include a note like:
Recency boost 1.214x — scope published 2.0d ago (window 14d, max 1.25x)Tune it per call: recommend_program(topN=10, recencyWindowDays=7, maxRecencyBoost=1.5).
Asset types are normalized to the manifest's vocabulary
(website/wildcard → url, web_service → api).
Out-of-scope assets (tier "Out Of Scope") are excluded from scoring.
Scope snapshots are stored as flat JSON at INTIGRITI_SNAPSHOT_PATH
(default ./data/scope-snapshots.json), keyed by program ID. Swap
ScopeStore for a SQLite-backed version if this grows large or you want
historical diff queries instead of just "since last check".
src/intigritiClient.ts — API client + response mapping
src/scoring.ts — program scoring and recency boost
src/scopeStore.ts — scope snapshot persistence and diffing
src/skillsManifest.ts — loads your skills.json
src/index.ts — MCP tool wiring
Fetch a program's current scope and compare it against the last stored snapshot, returning added/removed/modified assets. Updates the stored snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| programId | Yes | The Intigriti program ID or handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so well. The critical side effect is explicitly disclosed ('Updates the stored snapshot'), which is exactly the kind of mutating behavior an agent must know about. The only gaps are unspecified first-run behavior (what happens when no snapshot exists yet) and no mention of whether the update overwrites or appends history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The primary action is front-loaded, the result type (added/removed/modified assets) follows, and the side effect is stated last. Every sentence earns its place and the most decision-relevant information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core behavior, the result shape at a high level, and the side effect. The notable gap is undefined behavior on first invocation when no stored snapshot exists — a real operational question for a stateful diff tool. Explicit routing versus get_program_scope would also strengthen it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not add parameter details — the schema already documents programId as 'The Intigriti program ID or handle.' The description adds nothing about parameter semantics, but the baseline of 3 applies because the schema fully covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource combination: fetch a program's current scope, compare against a stored snapshot, and return added/removed/modified assets. This clearly distinguishes it from sibling tools: get_program_scope (static fetch without diff) and list_programs (enumerate programs). An agent can immediately tell what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied rather than stated: an agent would infer to use this tool when it needs change detection over time. However, there is no explicit guidance on when NOT to use it or a pointer to get_program_scope for cases where only the current scope is needed. The sibling distinction is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full in-scope/out-of-scope asset list and metadata (headers, rate limits) for a single program.
| Name | Required | Description | Default |
|---|---|---|---|
| programId | Yes | The Intigriti program ID or handle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a readonly fetch and specifies the returned content (asset list, headers, rate limits), but it does not mention authentication requirements, error behavior, or data freshness. These gaps keep it at a minimum-viable level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, and the most important information is front-loaded. Every part of the description contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema, the description explains what will be returned: the asset list and metadata including headers and rate limits. It does not cover edge cases like invalid program IDs or empty scopes, but it provides enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents programId. The description adds no additional meaning beyond the schema, which meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and names the exact resource: the full in-scope/out-of-scope asset list plus metadata. It also scopes the operation to a single program, which clearly distinguishes it from list_programs and the other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use this when you need scoped assets for one particular program, not a list of programs. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Intigriti bug bounty programs visible to this researcher account, with status and reward info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses account-scoped visibility and the presence of status/reward info, but does not state whether results are paginated, ordered, limited, or provide any response shape. Adequate for a simple read-only list, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence that front-loads the verb and resource, provides scope, and names the key output content without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is sufficient: it identifies the resource, the account scope, and the returned information fields. The lack of an output schema is partly mitigated by naming 'status and reward info', though exact response structure is not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete and there is nothing for the description to add. The baseline of 4 for no-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb ('List'), a clear resource ('Intigriti bug bounty programs'), and a scoping qualifier ('visible to this researcher account'). It also names the included output fields ('status and reward info'), making it distinct from the sibling scope-focused tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for getting an account-level overview of bug bounty programs with status and reward information. However, it does not explicitly state when to use it instead of alternatives like get_program_scope or recommend_program, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score all active programs against your skills manifest (INTIGRITI_SKILLS_PATH) and return them ranked best-fit first. Programs whose scope was recently published get a decaying recency boost so newly-updated programs surface higher.
| Name | Required | Description | Default |
|---|---|---|---|
| topN | No | Limit to top N results (default: all) | |
| maxRecencyBoost | No | Max score multiplier for a just-updated scope, decays to 1.0 over the window (default: 1.25) | |
| recencyWindowDays | No | Recency boost window in days (default: 14) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does disclose meaningful behavior: it scores only active programs, uses the skills manifest, returns ranked results, and applies a decaying recency boost. It does not describe possible side effects or output structure, but for a read-like ranking operation these omissions are relatively minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core operation and result, then adds the relevant recency-boost nuance in a concise second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description usefully states that the result is a ranked list of programs and explains the scoring context. The main gap is that it does not specify the output item shape or error conditions, but the essential behavior needed to decide whether and how to call it is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented in the schema. The description adds some conceptual context for the recency boost ('decaying', 'newly-updated programs surface higher'), but it does not add meaningful detail about topN or a need to clarify parameter formats beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Score all active programs against your skills manifest' and returning them 'ranked best-fit first'. This clearly distinguishes it from the siblings (list_programs, get_program_scope, diff_scope) by emphasizing ranking and fit scoring rather than plain listing or diffing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly conveys the intended use case—when you need programs ranked against your skills manifest—but does not explicitly contraindicate when to use list_program or get_program_scope instead. The context is clear enough that an agent can infer when this is the right tool, but no exclusions or alternative routes are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0diff_scopeget_program_scopelist_programsrecommend_programScored across 4 tools
The four tools have mostly distinct purposes, though list_programs and recommend_program both return program lists, and get_program_scope and diff_scope both fetch scope. Clear descriptions make the intended difference—overview vs. ranking and display vs. change tracking—usable, but mild confusion risk remains.
All tool names follow a consistent lowercase snake_case verb-first convention: list_programs, get_program_scope, diff_scope, recommend_program. The object follows the verb in each case, making the naming pattern predictable and easy to extend.
Four tools is a well-scoped size for a focused Intigriti program-monitoring server. Each tool addresses a necessary step in the workflow without redundancy or bloat.
For the inferred use case—program discovery, scope inspection, scope change tracking, and skill-based recommendations—the surface is largely complete. Submission/reporting workflows are absent, but they appear outside this server's narrow, deliberate scope.
Discover exposed assets, leaked secrets, APIs & client-side vulns across your attack surface
Discover verified deep-tech engineering bounties from any AI agent.
Hosted CVE + bug-bounty-mechanic MCP: exploitation-first ranking, CVE fact-check, mechanic transfer
Search and commission verified human research review through funded Research Bounties.
