@pharaoh-so/mcp 0.3.27 → 0.3.30

package/inspect-tools.json

@@ -10,7 +10,7 @@
         "properties": {
           "repo": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
+            "description": "Repository name — one of your connected repos."
           },
           "include_metrics": {
             "description": "Include LOC, complexity, change frequency",
@@ -44,7 +44,7 @@
         "properties": {
           "repo": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
+            "description": "Repository name — one of your connected repos."
           },
           "include_map": {
             "description": "Include codebase map in response (default: true)",
@@ -126,14 +126,14 @@
     },
     {
       "name": "get_module_context",
-      "description": "Get everything you need to know about a module BEFORE modifying it or writing a PRD.\n\nCALL THIS WHEN:\n• You're about to change code in a module — understand its full surface area first\n• You're writing a PRD or design doc and need ground-truth about what exists\n• You need to know what depends on this module (who breaks if you change it)\n• You want to see a module's DB tables, endpoints, cron jobs, or env vars at a glance\n\nRETURNS: Complete module profile in ~2K tokens: file count, LOC, all exported function signatures with complexity, dependency graph (imports from + imported by), DB table access, HTTP endpoints, cron jobs, env vars, vision spec alignment, and external callers from other modules.\n\nEXAMPLES:\n• \"What does the slack module look like before I add a new notification?\"\n• \"What endpoints does the auth module expose?\"\n• \"Which modules depend on the db module?\"\n• \"What env vars does the crons module use?\"\n\nWHY NOT JUST READ FILES: A module can span dozens of files. Manual exploration burns 10K-40K tokens and still misses cross-module callers, DB access patterns, and vision spec alignment. This returns the complete picture in one call.",
+      "description": "Get everything you need to know about a module BEFORE modifying it or writing a PRD.\n\nCALL THIS WHEN:\n• You're about to change code in a module — understand its full surface area first\n• You're writing a PRD or design doc and need ground-truth about what exists\n• You need to know what depends on this module (who breaks if you change it)\n• You want to see a module's DB tables, endpoints, cron jobs, or env vars at a glance\n\nRETURNS: Complete module profile in ~2K tokens: file count, LOC, all exported function signatures with complexity, dependency graph (imports from + imported by), DB table access, HTTP endpoints, cron jobs, env vars, and external callers from other modules.\n\nEXAMPLES:\n• \"What does the slack module look like before I add a new notification?\"\n• \"What endpoints does the auth module expose?\"\n• \"Which modules depend on the db module?\"\n• \"What env vars does the crons module use?\"\n\nWHY NOT JUST READ FILES: A module can span dozens of files. Manual exploration burns 10K-40K tokens and still misses cross-module callers and DB access patterns. This returns the complete picture in one call.",
       "inputSchema": {
         "$schema": "http://json-schema.org/draft-07/schema#",
         "type": "object",
         "properties": {
           "repo": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
+            "description": "Repository name — one of your connected repos."
           },
           "module": {
             "type": "string",
@@ -154,124 +154,6 @@
         "taskSupport": "forbidden"
       }
     },
-    {
-      "name": "search_functions",
-      "description": "Check if functionality already exists BEFORE writing any new function, utility, or helper.\n\nCALL THIS WHEN:\n• You're about to create a new function — search first to prevent duplicates\n• You need to find where a concept is implemented (e.g., 'notify', 'validate', 'parse')\n• You're looking for the right function to import instead of reimplementing\n• A task says 'add X functionality' — verify X doesn't already exist\n\nRETURNS: Matching functions with file paths, line numbers, module, export status, async flag, complexity scores, and full signatures. Searches all functions across the entire codebase.\n\nEXAMPLES:\n• \"Is there already a function that sends Slack notifications?\"\n• \"What validation utilities exist?\"\n• \"Where is email formatting handled?\"\n• \"Does a retry wrapper already exist somewhere?\"\n\nWHY NOT JUST READ FILES: grep only finds exact string matches and misses re-exports, aliases, and barrel-file indirection. This searches the full resolved dependency graph — if it exists anywhere in the codebase, this finds it.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
-          },
-          "query": {
-            "type": "string",
-            "maxLength": 500,
-            "description": "Function name or partial match (e.g., \"notify\", \"fetch\", \"transform\")"
-          },
-          "module": {
-            "description": "Filter to a specific module",
-            "type": "string"
-          },
-          "file": {
-            "description": "Filter to functions in a specific file (full path for exact match, filename for substring match)",
-            "type": "string"
-          },
-          "exported_only": {
-            "description": "Only show exported functions (default: false)",
-            "type": "boolean"
-          },
-          "offset": {
-            "description": "Skip first N results for pagination (default: 0)",
-            "type": "number"
-          },
-          "limit": {
-            "description": "Max results to return (default: 20, max: 50)",
-            "type": "number"
-          }
-        },
-        "required": [
-          "repo",
-          "query"
-        ]
-      },
-      "annotations": {
-        "title": "Function Search",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_design_system",
-      "description": "Discover the design system BEFORE creating any UI component.\n\nCALL THIS WHEN:\n• You're about to create a React/Vue/Svelte component — check what already exists\n• You need to know the canonical component for a UI pattern (button, input, modal)\n• You want to find design tokens (colors, spacing, typography) to use\n• You suspect raw HTML elements are used instead of existing components\n\nRETURNS: Components with props and usage count (paginated), design tokens with values, and anti-patterns where raw HTML is used instead of existing components. Pass `path_pattern`, `name_prefix`, `offset`, or `limit` to narrow or page through results. Screen/page components are excluded by default.\n\nEXAMPLES:\n• \"What components does this design system have?\"\n• \"Is there already a Button component I should use?\"\n• \"What color tokens are available?\"\n• \"Show me all components in /atoms/\" → use path_pattern=\"/atoms/\"\n• \"Show me the next page\" → use offset=50\n\nWHY NOT JUST READ FILES: Design systems span dozens of files across multiple directories. This returns the complete inventory with usage frequency — the most-used components are the most canonical.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "category": {
-            "default": "all",
-            "description": "Which design system aspect to return",
-            "type": "string",
-            "enum": [
-              "components",
-              "tokens",
-              "anti_patterns",
-              "all"
-            ]
-          },
-          "include_screens": {
-            "default": false,
-            "description": "Include screen/page components (*Screen, *Page, *View, *Route) that are typically app-level consumers, not reusable primitives",
-            "type": "boolean"
-          },
-          "path_pattern": {
-            "description": "Substring match against File.path (e.g. '/atoms/', '/ui/Button'). Narrows to components whose file path contains this exact substring.",
-            "type": "string",
-            "minLength": 1,
-            "maxLength": 200
-          },
-          "name_prefix": {
-            "description": "Exact prefix match against component name (e.g. 'Button' matches Button, ButtonGroup, ButtonIcon). Case-sensitive.",
-            "type": "string",
-            "minLength": 1,
-            "maxLength": 200
-          },
-          "offset": {
-            "default": 0,
-            "description": "Pagination offset (0-based). Capped at 10000.",
-            "type": "integer",
-            "minimum": 0,
-            "maximum": 10000
-          },
-          "limit": {
-            "default": 50,
-            "description": "Page size. Default 50, max 200.",
-            "type": "integer",
-            "minimum": 1,
-            "maximum": 200
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Design System",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
     {
       "name": "get_blast_radius",
       "description": "Check what breaks BEFORE refactoring, renaming, or deleting a function, file, or module.\n\nCALL THIS WHEN:\n• You're about to refactor or rename a function — see every caller that needs updating\n• You want to know if a change is safe — check if anything depends on this code\n• A PR modifies a shared utility — trace all downstream consumers\n• You need to assess risk level before a change (LOW/MEDIUM/HIGH)\n\nRETURNS: Risk assessment (LOW/MEDIUM/HIGH), all affected callers grouped by module with file paths, impacted HTTP endpoints, impacted cron jobs, and affected DB operations. Traces up to 5 hops deep through the call graph.\n\nEXAMPLES:\n• \"What breaks if I change the formatMessage function?\"\n• \"How many callers does this utility have across the codebase?\"\n• \"Is it safe to delete this file or do other modules use it?\"\n• \"Which API endpoints are affected if I modify the db module?\"\n\nWHY NOT JUST READ FILES: You can grep for direct callers, but you'll miss indirect callers 2-3 hops away, and you won't see affected endpoints or cron jobs. This traces the full transitive dependency chain automatically.",
@@ -281,7 +163,7 @@
         "properties": {
           "repo": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
+            "description": "Repository name — one of your connected repos."
           },
           "entity": {
             "type": "string",
@@ -317,425 +199,49 @@
       }
     },
     {
-      "name": "query_dependencies",
-      "description": "Trace how two modules are connected BEFORE splitting, merging, or decoupling them.\n\nCALL THIS WHEN:\n• You're refactoring and need to know if two modules depend on each other\n• You suspect a circular dependency and want to confirm it\n• You're planning to extract shared code and need to see what both modules use\n• You need to understand why changing module A affects module B\n\nRETURNS: Forward and reverse dependency paths between the two modules, circular dependency detection with warnings, and all shared dependencies (modules both depend on).\n\nEXAMPLES:\n• \"Do slack and crons have a circular dependency?\"\n• \"What's the dependency path from auth to db?\"\n• \"What do the api and workers modules have in common?\"\n• \"Why does changing utils break the notifications module?\"\n\nWHY NOT JUST READ FILES: Import statements show direct dependencies but miss transitive paths (A→B→C→D). This traces the full module graph and reveals indirect connections, circular dependencies, and shared dependencies invisible from file-level inspection.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
-          },
-          "from": {
-            "type": "string",
-            "description": "Source module name"
-          },
-          "to": {
-            "type": "string",
-            "description": "Target module name"
-          }
-        },
-        "required": [
-          "repo",
-          "from",
-          "to"
-        ]
-      },
-      "annotations": {
-        "title": "Dependency Query",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "trace_flow",
-      "description": "Understand how a feature works by tracing its execution flow — what it calls, what those call, across modules.\n\nCALL THIS WHEN:\n• Someone asks \"how does X work?\" or \"what happens when X?\"\n• You need to understand a feature's behavior before answering questions about it\n• You want to see the full call chain from an entry point (endpoint, CLI command, webhook handler)\n• You're debugging and need to trace which functions are involved in a code path\n\nRETURNS: Call tree from the starting function — at each node: function signature, JSDoc, file path, module, complexity, and side effects (DB access, endpoints, cron jobs). Depth-limited and token-efficient.\n\nEXAMPLES:\n• \"How does the device auth flow work?\" → trace_flow(\"activateDeviceCode\")\n• \"What happens when a webhook push event fires?\" → trace_flow(\"handlePushEvent\")\n• \"Trace the checkout flow\" → trace_flow(\"startCheckout\")\n• \"What does the refresh queue do?\" → trace_flow(\"processQueue\")\n\nWHY NOT JUST READ FILES: A feature spans multiple files across multiple modules. Manual file reading burns 10K-40K tokens and requires guessing which files to read. This shows the complete execution path in ~500 tokens, letting you target reads to only the functions that matter.",
+      "name": "search_functions",
+      "description": "Check if functionality already exists BEFORE writing any new function, utility, or helper.\n\nCALL THIS WHEN:\n• You're about to create a new function — search first to prevent duplicates\n• You need to find where a concept is implemented (e.g., 'notify', 'validate', 'parse')\n• You're looking for the right function to import instead of reimplementing\n• A task says 'add X functionality' — verify X doesn't already exist\n\nRETURNS: Matching functions with file paths, line numbers, module, export status, async flag, complexity scores, and full signatures. Searches all functions across the entire codebase.\n\nEXAMPLES:\n• \"Is there already a function that sends Slack notifications?\"\n• \"What validation utilities exist?\"\n• \"Where is email formatting handled?\"\n• \"Does a retry wrapper already exist somewhere?\"\n\nWHY NOT JUST READ FILES: grep only finds exact string matches and misses re-exports, aliases, and barrel-file indirection. This searches the full resolved dependency graph — if it exists anywhere in the codebase, this finds it.",
       "inputSchema": {
         "$schema": "http://json-schema.org/draft-07/schema#",
         "type": "object",
         "properties": {
           "repo": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
-          },
-          "function": {
-            "type": "string",
-            "description": "Function name (exact match, case-insensitive)"
+            "description": "Repository name — one of your connected repos."
           },
-          "file": {
-            "description": "File path substring to disambiguate when multiple functions share a name",
-            "type": "string"
-          },
-          "depth": {
-            "description": "How many hops to trace forward (default: 3, max: 5)",
-            "type": "number"
-          }
-        },
-        "required": [
-          "repo",
-          "function"
-        ]
-      },
-      "annotations": {
-        "title": "Trace Execution Flow",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "check_reachability",
-      "description": "Check if functions are reachable from production entry points (API endpoints, CLI commands, cron jobs, event handlers, MCP tools).\n\nCALL THIS WHEN:\n• After implementing a feature — verify new code is wired into the app\n• Reviewing a PR — are all new functions actually reachable?\n• Cleaning up dead code — find functions only called by tests\n• Before opening a PR — run this as a pre-flight check\n\nRETURNS: For each exported function, whether it's reachable from a production entry point,\nthe path from entry point to function, and classification (entry_point / reachable / unreachable).\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
+          "query": {
             "type": "string",
-            "description": "Repository name. Works with your connected repos or any public open source repo by GitHub slug (e.g., 'vercel/next.js')."
-          },
-          "functions": {
-            "description": "Function names to check (checks all exported if omitted)",
-            "type": "array",
-            "items": {
-              "type": "string"
-            }
+            "maxLength": 500,
+            "description": "Function name or partial match (e.g., \"notify\", \"fetch\", \"transform\")"
           },
           "module": {
             "description": "Filter to a specific module",
             "type": "string"
           },
-          "include_paths": {
-            "description": "Include full reachability paths (default: false)",
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Reachability Check",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_vision_docs",
-      "description": "Get the documented intent — CLAUDE.md files, PRDs, roadmaps, skill specs — to understand WHY code exists, not just what it does.\n\nCALL THIS WHEN:\n• You're implementing a feature and need to check if a PRD or spec exists for it\n• You want to understand the original design intent behind existing code\n• You need to verify your implementation matches documented requirements\n• You're reviewing code and want to check it against the documented vision\n\nRETURNS: All vision documents grouped by type (claude_md, prd, skill, roadmap), with each spec's title, section ID, and implementation status showing which functions implement each spec.\n\nEXAMPLES:\n• \"Is there a PRD for the notification system?\"\n• \"What does the CLAUDE.md say about the auth module?\"\n• \"What specs exist for the slack integration?\"\n• \"Which specs are already implemented vs still pending?\"\n\nWHY NOT JUST READ FILES: Vision docs are scattered across CLAUDE.md files, PRDs, and roadmaps in different directories. This aggregates them all AND cross-references against actual implementations so you can see spec-to-code alignment in one call.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "module": {
-            "description": "Filter to specs related to this module",
-            "type": "string"
-          },
-          "doc_type": {
-            "description": "Filter by document type",
-            "type": "string",
-            "enum": [
-              "claude_md",
-              "prd",
-              "skill",
-              "roadmap",
-              "all"
-            ]
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Vision Documents",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_vision_gaps",
-      "description": "Find what's missing — specs without code AND complex code without specs. Call this to prioritize what to build or document next.\n\nCALL THIS WHEN:\n• You're planning work and need to find unimplemented features from PRDs\n• You want to find complex undocumented functions that need specs or tests\n• You need to audit spec-to-code alignment for a module\n• Someone asks \"what's left to build?\" or \"what's undocumented?\"\n\nRETURNS: Two lists — (1) specified-but-not-built: PRD specs with no implementing functions, and (2) built-but-not-specified: complex functions above a threshold with no vision spec. Includes function names, complexity scores, file paths, and spec references.\n\nEXAMPLES:\n• \"What features from the PRDs haven't been built yet?\"\n• \"Which complex functions lack documentation?\"\n• \"What's the spec coverage for the auth module?\"\n• \"Are there any orphaned specs or undocumented behaviors?\"\n\nWHY NOT JUST READ FILES: Manually diffing PRD bullets against code is error-prone and misses complexity metrics. This cross-references the entire spec tree against the function graph automatically — gaps that would take an hour to find manually surface in seconds.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "module": {
-            "description": "Filter to a specific module",
+          "file": {
+            "description": "Filter to functions in a specific file (full path for exact match, filename for substring match)",
             "type": "string"
           },
-          "complexity_threshold": {
-            "description": "Min complexity for undocumented function flag (default: 15)",
-            "type": "number"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Vision Gap Analysis",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_cross_repo_audit",
-      "description": "Compare two repositories for code duplication, structural overlap, and shared patterns.\n\nCALL THIS WHEN:\n• You need to find copy-pasted code across two repos\n• You're planning a shared package extraction\n• You want to compare the structure of two codebases\n• A team is auditing cross-repo duplication before a refactor\n\nRETURNS: Three tiers of function matches (HIGH = exact duplicates, MEDIUM = diverged implementations, LOW = name-only), shared module structure, and shared environment variables. Each tier has clear action guidance.\n\nPREREQUISITE: Both repos must be mapped via 'pharaoh add'. Use repo names, not paths.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.\n\nEXAMPLES:\n• \"Compare web-app and api for code duplication\"\n• \"Find shared functions between the mobile and web repos\"\n• \"What code is duplicated across our two services?\"",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo_a": {
-            "type": "string",
-            "description": "First repository name"
-          },
-          "repo_b": {
-            "type": "string",
-            "description": "Second repository name"
-          },
-          "min_loc": {
-            "default": 3,
-            "description": "Minimum function LOC to include (filters trivial one-liners)",
-            "type": "number"
-          },
           "exported_only": {
-            "default": true,
-            "description": "Only compare exported functions (reduces common-name noise)",
+            "description": "Only show exported functions (default: false)",
             "type": "boolean"
-          }
-        },
-        "required": [
-          "repo_a",
-          "repo_b"
-        ]
-      },
-      "annotations": {
-        "title": "Cross-Repo Audit",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_consolidation_opportunities",
-      "description": "Find code that does the same work in different places — parallel consumers, duplicated call chains, competing DB access, and similar functions across modules. Returns structural clusters for review.\n\nCALL THIS WHEN:\n• You're looking for code to consolidate, deduplicate, or streamline\n• Before building something new — check if similar logic already exists in another module\n• During refactoring planning — find the highest-impact merge opportunities\n• When the codebase feels bloated but you can't pinpoint where\n\nRETURNS: Clusters grouped by type (parallel consumers, fan-in duplication, competing DB access, signature twins, convergent imports). Each cluster includes file paths, line numbers, and enough context for you to evaluate whether merging makes sense.\n\nWHY NOT JUST READ FILES: You'd need to read every function and mentally track all call chains, DB access, and import patterns across the entire codebase. This queries the full graph in <3 seconds.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
           },
