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_account

Check your plan and live repo, switch a free workspace's live repo, or refresh a repo's knowledge graph before its next push.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
fullNoUsed by: refresh_repo. Force a full rebuild, skipping the delta refresh.
repoNoUsed by: set_free_repo (required), refresh_repo (required). Repo slug (owner/repo).
actionYesWhich account action to perform

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.1.1
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / action
      Added value: +{
+  "description": "Which account action to perform",
+  "enum": [
+    "status",
+    "set_free_repo",
+    "refresh_repo"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / full
      Added value: +{
+  "description": "Used by: refresh_repo. Force a full rebuild, skipping the delta refresh.",
+  "type": "boolean"
+}
    • addedInput schema / properties / repo
      Added value: +{
+  "description": "Used by: set_free_repo (required), refresh_repo (required). Repo slug (owner/repo).",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "action"
+]
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds real behavioral context: invalid action/field combinations are rejected, and set_free_repo changes which repo is live while refresh_repo re-maps immediately. It doesn't note permission requirements or what happens to in-flight pushes during a refresh, so it stops short of the top.

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-line summary, a compact per-action bullet list, a when-to-use block, and a flag glossary. Every section serves a distinct purpose with no filler.

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?

For a three-action dispatcher with no output schema, the description covers what each action does, what status returns (plan, live repo, upgrade link, setup page), and the flag semantics. An agent has everything needed to pick an action and populate fields correctly.

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 coverage is 100% and the schema already tags each field with 'Used by: …' and the repo slug format. The description restates the per-action field mapping and the meaning of 'full' almost verbatim from the schema, so it adds little beyond the structured data.

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 resource domain (plan, live repo, refreshes) and enumerates each of the three actions with what it does: status reads plan/live repo, set_free_repo changes a free workspace's live repo, refresh_repo re-maps a repo. The sibling tools are all code-analysis utilities, so the account-management scope is unmistakably distinct.

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 lists four concrete triggering conditions, including the failure mode ('A repo doesn't answer because it isn't live') that selects set_free_repo. It also implies when to use refresh_repo versus status, leaving little 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