Allows fetching OWASP category details by ID, enabling security analysis reference.
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., "@Appknox MCP Server List all my projects"
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 that wraps the Appknox CLI for mobile application security testing.
Node.js 18 or higher
Appknox CLI - See installation instructions
Appknox Access Token - Get from Appknox Dashboard → Settings → Developer Settings
Related MCP server: PS_MobSF_MCP_Server
npm install -g @appknox/mcp-serverConfigure your access token using Appknox CLI:
appknox initThis will prompt for your access token and save it to ~/.config/appknox.json.
Alternatively, set the APPKNOX_ACCESS_TOKEN environment variable if you prefer not to use the config file.
For additional configuration options (API host, region, proxy), see Appknox CLI documentation.
Add to your Claude Desktop config:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"appknox": {
"command": "npx",
"args": ["-y", "@appknox/mcp-server"]
}
}
}If you haven't run appknox init, you can set the token directly in the config:
{
"mcpServers": {
"appknox": {
"command": "npx",
"args": ["-y", "@appknox/mcp-server"],
"env": {
"APPKNOX_ACCESS_TOKEN": "your-token-here"
}
}
}
}Variable | Description | Default |
| Your Appknox API access token | Read from |
| Absolute path to the Appknox CLI binary |
|
| Logging level ( |
|
If the Appknox CLI is installed in a non-standard location, set APPKNOX_CLI_PATH:
{
"mcpServers": {
"appknox": {
"command": "npx",
"args": ["-y", "@appknox/mcp-server"],
"env": {
"APPKNOX_CLI_PATH": "/opt/homebrew/bin/appknox"
}
}
}
}Restart Claude Desktop after updating.
The MCP server exposes Appknox CLI commands as tools:
Tool | Description |
| Show current authenticated user information |
| List all organizations accessible to the user |
| List projects with optional filtering by platform, package name, or search query |
| List all files (app versions) for a specific project. Requires |
| List security analysis results (vulnerabilities) for a file. Requires |
| Get detailed information about a specific vulnerability |
| Fetch OWASP category details by ID |
| Upload an APK/IPA file for security scanning. Returns |
| Check vulnerabilities against a risk threshold (for CI/CD pipelines) |
| Generate a SARIF report for integration with code analysis tools |
| Create a vulnerability report for a file |
| Download vulnerability report as CSV. Returns content directly |
| Check DAST (dynamic scan) status and results |
Most tools require IDs that come from other tools:
appknox_projects → project_id → appknox_files → file_id → appknox_analyses
→ appknox_reports_download
→ appknox_cicheck
→ appknox_sarif"Who am I logged in as?"
"List all my organizations"
"Show me all my projects"
"List projects with package name containing 'com.example'""List all files for project ID 1234"
"Show me the latest scan results for project 'MyApp'"
"What vulnerabilities were found in file ID 56789?""Upload /Users/me/Downloads/myapp.apk for security scanning"
"Upload the app at /Users/me/Desktop/app.ipa and tell me the file ID"Important: File paths must be absolute paths on your local machine (e.g.,
/Users/username/Downloads/app.apk). Drag-and-drop uploads or sandbox paths won't work.
"Show all critical and high vulnerabilities for file ID 12345"
"Check if file ID 12345 passes the security threshold for 'high' risk"
"Run a CI check on file 12345 with medium risk threshold""Download the vulnerability report for file ID 12345"
"Generate a SARIF report for file 12345 with high risk threshold"
"Get details about vulnerability ID 67890"
"What is OWASP M1_2016?""Upload /path/to/app.apk and check if it has any critical vulnerabilities"
"Scan the app and fail if there are any high-risk issues"
"Generate a SARIF report I can upload to GitHub Security""Check the DAST scan status for file ID 12345"
"What are the dynamic scan results for file 12345 with medium risk threshold?"Appknox CLI not found: Verify installation with which appknox
Authentication failed: Check your token with echo $APPKNOX_ACCESS_TOKEN
Debug logging: Set LOG_LEVEL=debug in your environment
# Clone and build
git clone https://github.com/appknox/appknox-mcp.git
cd appknox-mcp
npm install
npm run build
# add to mcp config
"appknox": {
"command": "node",
"args": ["/abosolute/path/to/appknox-mcp/build/index.js"]
}See CONTRIBUTING.md for contribution guidelines.
MIT
List all security analysis results (vulnerabilities) for a specific file. Requires file_id which can be obtained from appknox_files.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates that the tool is a list operation and requires a file_id, which is a useful dependency. However, it does not explicitly state that the operation is read-only, nor does it mention pagination, error behavior, or response format. Given the simplicity of the tool, the missing transparency is a minor gap.
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 and well-structured. It front-loads the core purpose in the first sentence and follows with a single critical dependency in the second. No superfluous information or repetition of schema details is present.
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 list tool with one parameter and no output schema, the description covers the essential context: purpose, parameter, and dependency. It does not detail the return structure (e.g., fields of each vulnerability), but since no output schema exists, the description could have elaborated slightly. However, for a straightforward list operation, the provided context is largely sufficient.
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 input schema already describes file_id with 100% coverage, so the baseline is 3. The description adds semantic value by explaining where to obtain the parameter: 'which can be obtained from appknox_files.' This extra guidance helps the agent source the required input 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's function: 'List all security analysis results (vulnerabilities) for a specific file.' It uses a specific verb ('List') and identifies the resource ('security analysis results') and scope ('for a specific file'). However, it does not explicitly distinguish itself from the similar sibling tool 'appknox_vulnerability', which likely focuses on individual vulnerabilities.
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 provides a clear prerequisite: 'Requires file_id which can be obtained from appknox_files.' This tells the agent when to use the tool (after obtaining file_id) and where to get the required parameter. It does not mention exclusions or alternative tools, but the context is clear enough for a simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for vulnerabilities based on risk threshold. Fails if vulnerabilities above threshold are found. Requires file_id (from appknox_files) and risk_threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID to check (required) | |
| risk_threshold | Yes | Minimum risk threshold (required) | |
| timeout_minutes | No | Timeout in minutes (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavior that the tool fails when vulnerabilities above the threshold are found, which is important. However, it does not explain what happens on success, what the return format is, or any other side effects, leaving gaps beyond this critical fail condition.
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 three concise sentences, each serving a clear purpose: the first states the core action, the second explains the failure condition, and the third lists the required parameters. It is front-loaded and contains zero 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?
The tool has no output schema, so the description needs to cover return behavior. It does mention the fail condition but does not specify what a successful call returns or whether a list of vulnerabilities is included. Given the tool's simplicity, this is a moderate gap in 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?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds value by noting that file_id comes from appknox_files, which helps source the parameter, but it does not add further semantics for risk_threshold or timeout_minutes 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 clearly states the tool checks for vulnerabilities based on a risk threshold and fails if vulnerabilities above the threshold are found. This specific behavior and the mention of requiring a file ID from appknox_files helps distinguish it from sibling tools, though it does not explicitly name alternatives.
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 provides a prerequisite by stating it requires file_id from appknox_files, implying the file must exist. However, it does not explicitly state when to use this tool versus alternatives like appknox_dastcheck, nor does it mention any conditions under which it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a dynamic scan and display results when complete. Requires file_id (from appknox_files) and risk_threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID to check DAST status for (required) | |
| risk_threshold | Yes | Minimum risk threshold (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions 'check status' and 'display results when complete' without explaining polling behavior, error handling, or side effects. The prerequisite note is context, not behavioral transparency.
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 action and result, with the prerequisite clause adding necessary context. No filler or redundant phrasing.
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 no annotations and no output schema, the description is too thin to fully support an agent. It leaves unclear what the 'results' look like, how risk_threshold affects output, and whether the tool blocks until the scan finishes. These gaps are significant for a status-checking 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?
The schema already covers both parameters 100%, including the enum for risk_threshold and file_id's purpose. The description adds that file_id comes from appknox_files, which is useful, but it does not meaningfully enrich the parameter meaning beyond that.
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 checks the status of a dynamic scan and displays results when complete, naming the resource (dynamic scan) and action. It does not explicitly contrast with siblings like appknox_cicheck, but the niche is reasonably specific.
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 provides a prerequisite context by noting file_id comes from appknox_files, which helps the agent know when to use this tool in a workflow. However, it offers no explicit guidance on when to choose this over sibling tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files (app versions) for a specific project. Requires project_id which can be obtained from appknox_projects.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (max 100) | |
| offset | No | Pagination offset | |
| project_id | Yes | Project ID (required) | |
| version_code | No | Filter by version code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the read-only action of listing files but does not describe pagination behavior, response format, or any potential side effects. The 'all files' wording could imply unlimited results, while limit/offset params hint at pagination.
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, immediate action, and a useful prerequisite note. No redundant 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?
For a simple list tool, the description covers purpose and input derivation. It lacks explicit return-value information, but the term 'files' is clear. The absence of an output schema is compensated by the clarity of the description.
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 baseline is 3. The description adds a cross-reference for project_id (from appknox_projects) but provides no additional semantics for limit, offset, or version_code, which are already documented in 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 uses the specific verb 'List' with resource 'files (app versions)' scoped to 'a specific project', clearly distinguishing it from sibling tools like appknox_projects or appknox_analyses. It also notes the requirement for project_id, reinforcing the tool's scope.
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 states a prerequisite: requires project_id obtainable from appknox_projects, giving clear usage context. It does not mention exclusions or alternatives, but the sibling names make the distinctions apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all organizations accessible to the authenticated user
| 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 of behavioral disclosure. It reveals that only organizations accessible to the authenticated user are returned, which is a useful scoping detail. However, it omits other behavioral aspects such as pagination, response format, or sorting, leaving gaps for the agent.
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 contains no redundant information. It effectively communicates the tool's purpose without any waste.
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, parameterless list tool, the description adequately conveys the core function and user scoping. However, the absence of an output schema means the agent must infer the return structure, and no details about pagination or rate limits are provided, leaving minor gaps.
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 empty. The description accurately implies there are no configuration options, and since there are no parameters to document, the baseline score of 4 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 clearly states the action ('List'), the resource ('organizations'), and the scope ('accessible to the authenticated user'), making it easy for an agent to select it. It also distinguishes from sibling tools like appknox_projects and appknox_files, which operate on different resources.
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 usage when listing organizations but provides no explicit guidance on when to use this tool over alternatives like appknox_projects or appknox_whoami. There are no exclusion criteria or named alternatives, so the agent must infer from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OWASP category details by ID (e.g., M1_2016)
| Name | Required | Description | Default |
|---|---|---|---|
| owasp_id | Yes | OWASP ID (e.g., M1_2016) (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only retrieval ('Get') but does not explicitly confirm safety, describe return format, or mention potential errors or rate limits. However, the operation appears straightforward and low-risk, so it meets the minimum viable threshold.
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, front-loaded sentence with no wasted words. It immediately conveys the tool's purpose and includes a concrete example, making it highly efficient.
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?
The tool is simple (one parameter) but lacks an output schema, so the description must specify what details are returned. It only says 'details' without elaborating, leaving the agent uncertain about the response content. This is a clear gap for a minimally complete description.
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 schema fully documents the single parameter `owasp_id` with description and example. The description only repeats the example without adding additional context or constraints, so it does not enhance 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 clearly states the action ('Get'), the resource ('OWASP category details'), and the key parameter ('by ID'). It distinguishes itself from sibling tools like appknox_vulnerability and appknox_analyses by focusing specifically on OWASP categories.
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 provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states what the tool does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects with optional filtering by platform, package name, or search query
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (max 100) | |
| query | No | Search query to filter projects | |
| offset | No | Pagination offset | |
| platform | No | Filter by platform (e.g., android, ios) | |
| package_name | No | Filter by package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read-only listing operation ('List all projects') but does not disclose pagination behavior, return format, or any potential rate limits. The behavioral scope is implied but not elaborated.
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, front-loaded with the core action 'List all projects'. Every word is relevant; no fluff 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?
The tool has 5 optional parameters and no output schema. The description covers the basic purpose and filters but omits details on pagination semantics (limit/offset), return format, and relationship to sibling tools. It is minimal but adequate for a straightforward list 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 100%, so the baseline is 3. The description highlights 'platform, package name, or search query' which aligns with schema properties but adds no extra meaning beyond what the schema already provides. Limit and offset are not mentioned in the description.
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 'List all projects' with specific optional filters. This distinguishes it from sibling tools like appknox_organizations or appknox_files, which handle different resources.
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 usage (when you need projects), but does not explicitly mention when not to use it or provide alternatives. No exclusions are stated, and the presence of siblings is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a vulnerability analysis report for a file. Returns the report ID.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID to create report for (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states that the tool creates a report and returns its ID, which is useful. However, it does not disclose whether the operation is asynchronous, requires specific permissions, or has side effects on existing reports. This is minimal but not misleading.
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 concise sentences that front-load the primary action and state the return value. Every word adds value with no redundancy or extraneous detail. It is appropriately sized for the tool's simplicity.
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 the tool's simplicity (one required parameter, no output schema), the description adequately covers the purpose and return value. It lacks details on prerequisites or asynchronous behavior, but for a basic create operation, it is sufficiently complete 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?
The input schema has 100% description coverage for the single parameter 'file_id', with the description 'File ID to create report for (required)'. The tool description adds no additional semantic meaning beyond the schema. Thus, baseline score of 3 is appropriate.
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's purpose: 'Create a vulnerability analysis report for a file.' The verb 'create' and the resource 'report' are specific, and the mention of 'returns the report ID' further distinguishes it from sibling tools like appknox_reports_download. This is a distinct, well-defined action.
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 usage when a file ID is available and a report is needed, but it does not explicitly state when to use this tool versus alternatives like analyses or vulnerability. There is no mention of prerequisites (e.g., file must be uploaded) or exclusions. The use case is clear from context, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a vulnerability report for a file in CSV format. Requires file_id (from appknox_files). Automatically creates a new report if one does not exist. Returns the CSV content directly as text - no file path needed.
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID to download report for (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key side effects ('Automatically creates a new report if one does not exist') and output behavior ('Returns the CSV content directly as text - no file path needed'). This is significant context for a tool that may write data despite being a download operation.
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 three sentences, each adding essential information: purpose, dependency, side effect, and return format. Every sentence earns its place with no redundancy or 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 single-parameter tool with no output schema, the description fully covers prerequisites, behavior, and return format. It is self-contained and gives the agent everything needed 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?
The schema already documents file_id with 100% coverage, but the description adds provenance ('from appknox_files') and clarifies that the tool will auto-create a report if needed, providing context beyond the parameter's basic definition.
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 action ('Download'), the resource ('vulnerability report'), the format ('CSV'), and the required file_id. It distinguishes itself from sibling tools like appknox_reports_create by focusing on download and direct CSV content.
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 specifies a prerequisite ('Requires file_id from appknox_files') and explains the auto-create fallback, implicitly guiding when to use this tool instead of reports_create. However, it doesn't explicitly name alternatives or provide 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a SARIF (Static Analysis Results Interchange Format) report for the scanned file
| Name | Required | Description | Default |
|---|---|---|---|
| file_id | Yes | File ID (required) | |
| output_path | No | Output file path for SARIF report | |
| risk_threshold | Yes | Minimum risk threshold (required) | |
| timeout_minutes | No | Timeout in minutes (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic generation function and does not disclose potential long-running behavior (despite the timeout_minutes parameter), side effects, or output details. The timeout parameter hints at non-instant behavior but the description omits this.
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 front-loads the core purpose without unnecessary words. It is well-structured and easily scannable.
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?
The description is minimal for a tool with four parameters and no output schema. It fails to explain the meaning and effect of risk_threshold, output_path, and timeout, nor does it describe the SARIF report content or expected output. This leaves the agent with insufficient context to invoke the tool 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?
All four parameters have schema descriptions (100% coverage), so baseline is 3. The description does not add substantive meaning beyond the schema, though it implies file_id refers to a scanned file. The schema already provides basic descriptions for each 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 clearly states the tool generates a SARIF report for a scanned file, with a specific verb and resource. It does not explicitly differentiate from sibling report tools like appknox_reports_create, but the SARIF format is distinct enough.
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 given on when to use this tool versus alternatives such as appknox_reports_create or reports_download. Usage context is only implied by the tool name and description, with no explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a mobile application package (APK/IPA) for security scanning. Returns the file ID. IMPORTANT: The file_path must be an absolute path on the HOST machine filesystem (e.g., /Users/username/Downloads/app.apk on Mac, or C:\Users\username\Downloads\app.apk on Windows). Paths inside Claude Desktop sandbox (/mnt/user-data/, /tmp/ inside sandbox) will NOT work. The user must provide the real path where the file exists on their actual computer, not paths from drag-and-drop uploads.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the APK or IPA file on the local filesystem (required). Must be a real path like /Users/name/Downloads/app.apk, NOT a sandbox path like /mnt/user-data/uploads/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals an important behavior (host-path requirement and sandbox path failure) and specifies the return value (file ID). It does not detail authentication, error handling, or size limits, but the most critical behavioral gotchas are covered.
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 and front-loaded with the core purpose, followed by an important warning. It is a bit repetitive with the schema's parameter description, but every sentence serves a purpose and the formatting is clear.
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 upload tool, the description covers the essential aspects: what it does, what input is expected (with a critical constraint), and what it returns (file ID). No output schema exists, so the explicit return value statement is valuable and sufficient.
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 file_path, including the absolute path requirement and sandbox path warning. The description adds a Windows example and reiterates the same constraint, providing marginal additional value 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 the action ('Upload a mobile application package'), the resource (APK/IPA), and the purpose (security scanning), while noting the return value (file ID). This differentiates it from the sibling tools, which are primarily read/query operations.
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 is implicit that this tool is used when uploading a file for scanning, and the context of the sibling tools (mostly retrieval) makes it the sole upload action. The description provides a crucial usage constraint: the file_path must be a host path, not a sandbox path. However, it does not explicitly contrast with alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific vulnerability
| Name | Required | Description | Default |
|---|---|---|---|
| vulnerability_id | Yes | Vulnerability ID (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It simply says 'Get detailed information' without mentioning whether the operation is read-only, what specific data fields are returned, or any authentication requirements. The minimal wording offers no insight into the function's behavior beyond the obvious.
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 sentence that immediately conveys the core purpose. It is entirely front-loaded with no redundant words or filler, making it highly concise and well structured.
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 retrieval tool with one fully described parameter and no output schema, the description is minimally adequate. However, it omits any indication of what 'detailed information' includes (e.g., severity, remediation), which could be important for the agent's decision-making. Given the low complexity and high schema coverage, a mid-range score is appropriate.
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 schema fully documents the single parameter 'vulnerability_id' with type and description, so the description adds no additional semantic value. Since schema coverage is 100%, the baseline of 3 is appropriate; there is no need for the description to elaborate further.
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 a specific action ('Get detailed information') on a specific resource ('a specific vulnerability'), which distinguishes it from sibling tools like appknox_analyses (likely listing) and appknox_owasp (likely framework data). The verb+resource combination is unambiguous and directly tied to the tool name.
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 such as appknox_analyses or appknox_sarif. The description only states the basic function without any context about prerequisites (e.g., obtaining a vulnerability_id) or when a user would need it. This leaves the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently authenticated Appknox user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Get') and the scope ('currently authenticated user'), but without annotations, it does not disclose additional behavioral details such as the exact fields returned, error behavior if unauthenticated, 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 a single, concise sentence that stays on point without extraneous details.
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 tool, the description covers the core functionality. However, the absence of an output schema or mention of return fields leaves some ambiguity about what 'information' includes, but given low complexity, it is sufficiently complete.
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, and the schema is empty. Thus the description doesn't need to elaborate on parameter semantics; the baseline is 4 given no parameter complexity.
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 the specific verb 'Get' and identifies the exact resource 'currently authenticated Appknox user'. It clearly distinguishes from sibling tools like appknox_organizations or appknox_projects which focus on other entities.
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 by the nature of a whoami endpoint – to identify the current authenticated user – but no explicit guidance on when to use this versus alternatives or when not to use it is provided.
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.1appknox_analysesappknox_cicheckappknox_dastcheckappknox_filesappknox_organizationsappknox_owaspappknox_projectsappknox_reports_createappknox_reports_downloadappknox_sarifappknox_uploadappknox_vulnerabilityappknox_whoamiScored across 13 tools
Most tools target distinct resources (projects, files, analyses, reports), so agents can generally tell them apart. The main overlap risk is between appknox_cicheck and appknox_dastcheck, which both check vulnerabilities against a risk threshold but for static vs dynamic scans, which could cause misselection.
The appknox_ prefix is consistent, but the suffix pattern is highly varied: bare nouns (organizations, projects, files), verbs (upload, whoami), compound nouns (cicheck, sarif), and noun_verb pairs (reports_create, reports_download). There is no predictable verb_noun convention, making the naming feel chaotic.
13 tools is well-scoped for a mobile app security platform. Each tool serves a distinct part of the workflow—auth, orgs, projects, files, upload, checks, vulnerability details, and reports—without unnecessary bloat or excessive granularity.
The tool set covers the core lifecycle: authenticate, navigate orgs/projects/files, upload packages, perform static and dynamic checks, view vulnerability details, and generate/download reports. Minor gaps exist, such as update/delete operations for projects or files, but agents can work around these for typical scanning workflows.
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
MCP server for static security analysis of Android source code
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Model Context Protocol server for Studex tools, notifications, and profile integrations
