Skip to main content
Glama
Pharaoh-so

Pharaoh - Your AI breaks things it can't see

by Pharaoh-so
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_blast_radius

Read-only

Maps what breaks when you change a function, file, or module, returning risk, callers, endpoints, cron jobs, and DB operations before refactoring.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository name — one of your connected repos.
depthNoHow many hops to trace (default: 3, range: 1–5)
entityYesFunction name, file path, or module name
entity_typeYesType of entity

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / depth
      Added value: +{
+  "description": "How many hops to trace (default: 3, range: 1–5)",
+  "maximum": 5,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / entity
      Added value: +{
+  "description": "Function name, file path, or module name",
+  "type": "string"
+}
    • addedInput schema / properties / entity_type
      Added value: +{
+  "description": "Type of entity",
+  "enum": [
+    "function",
+    "file",
+    "module"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / repo
      Added value: +{
+  "description": "Repository name — one of your connected repos.",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "repo",
+  "entity",
+  "entity_type"
+]
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description discloses the return payload shape (risk, production callers by module/file, endpoints, cron jobs, DB operations), the cost-limiting semantics of hops and the depth range, and the important exclusion of test-file callers. That is real behavioral context an agent cannot get from the annotations.

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 with the core question, then clearly labeled CALL THIS WHEN, RETURNS, and USE INSTEAD OF sections. Each line carries distinct information, and the hop/exclusion caveats sit inside RETURNS where they belong.

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

Completeness5/5

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

There is no output schema, and the description compensates by enumerating the returned fields, the depth semantics, and the test-file exclusion. For a 4-parameter read-only analysis tool, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: hops are the 'shortest detected path' within the requested depth, and test-file callers are filtered out. It does not clarify the entity/entity_type pairing or the repo scoping beyond what the schema says.

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

Purpose4/5

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

The opening line 'What breaks if you change a function, file or module' names the exact analysis performed and the entity types it accepts, so an agent can recognize impact analysis immediately. It does not explicitly distinguish itself from close siblings like get_module_context or search_functions, which keeps it short of a 5.

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?

A dedicated 'CALL THIS WHEN' block gives the triggering conditions (about to change a signature, refactor or delete; need callers or endpoints), and 'USE INSTEAD OF: following callers by hand' names the manual alternative it replaces. Nothing is left to inference.

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