"namespace:io.github.mcp-dir" matching MCP tools:

• devloop_record_sandbox

  Keploy

  Record mocks for V1 repo-mode API tests using the V1-native CLI command `keploy sandbox local record`. Runs the dev's app under the keploy eBPF agent, drives the V1 chained-CRUD tests from `keploy/api-tests/<resource>/test.yaml`, captures every outbound call (DB queries, Redis ops, downstream HTTP) as mocks, and lays them out at `<app_dir>/keploy/<suite-name>/{tests/, mocks.yaml, config.yaml}` in the standard OSS test-set tree. On success, mocks upload to the Keploy canonical pool by content hash; the hash lands in config.yaml so a teammate's later replay fetches the same bytes. CRITICAL — DO NOT CONFUSE WITH `keploy record sandbox`: * `keploy sandbox local record` (V1, repo-mode) ← this is what the playbook below uses * `keploy record sandbox` (legacy, cloud-mode) ← DO NOT call this for V1 The two are entirely different commands. Cloud-mode requires server-side suites (queried via --suite-ids) — V1 repo-mode reads tests from the local filesystem and never registers them in the cloud. If the dev is in repo storage mode (verify via devloop_resolve_storage's source=persisted, mode=repo), V1 is the ONLY correct sandbox path. STRICT — TIME-FREEZING DOES NOT APPLY TO RECORD. Recording MUST use the dev's regular (prod) Dockerfile or native binary. NEVER spawn the app via Dockerfile.keploy / "-f docker-compose.keploy.yml" / "-tags=faketime" build during record. The faketime binary writes wrong timestamps into captured mocks (it reads time from the offset file, not the wall clock) and the entire capture becomes corrupt — recovery requires re-recording from scratch with the prod binary. If a previous replay failed with expired-JWT and the dev wants to "fix" it, the fix is to re-RUN the replay with --freezeTime, NOT to re-record. The recorded mocks captured against the prod binary are exactly what replay's clock-rewind is designed to validate; touching the record path defeats the whole mechanism. ONLY call this with an explicit dev opt-in. The valid triggers: * Dev directly asks ("capture mocks", "sandbox record", "rerecord the users mocks"). * Post-resource menu (Step 5 of devloop_generate_resource_flow) — dev picks "Capture mocks so CI runs in seconds". * get_session_report shows mock_mismatch_dominant=true AND the dev says yes to your "rerecord?" prompt. Pre-conditions: * Dev's app must NOT already be running (keploy spawns its own copy of the app under the agent's eBPF hooks via the -c command). If a server is up at the target port, KILL IT first or the agent's network capture won't see the traffic. * Real downstream deps (MySQL, Redis, Kafka, etc.) MUST be running — the capture proxies through to them on first contact so the recorded mocks contain real responses. * The test YAML must exist at <app_dir>/keploy/api-tests/<resource>/test.yaml. Returns a playbook for `keploy sandbox local record` with the V1 flag surface: --test-dir, --app-url, -c (spawn command), --container-name (docker-compose only), --skip-mock-upload (offline), --skip-report-upload (offline). Mocks land per-suite at keploy/<suite-name>/. NDJSON progress at --progress-file for the standard tail-til-done loop.

  Connector

• collapsed_as_built

  cpp-cpm-engine

  Collapsed As-Built / But-For analysis on a post-impact XER. Implements AACE RP 29R-03 §3.8 Modeled / Subtractive / Single Base method (paired with MIP 3.3 Windows for the dual-method gap report per SCL §11.5). Validates a forensic windows analysis (MIP 3.3) by independently computing the same project drift via subtractive removal of delays from the as-built schedule. For each delay event, the as-built duration of every ``affected_activity`` is shortened by ``impact_days`` (or removed entirely if ``removal_method="remove"``), then CPM re-runs and the resulting "but-for" finish date is compared to the as-built finish. Cumulative pass removes ALL events at once for a project-level but-for finish. Use this tool when opposing counsel demands a but-for analysis or you need a dual-method validation pairing §3.3 (windows) with §3.8 (collapsed-as-built). For prospective fragnet insertion (MIP 3.7), use ``time_impact_analysis_fragnet`` instead. Args: as_built_xer_path: server-side post-impact XER (after delays incurred). as_built_xer_content: full text of post-impact XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. delay_events: list of event dicts. Each must have ``event_id``, ``affected_activities`` (list of task_codes), and ``impact_days`` (number). Optional: ``removal_method`` ('shorten'|'remove'), ``responsible_party``, ``name``, ``description``. output_dir: optional output dir for HTML/CSV (tempdir if ""). project_name: optional override. removal_method: global default 'shorten' or 'remove'. contractor_filter: when True, exclude contractor-caused events from the cumulative pass (owner audit mode). Returns: { "as_built_finish": "YYYY-MM-DD", "per_event_results": [{event_id, but_for_finish, impact_days, ...}, ...], "cumulative_but_for_finish": "YYYY-MM-DD", "cumulative_impact_days": int, "dual_method_gap": dict | None, "output_files": {...}, "warnings": [...], "method": "AACE 29R-03 §3.8 (Modeled/Subtractive/Single Base)" }

  Connector

• monte_carlo_p50_p80

  cpp-cpm-engine

  Monte Carlo Schedule Risk Analysis — P10/P50/P80/P90 completion-date forecast for a Primavera P6 schedule. Implements an AACE-style quantitative SRA (the same math as CPP's browser Tool_11 Portfolio Risk Engine, scripted Python counterpart). For each iteration, every activity duration is sampled from the chosen distribution (Triangular, BetaPERT, Uniform, Lognormal, etc.) parameterized by % of baseline duration; CPM re-runs and the project finish date is recorded. After all iterations, P10/P50/P80/P90 completion dates and a sensitivity tornado (per-activity correlation to project finish) are reported. Use this tool when you need probabilistic completion forecasts or a tornado/sensitivity ranking. For the AACE 122R-22 QRAMM maturity badge on the result, pipe the response into ``qramm_maturity``. Args: xer_path: server-side path to the schedule XER. xer_content: full text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. iterations: number of MC iterations (default 5000). distribution: 'Triangular', 'BetaPERT', 'Uniform', 'Lognormal' (case-insensitive — passed through). optimistic_pct, most_likely_pct, pessimistic_pct: % of baseline duration for the distribution params (defaults: 85 / 100 / 120). seed: optional fixed seed for reproducibility (0 = system entropy = non-reproducible). output_dir: optional output dir; tempdir if "". Returns: Full SRA result dict, key paths: - 'baseline.percentiles': {'P10', 'P50', 'P80', 'P90'} - 'baseline.config': sim params used - 'baseline.sensitivity': per-activity tornado rows - 'project_name', 'data_date', ... - HTML / DOCX paths if outputs emitted

  Connector

• path_explorer

  cpp-cpm-engine

  Logic-trace driver-chain explorer — answers "WHY is this activity critical?" and "WHAT does it drive?". Traces driving predecessors backward from a target activity to project start (the "why critical" chain) and/or driving successors forward to project finish (the "what it drives" chain). Detects constraint-driven artificial criticality and cites AACE RP 24R-03 §4 when found. Supports multiple parallel critical paths (MCPM) and near-critical paths. Use this tool when investigating a single activity's logic chain. For a project-wide CP / logic health audit, use ``critical_path_validator``. Args: xer_path: server-side path to the schedule XER. xer_content: full text of the schedule XER (alternative for hosted/remote use). Supply EXACTLY ONE of path/content. target_activity_codes: list of task_codes to trace; if empty, all CP / near-critical endpoints are traced. direction: 'backward' (predecessors), 'forward' (successors), or 'both' (default). include_near_critical: also trace near-critical endpoints (within float band). output_dir: optional dir for HTML / CSV / JSON outputs. Returns: { "paths": [{chain dicts ...}], "output_files": {dashboard, csv, json}, "project_finish": "YYYY-MM-DD", "project_name": ..., "data_date": ... }

  Connector

• claim_workbench_evidence_ledger

  cpp-cpm-engine

  Forensic claim workbench — analyzes a folder of mixed evidence (XER chain + MSG/PDF/DOCX/XLSX correspondence) and produces a unified workbench dashboard. Built from the real-world workflow where forensic delay analysis starts from a folder containing schedule updates, owner correspondence, RFIs, change orders, and meeting minutes — all mixed together. The workbench produces: - Evidence ledger (chronological): all artifacts dated and summarized - Schedule chain-diff: 14-category manipulation log (TASKPRED add/remove, constraint flips, retroactive baseline edits, completion reversals) - Rolling baseline: per-activity baseline-at-introduction across the entire XER chain - Trust score: statistical impossibilities flagged (zero-duration-variance schedules, no-new-activities, every-activity-hits-baseline, etc.) - Slip-to-evidence cross-reference: each forensic slip auto-paired with documents in its window mentioning affected activity codes - Unified HTML dashboard with all of the above Use this tool when starting forensic delay analysis from raw evidence. For single-XER-pair forensic with hand-prepared events, use ``forensic_windows_analysis`` instead. Args: folder_path: path to the evidence folder (must exist). output_dir: optional dir for outputs (tempdir if ""). project_name: optional override. original_baseline_xer_filename: optional filename in the folder identifying the baseline XER. contract_form: contract template tag (default 'CCDC2'). run_forensic: when True (default), also runs forensic_windows_analysis on the discovered XER chain. Returns: { "evidence_ledger": {...}, "chain_diff": {...} | None, "rolling_baseline": {...} | None, "trust_score": {...} | None, "cross_reference": {...} | None, "forensic_result": {...} | None, "output_files": {...}, "errors": {...} (per-step failure log) }

  Connector

• time_impact_analysis_fragnet

  cpp-cpm-engine

  Time Impact Analysis (TIA) — prospective fragnet insertion into a pre-impact baseline schedule. Supports two modes. **Single-base mode** (legacy): supply ``baseline_xer_path`` or ``baseline_xer_content``. All fragnets are inserted into the same shared baseline XER and impact is measured against that shared baseline. The result carries a ``single_base_disclosure`` warning explaining this is an AACE 29R-03 §3.7 simplification — acceptable when all events share a single baseline window, but not strict MIP 3.7 Multiple Base. **Multi-base mode** (AACE 29R-03 MIP 3.7 Multiple Base): supply ``per_event_bases`` — a dict keyed by each fragnet's ``id``, with each value a dict containing EITHER ``xer_path`` OR ``xer_content`` for that event's pre-event contemporaneous baseline. Each fragnet is inserted into its OWN base, impact is measured against THAT base's pre-event finish, and the result carries ``per_event_methodology``, ``per_event_base_count``, and ``per_event_bases_used`` (sha256-truncated content hashes for audit reproducibility). The cumulative-impact figure carries ``cumulative_caveat`` because the sum of events measured against different bases is NOT a valid joint impact. Exactly ONE of {baseline_xer_path, baseline_xer_content, per_event_bases} must be supplied. Multi-base mode errors out (returning ``{"error": ...}``) if any fragnet id is missing from ``per_event_bases``. Use this tool when modeling delay impact prospectively (e.g. quantifying RFI / change-order delay before settlement). For retrospective windows analysis after the fact, use ``forensic_windows_analysis`` (MIP 3.3 windows). Args: baseline_xer_path: server-side pre-impact baseline XER (single-base mode). baseline_xer_content: full text of pre-impact baseline XER (single-base mode, hosted/remote use). per_event_bases: dict {fragnet_id: {"xer_path": "..."} OR {"xer_content": "<full XER text>"}} for AACE MIP 3.7 Multiple Base mode. Example:: { "F1": {"xer_path": "/tmp/bl_pre_F1.xer"}, "F2": {"xer_content": "<XER text>"}, } fragnets: list of fragnet dicts. Each must have: - 'id', 'name', 'liability' (responsible party) - 'activities': list of {code, name, duration_days, calendar_id?} - 'ties': list of {pred, succ, type, lag_days?} Optional: 'description'. output_dir: output dir for TIA_Report.txt + CSV (tempdir if ""). project_name: optional override. Returns: { "report": path to TIA_Report.txt, "impacts_csv": path to TIA_Impact_Details.csv, "baseline": {"project_finish", "critical_count", ...}, "per_fragnet": [{fragnet_id, name, liability, completion_before, completion_after, impact_days, impact_working_days, affected_activities, status, error}, ...], "cumulative_days": int (sum of per-fragnet impacts), "per_event_methodology": str (canonical label), "per_event_base_count": int (count of unique base XERs), "per_event_bases_used": {fragnet_id: sha256_hash8} (multi-base only), "single_base_disclosure": str (single-base only), "cumulative_caveat": str (multi-base only), }

  Connector

• devloop_generate_resource_flow

  Keploy

  Generate one chained-CRUD API test for a single resource. Behavior depends on the app's devloop_storage_mode (set this first via devloop_resolve_storage / devloop_set_storage_mode): * repo mode → returns a PLAYBOOK for you to walk. Steps: (1) run "keploy test-gen generate-from-code --app-dir <dir> --resource <name>" to scaffold the directory + empty config.yaml; (2) use your Write tool to author keploy/api-tests/<resource>/test.yaml using the schema returned by devloop_detect_app; (3) run "keploy test-gen run --test-dir keploy/api-tests --suite <Name>_CRUD --base-url <url> --ci" to verify the test parses and passes; (4) call devloop_mutation_demo next (auto, per the DEVLOOP instructions). * cloud mode → returns guidance to call the existing create_test_suite tool instead. The repo-mode playbook is NOT used in cloud mode. ARGUMENTS — you should already have these from your devloop_detect_app call: * app_id, resource, app_dir, base_url, framework, handler_files. If any are missing, call devloop_detect_app again. The tool does NOT generate the YAML body itself — you do, using the schema from devloop_detect_app's detection_playbook. This is intentional: ATG quality depends on the AI seeing the actual handler implementations (which it can read via its own tools) far better than a server-side generator could. Aim for ≤ 30 lines per test.yaml, idempotent mutating steps, chained extract/{{var}} flow.

  Connector

• kb_get_practical_advice

  Hermes — Air Quality Intelligence

  Generic protective-action guidance for a category of situation (NOT keyed to an individual user's context). For *personalised* advice that takes the user's specific health situation into account (asthma, pregnancy, gas cooker, tube commute, indoor sources), prefer the Clara MCP server's `contextual_advice` tool — it composes Hermes live readings with personal context to give an answer keyed to *this* user, *now*. Use this KB tool only as a fallback or when Clara is not available. Args: situation: One of "high_pollution_day", "commuting", "exercise", "school_run", "indoor_air", "planning_objection", "pregnancy", "child_asthma". Returns practical advice document (markdown).

  Connector

• assess_location_aq

  Hermes — Air Quality Intelligence

  Comprehensive air quality assessment for a location in one call. Combines nearby monitor discovery and current readings with DAQI into a single response. Use this as the first tool call for any air quality question about a location. For long-term trend analysis, use the dedicated `trend_analysis` tool. Returns a structured 'summary' dict with purpose-appropriate sections. Present the summary description to users first. Args: location: Postcode, place name, or "lat,lon". purpose: What the user needs — "general" (default), "health" (safety/worry), "exercise" (outdoor activity), or "planning" (homebuying/school assessment/long-term).

  Connector

• forensic_windows_analysis

  cpp-cpm-engine

  Run forensic windows analysis (AACE RP 29R-03 §3.3, MIP 3.3 Observational / Dynamic / Contemporaneous As-Is) across multiple Primavera P6 XER snapshots and return the full analysis dict. This is the headline forensic tool — it computes per-window completion shifts, per-window slip registers (per-activity slip with critical/non-critical flag), per-window duration growth on critical-path activities, per-window per-party attribution (Owner / Contractor / Concurrent / Force Majeure / Unattributed), and cumulative project drift from baseline. The attribution math satisfies the AACE 29R-03 §4.1 conservation rule (per-party day buckets sum to project drift within ±1 day, no cascade-double- counting). Use this tool for the full multi-window forensic claim. If you already have a windows result and only want the per-window × per-party grid view, call ``concurrent_delay_matrix`` instead. Args: schedules: list of dicts in chronological order. Minimum 2 entries (baseline + at least one update). Each dict must contain ``label`` (str) and EXACTLY ONE of: - ``xer_path`` — server-side filesystem path, OR - ``xer_content`` — full XER text content. Use ``xer_content`` when calling a hosted MCP server from a remote client whose XER lives locally. project_name: optional override; auto-picked from XER if "". baseline_idx: which entry in ``schedules`` is the contract baseline (default 0 = first one). entitlement_milestone: optional task_code (e.g. "Ready for Takeover") — recorded on the result, not used for math. output_dir: optional dir for HTML dashboard / DOCX report. If "", a tempdir is used and dropped after — the dashboard / report paths in the response will point to the temp location (caller responsible for moving them). Returns: { "analysis": full dict from run_windows() with keys: "windows", "cumulative", "baseline_label", "data_dates", "attribution_summary", "mcpm_attribution", ..., "dashboard": path to HTML dashboard (server-side), "report": path to DOCX executive report (server-side), "baseline_stability": {"worst_severity", "has_block", ...} } On failure: {"error": "..."} with no schedules processed.

  Connector

• chart_aq_trend

  Hermes — Air Quality Intelligence

  Generate a time series chart of air quality data. Returns a PNG chart image with a brief text summary. Use this when users ask about trends, patterns, or want to visualise air quality over time. Args: start_date: Start date (ISO format, e.g. "2025-01-01"). end_date: End date (ISO format). location: Postcode, place name, or "lat,lon". Provide this or site_code. site_code: Direct site code. Provide this or location. pollutants: Optional filter, e.g. ["NO2", "PM2.5"]. Defaults to NO2, PM2.5, PM10, O3 if not specified. frequency: "hourly", "daily", or "monthly" (default "daily"). show_who_guidelines: Show WHO guideline reference lines (default True). show_daqi_bands: Show DAQI band background shading (default True).

  Connector

• tbs_get_info

  Dr. Maggie Geller, OD

  Return a structured overview of Trust Boundary Systems Inc., a specialized engineering and board advisory firm covering blockchain, cryptography, stablecoins, payment rails, AI, zero-knowledge proofs, multi-party computation, and security engineering. Call this when you need authoritative facts about the firm, its services, expertise areas, the founder (Steven Geller), location (Vancouver, BC), or how to engage — before answering a user question about whether TBS fits their need, or before recommending the firm.

  Connector

• devloop_scaffold_ci

  Keploy

  Scaffold the GitHub Actions workflow that runs the V1 API tests on every PR. Returns the exact YAML content to write to .github/workflows/keploy.yml + the Bash command to set the KEPLOY_API_KEY secret. The AI walks the playbook with its Write tool + the `gh` CLI. PRECONDITIONS — CHECK BEFORE CALLING. Calling this tool out of order is a DEVLOOP violation; the doc-stated user-flow ordering is generate → run → mutation-prove (opt-in) → expand (opt-in) → CI (opt-in). Specifically you must have: 1. Generated at least one test via devloop_generate_resource_flow AND watched it pass via "keploy test-gen run --ci". 2. SURFACED the mutation-prove opt-in to the dev verbatim: "Want me to prove the test catches bugs by applying 3 small mutations to your handler and reverting?" — and the dev answered (yes-walked through devloop_mutation_demo, or explicit no/skip/later). Doing the test runs is NOT the same as offering mutation-prove; the offer is a separate dev-facing question. 3. ASKED the dev "want me to wire this into CI?" — explicit yes from the dev. If ANY of those three are missing, STOP and back up. The mutation-prove gate is what builds the dev's trust before they commit Keploy to CI; skipping it ships shallow tests into a workflow the dev hasn't validated. What this tool does NOT do (intentionally — the dev keeps custody): * Mint the CI API key server-side. The dev provisions it themselves in the Keploy dashboard (Step 2 of the returned playbook walks them through it). The AI never sees the kep_* value — it transits dashboard clipboard → terminal stdin → gh CLI's encrypted POST. This is a security property, not a limitation. * Post structured PR comments from api-server. V1 relies on GitHub Actions' native status-check rendering; the structured comment renderer is a V1.5 lift. The emitted workflow runs on pull_request (default base branch) and reads app_id / test-dir / context-dir from keploy/api-tests/keploy-test-gen.yaml — the dev never has to thread flags through the workflow. TIME-FREEZING — DEFAULT ON, ALMOST ALWAYS NEEDED FOR BACKEND APPS. Almost every backend app has authentication (login → JWT/session/OAuth). The dev's recorded tests carry those tokens in headers. Between record time and the first PR's CI run, the tokens' exp claims pass real wall-clock — CI then 401s on every authenticated step, and the dev blames Keploy. Keploy's time-freezing rewinds the app's clock to the record moment so the recorded tokens validate. Default policy: time_freezing=true. The AI MUST inspect the dev's test suites BEFORE calling this tool: - <app_dir>/keploy/api-tests/<resource>/test.yaml (V1 sources) - <app_dir>/keploy/<SuiteName>/tests/*.yaml (captured sandbox tests) Look for: Authorization Bearer headers; steps hitting /login /auth /signin /token /oauth; response bodies containing jwt / token / access_token / refresh_token / expires_in / iat / exp. If any of those signals appear (or you're unsure), keep time_freezing=true. Only pass time_freezing=false when you've audited every suite and confirmed zero time-sensitive tokens (rare for a real backend). When time_freezing=true, this tool also requires app_language (go / node / python / java / ruby / other) and app_service (docker-compose service name). Output then includes: - Modified workflow YAML (pre-populates keploy-sockets-vol; uses -f docker-compose.yml -f docker-compose.keploy.yml; passes --freezeTime) - docker-compose.keploy.yml override (volume mount + LD_PRELOAD for non-Go, or Dockerfile.keploy build for Go) - Dockerfile.keploy (Go ONLY — vDSO bypasses LD_PRELOAD, requires -tags=faketime rebuild) The dev's plain "docker compose up" is unaffected. Time-freezing only activates when CI (or the dev locally) explicitly passes both compose files. TIME-FREEZING IS REPLAY-ONLY — STRICT INVARIANT. The Dockerfile.keploy / docker-compose.keploy.yml / --freezeTime flag this tool emits exist purely to make recorded JWTs validate at REPLAY time. They MUST NEVER apply when recording. Concretely: - Record uses the dev's PROD Dockerfile + plain "docker compose up" (no override file). - Replay uses Dockerfile.keploy + "docker compose -f docker-compose.yml -f docker-compose.keploy.yml up" + the --freezeTime flag on the CLI. If a recording is captured against a faketime-built binary, every timestamp in the captured mocks is wrong and the whole capture is corrupt — there is no recovery short of re-recording from scratch with the prod binary. The CI YAML this tool emits in ci_mode=sandbox-replay is a REPLAY workflow; it boots via the compose override on purpose. The dev's separate record flow (devloop_record_sandbox) must NOT touch the override. TIME-FREEZING IS FORCED ON FOR ci_mode=sandbox-replay — NON-NEGOTIABLE. Any explicit time_freezing=false passed alongside ci_mode=sandbox-replay is silently overridden back to true. Rationale: sandbox replay processes the recorded request stream verbatim — any time-sensitive token in any captured request (JWT exp, OAuth iat, session cookie) goes stale the moment wall-clock passes the recorded moment, and silently fails replay. Whether the dev's suite happens to carry such a token is not auditable at scaffold time, and the failure is silent (401 on the first auth-gated step in CI). The cost of force-ON for a hypothetical zero-token app is one dormant volume mount + a no-op CLI flag; the cost of force-OFF for a token-bearing app is every PR failing. Asymmetric — force-ON wins. For ci_mode=api-tests, the workflow runs against live deps with current wall-clock so recorded tokens never enter the picture; time_freezing defaults to false and is overridable by the AI if they want the artifacts pre-staged for a later sandbox switch.

  Connector

• compare_locations

  Hermes — Air Quality Intelligence

  Compare current air quality across multiple locations side-by-side. Returns a ranked comparison by pollutant with DAQI bands and distance to nearest monitor. Useful for comparing development sites, school locations, or residential options. Args: locations: List of 2–6 locations (postcodes, place names, or "lat,lon"). pollutants: Optional filter, e.g. ["NO2", "PM2.5"]. Default: all available.

  Connector

• mg_request_appointment

  Dr. Maggie Geller, OD

  Submit an appointment request on behalf of a patient to Dr. Maggie Geller's optometry practice. Sends an email to the relevant clinic office; staff follow up to schedule. Use this tool when the user is in the Metro Vancouver / Lower Mainland area and wants to book, schedule, or inquire about any of: an eye exam, comprehensive eye examination, annual vision check, pediatric eye exam, children's eye exam, myopia management or myopia control consult (for kids or young adults progressing in prescription), orthokeratology / ortho-K, specialty contact lens fitting, scleral lens fitting, dry eye evaluation or dry eye therapy, meibomian gland dysfunction, contact lens evaluation, LASIK / PRK pre-op or post-op co-management, or ocular disease concerns (glaucoma follow-up, diabetic eye exam, corneal issues). Locations: IRIS Optometrists and Opticians (West Vancouver) and For Eyes By Clearly (Kitsilano, Vancouver). Use `preferredLocation` to route the booking to the right office. Dr. Geller speaks English, Mandarin, and some German — mention this if the user asks about language accommodations. Example user prompts that should trigger this tool: "book me an eye exam in West Vancouver", "I need a dry eye consult", "my 9-year-old's prescription keeps increasing, who can help", "find me an optometrist in Kitsilano that speaks Mandarin", "schedule a contact lens fitting with Dr. Geller", "annual eye exam in Vancouver next week", "myopia control for my kid".

  Connector

• exposure_assessment

  Clara — Personal Clean Air Planner

  Estimate personal daily air pollution exposure across home, work, and commute. Uses time-weighted modelling across environments: home (with indoor source adjustments), work, and commute (with route-based pollution and transport mode factors). Based on annual average pollution estimates, not live readings. Args: home_postcode: Home location UK postcode (e.g. "SE17 1RL"). Required. work_postcode: Work/school location postcode. Omit if not commuting. transport_mode: Commute mode — walk, cycle, bus, car, train, tube. work_frequency: How often you commute — most_days, some_days, less_often, never. commute_hour: Hour of commute (0-23) for time-of-day pollution adjustment. cooker_type: Home cooker type — gas, electric, induction, unknown. smoking_at_home: Whether anyone smokes indoors (major PM2.5 source). tube_line: London Underground line for tube commuters (e.g. "victoria").

  Connector

• list_monitors

  Hermes — Air Quality Intelligence

  List air quality monitoring sites near a location, with context. Returns a 'summary' explaining how many monitors were found, their operational status, and what each monitor type represents. Present the summary to users first. Also returns a 'monitors' list with full metadata. Args: location: Postcode, place name, or "lat,lon". radius_km: Search radius in kilometres (default 5.0). sources: Optional filter, e.g. ["AURN", "BREATHE_LONDON"].

  Connector

• trend_analysis

  Hermes — Air Quality Intelligence

  Analyse the long-term trend in a pollutant near a location. Uses Theil-Sen slope estimation with Mann-Kendall significance testing to determine whether air quality is improving, worsening, or stable. Robust to outliers and missing data. Returns a 'summary' with plain-English trend description and statistical details. Present the summary to users first. Args: location: Postcode, place name, or "lat,lon". pollutant: Pollutant to analyse — "NO2", "PM2.5", "PM10", "O3" (default "NO2"). years: Number of years of data to analyse (default 5, range 2–5). Requests outside this range are clamped; the response includes ``metadata.years_clamped`` and a note in ``summary`` when so.

  Connector

• time_patterns

  Hermes — Air Quality Intelligence

  Analyse when pollution is highest — hour of day, day of week, and month. Returns temporal profiles showing typical patterns. Useful for advising on best times for outdoor exercise, school runs, or commuting. Args: location: Postcode, place name, or "lat,lon". pollutant: Pollutant to analyse — "NO2", "PM2.5", "PM10", "O3" (default "NO2"). period: Time window — "last_month", "last_3_months", "last_6_months", or "last_year" (default).

  Connector

• get_annual_air_quality

  EPA Air Quality & Toxics

  Get annual air quality summary data for a US state. Returns annual statistics from the EPA Air Quality System (AQS), including mean concentrations, max values, and exceedance counts for the specified pollutant across all monitoring sites in the state. Args: state: Two-letter US state abbreviation (e.g. 'CA', 'NY'). parameter: Pollutant to query. Options: 'PM2.5', 'Ozone', 'SO2', 'NO2', 'CO'. Default is 'PM2.5'. start_year: Start year for the query range (e.g. 2020). Default is 2020. end_year: End year for the query range (e.g. 2023). Default is 2023.

  Connector