Skip to main content
Glama
Sign In
Pharaoh - Your AI breaks things it can't see

Pharaoh - Your AI breaks things it can't see

by Pharaoh-so
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Refresh Repo

pharaoh_manage_repo
Destructive

Queue a re-map of a repository's knowledge graph when it looks out of date, optionally rebuilding the full graph instead of a delta refresh.

Instructions

Re-map a repo now. Every repo is mapped during the trial and on Pro, and re-maps on every push.

• refresh_repo { repo, full? }: queue a re-map of one repo. • set_free_repo { repo }: retired; it changes nothing, since there is no live repo to choose.

CALL THIS WHEN: • A repo's graph looks out of date, or needs a full rebuild

RETURNS: The queued job.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "repo": "<repo>"
    },
    "name": "pharaoh_manage_repo"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNorefresh_repo only: rebuild the whole graph instead of a delta refresh
repoYesRepo slug (owner/repo) or repo name
actionYesWhich change to make

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true; the description adds real context beyond them by stating the call only queues a job (asynchronous) and returns 'The queued job', and by explaining that automatic re-mapping on push makes most calls redundant. It stops short of explaining why the destructive hint applies (e.g., that a full rebuild replaces the existing graph), which is the one piece an agent would want.

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

Conciseness4/5

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

Front-loaded with the core action, then scannable bullets for each action and labeled CALL THIS WHEN / RETURNS sections. Slight overhead from the plan-tier sentence ('during the trial and on Pro'), which is context rather than invocation detail, but it supports the do-not-call guidance.

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 3-parameter mutation tool with annotations but no output schema, the description covers the action split, the trigger condition, and the return value (a queued job). What's missing is the cost/destructiveness of a full rebuild versus a delta refresh, which matters given destructiveHint=true.

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?

With 100% schema description coverage the baseline is 3, but the description earns above that by giving the action enum real meaning the schema lacks: refresh_repo queues a re-map, set_free_repo is retired and does nothing. The 'full? rebuild' note reinforces the schema's own description of the full flag rather than adding new constraints.

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 description opens with a specific verb and resource ('Re-map a repo now') and breaks down both enum actions, refresh_repo and set_free_repo. It is clear what the tool does, but it never explicitly contrasts itself with read-only siblings like get_codebase_map, so an agent must infer that those read while this mutates.

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?

It gives an explicit CALL THIS WHEN block ('A repo's graph looks out of date, or needs a full rebuild') plus a strong negative signal that repos are already mapped at trial/Pro and re-mapped on every push, which suppresses unnecessary calls. It also flags set_free_repo as retired and a no-op, so the agent knows not to use that action.

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