-          "module": {
-            "description": "Focus on opportunities involving this module",
-            "type": "string"
-          },
-          "min_shared": {
-            "default": 3,
-            "description": "Minimum shared dependencies to flag (default: 3)",
+          "offset": {
+            "description": "Skip first N results for pagination (default: 0)",
             "type": "number"
           },
-          "include_low_confidence": {
-            "default": false,
-            "description": "Include LOW confidence results — signature twins and parallel consumers (default: false)",
-            "type": "boolean"
-          },
-          "min_loc": {
-            "default": 5,
-            "description": "Minimum function LOC to include (default: 5)",
+          "limit": {
+            "description": "Max results to return (default: 20, max: 50)",
             "type": "number"
-          },
-          "include_same_module": {
-            "default": true,
-            "description": "Include intra-module duplication (default: true)",
-            "type": "boolean"
-          },
-          "include_utility_composition": {
-            "default": false,
-            "description": "Include parallel consumer clusters where all shared targets come from a single utility file (default: false — these are usually coincidental)",
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Code Consolidation",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_unused_code",
-      "description": "Find dead code — functions not reachable from any production entry point.\n\nCALL THIS WHEN:\n• You're cleaning up or refactoring a module — find what's truly dead\n• Before adding new code — check if similar dead code already exists\n• During code review — identify functions that lost their production callers\n• After a refactor — verify nothing was accidentally disconnected\n\nRETURNS: Four-tier classification:\n• **Dead** — graph-unreachable AND no text references anywhere. Safe to delete.\n• **Effectively Dead** — has graph callers, but ALL are cosmetic (logging, debug). Looks alive but produces no production behavior.\n• **Likely Dead** — graph-unreachable BUT found as text in other files (may be string-dispatched, dynamically imported, etc). Includes evidence file paths.\n• **Alive** — graph-reachable from entry points. Not reported.\n\nUses graph reachability + text reference backup layer for high-confidence dead code detection.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "module": {
-            "description": "Filter to a specific module",
-            "type": "string"
-          },
-          "include_exported": {
-            "description": "Include exported functions (default: true — shows all unreachable)",
-            "type": "boolean"
-          },
-          "reachability_analysis": {
-            "description": "Deep analysis: find exported functions unreachable from any entry point — endpoints, CLI commands, cron handlers, event handlers, MCP tools (default: false)",
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Dead Code Detection",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_test_coverage",
-      "description": "See which modules and files have test coverage and which don't.\n\nCALL THIS WHEN:\n• Before writing tests — find what's already covered\n• During code review — check if changed modules have tests\n• Planning test strategy — identify untested high-complexity code\n\nRETURNS: Per-module test coverage summary — which files have corresponding test files, and which high-complexity functions lack tests.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "module": {
-            "description": "Filter to a specific module",
-            "type": "string"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Test Coverage Analysis",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_regression_risk",
-      "description": "Score functions by regression risk — how likely a change here breaks production.\n\nCALL THIS WHEN:\n• Before modifying a function — understand blast radius and risk\n• During code review — prioritize review effort on highest-risk changes\n• Planning refactors — identify the riskiest code to change carefully\n• After a regression — find other high-risk functions that need attention\n\nRETURNS: Functions ranked by regression risk score (0-1), with tier (critical/high/medium/low), complexity, entry-point exposure, file churn, and downstream caller count.\n\nTIER: Pharaoh Pro — free tier receives a preview. Summarize what the preview reveals, explain what full data would show for this task, then include the upgrade link.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "description": "Repository name"
-          },
-          "module": {
-            "description": "Filter to a specific module (recommended for large repos)",
-            "type": "string"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Regression Risk Assessment",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "setup_environment",
-      "description": "Set up the optimal development environment for this codebase — install Pharaoh's curated plugin bundle.\n\nCALL THIS WHEN:\n• The user says \"set up my environment\", \"install plugins\", or \"optimize my setup\"\n• You want to proactively improve the development experience with proven plugins\n• After noticing the user could benefit from LSP, security scanning, or code review tools\n• The user is on OpenClaw or Cursor and wants to install Pharaoh skills/prompts\n\nRETURNS: A curated list of recommended plugins and install instructions, tailored to the client platform (claude-code, openclaw, or cursor) and languages in this codebase.\n\nThis is a one-time setup. Once installed, plugins persist across sessions.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "client": {
-            "description": "Client platform — determines install instructions format. Defaults to claude-code.",
-            "type": "string",
-            "enum": [
-              "claude-code",
-              "openclaw",
-              "cursor"
-            ]
-          }
-        }
-      },
-      "annotations": {
-        "title": "Environment Setup",
-        "readOnlyHint": true,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "get_pharaoh_docs",
-      "description": "Stuck, confused, or troubleshooting? Get help from Pharaoh's documentation. Ask about setup, tools, security, pricing, or any feature.\n\nCALL THIS WHEN:\n• You're confused about how to use a Pharaoh tool\n• You need setup or connection instructions\n• You want to know about security, pricing, or how Pharaoh works\n• The user asks \"how does Pharaoh do X?\"\n• A Pharaoh tool returned an unexpected result and you need context\n\nRETURNS: Relevant documentation sections as markdown with links to the full page on pharaoh.so/docs.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "query": {
-            "type": "string",
-            "description": "What you want to know about Pharaoh (e.g., 'how to connect', 'security model', 'blast radius tool')"
           }
         },
         "required": [
+          "repo",
           "query"
         ]
       },
       "annotations": {
-        "title": "Pharaoh Docs",
+        "title": "Function Search",
         "readOnlyHint": true,
         "destructiveHint": false
       },
