Skip to main content
Glama
Sign In
Pharaoh-so

Pharaoh - Your AI breaks things it can't see

by Pharaoh-so
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

pharaoh_recon

Read-only

Runs codebase map, module profiles, function searches, blast radius and dependency path queries in one parallel call to assess changes, PRs or architecture.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository name — one of your connected repos.
modulesNoModules to profile (max 5)
functionsNoFunction searches (max 3)
include_mapNoInclude the codebase map (default true)
blast_radiusNoBlast radius targets (max 3)
dependenciesNoModule pairs to trace a dependency path between (max 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.1.1
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / blast_radius
      Added value: +{
+  "description": "Blast radius targets (max 3)",
+  "items": {
+    "properties": {
+      "entity": {
+        "description": "Function, file or module name",
+        "type": "string"
+      },
+      "entity_type": {
+        "description": "Default: function",
+        "enum": [
+          "function",
+          "file",
+          "module"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "entity"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / dependencies
      Added value: +{
+  "description": "Module pairs to trace a dependency path between (max 3)",
+  "items": {
+    "properties": {
+      "from": {
+        "type": "string"
+      },
+      "to": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "from",
+      "to"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / functions
      Added value: +{
+  "description": "Function searches (max 3)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / include_map
      Added value: +{
+  "description": "Include the codebase map (default true)",
+  "type": "boolean"
+}
    • addedInput schema / properties / modules
      Added value: +{
+  "description": "Modules to profile (max 5)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / repo
      Added value: +{
+  "description": "Repository name — one of your connected repos.",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "repo"
+]
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: queries execute in parallel, results come back as 'each requested section in one response,' and per-call caps are enumerated. It stops short of describing failure modes (e.g., what happens if one section errors) or payload size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-sentence purpose, then clearly labeled CALL THIS WHEN / RETURNS / USE INSTEAD OF sections. Every sentence carries distinct information: what it does, when to fire it, what comes back, and what it replaces.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter batch tool with no output schema, the description is nearly sufficient: it explains that each requested section returns in one response and sets per-call limits. Some ambiguity remains about what a 'module profile' or 'codebase map' section actually contains, but annotations and full schema coverage fill most of the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including the nested blast_radius and dependencies objects is already documented in the schema. The description's per-call caps ('up to 5 modules, 3 searches, 3 blast radius targets, 3 dependency pairs') echo the schema's max annotations rather than adding new semantics. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource (batched Pharaoh queries) and enumerates exactly which five query types it runs in parallel: codebase map, module profiles, function searches, blast radius, and dependency paths. An agent can distinguish it from every sibling (get_codebase_map, get_blast_radius, search_functions, etc.) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'CALL THIS WHEN: Planning a change, reviewing a PR or assessing architecture, when you know what to check' gives explicit activation conditions, and 'USE INSTEAD OF: separate tool calls and file reads' names the alternatives it displaces. The qualifier 'when you know what to check' implicitly routes open-ended exploration elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools