Enables scanning Android app packages (.apk, .xapk, .apks, .apkm) for security issues and retrieving findings with severity, OWASP MASVS category, CWE, CVSS, location, and descriptions.
Enables scanning iOS app packages (.ipa) for security issues and retrieving findings with severity, OWASP MASVS category, CWE, CVSS, location, and descriptions.
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., "@GoMobSec MCP server Scan ./build/app-release.apk and tell me what to fix first"
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.
The official Model Context Protocol server for GoMobSec. Use it to scan Android and iOS apps for security issues from Claude, Cursor, VS Code or any other MCP client. Results are mapped to OWASP MASVS, CWE and CVSS, and you can download the full pentest-style report.
You: Scan ./build/app-release.apk and tell me what to fix first.
AI: start_scan → wait_for_scan → get_findings → a prioritised fix planA GoMobSec account with an API key. Create one under API keys in GoMobSec. API keys come with the Professional and Enterprise plans.
uv (recommended) or Python 3.10+.
Related MCP server: agentguard
The server runs locally over stdio. Your API key stays on your machine, and the server reads the APK or IPA straight from disk.
claude mcp add gomobsec --env GOMOBSEC_API_KEY=your-key -- uvx gomobsec-mcpAdd this to the client's MCP config file. For Claude Desktop that is
claude_desktop_config.json; for Cursor it is ~/.cursor/mcp.json.
{
"mcpServers": {
"gomobsec": {
"command": "uvx",
"args": ["gomobsec-mcp"],
"env": { "GOMOBSEC_API_KEY": "your-key" }
}
}
}Add this to .vscode/mcp.json. VS Code asks for the key on first use and
stores it securely:
{
"inputs": [
{ "type": "promptString", "id": "gomobsec-key", "description": "GoMobSec API key", "password": true }
],
"servers": {
"gomobsec": {
"command": "uvx",
"args": ["gomobsec-mcp"],
"env": { "GOMOBSEC_API_KEY": "${input:gomobsec-key}" }
}
}
}Without uv, run pip install gomobsec-mcp and use gomobsec-mcp as the command.
Tool | What it does |
| The account and plan the key belongs to |
| Scans used this month against the plan limit |
| Recent scans, newest first |
| Status of one scan and, once it is complete, the findings count by severity |
| Findings with severity, CWE, MASVS category, CVSS, location and description. Can filter by severity; false positives are hidden unless asked for |
| Uploads a local |
| Waits for a scan to finish and reports progress meanwhile |
| Saves the DOCX, XLSX, JSON or SARIF report to your download folder |
There is also one prompt, security_review, which turns a finished scan into
a prioritised fix plan.
Scans you start here count against your GoMobSec plan, exactly like scans from the web app or CI. The scan modes and limits are the ones your plan allows.
Variable | Default | |
| — | Required. Your GoMobSec API key |
|
| The only folder |
|
| Change this only for a dedicated or on-prem GoMobSec |
|
| Base URL for the report links |
Your key stays local. It is read from the environment and only ever sent to GoMobSec over HTTPS. It is never written to a file or included in tool output.
Uploads are limited to app packages. start_scan only sends files that are
mobile app packages: the right extension, a zip archive, and at most 250 MB.
It cannot be used to upload any other file from your machine.
Downloads never overwrite. download_report takes no path. It writes new
files (mode 0600) into GOMOBSEC_DOWNLOAD_DIR and never replaces an
existing file.
Finding text is treated as untrusted. Titles and descriptions can contain strings from the scanned app, and an app author controls those. The server strips control and bidi characters, keeps the text inside a fenced data block, and tells the model to treat it as data. Still, review what your assistant does after reading the results of a scan of an app you don't trust.
Access is limited to your own scans. The key only sees scans on its own account or organisation. Revoke it in GoMobSec at any time.
To report a vulnerability, see SECURITY.md.
python -m venv .venv && . .venv/bin/activate
pip install -e ".[test]"
pytestTry it with the MCP Inspector: npx @modelcontextprotocol/inspector gomobsec-mcp.
Bump the version in src/gomobsec_mcp/__init__.py and both version fields
in server.json (the tests and the release workflow check they match), and
add a CHANGELOG.md entry.
Publish a GitHub release tagged vX.Y.Z. The Publish workflow tests and
builds it, uploads it to PyPI (Trusted Publishing), then lists it in the MCP
Registry (GitHub OIDC). No tokens are stored in the repository.
MIT
Download the full report of a completed scan — DOCX (pentest report), XLSX, JSON or SARIF (for code-scanning tools) — into the GoMobSec download folder (GOMOBSEC_DOWNLOAD_DIR, default ~/Downloads/gomobsec). Never overwrites an existing file. Returns the saved path.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | docx | |
| scan_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-idempotent, non-destructive write with openWorldHint, and the description usefully reconciles that profile by disclosing the target directory (GOMOBSEC_DOWNLOAD_DIR, default ~/Downloads/gomobsec) and the never-overwrites policy. It also states the return value. It does not mention any permission or auth requirements for writing to disk.
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?
Three compact sentences, front-loaded with the action and resource, then formats, then side effects and return value. No filler and nothing repeated from the schema.
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 2-parameter tool with an output schema, the description covers the action, format choices, destination path, overwrite behavior, and return value. An agent has everything needed to call it correctly; only edge-case behavior on an incomplete scan is unstated.
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 0%, so the description must carry parameter meaning; it does explain all four format enum values (DOCX as the pentest report, XLSX, JSON, SARIF for code-scanning tools). scan_id is only indirectly characterized as identifying a completed scan, leaving a small gap.
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?
States a specific verb and resource ('Download the full report of a completed scan') and enumerates the exact output formats. No sibling (list_scans, get_scan, get_findings) does artifact download, so the tool is instantly distinguishable.
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 phrase 'of a completed scan' implicitly gates usage on a finished scan and hints at wait_for_scan, and 'SARIF (for code-scanning tools)' guides format selection by tool type. It stops short of explicitly naming the prerequisite step or telling the agent what to do when the scan is still running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Findings of a completed scan: severity, title, CWE, MASVS category, CVSS, location and description, most severe first. Optionally filter by severity. False positives are left out unless include_false_positives is true.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scan_id | Yes | ||
| severity | No | ||
| include_false_positives | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description doesn't need to cover safety. It still adds real behavioral context: results are ordered most-severe-first, and false positives are excluded by default unless include_false_positives is true. The one omission is truncation behavior for limit (default 50) — nothing says whether output is capped or how totals are reported.
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, no filler: the first leads with what is returned and in what order, the second covers the filtering controls and the default false-positive exclusion. The most decision-relevant facts (ordering, default exclusion) are front-loaded.
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?
An output schema exists, so return-field structure needn't be restated and the description appropriately focuses on ordering and filtering. Given a 4-parameter tool with 0% schema coverage, the only substantive gap is limit/pagination semantics; otherwise an agent has enough to call this 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 0%, so the description must carry the parameter burden. It explains severity (as a filter) and include_false_positives (default exclusion of false positives), and implies scan_id via 'of a completed scan', but the limit parameter is never mentioned, so an agent can't tell whether raising it retrieves more findings or whether results are paginated.
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 names the resource (findings) and its scope (of a completed scan) and enumerates the returned fields (severity, title, CWE, MASVS, CVSS, location, description), which is far more specific than the title 'Scan findings'. It implicitly distinguishes itself from get_scan/list_scans by dealing in findings rather than scan metadata, but never states that distinction explicitly.
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?
'Findings of a completed scan' establishes a precondition (the scan must be finished) and the severity filter implies when to narrow results. However, there is no explicit guidance on when to use this versus get_scan or wait_for_scan, and no statement about what to do if a scan is still running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of one scan and, once complete, its findings count by severity.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds one genuinely useful trait beyond that: findings counts are only present once the scan is complete, implying callers must handle a pending state. It says nothing about what status values exist or whether findings are truncated in the count.
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 conditional behavior ('once complete') is stated inline rather than buried. It is arguably slightly too terse given the gaps elsewhere, but there is no wasted text.
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?
An output schema exists, so return structure needn't be explained, and annotations cover the read-only nature. For a single-ID lookup tool, the only real gap is how to obtain a scan_id and how to handle a not-yet-complete scan.
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 0% for the single required scan_id, so the schema contributes only the name. 'of one scan' implies the ID selects a single scan, which is adequate for an obvious identifier, but no format, source (e.g. from list_scans), or error behavior for an unknown ID is described.
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?
States a specific verb+resource (status of one scan) and adds the payoff (findings count by severity once complete). The 'one scan' framing implicitly separates it from list_scans and get_findings, though neither sibling is named.
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 call this versus list_scans (to find a scan_id), wait_for_scan (to poll until completion), or get_findings (for detailed findings). The agent must infer the polling/alternative relationship entirely from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many scans the account has used this month against its plan limit.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral scope by pinning the measurement to a monthly billing window and a plan limit, but says nothing about reset timing, overage behavior, or whether the count is live or cached.
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 short sentence with no filler, and the key qualifier (this month against plan limit) is front-loaded. It reads as a fragment without a leading verb, which is slightly less scannable than an imperative form.
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?
An output schema exists and annotations cover safety, so return shape and side-effect risk need not be restated. For a no-parameter, no-side-effect tool the description supplies everything needed to decide to call it, short of a policy on when quota checks are warranted.
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?
Zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly avoids inventing inputs, implicitly confirming the tool needs no arguments.
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 names the specific resource (scan usage) and the exact measurement (this month's consumption against the plan limit), which is more precise than the bare name get_usage. It lacks an explicit verb, but the intent is unambiguous. Differentiation from the scan/findings siblings is clear by subject matter alone.
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?
There is no explicit when/when-not guidance or named alternative, but for a zero-argument quota read the intent is self-evident: check remaining allowance before calling start_scan. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's most recent scans, newest first (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine behavioral facts beyond the annotations: result ordering (newest first) and a hard cap of 50 with no pagination. It does not state what a scan record contains or how truncation should be handled.
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, front-loaded with the verb and resource, with the ordering and range constraint packed in without waste. Nothing redundant.
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?
An output schema exists so return values need not be explained, and readOnlyHint covers the safety profile. For a one-parameter list tool the description plus structured fields is nearly sufficient; only the absence of pagination/truncation behavior at the 50 cap leaves a small gap.
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 0% – the single `limit` parameter has only a default of 10 and no documented meaning. The description partially compensates by giving the valid range (1-50), which is real added value, but it leaves the default implicit and never ties the range explicitly to the `limit` parameter name.
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?
States a specific verb and resource ("List the account's most recent scans") with scope (account-level) and ordering (newest first), which distinguishes it from the singular get_scan sibling. It stops short of explicitly naming the alternative or clarifying how it relates to get_findings/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?
"Most recent scans" implies the discovery/browse use case, but there is no explicit guidance on when to prefer this over get_scan, get_findings, or start_scan, and no stated prerequisites. Usage must be inferred from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local Android (.apk, .xapk, .apks, .apkm) or iOS (.ipa) app to GoMobSec and start a security scan. Uses one scan from the account's plan — confirm with the user first. 'quick' and 'static' work on every plan; 'full' (static + dynamic) needs a paid plan. Returns the scan id; follow it with wait_for_scan.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| scan_mode | No | quick | |
| project_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover mutation/safety (readOnly=false, idempotent=false, openWorld=true), and the description adds non-obvious context: quota consumption, the confirmation requirement, plan-dependent mode availability, and that it returns a scan id. It doesn't warn about duplicate scans if retried or file size limits, so not a 5.
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?
Front-loaded with the action, then constraints, then return/follow-up — good ordering with no filler. Slightly dense in places (the plan sentence could be tightened), but every sentence conveys actionable 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?
An output schema exists, so return values are covered, and the description still notes it returns a scan id and the natural next call. Remaining gap is the undocumented project_name parameter and any file-size/upload limitations for a non-idempotent, quota-consuming operation.
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 0%, so the description must carry the load. It explains file_path by giving accepted extensions and explains scan_mode values plus the 'full' plan requirement, but says nothing about project_name (null default, whether it's required for grouping) and no size/format constraints.
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?
Specific verb+resource: 'Upload a local Android ... or iOS ... app to GoMobSec and start a security scan.' It also enumerates accepted file extensions, which no sibling does, so the agent can distinguish start_scan from list_scans/get_scan/wait_for_scan at a glance.
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?
Explicitly says to confirm with the user first because a scan is consumed from the plan, and states the follow-up ('wait_for_scan'). Plan-tier gating on scan_mode is also usage guidance. No explicit 'do not use this when...' exclusion, 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.
Wait until a scan finishes (or the timeout passes, 1-60 minutes), reporting progress, then return its status and findings count.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | ||
| timeout_minutes | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them — that the call blocks until completion or timeout, that the timeout window is 1–60 minutes, and that it reports progress while waiting. It stops short of saying whether a timed-out call errors or returns partial status, which matters for a long-blocking call.
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 sentence that front-loads the wait condition, then the timeout caveat, then the return value. No filler and nothing to trim.
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?
With an output schema present, the description needn't detail the response shape, and it still summarizes status and findings count. The only remaining gap is the timeout outcome (error vs. partial result), which is the one thing an agent calling a blocking tool would want to know.
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 0%, so the description carries the burden. It does add the useful 1–60 minute range for timeout_minutes (the schema only supplies a default of 20), which is genuine added meaning, but scan_id semantics and the effect of the default are left unaddressed.
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 names a specific verb+resource (wait for a scan) and states the completion condition plus the return payload (status and findings count). It is distinct from get_scan, though it never explicitly contrasts with it, so an agent must infer that get_scan is the non-blocking alternative.
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 word "Wait" implies this is the blocking follow-up to a scan launch, and the timeout clause implies a fallback when a scan is slow. However, no sibling is named and no explicit when-to-use/when-not condition (e.g., use get_scan for an immediate snapshot) is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show which GoMobSec account the API key belongs to and its plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully clarifies that the account is derived from the API key rather than passed in, but adds nothing about auth failure modes or rate limits — modest added value over the 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?
One short sentence with zero filler, front-loading the action and the two pieces of information 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?
A trivial, parameterless tool with full annotation coverage and an output schema that documents return shape, so little description is needed. What is missing is minor: whether the call fails without a valid key, and how it relates to get_usage, which also surfaces plan information.
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?
Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly signals that identity comes from the credential, not from inputs.
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?
States a specific verb and resource: reveals the account the API key belongs to plus its plan. This is meaningfully distinct from all siblings, though it does not name any of them (e.g. get_usage) to reinforce the boundary between account identity and usage metrics.
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?
Usage is only implied — an agent would infer it should call this when it needs to identify the current principal or plan before other operations. There is no explicit when-to-use statement, no exclusion versus get_usage, and no note about prerequisites.
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.
v0.1.0download_reportget_findingsget_scanget_usagelist_scansstart_scanwait_for_scanwhoamiScored across 8 tools
Each tool maps to a distinct resource/action: account identity, usage, scan listing, scan status, findings, scan creation, waiting, and report download. The only mild overlap is that get_scan and wait_for_scan both can return status, but wait_for_scan is clearly scoped to blocking/polling until completion.
All tool names use lowercase snake_case, which is highly consistent. However, whoami deviates from the otherwise predictable verb_noun pattern used by the other seven tools.
Eight tools are well-scoped for a mobile app security scanning workflow. The set is neither thin nor bloated, and each tool appears to earn its place in the scan lifecycle.
The surface covers the core workflow: authenticate, check usage, start a scan, wait, inspect status/findings, and download reports. Minor gaps include no cancel/delete scan operation and no broader scan-management controls, but these do not block the main use case.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Compliance & security scan for your app: secrets, exposed files, headers, privacy, AI-disclosure.
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
