Appknox MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level (debug, info, warn, error). Default: info | |
| APPKNOX_CLI_PATH | No | Absolute path to the Appknox CLI binary. Default: /usr/local/bin/appknox | |
| APPKNOX_ACCESS_TOKEN | No | Your Appknox API access token. If not provided, read from ~/.config/appknox.json. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| appknox_whoamiA | Get information about the currently authenticated Appknox user |
| appknox_organizationsA | List all organizations accessible to the authenticated user |
| appknox_projectsA | List all projects with optional filtering by platform, package name, or search query |
| appknox_filesA | List all files (app versions) for a specific project. Requires project_id which can be obtained from appknox_projects. |
| appknox_analysesA | List all security analysis results (vulnerabilities) for a specific file. Requires file_id which can be obtained from appknox_files. |
| appknox_vulnerabilityB | Get detailed information about a specific vulnerability |
| appknox_owaspA | Get OWASP category details by ID (e.g., M1_2016) |
| appknox_uploadA | 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. |
| appknox_cicheckA | Check for vulnerabilities based on risk threshold. Fails if vulnerabilities above threshold are found. Requires file_id (from appknox_files) and risk_threshold. |
| appknox_sarifC | Generate a SARIF (Static Analysis Results Interchange Format) report for the scanned file |
| appknox_reports_createA | Create a vulnerability analysis report for a file. Returns the report ID. |
| appknox_reports_downloadA | 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. |
| appknox_dastcheckB | Check the status of a dynamic scan and display results when complete. Requires file_id (from appknox_files) and risk_threshold. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.