site-indexer
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| INDEXNOW_KEY | No | Your IndexNow key (after publishing <key>.txt). | |
| NETLIFY_AUTH_TOKEN | No | Netlify personal access token, for create_dns_record with Netlify DNS. | |
| CLOUDFLARE_API_TOKEN | No | Cloudflare token with Zone → DNS → Edit on the zone. | |
| SITE_INDEXER_DRY_RUN | No | Set to '1' to enable dry-run: no Google, DNS-provider or IndexNow requests; tools return wouldCall. The public site is still fetched (read-only). | 0 |
| GOOGLE_OAUTH_CLIENT_ID | No | OAuth client ID (used with GOOGLE_OAUTH_CLIENT_SECRET as an alternative to GOOGLE_OAUTH_CLIENT_FILE). | |
| SITE_INDEXER_CONFIG_DIR | No | Override token location. Default: ~/.config/site-indexer (Linux, $XDG_CONFIG_HOME), ~/Library/Application Support/site-indexer (macOS), %APPDATA%\site-indexer (Windows). | |
| GOOGLE_OAUTH_CLIENT_FILE | No | Path to the Desktop OAuth client JSON. | |
| SITE_INDEXER_EXTRA_OWNERS | No | Comma-separated emails added as owners on verification (service-account mode). | |
| GOOGLE_OAUTH_CLIENT_SECRET | No | OAuth client secret (used with GOOGLE_OAUTH_CLIENT_ID as an alternative to GOOGLE_OAUTH_CLIENT_FILE). | |
| GOOGLE_SERVICE_ACCOUNT_FILE | No | Optional service-account mode: path to a service account key JSON. OAuth mode is the supported path; see caveats. | |
| SITE_INDEXER_ENABLE_DESTRUCTIVE | No | Set to '1' to register delete/unverify/owner tools (still need confirm). | 0 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| auth_statusA | Is site-indexer signed in to Google, in which mode, and what to do if not. Never returns secrets. |
| auth_loginA | One-time Google OAuth (loopback on 127.0.0.1). Returns a consent URL immediately; the owner opens it in a browser on THIS machine. Poll auth_status until ready. The refresh token is stored in the OS config dir with 0600 permissions. |
| auth_logoutA | Deletes the stored refresh token from this machine. |
| get_verification_tokenA | Gets the Google Site Verification token and returns exactly what to place: FILE -> fileName + fileContent to publish at the site root; META -> tag for ; DNS_TXT/DNS_CNAME -> the DNS record. Does not verify. |
| verify_siteA | Checks locally that the token is live (file / meta / DNS), then asks Google to verify ownership, retrying with backoff for deploy/DNS propagation. Idempotent: returns alreadyVerified if the site is already yours. |
| create_dns_recordA | For sc-domain: properties: fetches the DNS token and creates the TXT (or CNAME) record via Netlify DNS (NETLIFY_AUTH_TOKEN) or Cloudflare (CLOUDFLARE_API_TOKEN). Skips if it already exists. |
| list_sitesA | Search Console properties for the signed-in account, with permission level. |
| add_siteA | Adds a VERIFIED site to Search Console (sites.add). Run verify_site first. |
| check_sitemapA | Fetches a sitemap from the live site (no Google call) and reports URL count, sample URLs and problems such as wrong host or HTML fallback. |
| submit_sitemapA | Probes then submits a sitemap to Search Console (default /sitemap.xml) and returns Google's sitemap status. |
| list_sitemapsB | Sitemaps known to Search Console for a property, with last download, errors, warnings and submitted counts. |
| inspect_urlA | URL Inspection (read-only): verdict, coverage state, last crawl, canonical. Does NOT request indexing (no public API exists for that). |
| inspect_urlsA | Inspects many URLs (given, or read from the live sitemap) and summarises how many are indexed. Quota: ~2,000 inspections/day and 600/min per property. |
| setup_siteA | Runs the whole loop idempotently: auth -> verification -> add to Search Console -> submit sitemap -> first inspection. Stops at the first step that needs action and returns |
| indexnow_keyA | Generates (or echoes INDEXNOW_KEY) an IndexNow key and the key file to publish at the site root. Bing/Yandex/etc only, not Google. |
| indexnow_pingA | Submits URLs (given or from the sitemap) to IndexNow (Bing, Yandex, Seznam, Naver...). Google ignores IndexNow. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Each tool targets a distinct resource and action (auth, verification, sitemaps, URL inspection, IndexNow), with clear boundary lines like check_sitemap (live fetch) vs submit_sitemap (Google submission) vs list_sitemaps (reported state). setup_site is an explicit orchestrator that wraps the individual steps rather than duplicating them, so no tool genuinely overlaps another's purpose.
Mostly consistent snake_case with a verb_noun pattern (list_sites, add_site, check_sitemap, submit_sitemap, inspect_urls, verify_site), but a few names break the pattern: auth_status and indexnow_key are noun-first rather than verb-led. The deviations are minor and still readable, so the convention is largely predictable.
16 tools is slightly above the typical 3-15 sweet spot, but every tool here earns its place: three auth tools, three verification/setup tools, three sitemap tools, two inspection tools, two IndexNow tools, and one orchestrator. There is no redundant CRUD padding or missing obvious helper, making the count well-scoped for the domain.
The surface covers the full lifecycle from authentication through Google verification, Search Console submission, and URL inspection, plus an alternate IndexNow path. Minor gaps exist (no remove_site/delete_sitemap operations, and no sitemap update beyond re-submission), but agents can work around them and the core workflow is complete.