AppLedger
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPLEDGER_KEY | No | Connection key for the AppLedger dashboard. Overrides the key saved in ~/.appledger/key. | |
| APPLEDGER_MODE | No | Set to 'local' to run in local mode. Default is 'hosted'. | hosted |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_appA | Scan an app folder with independent security scanners and explain the findings in plain language. Hosted mode sends the project's files over HTTPS to the AppLedger scanning service, where they are scanned with Trivy and Opengrep and deleted right after. Only files git would commit are sent; secrets files (.env, keys, certificates, local settings), dependencies, media and files over 1 MB never are. The first check of a folder returns needs_confirmation and an upload_preview instead of uploading: show the preview to the user and ask. Only after they agree, call again with confirm_upload=true; later checks of that folder don't ask again. Results are written to /.appledger (report.html, fix-prompt.md, findings.json). Returns the score (0-100), grade, who may use the app right now, and every finding with why it matters and what to do. A hosted check from a computer that isn't connected to a dashboard also returns save_link: a link (valid 24 hours, works once) that saves this result to a free AppLedger ledger. Offer it to the user once, in one line. Args: path: absolute path to the app's folder. app_name: a friendly name for the app, shown in the report. confirm_upload: true only after the user agreed to send this folder's files to appledger.net. save_to_dashboard: false to keep this check out of the user's AppLedger dashboard. |
| preview_uploadA | List the files a hosted check of this folder would send to appledger.net, and what stays behind. Nothing is sent. In a git repository only files git tracks or would commit count; elsewhere the folder's .gitignore files decide. Secrets files, media, files over 1 MB, dependencies and build output are always left out. Also lists secrets files git would commit, which the check reports as problems. Args: path: absolute path to the app's folder. |
| get_fix_promptA | Return the fix request written by the last check_app run for this app folder. The fix request lists every problem in order, where it is, and the expected fix, plus rules such as never putting keys in code and never removing features to silence a warning. Args: path: absolute path to the app's folder (the same path given to check_app). |
| connect_dashboardA | Save a connection key so future checks from this computer appear in the user's AppLedger dashboard. The user creates the key (it starts with al_) at https://appledger.net/app/ under "Connect a computer". The key is stored in ~/.appledger/key. Only call this with a key the user gave you. Args: key: the connection key, starting with al_. |
| scanner_statusA | Show whether the AppLedger scanning service is reachable (or, in local mode, which scanners are installed on this computer), and how to fix anything that is missing. |
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 5 tools
Each tool targets a distinct action: preview, scan, retrieve fix request, connect dashboard, and check service status. The only real overlap is between preview_upload and check_app, which itself returns an upload_preview on first run; the descriptions explain the difference, but an agent may still wonder which to call first.
All names are snake_case and mostly follow a verb_noun pattern (preview_upload, get_fix_prompt, connect_dashboard, check_app). scanner_status is noun-first rather than a verb, a minor deviation but still clear.
Five tools is well-scoped for a security-check service: scan, preview, retrieve fix guidance, connect, and status. Nothing feels redundant or missing from the count perspective.
The scan lifecycle is covered: preview what's sent, run the check, get the fix prompt, verify the scanner, and connect to the dashboard. Minor gaps exist — no way to disconnect/revoke a saved key or list prior check results beyond the on-disk files.