Skip to main content
Glama
254,482 tools. Last updated 2026-07-01 10:00

"namespace:io.github.HitTheRoad-Git" matching MCP tools:

  • Create a frontend deployment and get an upload URL. Upload your built frontend as a zip file to the returned URL, then use manage_frontend (action: "start_deployment") to trigger the deploy. Steps: 1. Call this tool to get an upload URL 2. Upload your zip file to the URL (e.g. curl -X PUT "{uploadUrl}" -H "Content-Type: application/zip" --data-binary @frontend.zip) 3. Call manage_frontend (action: "start_deployment") with the returned deployment_id Example: Input: { app_id: "app_abc123", framework: "react-vite" } Output: { deployment_id: "uuid-1234", uploadUrl: "https://...", expiresIn: 900, maxSizeBytes: 104857600 } Prerequisites: - App must exist (use init_app to create) Free plan: 1 deployment per app. Deploying again automatically replaces the previous deployment (no need to delete first). Starter+: unlimited deployments. Framework options: - react-vite: React app built with Vite (zip the dist/ folder) - nextjs-static: Next.js static export (zip the out/ folder) - static: Plain HTML/CSS/JS - other: Any framework that produces static output SPA routing: For SPA frameworks (react-vite, nextjs-static, other), a _redirects file is auto-injected so all routes serve index.html. If your zip already includes a _redirects file, it is preserved. IMPORTANT — Zip file paths must use forward slashes (/), not backslashes (\). On Windows, zips created with built-in tools use backslashes, which causes all files to be served as text/html (breaking JS/CSS with MIME errors). On Windows use Git Bash or WSL to run: cd dist && zip -r ../frontend.zip . Common errors: - RESOURCE_NOT_FOUND: App doesn't exist Idempotency: Not idempotent — creates a new deployment each time (replaces existing on free plan). Your frontend will be deployed to https://<app-name>.butterbase.dev. Next steps: Upload your zip to the returned URL, then call manage_frontend (action: "start_deployment").
    Connector
  • Returns the LOCAL shell commands to package your working directory and upload it for an upload-mode deploy (no git, no PAT). Run them in the user's terminal, capture `source_token` from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTOMATICALLY with a short-lived ticket minted from your MCP credential — NO API key needed in the command and nothing secret is printed (it falls back to needing $REDU_API_KEY only if minting is unavailable). Excludes node_modules/.git/.venv/build output and .env by default; honors .gitignore when is_git_repo=true.
    Connector
  • Deploys a MULTI-CONTAINER app — a repo that ships a docker-compose.yml / compose.yaml (app + its own db/redis/worker containers) — onto ONE VM via podman-compose, and exposes ONE service at https://<name>-<id>.redu.cloud. Use this instead of deploy_app when the repo is a compose stack rather than a single Dockerfile. SAME prereqs + source modes as deploy_app: run check_deploy_prerequisites (network_id + keypair_name), then GIT (`repo`, +git_token for private) or UPLOAD (prepare_upload → source_token). PORT: pass the HOST port the exposed service publishes (the LEFT side of its `ports:` mapping) — redu probes + proxies that exact port; pass `service` to name which service it is (plan_deploy detects both). DB: 'compose' (default) uses the stack's own db service (self-contained); 'single_vm'/'managed' provision a Postgres/MySQL and APPEND its conn env (DATABASE_URL/PG*/MYSQL_*) to the project .env — your compose must REFERENCE those vars to use it (we never rewrite your compose file). Build+provision can take 4-40 min (it pulls/builds every service — heavy ClickHouse/Kafka stacks are slow); poll get_deployment until status='ready', and on failure read build_log (it captures podman-compose logs). TIPS: (1) prefer the project's PREBUILT published images — swap any `build:` block for the published `image:` tag (building from source on the VM is less reliable). (2) redu injects APP_URL/PUBLIC_URL (= the app's public URL) into the env — map the app's own URL/cookie-domain var (SERVER_URL/NEXTAUTH_URL/…) to ${PUBLIC_URL}. (3) multi-surface apps (dashboard + API on separate ports) → pass `expose:[{port,service},…]`, each gets its own URL. (4) if the stack needs a ONE-TIME DB migrate/prepare before it serves (Rails `rails db:prepare`, Django `migrate`, Prisma `migrate deploy` — e.g. Lago), pass `migrate_command` (+ `migrate_service`); without it the stack deploys to 'ready' but 502s on real use because the schema is missing. ALWAYS run plan_deploy first and confirm the plan + cost with the user.
    Connector
  • Deploys an app to a VM and exposes it at a public https://<name>-<id>.redu.cloud URL (a random 8-char suffix is appended to <name> for uniqueness — a BARE custom `dname` like `myapp.redu.cloud` ALSO gets a suffix, so to PIN a known URL pass a dname that already includes an 8-char suffix like `myapp-7k2m9x4p.redu.cloud` and wire the app's own URL env to it; single-surface apps can instead just read the injected PUBLIC_URL/APP_URL). The container is built ON the VM — no local Docker/podman needed. PREREQS — run check_deploy_prerequisites first: it auto-selects your network_id + keypair_name (and returns a recipe to mint a keypair if you have none). Pass those two ids here. PORT: pass the port the app actually listens on (plan_deploy detects it / Dockerfile EXPOSE) — redu health-probes that exact port, so a wrong/omitted port (defaults to 3000) fails a non-3000 app (e.g. a static nginx app listens on 80 → pass 80). TWO source modes: (1) GIT — pass `repo` (public; private repos also need git_token). (2) UPLOAD — call prepare_upload first to tar + POST your LOCAL working dir, then pass the returned `source_token` (no git, no PAT; use this for uncommitted code, a fixed clone of a repo you don't own, or private code). The source needs a Containerfile/Dockerfile; redu auto-finds one in common subfolders (Docker/, scripts/, packaging/…) and builds with the repo root as context — for a repo with MULTIPLE Dockerfiles pass `dockerfile`+`context` to pick the right one. If it has NONE, pass dockerfile_content (the one plan_deploy generated) or include a Dockerfile in the uploaded tarball. To wire a DB, pass `database` (auto-injects the connection env + DATABASE_URL — zero setup): `database:'single_vm'` puts Postgres ON the app VM (cheapest; data dies if the VM is replaced); `database:'managed'` provisions a SEPARATE managed-DB VM on the same private network and wires it automatically (data PERSISTS across redeploys; reused on a same-name redeploy) — you do NOT call create_database/create_relational_database for this. Choose the engine with `db_engine` ('postgres' default → PG* env; 'mysql'/'mariadb' → MYSQL_* env + mysql:// URL, for WordPress/Matomo/LAMP apps; mysql/mariadb require database:'managed'). redu also injects APP_URL/PUBLIC_URL (= the app's public URL) into its env, so apps that need their own URL get it (map an app-specific var like BASE_URL to PUBLIC_URL if needed). Build+provision takes ~3-6 min (a bit longer for managed, which also brings up the DB VM); poll list_deployments or get_deployment until status='ready'. On 'build_failed'/'error', call get_deployment(id) to read build_log. ALWAYS run plan_deploy first and confirm the plan + cost with the user before deploying.
    Connector
  • Create a Firecrawl monitor — a recurring scrape, crawl, or search that diffs each result against the last retained snapshot. Prefer the simple path: pass `page` or `pages` plus `goal` to monitor specific URLs, OR pass `queries` plus `goal` to monitor web search results for new/changed hits. The tool will create the monitor with a 30-minute schedule and meaningful-change judging enabled by the API. Use `body` only for advanced requests such as crawl targets, JSON change tracking, custom retention, or manual `judgeEnabled` control. Meaningful-change judge: set `goal` to a plain-language description of what the user actually cares about. `judgeEnabled` defaults to true when `goal` is set, so providing `goal` is enough. Page webhooks expose `isMeaningful` and `judgment` on `monitor.page` events. Simple fields: - `page`: one page URL to monitor. - `pages`: multiple page URLs to monitor. - `queries`: one or more search queries (1-12) to monitor instead of fixed URLs. Each check runs the searches and diffs the result set, so you get alerted when new or changed results appear. Mutually exclusive with `page`/`pages` in the simple path. - `searchWindow`: optional recency window for search targets — one of `5m`, `15m`, `1h`, `6h`, `24h`, `7d` (default `24h`). - `maxResults`: optional max results per search, 1-50 (default 10). - `includeDomains` / `excludeDomains`: optional domain allow/deny lists for search targets. - `goal`: plain-English instruction for what changes matter. Required for the simple path (and always required when `queries` are set — web monitors must have a goal). - `scheduleText`: optional natural-language schedule, default `every 30 minutes`. - `email`: optional email recipient for summaries. - `webhookUrl`: optional webhook URL. Configures `monitor.page` and `monitor.check.completed`. **Search-mode example:** ```json { "name": "firecrawl_monitor_create", "arguments": { "queries": ["new LLM release", "frontier model launch"], "goal": "Notify me about major new LLM model releases.", "searchWindow": "24h", "maxResults": 10 } } ``` Goal guidance: - Expand the user's one-line monitoring intent into a concise 2-3 sentence monitor goal. - State what should trigger an alert, restate any scope the user gave, and include intent-specific exclusions only when obvious from the user's request. - Generic noise such as whitespace, formatting-only changes, request IDs, tracking params, generic metadata, and unrelated page chrome is already handled by the judge; do not repeat it in every goal. - If the user is vague, keep the goal broad rather than guessing exclusions. If the user asks for broad monitoring or "any change", preserve that and do not add exclusions that hide changes. - If the user says they do not care about something, include that explicitly. It is okay to ask whether they want to ignore specific noise when it is likely to matter. - Do not invent page-specific sections, thresholds, entities, or business rules unless the user mentioned them. Query guidance (web monitors): `queries` control recall (what search retrieves) and `goal` controls precision (which results alert) — tune both. - Write keywords, not sentences: `OpenAI new model release`, not `tell me when OpenAI releases a new model`. - Quote multi-word entities (`"Llama 4"`); group synonyms with `OR` (`launch OR release OR announcement`). - Keep each query tight (~2-6 terms). One broad query usually beats several narrow ones — extra queries split the `maxResults` budget. Use one query per distinct entity; do not emit one per facet of a single subject. - Keep `site:` operators out of queries — use `includeDomains` / `excludeDomains`. - A healthy web monitor mostly returns `new: 0` and alerts only on genuinely new, on-goal results. Many `ignored` results ⇒ queries too broad (tighten them); nothing for long stretches ⇒ queries too narrow or window too tight (broaden); dismissed alerts ⇒ goal too broad (add an intent-specific Ignore). Aim for high precision with enough recall. Full `body` requests require: `name`, `schedule` (with `cron` or `text`), and `targets` (one or more `{ type: 'scrape', urls: [...] }`, `{ type: 'crawl', url: '...' }`, or `{ type: 'search', queries: [...], searchWindow?, maxResults?, includeDomains?, excludeDomains? }`). Optional: `goal` (required when any search target is present), `judgeEnabled`, `webhook`, `notification`, `retentionDays`. **Markdown-mode (default):** Each check produces a unified text diff of the page's markdown. No extra configuration needed. ```json { "name": "firecrawl_monitor_create", "arguments": { "page": "https://example.com/blog", "goal": "Alert when a new blog post is published or an existing headline changes.", "email": "alerts@example.com" } } ``` **Multiple pages:** ```json { "name": "firecrawl_monitor_create", "arguments": { "pages": ["https://example.com/pricing", "https://example.com/changelog"], "goal": "Alert when pricing, packaging, or launch messaging changes.", "webhookUrl": "https://example.com/webhooks/firecrawl" } } ``` **JSON-mode change tracking:** To detect changes in **specific structured fields** (price, headline, in-stock flag, list items) instead of the whole page, add a `changeTracking` format with `modes: ["json"]` and a JSON schema to the target's `scrapeOptions.formats`. The check response will then carry a per-field diff (keyed by JSON path, e.g. `plans[0].price`) and a `snapshot.json` with the full current extraction. See `firecrawl_monitor_check` for the response shape. ```json { "name": "firecrawl_monitor_create", "arguments": { "body": { "name": "Pricing watch", "schedule": { "text": "hourly", "timezone": "UTC" }, "goal": "Alert when a pricing tier, price, billing period, limit, or headline feature changes. Ignore unrelated marketing copy unless it changes the pricing offer.", "targets": [{ "type": "scrape", "urls": ["https://example.com/pricing"], "scrapeOptions": { "formats": [{ "type": "changeTracking", "modes": ["json"], "prompt": "Extract pricing tiers and headline features for each plan.", "schema": { "type": "object", "properties": { "plans": { "type": "array", "items": { "type": "object", "properties": { "name": { "type": "string" }, "price": { "type": "string" }, "features": { "type": "array", "items": { "type": "string" } } } } } } } }] } }] } } } ``` **Mixed mode (JSON + git-diff):** Use `modes: ["json", "git-diff"]` to get both per-field diffs and a markdown sidecar. The page is marked `changed` whenever either surface changed.
    Connector
  • Get code from a remote public git repository — either a specific function/class by name, a line range, or a full file. PREFERRED WORKFLOW: When search results or findings have already identified a specific function, method, or class, use symbol_name to extract just that declaration. This avoids fetching entire files and keeps context focused. Only fetch full files when you need a broad understanding of a file you haven't seen before. For supported languages (Go, Python, TypeScript, JavaScript, Java, C, C++, C#, Kotlin, Swift, Rust) the response includes a symbols list of declarations with line ranges. This is not a first-call tool — use code_analyze or code_search first to identify targets, then extract precisely what you need.
    Connector

