IndexMachine MCP server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INDEXMACHINE_API_KEY | Yes | Your IndexMachine API key (starts with im_live_), created under Settings > API keys in the IndexMachine dashboard. Used both as the env var for the npx package and as the Authorization: Bearer header for the remote server. | |
| INDEXMACHINE_API_URL | No | May point the npx package to a local development server instead of https://api.indexmachine.co; nowhere else. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| account_statusA | The plan, the key's permissions and hourly request budget, whether the user's IndexMachine Chrome extension is online (it performs every Request indexing click), and today's requests per site against Google's daily quota of about 10 per site. |
| list_sitesA | Every Search Console property connected to IndexMachine, with its page counts (indexed, awaiting, rejected, needs_fix, excluded), whether Google indexing is on, whether a paid plan covers it (billable, which Request indexing needs) and whether IndexNow is ready. |
| site_summaryA | One site in full: page counts, today's Request indexing quota (about 10 a day, reset at midnight Pacific), the median days from a first request to indexing, and up to 30 days of counts. |
| list_pagesA | A site's pages by path, with their status, Google's coverage state and the last crawl and request. status not_indexed is every page that is neither indexed nor excluded; q matches part of the URL. A status comes from the last stored inspection; check_url has a single URL in full. |
| check_urlA | Whether a URL of one of the user's sites is indexed on Google, and as of when: the stored Search Console inspection, its open indexing request with the ETA, and with live: true a fresh URL Inspection from Google, which uses 1 of 50 live checks per site a day. indexed is null, not known, when the URL was never inspected. When Google refuses a live check, the stored state comes back with a warning. |
| request_indexingA | Queues a Request indexing click for a URL of one of the user's sites, also one that is not a page of the site yet. The user's IndexMachine Chrome extension performs it in their own Search Console when it next checks in, within about 10 requests per site per day; the answer has the queue position and the ETA in eta_text, which is for the click and not for indexing. It previews first, and queues nothing for a page that is already indexed unless force is true, a re-index. A re-index, a URL that is not in the sitemap, or the site's last request of the day waits for the user's yes. Clients that can ask their user (MCP elicitation) get a question to confirm, and the answer does not pass through the model; with other clients the tool refuses first with a confirm token, and the call with that token stands for the user's yes. |
| get_indexing_requestA | One indexing request: its status, queue position and ETA in eta_text while open, and what Search Console answered once the extension performed it. A closed request with status requested means the click happened; whether Google indexed the page is check_url's answer. |
| list_indexing_requestsA | Indexing requests newest first, for one site or all of them: open ones (preparing, queued, served) with their position and ETA, or closed ones with their outcome. Closed requests are kept 90 days. |
| cancel_indexing_requestA | Takes an open indexing request out of the queue, so the extension never performs it. The page stays in IndexMachine. A closed request cannot be canceled. |
| submit_indexnowA | Notifies Bing, Yandex and the other IndexNow engines of up to 100 URLs of one site at once; it does not reach Google, and each engine decides when it crawls. It needs the site's IndexNow key file in place (indexnow_ready in list_sites) and takes 20 submissions per site a day. More than 10 URLs at once wait for the user's yes. Clients that can ask their user (MCP elicitation) get a question to confirm, and the answer does not pass through the model; with other clients the tool refuses first with a confirm token, and the call with that token stands for the user's yes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| index_url | Checks a URL of your site on Google, queues a Request indexing click when it is not indexed, and tells you the honest ETA. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools are clearly separated by resource and action: list_sites vs. site_summary differ in overview vs. detail, and list_pages vs. check_url differ in bulk page status vs. single-URL inspection. The overlap is manageable, but an agent could initially hesitate between the site-level and page-level read tools.
All names use consistent snake_case and are generally readable. The pattern is mostly verb_noun, but site_summary and account_status are noun phrases rather than action-first names, a minor deviation.
Ten tools is well-scoped for an indexing-management server. Each tool earns its place by covering a distinct part of the site, page, indexing-request, and IndexNow workflow.
The surface covers the core lifecycle: listing sites and pages, checking index status, requesting and canceling indexing, viewing request details, and submitting to IndexNow. Minor gaps include no tools for adding/removing sites or managing sitemaps/IndexNow key setup, but the main agent workflows are supported.