Nativekeel
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NATIVEKEEL_MCP_ROOTS | No | Set this when your MCP client starts servers from another folder. The server is read-only and scans folders under the directory it was started in, plus the folders listed in NATIVEKEEL_MCP_ROOTS. When the server is started inside a plugin folder (Codex), your home folder is the boundary unless NATIVEKEEL_MCP_ROOTS is set. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_projectA | Health check for a React Native or Expo project: upgrade blockers, New Architecture, Google Play and App Store rules (target SDK, 16 KB pages, Xcode 27 UIScene, privacy manifests), crash risks, accessibility (unlabeled icon buttons and text fields, small touch targets, low text contrast, text scaling), OWASP MASVS security findings, leaked secrets, and signs of malware planted in the project (run it before installing or starting a project you did not write). Read-only, never runs project code; returns findings with file:line references and fixes, never source code. |
| security_auditA | Review mobile app data exposure, account access, unsafe code execution, backend rules and dependency risks. Returns source evidence, attacker prerequisites, fixes, validation steps and explicit coverage limits. Static and read-only; does not claim a live penetration test or a clean bill of health. |
| improve_appB | Prioritize existing security, crash, accessibility, performance, store and dependency findings into a review plan with prerequisites, expected effects and validation. No project code runs, no automatic changes or unmeasured performance claims. Reports unassessed areas explicitly. |
| measure_bundleA | What the release JavaScript bundle of a React Native or Expo app is made of, measured from the source map a release build already wrote (Hermes bytecode maps included): bytes and share for the app code and each package, packages bundled more than once, and the largest JSON. With base (an older map), what was added, removed or changed size since that build. Nothing is built or run; returns found:false with how to produce a map if there is none. |
| upgrade_planA | Ordered, step-by-step upgrade plan for a React Native or Expo project: phases in the order to do them (security fixes, crash risks, store deadlines, React Native and Expo upgrades, library replacements), the reason for each phase and concrete steps with file names. Built from the same scan as scan_project; stops with a warning if the project contains planted malware. Read-only. |
| check_libraryA | What to know about one React Native library before adding or upgrading it: latest version, New Architecture support and maintenance status (React Native Directory), the version range that works with a given React Native version where NativeKeel has a compatibility table, replacements, and known traps. |
| explain_errorA | Explain a React Native or Expo build, launch, crash or store-review error: what it means and the fix, from errors NativeKeel has reproduced or verified against Apple, Google, Expo and React Native documentation. Pass the error message (or the failing part of the log) and, optionally, the project path to see where this project is affected. Call it before searching the web or changing versions. |
| verify_upgradeA | Check a change before committing it: compares the React Native or Expo project as committed at a git revision (default HEAD) with the working tree, and lists what got fixed, what is new and how versions moved. Call it after an upgrade or a dependency change. Read-only: the committed version is unpacked into a temporary folder outside the project and deleted. |
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 8 tools
Most tools target distinct activities (library lookup, error explanation, bundle measurement, change verification), and the descriptions are unusually detailed. However, scan_project and security_audit both surface security findings, and improve_app and upgrade_plan both transform scan findings into a prioritized plan, so the boundaries between those pairs are somewhat blurry.
All eight tools use consistent snake_case with a verb_noun pattern (check_library, explain_error, measure_bundle, scan_project, upgrade_plan, verify_upgrade). Only security_audit is a noun phrase rather than verb_noun, a trivial deviation that remains perfectly readable.
Eight tools is well within the ideal 3-15 range and each maps to a recognizable part of the React Native/Expo project-health workflow. No tool feels redundant filler or conspicuously absent.
The surface covers the main lifecycle: library compatibility, error diagnosis, project scanning, security review, bundle analysis, upgrade planning, and change verification. The intentionally read-only design means no apply/fix tool exists, which is a minor gap agents can work around by following the returned plans.