Skip to main content
Xerg’s MCP server offers 7 tools, the same ones Ask Xerg uses. All of them read the workspace’s shared map, and none change anything. See Set up coding agents to connect one.

​
overview

Workspace overview. Summary of everything on the workspace’s map: how many repos, apps, outside services and cloud resources; which services are connected (seen live) and which are only found in code; what can be connected next; and when the map was last updated. Start here for broad questions. No parameters. Search the map. Find items on the map by name or keyword (e.g. ‘stripe’, ‘postgres’, ‘api’), optionally filtered by kind (repo, app, outside service, resource), category (e.g. database, payments, ai, hosting) or status (connected, detected = found in code but not connected, unrecognized). Returns ids to use with the other tools. With no query, lists everything that matches the filters. Parameters:
  • query (string): Name or keyword. Leave out to list by filters.
  • kind (one of repo, app, service, resource): repo, app (a deployable unit in a repo), service (an outside service like Stripe), or resource (a cloud resource).
  • category (one of code, hosting, cloud, database, queue, storage, payments, observability, analytics, ai, auth, messaging, devtools, ci, infra, unknown)
  • status (one of connected, detected, unrecognized)
  • limit (integer from 1 to 50, default 20)

​
get_item

Item details. Everything Xerg knows about one item: what it is, whether it’s connected, details read from code or the live account (region, plan, spend…), env variable names it uses (names only, never values), where in the code it was found, and what it links to in both directions. Parameters:
  • item (string, required): An id from search (e.g. tool:stripe) or a name.

​
impact

Blast radius and dependencies. Follow the links on the map from one item. direction=dependents answers ‘what is affected if this breaks, is removed or its key is rotated’ (apps and repos that use it, directly or through other items). direction=dependencies answers ‘what does this need to run’ (services, databases, hosting, resources). Each result says how many hops away it is, through what, and which way traffic flows on that last step: outgoing (it calls the item it was reached through), incoming (that item calls into it: webhooks) or both. An app that receives a service’s webhooks depends on that service. Parameters:
  • item (string, required): An id from search or a name.
  • direction (one of dependents, dependencies, default dependents)
  • depth (integer from 1 to 4, default 3)

​
owners

Who owns it. Who owns an item: the CODEOWNERS owners for the files where it’s used or defined, the repos it appears in, and for a connected service, who connected it. Use it to find who to ask or who to notify. Parameters:
  • item (string, required): An id from search or a name.

​
what_changed

What changed. What changed on the map over a period: items that appeared or disappeared (new services, apps, resources, domains) and services that became connected or disconnected. Use since=‘24h’, ‘7d’, ‘4w’ or a date. Without since, compares with the end of the last earlier day the map changed. Parameters:
  • since (string): ‘24h’, ‘7d’, ‘4w’, or an ISO date. Optional.

​
where_used

Where a key or env variable is used. Where an environment variable or secret name is used (e.g. STRIPE_SECRET_KEY, DATABASE_URL, or a partial like ‘OPENAI’): which repos and apps reference it, in which files, and which outside service it belongs to. Xerg only knows names, never values. Use it before rotating a key. Parameters:
  • name (string, required): The variable name or part of it.