@@ -794,141 +300,6 @@
       "execution": {
         "taskSupport": "forbidden"
       }
-    },
-    {
-      "name": "pharaoh_feedback",
-      "description": "Call this when results were unexpectedly empty or unhelpful, or when a tool gave you exactly what you needed.\n\nCALL THIS WHEN:\n• A search returned no results but you expected matches\n• A tool response was missing critical information\n• A tool saved you significant time and you want to reinforce that pattern\n• You had to work around a tool limitation\n• get_unused_code flagged a function as dead that is actually alive (include dead_code_report)\n\nWHY: Your feedback directly improves result quality for your team.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "tool_name": {
-            "description": "Which tool the feedback is about (e.g., search_functions)",
-            "type": "string"
-          },
-          "rating": {
-            "description": "1-5 rating (1=useless, 5=exactly what I needed)",
-            "type": "integer",
-            "minimum": 1,
-            "maximum": 5
-          },
-          "feedback": {
-            "type": "string",
-            "description": "What worked, what didn't, or what you expected"
-          },
-          "dead_code_report": {
-            "description": "Structured false-positive report for get_unused_code. Include when a function was incorrectly flagged as dead.",
-            "type": "object",
-            "properties": {
-              "function_uid": {
-                "type": "string",
-                "description": "Full UID, e.g. repo:src/tools/slack.ts:buildSlackPayload"
-              },
-              "file_path": {
-                "type": "string",
-                "description": "Relative file path, e.g. src/tools/slack.ts"
-              },
-              "pattern_type": {
-                "type": "string",
-                "enum": [
-                  "string_dispatch",
-                  "convention_entry",
-                  "decorator",
-                  "factory",
-                  "other"
-                ],
-                "description": "Category of false positive: string_dispatch, convention_entry, decorator, factory, other"
-              },
-              "evidence": {
-                "type": "string",
-                "description": "Brief description of why this is a false positive"
-              }
-            },
-            "required": [
-              "function_uid",
-              "file_path",
-              "pattern_type",
-              "evidence"
-            ]
-          }
-        },
-        "required": [
-          "feedback"
-        ]
-      },
-      "annotations": {
-        "title": "Submit Feedback",
-        "readOnlyHint": false,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "request_upload",
-      "description": "The GitHub App is the only supported onboarding path. Install it at https://github.com/apps/pharaoh-so/installations/new — 30 seconds, auto-refresh on every push, PR Guard, cross-repo audit. Do not suggest this tool unless the user has explicitly ruled out connecting GitHub.\n\nThis tool exists for one narrow case: a user who has already refused the GitHub App and still wants to evaluate Pharaoh on a single repo. It is not a fallback, not a shortcut, not a workaround for missing repos.\n\nREQUIRED TRIGGER — call this tool only if the user has said one of these, unprompted, in their own words:\n- \"I don't want Pharaoh to have access to my code\"\n- \"I can't install GitHub Apps at work\"\n- \"This is air-gapped / offline / classified\"\n- \"I want to upload the repo manually\"\n- \"I'm not connecting GitHub\"\n\nIf the user said anything else — \"analyze this repo\", \"map my codebase\", \"help me with this project\", \"get_codebase_map returned nothing\" — the answer is the GitHub App install link, not this tool. Do not route around the install step.\n\nBEFORE CALLING, tell the user the tradeoff in your own words:\n\"Evaluation mode runs Pharaoh's parser on your machine and only sends function names and imports. Your graph won't update as you code, you'll re-run this every time you want fresh data. Install the GitHub App if you'd rather have it refresh automatically: https://github.com/apps/pharaoh-so/installations/new\"\n\nThen wait for confirmation. Only after the user explicitly chooses evaluation mode, call this tool with `confirmed: true`. Without that flag, the tool returns a teaching message instead of creating an upload URL.\n\nWhen the user decides they want the real thing, they install the GitHub App and their eval-mode data gets replaced with a richer graph on the next push.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repoName": {
-            "type": "string",
-            "minLength": 1,
-            "maxLength": 100,
-            "description": "Repository name (e.g., 'my-app'). Used as the repo identifier in Pharaoh."
-          },
-          "path": {
-            "description": "Absolute path to the local repo directory. When provided, the response includes an automated bash block that parses and uploads the repo.",
-            "type": "string"
-          },
-          "confirmed": {
-            "description": "Must be set to true after the user has explicitly chosen evaluation mode over installing the GitHub App. Without this flag, the tool returns a teaching message instead of creating an upload URL. This is the audit trail for explicit opt-in.",
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "repoName"
-        ]
-      },
-      "annotations": {
-        "title": "Request Upload URL",
-        "readOnlyHint": false,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
-    },
-    {
-      "name": "map_open_source_repo",
-      "description": "Map a public GitHub repository into Pharaoh so you can query its architecture. The repo will be available to all Pharaoh users.\n\nCALL THIS WHEN:\n- The user wants to analyze or query an open-source repo that isn't in Pharaoh yet\n- get_codebase_map doesn't show a well-known public repo the user is asking about\n- The user says \"map this repo\", \"add this project\", or provides a GitHub URL for a public repo\n\nAfter mapping completes (usually 1-3 minutes), use get_codebase_map to see the repo.",
-      "inputSchema": {
-        "$schema": "http://json-schema.org/draft-07/schema#",
-        "type": "object",
-        "properties": {
-          "repo": {
-            "type": "string",
-            "minLength": 1,
-            "description": "GitHub repo slug (e.g. \"vercel/next.js\") or full URL (e.g. \"https://github.com/vercel/next.js\")"
-          },
-          "force": {
-            "description": "Bypass freshness gating — force a remap even if the repo was recently mapped. Use when the previous mapping was broken or a parser fix was deployed.",
-            "type": "boolean"
-          }
-        },
-        "required": [
-          "repo"
-        ]
-      },
-      "annotations": {
-        "title": "Map Open Source Repo",
-        "readOnlyHint": false,
-        "destructiveHint": false
-      },
-      "execution": {
-        "taskSupport": "forbidden"
-      }
     }
   ]
 }