Click on "Install 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., "@disasm.dev MCP server solve a DataDome challenge for https://example.com"
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.
A Model Context Protocol server for disasm.dev. It lets an AI assistant (Claude, Cursor, and any MCP client) generate valid DataDome and Incapsula clearance tokens, without a headless browser.
It is built for development and prototyping: solve a challenge inline and have your assistant wire the result into your scraper. Production traffic should call the HTTP API directly.
Tool | What it does |
| Solve a DataDome |
| Solve an Incapsula (Imperva) |
| Your account profile. |
| Subscription balance and PAYG wallet. |
| Recent solve usage. |
| Your API keys (metadata only). |
Every tool uses one disasm.dev API key. Create one in the dashboard.
Related MCP server: sessemi-mcp
Add it to your MCP client. For Claude Desktop, edit claude_desktop_config.json:
{
"mcpServers": {
"disasm": {
"command": "npx",
"args": ["-y", "disasm-mcp"],
"env": { "DISASM_API_KEY": "your_api_key" }
}
}
}The same command / args / env shape works for Cursor and other clients.
The server also runs as a remote Streamable HTTP endpoint. Point your client at the URL and pass your key as a Bearer token:
{
"mcpServers": {
"disasm": {
"url": "https://mcp.disasm.dev/mcp",
"headers": { "Authorization": "Bearer your_api_key" }
}
}
}The hosted endpoint is stateless: each request carries its own key and no key is stored server-side.
npm install
npm run build
# stdio (what npx runs)
DISASM_API_KEY=your_api_key npm start
# remote HTTP on :8787 (override with PORT)
npm run start:httpVariable | Default | Purpose |
| (required, stdio) | Your disasm.dev API key. |
|
| HTTP server port. |
|
| DataDome solve host. |
|
| Incapsula solve host. |
|
| Management API host. |
Treat your API key like a password. Anyone with it can spend your balance.
MIT. See LICENSE.
Your disasm.dev account profile.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does not disclose behavioral traits such as read-only nature, authentication requirements, or side effects. The description is insufficient for a tool with no annotations.
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 a single concise sentence. It earns its place but could be slightly more informative about the data returned.
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?
No output schema exists. The description does not explain what fields the account profile contains, leaving the agent unsure about the return value. Sibling tools provide contrast but not completeness.
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?
There are no parameters in the input schema, so schema coverage is 100% trivially. Baseline for zero parameters is 4, and the description adds no further information needed.
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 clearly states the resource is 'Your disasm.dev account profile.' It distinguishes from siblings like get_balance and get_usage.
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?
No explicit guidance on when to use this tool. Usage is implied as fetching the user's own profile, but no alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your subscription request balance and PAYG wallet balance (in pence).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states what is returned (balance in pence) but omits any side effects, authorization requirements, rate limits, possible errors, or data freshness guarantees. The read-only nature is implied but not explicit.
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 a single, clear, front-loaded sentence with no redundant words. Every element ('subscription request balance', 'PAYG wallet balance', 'in pence') earns its place.
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 parameterless read-only tool with no output schema, the description is minimally adequate. It specifies the two balance types and their unit, but lacks detail on the return structure (e.g., whether it returns an object with keys, a single number, or separate fields). More context would improve usability.
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 baseline is 4. The description adds value by explaining the output semantics (both subscription and PAYG wallet balances, denominated in pence), which goes beyond the empty schema.
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?
Description clearly identifies the tool's function: retrieving subscription request and PAYG wallet balances, specified in pence. It uses specific resource references ('subscription request balance', 'PAYG wallet balance') and distinguishes from sibling tools like 'get_account' and 'get_usage' which serve different purposes.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, contextual conditions, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your recent solve usage statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or whether data is cached. It only states what is returned.
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 a single concise sentence that is front-loaded with essential information. Every word is necessary and there is no fluff.
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 tool with no parameters, the description is adequate but could be more complete by specifying the output format or time range of 'recent'. It lacks details that would help the agent understand what to expect.
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?
With zero parameters and 100% schema coverage, the description adds no parameter info, but the baseline for no parameters is 4. No additional semantics needed.
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 'Your recent solve usage statistics' clearly identifies the tool's purpose as retrieving usage statistics. It distinguishes from siblings like get_account and get_balance which focus on different data.
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?
No guidance on when to use this tool versus alternatives. The description does not specify context or exclude any scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your API keys (metadata only, never the secret value).
| 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 burden. It discloses that secret values are never returned, which is a key behavioral trait. Lacks details on pagination or potential rate limits.
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?
Single sentence, front-loaded with the action and a critical caveat. No wasted words.
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 zero-parameter list tool, the description is complete enough. It omits the structure of metadata but that is not essential for invocation.
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?
No parameters exist; schema coverage is 100%. Description adds no parameter info, which is appropriate since there are none.
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?
Clearly states it lists API keys, with the crucial clarification that it only returns metadata, never secrets. Distinguishes from sibling tools that handle account, balance, usage, or captchas.
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?
No explicit when to use or not, but the purpose is clear and sibling tools are distinct. Implied usage for retrieving API key metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a valid DataDome clearance payload without a headless browser. Pick challenge='interstitial' (provide device_check_link and device_check_page from the blocked response), 'captcha' (provide captcha_link, the geo.captcha-delivery.com URL), or 'tags'. Returns { success, payload, headers } where headers is the client-hints set to replay on your follow-up request. Each call costs one solve against your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Any additional fields the endpoint expects (forwarded as-is) | |
| challenge | Yes | Which DataDome challenge to solve | |
| captcha_link | No | captcha: the geo.captcha-delivery.com challenge URL | |
| device_check_link | No | interstitial: the device-check URL from the blocked response | |
| device_check_page | No | interstitial: the device-check page URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return shape ({ success, payload, headers }), the cost per call, and the fact that it bypasses a headless browser. It lacks explicit mention of authentication or error cases, but is sufficiently transparent for typical use.
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, front-loaded with the main purpose, and wastes no words. It efficiently lists challenge types and their inputs.
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?
Given no output schema, the description explains the return structure. It covers main use cases and differentiates challenge types. Minor gaps: no mention of error responses or prerequisites like authentication, but overall adequate for a solve tool.
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% with descriptions, but the tool description adds crucial context: which parameters apply to which challenge type and how 'params' is forwarded. This goes beyond the schema and helps an agent select parameters correctly.
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 clearly states the tool generates a DataDome clearance payload and specifies three challenge types (interstitial, captcha, tags) with required inputs. It distinguishes itself from siblings like solve_incapsula by naming, and from account/balance tools by function.
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 explicitly explains when to use each challenge type and what parameters to provide (e.g., 'captcha: provide captcha_link'). It also mentions cost. However, it does not directly contrast with solve_incapsula or state when not to use this tool, leaving some ambiguity for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an Incapsula clearance token without a headless browser. challenge='reese84' produces a reese84 sensor payload; 'utmvc' solves the ___utmvc cookie. Returns the payload and cookies to replay. Each call costs one solve against your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | The target site URL the token is for | |
| params | No | Any additional fields the endpoint expects (forwarded as-is) | |
| challenge | Yes | Which Incapsula challenge to solve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool generates tokens, produces payload and cookies, and costs a solve. This is good transparency, though it could mention error handling or rate limits.
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 concise with two sentences that front-load the purpose and efficiently convey usage details. No extraneous information.
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?
Despite no output schema, the description hints at the return (payload and cookies). With three parameters and a straightforward function, this is sufficient for an agent to use the tool effectively.
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% with descriptions for all parameters. The description adds behavioral meaning: 'reese84' produces sensor payload, 'utmvc' solves cookie, and 'params' are forwarded as-is. This enhances understanding beyond the schema.
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 clearly states it generates an Incapsula clearance token without a headless browser. It specifies two challenge types (reese84 and utmvc) with distinct outputs, distinguishing it from sibling tools like solve_datadome.
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 indicates usage without a headless browser and notes the cost per call. However, it does not explicitly state when not to use it or compare directly to alternatives like solve_datadome.
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. Dates show when Glama detected each change.
v0.1.0get_accountget_balanceget_usagelist_api_keyssolve_datadomesolve_incapsulaEach tool has a distinct and clear purpose: account info, balance, usage, API key listing, and two different captcha-solving tools (DataDome and Incapsula). No overlap in functionality.
Most tools follow a verb_noun pattern with snake_case (e.g., get_account, solve_datadome). The only minor inconsistency is using both 'get_' and 'list_' for retrieval operations, but they are still clearly distinguished.
With 6 tools, the server is well-scoped for its purpose—managing an account and solving captchas. Each tool earns its place without redundancy or excessive complexity.
The tool set covers core account operations (profile, balance, usage, API keys) and two major captcha-solving challenges. Missing features like creating/deleting API keys or additional captcha types are minor gaps for the stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Cloudflare Solver: Scraping API designed to bypass Cloudflare protection.
Solve reCAPTCHA v2/v3, hCaptcha, Cloudflare Turnstile and image captchas. Platform-hosted, no creden
Stealth scraping & search. Bypasses Cloudflare, DataDome & LinkedIn via Cyborg HITL approach.
Bypass Cloudflare API: A powerful scraping API designed to bypass Cloudflare protection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/disasm-dev/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server