Pharaoh - Your AI breaks things it can't see
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_codebase_mapA | A repo's architecture in one call. CALL THIS WHEN: • You need a repo's overall structure, or which module owns something • You don't know the repo's exact name in Pharaoh RETURNS: Modules with file counts and LOC, module dependencies with two-way ones flagged, the files changed most in 90 days, and every endpoint with its handler file. USE INSTEAD OF: directory listings, which omit dependency relationships. |
| pharaoh_reconA | Several Pharaoh queries in one call, run in parallel: codebase map, module profiles, function searches, blast radius and module dependency paths. CALL THIS WHEN: • Planning a change, reviewing a PR or assessing architecture, when you know what to check RETURNS: Each requested section in one response. Per call: up to 5 modules, 3 searches, 3 blast radius targets, 3 dependency pairs. USE INSTEAD OF: separate tool calls and file reads. |
| get_module_contextA | One module's full profile before you change it, in about 2K tokens. CALL THIS WHEN: • You're about to change code in a module, or plan a change to it • You need what a module exports, depends on, or who calls into it RETURNS: Files, LOC, exported signatures with complexity, imports in and out, DB tables, endpoints, cron jobs, env vars, and callers in other modules. USE INSTEAD OF: reading every module file; callers can live elsewhere. |
| get_blast_radiusA | What breaks if you change a function, file or module. CALL THIS WHEN: • You're about to change a signature, refactor or delete code • You need callers or detected endpoints a change reaches RETURNS: Risk, production callers by module/file, endpoints, cron jobs and DB operations. Hops are the shortest detected path within the requested depth (1–5). Test-file callers are excluded. USE INSTEAD OF: following callers by hand. |
| search_functionsA | Find functions by name or concept across the whole codebase. CALL THIS WHEN: • You're about to write a function, helper or utility: check it doesn't already exist • You need to know where something is implemented (e.g. "retry", "validate", "notify") RETURNS: Matching functions with file path, line range, module, signature, export status and complexity. USE INSTEAD OF: grep, which misses aliases and re-exports and includes comments. |
| get_unused_codeA | Find code nothing runs: functions no production entry point (endpoint, CLI command, cron job, event handler, worker, entry file) reaches. Pass CALL THIS WHEN: • Before cleaning up a module or deleting a function • After merging new code, to confirm an entry point reaches it RETURNS:
• Dead: unreached, named in no other file, and no production file imports its file. Safe to delete.
• Possibly unused: unreached, but named in other files (string dispatch, dynamic loading) or its file is imported. Listed with the files that name it; check before deleting.
• Used only by tests: exported functions and class methods only test files reference.
With USE INSTEAD OF: reference searches; references do not prove code runs. |
| pharaoh_accountA | Your Pharaoh plan, live repo and refreshes. Pick one action and provide its fields; invalid combinations are rejected. • status: each workspace's plan and live repo, the upgrade link, the setup page • set_free_repo { repo }: change a free workspace's live repo • refresh_repo { repo, full? }: re-map one live repo now CALL THIS WHEN: • You want to know what plan you're on or which repo is live • A repo doesn't answer because it isn't live, or you want to switch which one is • You want to upgrade so every repo is live, or manage billing • You want a repo's graph refreshed before its next push Flag reference: full = force a full rebuild, skipping the delta refresh. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pharaoh-trace | Compact, expandable evidence from Pharaoh tool results. |
TDQS
Scored across 7 tools
Most tools target clearly distinct questions: architecture map, module profile, blast radius, function search, dead code, account. The only real overlap is pharaoh_recon, which bundles codebase map, module profiles, searches, and blast radius, so an agent might hesitate between it and the individual tools. The descriptions do mitigate this with explicit 'call this when' guidance, but the batch wrapper is inherently a superset of other tools.
Mostly consistent snake_case with a verb-first pattern (get_codebase_map, get_module_context, get_blast_radius, search_functions, get_unused_code). The two pharaoh_-prefixed tools (pharaoh_recon, pharaoh_account) break the verb_noun convention slightly, but remain readable and logically clustered as server-management operations.
Seven tools is well-scoped for a codebase-intelligence server, and each tool earns its place: map, module context, impact analysis, function search, dead-code detection, batch recon, and account management. No padding or obviously trivial tool.
Coverage is strong for architecture understanding, change impact, function discovery, and unused-code cleanup. The notable gap is that none of the tools return actual source code bodies or line contents—agents can locate and assess functions but cannot read the implementation, which may force a fallback to another file-access mechanism.