OpenRush
OpenRush is an agent-native marketing data API giving AI agents clean facts on competitors, search, analytics, and ads data.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноТолько чтение
Что умеет
- Describe Capabilities: START HERE. List the live OpenRush surface: enabled data domains, the tools in each, the fact types every tool can emit, which sources back them (live SERP, search index, backli
- Inspect Domain: Starting map for any domain: top organic keywords, top pages, estimated traffic, dominant search intents, and likely competitors in one call. Use this first when handed a bare domain.
- Discover Competitors: Find organic competitors. Provide exactly one of `domain` or `seed_keywords`. - domain mode: competitors by keyword overlap with the target's indexed set. Broad, but unreliable f
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
OpenRush is an agent-native marketing data API giving AI agents clean facts on competitors, search, analytics, and ads data. We are building the unified context layer that lets agents reason accurately and efficiently across every marketing tool a company uses.
Список инструментов сервера (11)
Технические названия из tools/list. Нужны только разработчикам.
| describe_capabilities | START HERE. List the live OpenRush surface: enabled data domains, the tools in each, the fact types every tool can emit, which sources back them (live SERP, search index, backlinks, owned Search Console/Analytics/Ads), and which tools need an owned-data connection. Use this to discover what's available before assuming a tool exists. Returns the standard OFE envelope; the tool list is in `data.tools`. |
| inspect_domain | Starting map for any domain: top organic keywords, top pages, estimated traffic, dominant search intents, and likely competitors in one call. Use this first when handed a bare domain. The `next_actions` typically point to inspect_page (for a winning URL), research_keywords (around a theme), or discover_competitors. Backed by the search index, so a brand-new or barely-indexed domain may return thin `data` — check `coverage` before concluding a site ranks for nothing. |
| discover_competitors | Find organic competitors. Provide exactly one of `domain` or `seed_keywords`. - domain mode: competitors by keyword overlap with the target's indexed set. Broad, but unreliable for new/small sites because the search index lags the live SERP — the response flags this with a `data_freshness` fact. - seed_keywords mode (1-20 queries): aggregates who consistently ranks across those queries by hitting the live SERP database directly. Works for any target including pre-launch. Prefer this when the domain is new or domain mode came back thin. |
| research_keywords | Expand a seed term into a ranked demand list (volume, CPC, competition, intent per keyword). mode: - "ideas" (default): broad, category-level expansion. Best for mapping a topic. - "suggestions": autocomplete-style long-tail off the exact seed. - "related": semantically adjacent terms. Optional filters: `min_volume` drops low-demand noise; `intent` restricts to one of informational | navigational | commercial | transactional. |
| compare_keyword_coverage | Keyword gap analysis: terms one or more competitors (1-10 domains) rank for that `domain` does not, plus terms where the target is losing ground. Use after discover_competitors to turn a competitor set into a concrete content/keyword target list. Results group into intent clusters so the agent can prioritize. Both target and competitors must be reasonably indexed for the gap set to be meaningful — see `coverage`. |
| inspect_serp | Live SERP snapshot for one query: ranked organic results plus which SERP features are present (AI overview, featured snippet, local pack, paid, people-also-ask, related searches). Use to see who actually ranks right now and what the result page looks like before targeting a query. `depth` (10-100) is how many organic results to pull; raise it only when you need the long tail. Reflects Google today, not the index. |
| inspect_search_visibility | Where `domain` ranks across a specific keyword set (1-100 keywords), with a position summary. mode controls the data backend: - "auto" (default): search-index lookup, auto-falling back to live SERPs when the target is underindexed. Best signal-to-noise for any-size domain. - "index": search index only. Fastest; reports unranked for new domains. - "live": one live SERP fetch per keyword — the most thorough mode (slower); always reflects today's Google. Use when "auto"/"index" look stale for a new site. This is a point-in-time read of current positions. |
| audit_site | Fast, opinionated technical / content health audit across a sampled set of a domain's pages, tuned for organic-search signal over noise. Discovers URLs from the sitemap/robots (or a homepage link-crawl fallback), then samples one representative per URL template BY VALUE: money/content pages first, while enumerated low-value sections (e.g. a jobs board or event listings) get a single spot-check rather than eating the budget. Fetches the sample concurrently, then GATES OUT non-indexable pages — anything intentionally `noindex` (on a low-value page) or canonicalized to another URL is excluded from scoring instead of being reported as a problem (a noindexed job listing is working as intended). Returns: grouped `issue_clusters` (issue + severity + affected page count + which page roles + a fix), a ranked `recommendations` list weighted by the *value* of the pages affected, an `onpage_score`, and cross-page duplicate-title/description checks. Full per-page rows — including excluded pages and why — are linked via `resources` (fetch with export_dataset). Runs in seconds. - `max_pages` (default 10, max 20): how many sampled pages to audit. Key fields: `page_class_summary` (sampled pages by role: core/content/ utility/ephemeral), `pages_excluded` + `excluded_summary` (non-indexable pages skipped, by reason), and `worst_page` (the highest-value page with the most issues — the best drill-down target). Each cluster/recommendation carries `page_classes` so you can tell whether a finding hits money pages or just utility ones. Scope: this reads each page's raw HTML — it does NOT execute JavaScript or measure Core Web Vitals. `render_warning: true` means ≥1 audited page looks client-rendered (its raw HTML is near-empty), so its content checks are low-confidence. Also read `coverage` (audited vs discovered), `discovery_source` (a `homepage_fallback` means no sitemap was found), and `fetch_failures` (pages that didn't respond in time). To confirm which findings hit pages that actually earn search traffic, follow the `inspect_domain` / `inspect_page` next_actions. |
| inspect_keyword | Full detail on a single keyword: monthly volume, CPC, competition level, intent, 12-month trend, the current top SERP, and which SERP features it triggers. Use to validate or deep-dive one term surfaced by research_keywords or a gap analysis before committing to it. |
| inspect_page | Full detail on a single page (exact URL): how many organic keywords it ranks for, estimated monthly traffic, and the top terms driving that traffic. Use to understand why a specific competitor URL wins, or to profile one of your own pages surfaced by inspect_domain's top_pages. |
| export_dataset | Fetch the full rows behind a dataset `uri` that another tool returned in its `resources` block (results too large to inline). Pass the uri verbatim; do not construct one yourself. Datasets are retained for a limited window and may be dropped sooner under load, so a valid uri can come back empty. That is not an error: when it happens the response has `data.available = false` with a `note`, and `next_actions` contains the tool to re-run to regenerate the dataset. Follow that action, then export the fresh uri from the new `resources` block. |