Matching MCP Servers

  • F
    license
    A
    quality
    B
    maintenance
    A deterministic MCP server that reimplements ai-git-fish workflows (aicommit, aibranch, aipr) with Leantime integration, enabling Claude Code and Codex to perform git operations and manage tickets without an internal LLM.
    Last updated
    9
  • F
    license
    A
    quality
    D
    maintenance
    MCP server for managing Git operations on local repositories, allowing users to list repositories, get and create tags, list commits, push tags, and refresh repositories through a standardized interface.
    Last updated
    6
    3

Matching MCP Connectors

  • DESTRUCTIVE: Restore an app to a previous version using git reset --hard. This permanently overwrites all current files with the state from the specified commit — any changes made after that commit will be lost and CANNOT be recovered. You MUST confirm with the user before calling this tool. Use list_versions to show the user available versions first.
    Connector
  • Create a new sncro session. Returns a session key and secret. Args: project_key: The project key from CLAUDE.md (registered at sncro.net) git_user: The current git username (for guest access control). If omitted or empty, the call is treated as a guest session — allowed only when the project owner has "Allow guest access" enabled. brief: If True, skip the first-run briefing (tool list, tips, mobile notes) and return a compact response. Pass this on the second and subsequent create_session calls in the same conversation, once you already know how to use the tools. After calling this, tell the user to paste the enable_url in their browser. Then use the returned session_key and session_secret with all other sncro tools. If no project key is available: tell the user to go to https://www.sncro.net/projects to register their project and get a key. It takes 30 seconds — sign in with GitHub, click "+ Add project", enter the domain, and copy the project key into CLAUDE.md.
    Connector
  • Verify the code running on Blueprint servers. Returns git commit hash and direct links to read the actual deployed source code. Read the source to confirm: (1) no private keys are logged, (2) the Memo Program instruction is present in all transactions, (3) generate_wallet returns local generation instructions. Don't trust — read the code yourself via the source endpoints.
    Connector
  • Get contents of multiple files from a remote public git repository in a single call. Reduces round-trips when you need to read several related files. Max 10 files per batch, 5000 total lines budget across all files. Each file supports optional line ranges. Failed files return per-file errors without blocking other files.
    Connector
  • Manage Edge SSR (Cloudflare Workers) deployments: prebuilt-zip flow, server-side build flow, list history. Actions: - "create": Create a deployment from a locally-built zip; returns upload URL + deployment_id - "start": Start the deployment after the zip is uploaded; polls until READY/ERROR (≤60s) - "create_from_source": Server-side build — Mode 1: create deployment + return upload_url - "start_from_source": Server-side build — Mode 2: kick off the build after source upload - "list": List recent deployments (status, URL, sizes) Two flows (pick ONE): FLOW A — local build (you build with @cloudflare/next-on-pages locally): 1. Run `npx @cloudflare/next-on-pages` then zip the CONTENTS of `.vercel/output/static/` (cd .vercel/output/static && zip -r ../../../edge-ssr.zip .) On Windows use Git Bash or WSL; built-in zip tools use backslashes which break uploads. 2. action: "create" → { deployment_id, uploadUrl, expiresIn } 3. PUT zip to uploadUrl with Content-Type: application/zip 4. action: "start" → polls; returns { url, status: "READY" } FLOW B — server-side build (Butterbase runs the build for you): 1. action: "create_from_source" → { deployment_id, upload_url, max_source_bytes } 2. PUT source zip (≤50 MB) to upload_url with Content-Type: application/zip 3. action: "start_from_source" with deployment_id + lockfile_hash (sha256 of package-lock.json) → { build_id, status, logs_url, status_url } 4. Stream logs_url for live build output; poll status_url for terminal status Parameters by action: create: { app_id, action, framework? } start: { app_id, action, deployment_id } create_from_source: { app_id, action, framework? } start_from_source: { app_id, action, deployment_id, lockfile_hash, build_command?, output_dir?, package_manager?, user_env? } list: { app_id, action, limit? } framework: "nextjs-edge" (default) | "remix-edge" | "other-edge" Status values: WAITING | UPLOADING | BUILDING | READY | ERROR | CANCELED | TIMEOUT On TIMEOUT: deployment did not reach a terminal state within 60s. Use action: "list" to check the current status, or call "start" again if it is still BUILDING. Plan limits: Free = 1 deployment per app (replaces previous). Starter+ = unlimited. Common errors: - INVALID_STATUS / UPLOAD_EXPIRED: zip not uploaded before "start" - STATE_PREREQUISITE_MISSING: source zip not uploaded before "start_from_source" - QUOTA_FILE_SIZE_EXCEEDED: source zip exceeds 50 MB - RESOURCE_NOT_FOUND: app or deployment doesn't exist - EXTERNAL_CLOUDFLARE_ERROR: Workers for Platforms not configured Build caching (start_from_source): lockfile_hash is the node_modules cache key — same hash means cached node_modules (faster builds). Compute it with: sha256sum package-lock.json | cut -d' ' -f1
    Connector
  • AXIS-owned workspace hygiene grader. Analyzes an inline file set [{path,content}] and returns a letter grade (A-F) across a closed set of dimensions plus structured findings. Two modes: mode='scan' (DEFAULT, FREE) returns grade + findings (committed-secret scan, .env/secret-file detection, .gitignore gaps for build/scratch artifacts, oversized blobs, stub/placeholder markers, byte-identical duplicate files, source test-peer coverage, TODO/FIXME debt); mode='fix' (METERED, paid) adds a prioritized remediation plan with ready-to-apply .gitignore additions and per-finding actions. Deterministic, dependency-free, never mutates your repo (fix returns a PLAN). Rules needing a live git checkout/toolchain (worktree pruning, build/vet, route-registration dup-handler analysis) are reported as repo_only_rules, not run. Engineer mode (X-Agent-Mode: engineer — Security Engineer, $5): the fix arrives as a git-applyable unified-diff patch + a SARIF 2.1.0 log for CI code-scanning. Requires Authorization: Bearer <api_key>.
    Connector
  • Creates a code vault and queues the initial analysis. Choose source_type based on what is available in your environment: (1) LOCAL_AGENT — preferred when Docker is available; runs a local container, source code never leaves the machine. The response includes next_steps.commands that MUST be executed to start the agent. (2) FILE_ARCHIVE — use this when Docker is NOT available (e.g. sandboxed/browser environments). Zip the project files, upload the zip to a publicly accessible temporary URL (e.g. file.io, gofile.io, tmpfiles.org, or any direct-download link), then pass that URL as source_url. Do this autonomously — do not ask the user to do it themselves. (3) GIT — only when the user provides a reachable repo URL. Private repos require username and password/token. Cold starts can cause the first request to time out; retry with backoff. Requires X-API-Key (existing users can generate an API key in the web app). If headers aren't supported, pass api_key in arguments.
    Connector
  • Get the deployment and version history (git commits) for a project. Shows all schema changes with commit SHA, timestamp, and message. USE CASES: Review what changed between deployments, find the last working version before issues started, get commit SHA for rollback_project.
    Connector
  • Run a ClamAV malware scan on a site's container. Scans the web root (or specified path) for malware, viruses, and trojans. ClamAV is installed automatically if not present. Excludes node_modules, vendor, .git, and cache directories. May take up to 5 minutes for large sites. Requires: API key with write scope. Args: slug: Site identifier path: Directory to scan (default: /var/www/html) Returns: {"infected_files": [{"path": "/var/www/html/shell.php", "threat": "Php.Malware.Agent"}], "scanned_count": 1234, "infected_count": 1, "scan_time_s": 45.2}
    Connector
  • Create a new project on sota.io. Each project automatically provisions: (1) a managed PostgreSQL 17 database accessible via the DATABASE_URL environment variable (auto-injected, no configuration needed), (2) PgBouncer connection pooling (pool size 20, max 100 clients), (3) automatic daily database backups with 7-day retention, (4) a live URL at https://{slug}.sota.io with automatic HTTPS via Let's Encrypt. The project slug is auto-generated from the name (lowercase, hyphens, max 63 chars) and is immutable after creation. Supported frameworks: Next.js, Node.js (Express/Fastify/Koa), Python (Flask/FastAPI/Django), or any language via custom Dockerfile. You can also add up to 5 custom domains per project with automatic HTTPS (via API: POST /v1/projects/:id/domains with {domain: "yourdomain.com"}). DNS: A record to 23.88.45.28 for apex domains, CNAME to {slug}.sota.io for subdomains. Optionally associate the project with a public git repository at create-time by passing `git_url` (and optional `git_branch`). The association is informational — it shows up in the dashboard and the `sota deploy --git` CLI flag can default to it — but does NOT enable auto-deploy-on-push yet.
    Connector
  • Deploy an application to sota.io. The platform auto-detects your framework and builds a Docker image automatically: - Next.js: Detected via next.config.js/ts. Add output: 'standalone' to next.config for optimal builds. - Node.js: Detected via package.json with a "start" script. Works with Express, Fastify, Koa, Hapi, etc. - Python: Detected via requirements.txt or pyproject.toml. Works with Flask, FastAPI, Django. - Custom Dockerfile: If a Dockerfile exists in the project root, it takes priority over auto-detection. Use this for Go, Rust, Java, or any other language. The EXPOSE directive in the Dockerfile is used to detect the app port automatically. THREE WAYS to supply the source code — pick EXACTLY ONE: 1. **files** (inline source from AI): Pass a map of relative paths to UTF-8 text content. Best when you've just generated a small app in this conversation and want to deploy it without any filesystem step. Up to 200 files, 10 MB total. Include the framework manifest (package.json, requirements.txt, or Dockerfile) so auto-detection works. 2. **git_url** (clone a public repo): Pass an https://, git://, ssh://, or git@host:path URL. We shallow-clone it (--depth=1 --single-branch) on the server and deploy. Optional git_branch picks a non-default branch. Only public repos are supported in v1. Max 200 MB after clone. 3. **directory** (local filesystem): Pass an absolute path. Only works when the MCP client has filesystem access (Claude Code / CLI; not Claude.ai web). Defaults to the current working directory when omitted. IMPORTANT: Your app MUST listen on the PORT environment variable. For auto-detected frameworks (Next.js, Node.js, Python) PORT is 8080. For custom Dockerfiles, the port is auto-detected from the EXPOSE directive (e.g. EXPOSE 3000 sets PORT=3000). If no EXPOSE is found, it defaults to 8080. Every project includes a managed PostgreSQL 17 database. Six environment variables are auto-injected into your container — no manual database configuration needed: DATABASE_URL (full connection string), PGHOST, PGPORT, PGUSER, PGPASSWORD, and PGDATABASE. Libraries that follow libpq conventions (node-postgres, pgx, psycopg2, Django) pick up the PG* variables automatically with no configuration. If your app needs database migrations, run them on startup. Deployments use blue-green strategy for zero downtime. The old container keeps running until the new one passes health checks (60s timeout). Use get-logs to monitor build progress. Files matching .gitignore, .git/, node_modules/, .env, and .DS_Store are excluded from the archive.
    Connector
  • AUTHENTICATED. Bulk-apply a reviewed set of facts as the 'submission' JSON (the reviewed rows — Status / Corrected value / Source / Notes filled in), carrying each sheet's slug + base_version_id. It's validated (rows reviewed, known/published skill, base version still live), then applied IN-PROCESS: reconciled by fact_key, judged by an advisory reviewer, and the document is regenerated deterministically from facts — no markdown is rewritten by an LLM and nothing touches a git repo. A skill with a live base applies immediately; the reviewer's pushback comes back as non-blocking `warnings`. For a single fact or a quick spot-fix, prefer submit_fact_verification (no base_version bookkeeping). Requires sign-in and completed onboarding.
    Connector
  • Get a single check with page-level diff results. Filter `pageStatus` to surface only the pages that changed (or were new, removed, etc.). Each entry in `data.pages[]` has `url`, `status` (`same` | `new` | `changed` | `removed` | `error`), optional `judgment` when goal-based judging ran, and — when changed — a `diff` and possibly a `snapshot`. The shape of `diff` depends on the monitor's `formats` configuration: - **Markdown mode (default).** `diff.text` is the unified markdown diff; `diff.json` is a parse-diff AST (`{ files: [...] }`). No `snapshot`. - **JSON mode** (`changeTracking` with `modes: ["json"]`). `diff.json` is a per-field map keyed by JSON path into the extraction, e.g. `plans[0].price`, with each value being `{ previous, current }`. `snapshot.json` is the full current extraction. No `diff.text`. - **Mixed mode** (`modes: ["json", "git-diff"]`). Both `diff.text` (markdown sidecar) AND `diff.json` (per-field map) are present, plus `snapshot.json`. **Example JSON-mode response `pages[]` entry:** ```json { "url": "https://example.com/pricing", "status": "changed", "diff": { "json": { "plans[0].price": { "previous": "$19/mo", "current": "$24/mo" }, "plans[1].features[2]": { "previous": "10 GB storage", "current": "25 GB storage" } } }, "snapshot": { "json": { "plans": [/* current full extraction matching the monitor's schema */] } }, "judgment": { "meaningful": true, "confidence": "high", "reason": "The pricing changed, which matches the monitor goal.", "meaningfulChanges": [ { "type": "changed", "before": "$19/mo", "after": "$24/mo", "reason": "The tracked plan price changed." } ] } } ``` When summarizing a check for the user, prefer `diff.json` paths (e.g. "plans[0].price changed from $19/mo to $24/mo") over re-printing the markdown diff — it's more concise and grounded in the schema fields they asked for. When `judgment` is present, use it to decide what to surface. `judgment.meaningful: false` means the change was classified as noise for the monitor's goal. When `judgment.meaningfulChanges` is present, prefer those goal-relevant changes over raw diff hunks; each item includes `type`, `before`, `after`, and `reason`. The endpoint paginates via a top-level `next` URL; this tool returns one page at a time. Increase `limit` (max 100) to fetch fewer pages. **Usage Example:** ```json { "name": "firecrawl_monitor_check", "arguments": { "id": "mon_abc123", "checkId": "chk_xyz", "pageStatus": "changed" } } ```
    Connector
  • List files and directories in any public git repo. Supports fuzzy file search (query parameter), language/path filtering, and depth control. Combine query with path_filter to search within a directory subset. Use to explore project layout, find files by name, or browse specific directories. Results capped at 1000 files; response includes total_files, files_shown, and truncated fields. Use language or path_filter to narrow large repos. Dependency/build directories excluded by default.
    Connector