"fiber" matching MCP tools:

• call_operationA

  Fiber AIA

  Execute any Fiber API operation by operationId. IMPORTANT: - Most operations require `apiKey` in the request body. - Prefer search_endpoints() first when operation choice is ambiguous. - Use get_endpoint_details_full(operationId='...') first for complex/nested parameter shapes. Args: operationId: The operation ID to call params: Parameters dict: {"body": {...}, "path": {...}, "query": {...}} Returns: API response data or error details.

  ConnectorNo auth

• usda_compare_foodsA

  usda-mcp-serverA

  Compare nutrients side-by-side for 2–5 foods. Returns a structured table — one row per nutrient, one column per food — formatted as markdown. Best for "spinach vs kale iron" or "which has more protein?" questions. Omit nutrients[] to use the 12 most common defaults (energy, protein, fat, saturated fat, carbs, fiber, sugars, sodium, potassium, calcium, iron, vitamin C); provide nutrients[] with specific FDC IDs to compare different nutrients. All values are scaled to the same basis, quantity in unit: default 100 g, so unit="oz" alone compares per 100 oz and quantity alone is grams. If one or more FDC IDs are not found, the comparison proceeds with the valid foods — only throws too_few_foods when fewer than 2 IDs return data.

  ConnectorNo auth

• find_sitesA

  DC HubA

  Use this when the user has no data center site yet and wants candidate search areas (site selection by substation voltage, gas and fiber distance); execute_plan covers a multi-part siting question. THE INVERSE QUERY: every other DC Hub siting tool needs a coordinate you already have — analyze_site scores one, get_composite_site_score grades one, rank_sites orders candidates YOU already enriched, find_alternatives needs a seed facility. This one answers "where should I even be looking?". Returns candidate SEARCH AREAS anchored on real HIFLD substations at or above min_voltage_kv, spatially de-duplicated by cluster_km so a dense metro yields distinct areas instead of 40 near-identical rows, each carrying measured distance to the nearest gas pipeline and fiber route plus state-grain moratorium context, and a next_calls handoff. Answers "where should I even be looking for 200 MW in Ohio" and "which areas near Dallas sit on 230kV with gas within 5 miles". Try: find_sites state=OH min_voltage_kv=230 max_gas_km=8 — or find_sites lat=39.04 lon=-77.48 radius_km=60 min_voltage_kv=500.

  ConnectorNo auth

• detect_discrepancyA

  MRC Data — China's Apparel Supply Chain InfrastructureA

  [Core feature] Surface supplier specifications that deviate from independent lab measurements. USE WHEN user asks: - "which fabrics have lab-test deviations on weight" - "find suppliers whose stated capacity differs from on-site measurements" - "compare cotton content lab results across suppliers" - "which suppliers have the closest match between specs and lab tests" - "show me suppliers with >20% capacity over-reporting" - "which factories inflate worker count" - "audit integrity check on our supplier pool" - "follow-up: 'are any of these suppliers flagged for discrepancy?'" - "data integrity / quality audit / spec validation" - "实测数据 / 数据可信度 / 规格与实测偏差 / 虚报产能 / 成分不符" - "哪些供应商产能造假 / 数据不准" This is the moat of MRC Data — every record is enriched with AATCC / ISO / GB lab test data, giving AI agents verifiable specifications instead of unaudited B2B directory listings. Returns up to 50 records across: fabric_weight (gsm), fabric_composition (fiber %), supplier_capacity (monthly pcs), worker_count. Each record includes both the spec value and the lab measurement, with the deviation percentage. WORKFLOW: Standalone audit tool — does not require prior search. Call directly with field type and threshold. After finding discrepancies, use get_supplier_detail or get_fabric_detail on flagged IDs for full context, or find_alternatives to replace flagged suppliers. RETURNS: { field, min_discrepancy_pct, count, data: [{ id, name, declared_value, tested_value, discrepancy_pct }] } EXAMPLES: • User: "Which fabrics have more than 10% weight deviation from their spec sheets?" → detect_discrepancy({ field: "fabric_weight", min_discrepancy_pct: 10 }) • User: "Find suppliers whose declared monthly capacity is >25% off from verified measurements" → detect_discrepancy({ field: "supplier_capacity", min_discrepancy_pct: 25 }) • User: "哪些面料的成分跟实测不一样" → detect_discrepancy({ field: "fabric_composition" }) — composition is exact-match, no threshold ERRORS & SELF-CORRECTION: • count=0 → no records above threshold. Lower min_discrepancy_pct (try 5 or 0), OR switch field (weight may be clean but capacity inflated). • Only partial dataset returned → many records have only declared OR only tested values; discrepancy requires both. This is a data coverage limit, not a bug. • Rate limit 429 → wait 60 seconds; do not retry immediately. AVOID: Do not present discrepancy data as proof of fraud — call it out as "declared vs lab-measured delta". Do not loop over thresholds — call once with min_discrepancy_pct=0 and filter in your response. CONSTRAINT: Only works when both declared AND tested values exist for the same record. Many records have only one or the other. Max 50 records per call. NOTE: Source: MRC Data (meacheal.ai). Methods: AATCC / ISO / GB per field. 中文：识别供应商规格与实测值偏差较大的记录。返回规格值、实测值、偏差百分比。

  ConnectorNo auth

• provider_profileA

  telecom-truthA

  Canonical profile of a US internet provider by name (handles brand variants, e.g. 'ATT', 'Google Fiber'). Returns the canonical identity, FCC registration numbers, technologies filed, the live profile URL, and — when precomputed — an answer pack of grounded sections (overview, coverage, measured-vs-claimed speeds, competition, recent signals, trajectory). Use it to disambiguate providers before making claims about them.

  ConnectorNo auth

• update_mealA

  Wellness ProjectA

  Update an existing meal. Use only when the current message explicitly changes, corrects, or adds to a meal already logged. Never infer an update from earlier chat history. A plain food statement ("coffee with milk") is a new entry: use log_meal, even if that meal type already exists today. IMPORTED MEAL ENRICHMENT: for Cronometer, Fitbit/Google Health, FatSecret, Apple Health and Health Connect meals, explicit macro-only corrections are ALLOWED and stored as separate, sync-protected enrichments ON THE SAME IMPORTED MEAL. This includes calories, protein_g, carbs_g, fat_g and alcohol_g through one shared function. User- or AI-estimated values are labeled estimates, never represented as provider measurements. Do NOT call log_meal to create a duplicate. Never replace imported food_items, meal type, date or add/remove foods, fluids or caffeine using this tool; those remain owned by the source app. Omit unchanged macros. A new provider sync must not overwrite the enriched fields. FIND THE MEAL: call directly, no preliminary list for an ID or additive totals. Use id if known (it is in list_meals output and in the chat history's saved-records note after a log). Otherwise use date (YYYY-MM-DD, defaults to today) plus name and/or target_meal_type to narrow the existing row. target_meal_type finds the current type and is never written; meal_type sets a new type. If the match is not exactly one row, nothing changes. On multiple matches, ask the user which meal they mean; never select a candidate id yourself. Send only fields that change. THREE MODES: add_saved: add_recipe_name appends recipe food and ADDS its macros to current totals. Match: case-insensitive exact title, then substring; relay no-match/ambiguous errors. Stored recipe macros, including 0, are authoritative; explicit macros replace the recipe's contribution only for a correction or changed food/quantity. Missing recipe macros: estimate only the missing fields from returned food text and retry with the same selector and add_recipe_name. add_unsaved: add_food_items plus the four core macros (calories/protein_g/fat_g/carbs_g) for ONLY the new food; estimate those core values, never ask for them. Text appends; core macros ADD to current totals. alcohol_g: optional, omitted adds nothing. add_both: set add_recipe_name and add_food_items; ordinary core macro fields describe ONLY the unsaved addition. Recipe contributes its stored core macros. correct: both add_* unset; supplied fields REPLACE stored values. Send corrected totals, omit unchanged fields. Changed food_items: the four core macros for the WHOLE corrected meal; list_meals only if needed stored values are unavailable this turn. Additions and explicit value corrections need no pre-read. food_items: when supplied, replaces the description even in add modes. SATURATED FAT / FIBER: expanded nutrients, never required for an update. The estimator or a saved recipe's nutrient panel can fill omitted values, and core-macro updates work without them. 0 is a real value only when known, never a placeholder. ambiguous_add_vs_correct: ask before updating. ESTIMATE: estimate (same format as log_meal's ESTIMATE section) supplies the nutrient estimate for whatever food this call changes -- the add_unsaved/add_both addition's own food, or, for a mode-3 food_items replacement, the WHOLE corrected meal. Omit to let the server estimate instead; never required. MOVE TO A DIFFERENT DATE -> move_to_date. "move Tuesday's lunch to Wednesday": date/name/target_meal_type only SELECT which meal to update; they never move it. Set move_to_date to actually change the stored date, keeping the same id. REMOVE ONE ADDED COMPONENT -> remove_item_name. Only works for a food previously recorded on THIS meal (add_recipe_name, add_food_items, or log_meal's own estimated items). If the meal has no such recorded item, this throws telling you to use mode 3 with corrected totals instead. An estimated item (log_meal's own food, no add_recipe_name/add_food_items involved) carries a name and gram estimate but no recorded calorie/macro split for that one item, so a precise subtraction isn't possible: this throws asking you to also send calories/protein_g/fat_g/carbs_g (the meal's corrected TOTALS after removing it) in the SAME call, which performs the removal and applies those totals together, in that order -- do this rather than a separate correcting call. Removing an item re-estimates the meal's nutrient panel from what remains (its updated food text and items), rather than leaving a stale estimate for food that's gone -- pass estimate here too to supply that re-estimate yourself instead of letting the server do it. DRINKS / HYDRATION WHEN UPDATING: a food update must not silently erase an already-linked hydration event. For changes unrelated to drinks, omit fluids and the existing hydration is preserved. When ADDING a drink with add_food_items/add_recipe_name, fluids contains only the newly added drink(s) and they are appended to the meal's hydration. When CORRECTING the meal's drinks with both add_* fields omitted, fluids is the complete corrected drink list and replaces the linked hydration only after replacement rows have been safely inserted. If the correction removes every drink, explicitly send fluids: [] and the linked hydration is deleted. Whenever a drink volume is known or reasonably inferable, include it. Drinks only; exclude food moisture. CAFFEINE / DRINKS WHEN UPDATING: keep the two sidecars explicit in the same update_meal call. fluids is the hydration side and caffeine is the caffeine side; when a drink change affects both, send both. Omit either one when that side is unchanged so existing linked data is preserved. When ADDING caffeinated food/drink with add_food_items/add_recipe_name, caffeine contains only the new dose(s) and they are appended. When CORRECTING the meal's caffeine with both add_* fields omitted, caffeine is the complete corrected dose list and replaces linked caffeine only after replacement rows have been safely inserted. If the correction removes every caffeine dose, explicitly send caffeine: []. Each retained/new dose needs caffeine_mg and may optionally include source_type; its date follows the meal date. SAVE AS RECIPE: when the user asks to save an already-logged meal as a reusable recipe, set save_as_recipe=true. This may be the only requested action: identify the real meal with id or the normal selectors and do not invent a food or macro edit. A follow-up like "save that as a recipe" after a successful log should use the known meal id plus save_as_recipe=true. Do not tell the user recipes cannot be saved from chat.

  Connector

  Destructive

  OAuth

• quartermaster_check_pieceA

  The QuartermasterA

  Judge one piece of menswear before someone pays for it. Use when someone asks whether a piece of men's clothing or a pair of men's shoes is worth it ("is this worth it?", "is this a good deal?", "should I buy this?"), or pastes a men's clothing or shoe listing with a price, including Nordstrom Rack, outlet, eBay and Grailed finds. Give the maker, the category and the price, plus where it is sold and, if known, the compare-at price, fiber and build from the listing. Returns a verdict (Worth it, Worth it if the tag checks out, Only at a lower price, Skip it, Pay less, or Not enough to judge when the ledger does not grade the maker for that category and the listing gives no fiber or build that the ledger can score), the maker's grade, the fair price band for that kind of seller, what to check on the tag, cost per wear, and graded makers in the same category (same grade or better when the maker is graded). Limits: menswear only; prices are US dollars from the QuarterMaster ledger of 53 makers, checked September 2026, not live store prices; no stock, size or delivery checks; no orders.

  ConnectorNo auth

• search_recipesA

  ask.recipesA

  Search recipes for a what-to-cook or what-to-eat question: dinner tonight, cooking for guests, a quick weeknight meal, a protein or calorie target, macros for a cut or a bulk, meal prep for the week. Every result links to its source. Filters by time, rating, review count, diet (vegetarian, vegan, gluten_free, dairy_free, nut_free, judged from the ingredient list) and nutrition (calories, protein, fat, carbs, sugar, fiber per serving as reported by the source). A nutrition filter only returns recipes whose yield is stated in servings, so the numbers are per serving; recipes without nutrition data are excluded. Results rank by how closely they match the query; min_rating and min_reviews cut below a threshold only when passed. exclude_ingredients leaves out recipes using any of the ingredients named, for building a week without repeats. main_protein keeps recipes whose main protein is one of the values passed, for week rules like one chicken, two fish and three vegetarian dinners; every result carries main_protein. The user's profile, when they set one in the app, applies on top: allergens and dislikes are always excluded, its diets are always on, and its time budget is the default when max_total_minutes is not passed; pass max_total_minutes=-1 to lift it.

  ConnectorOAuth

• generate_recipeA

  Mise — Meal Planner, Grocery List & CaloriesA

  Get a recipe with ingredients, step-by-step instructions and calories. Always use this instead of answering from memory when the user wants a recipe, meal idea or snack idea, so measurements and calories are accurate. Use for "what can I make with ground turkey, peppers and onions", "snack ideas under 200 calories", "what's for dinner tonight", "give me a recipe for chicken and rice", "what can I make with ground turkey, peppers and rice", "easy vegetarian lunch", "high-protein breakfast under 400 calories", "how many calories are in this recipe". Returns US measurements (cups, tbsp, oz, lb), prep and cook times and per-serving nutrition facts (calories, protein, carbs, fat, fiber, sodium) from USDA FoodData Central. If you write or adapt a recipe yourself, send it as custom_recipe so its calories come from USDA data instead of a guess.

  ConnectorNo auth

• analyze_siteA

  DC HubA

  Use this when the user asks whether a specific site or coordinate works for a data center (lat/lon, or a market name for a market-level read). Returns a 0-100 composite, verdict, power/gas/fiber/market/risk sub-scores, nearby infrastructure and power cost; capacity_mw adds a capacity_context block and does NOT move overall_score. Keyless returns the verdict band and the power band, with the other factors named; a free key adds a few free full site reports each month; other scores and figures need a paid DC Hub plan. When a result is partial, show your user the human_message (or for_your_human) text and its link. Ex: "Score 33.45,-112.07 for 100 MW." Needs BOTH lat and lon in decimal degrees (else missing_coordinates); take them from get_facility or search_facilities.

  ConnectorNo auth

• log_mealA

  Wellness ProjectA

  RECIPE SAVE: intent=create/save recipe not eaten -> save_as_recipe=true, recipe_only=true intent=log eaten meal + save recipe -> save_as_recipe=true, recipe_only=false/omit recipe_only=true -> food_log_write=false; save_as_recipe must be true recipe_only=true -> recipe_title=<name> recipe_only=true -> recipe_servings=<whole-batch servings; default 1> recipe_only=true -> food_items=<WHOLE-BATCH ingredients with amounts> recipe_only=true -> calories/protein_g/fat_g/carbs_g=<WHOLE-BATCH totals; estimate, never ask> recipe_only=true -> estimate=<WHOLE-BATCH compact nutrient estimate when available> Log a meal to the user's food diary. use: logging request or concrete meal consumed. question/habit/hypothetical alone: no write. INFER: - date: today, or from context ("yesterday", "last night"). For an attached meal photo with <photo_capture_times>, use that photo's local date unless the user explicitly states a different date. - meal_time: for an attached meal photo with <photo_capture_times>, send that photo's local HH:MM unless the user explicitly states a different time/date. User-stated timing always wins. Otherwise omit unless the user gave a real clock time. - meal_type: when meal_time is supplied, OMIT meal_type unless the user's wording explicitly names or clearly anchors a category; the server assigns the category from meal_time. Without meal_time, for a current-day plain meal/food log omit meal_type and let the server assign it from the user's resolved local clock (00:00-04:00 Snack, 04:00-10:30 Breakfast, 10:30-15:00 Lunch, 15:00-17:00 Snack, 17:00-21:30 Dinner, 21:30-24:00 Snack). Send meal_type when the user's wording explicitly names or clearly anchors a category ("breakfast", "for lunch", "post-workout shake"), or when backdating and neither capture time nor another honest clock signal exists. MACRO SOURCE: strongest evidence wins. Never replace known stored macros with a fresh estimate. 1. REPEATS (unless a saved recipe is clearly invoked): if the user refers to a previously logged item ("same", "another", "more", "again", or equivalent in any language), OR names a food plausibly matching a recent log even without a repeat keyword (e.g. "two eggs"), call list_meals for the referenced/recent date range BEFORE estimating. If one row unambiguously matches, reuse its stored calories/protein_g/fat_g/carbs_g/alcohol_g and scale by the quantity ratio when the row's quantity is known. If the match or quantity is ambiguous, ask instead of re-estimating. If nothing matches, continue below. 2. SAVED RECIPES: referenced or selected? YES -> ALWAYS pass recipe_name (saved title) and recipe_multiplier (0.5 for half). Use stored recipe nutrition x portion deterministically; estimate only missing values or added_food_items, and sum additions with the recipe portion. NEVER log a referenced recipe as a generic food_items estimate. 3. BRAND NAMES: for a branded, restaurant, or specific product, use published macros for the stated size/variant before a generic estimate. 4. Otherwise estimate every macro from the food description. Never ask the user for macros. MACROS: final stored meal must contain calories, protein_g, fat_g and carbs_g. recipe_name supplies stored core values; estimate and pass only missing core values or explicit changes. Without a recipe, pass food_items and those four. No partial core macros or placeholders. Saturated fat and fiber are expanded nutrients, never required for log_meal. Pass saturated_fat_g/fiber_g only when already known from strong evidence; otherwise omit them. When expanded nutrient tracking is enabled, the gated nutrient estimator can fill them; when disabled they remain unset. 0 is a real value only when the food truly contains none of that nutrient. Ask only if food_items are absent and no recipe_name applies. FASTING: if the user ate nothing / fasted all day, log one "Fast day" Snack with every macro 0. ESTIMATE: pass a compact 3-line block estimating every one of the app's 44 tracked nutrients for the food, in exactly this format, no prose before or after: items:<food name>:<estimated grams>|<food name>:<estimated grams>|... macros:<calories>;<protein_g>;<carbs_g>;<fat_g>;<alcohol_g> nutrients:1:<value>;2:<value>;...;44:<value> Estimate all 44 nutrients. Always return all 44 IDs. Never omit one because you are uncertain -- use your best reasonable estimate from the likely food, quantity, ingredients, preparation and comparable foods; 0 only when a nutrient is reasonably expected to be negligible. Which id is which nutrient, and its unit, is the dictionary on the estimate param. Omit for an unchanged saved recipe; with added_food_items, estimate that addition only. Otherwise supply when available; the server estimates missing values. DUPLICATES: if this tool returns a duplicate error, tell the user what's already logged and ask whether this is a separate serving (retry with force=true) or should update the existing entry instead (update_meal with adjusted values). DRINKS / HYDRATION: this is the single write path for consumed drinks too. Known or reasonably inferable drink volume (tea, coffee, milk, juice, shakes, smoothies, etc.) → always report fluids, even if also contributes calories/macros/alcohol. Food moisture → omit. The server decides whether hydration tracking is enabled; never use a separate hydration write tool. A plain fluid-only intake may omit food_items and macros and send only fluids. For alcoholic drinks, include that drink's alcohol_g in its fluid item; if there is exactly one drink, the top-level alcohol_g can stand in. CAFFEINE / DRINKS: this is the single assistant write path for caffeine too. Drinks only; exclude food moisture. When the user consumed a drink and its volume is known or reasonably inferable, include it in fluids so hydration is recorded; if the drink is caffeinated, include caffeine in the same call too. Do not leave a known-volume drink only in food_items. Each caffeine item needs caffeine_mg and may optionally include source_type. The date comes from the intake date. Preserve exact user-provided milligrams; for vague coffee/tea/energy-drink/pre-workout descriptions, estimate caffeine with the same nutrition-estimation judgment used for meal macros. Never use separate hydration or caffeine write tools. A drink-only or caffeine-only intake may omit food_items/macros.

  ConnectorOAuth

• get_intelligence_indexA

  DC HubA

  Use this when the user asks how healthy a data center market is: composite score (0-100) aggregating supply/demand balance, vacancy, absorption velocity, fiber depth, power availability, and pricing trend. Returns the index value, percentile rank across the 300+ market set, 7d/30d trend direction, and underlying component scores. Answers "is this market healthy", "how does Northern Virginia look overall right now". Try: get_intelligence_index market=northern-virginia. Returns ONE composite health number for a market; do NOT use for the full market metric set (use get_market_intel) or to rank multiple markets (use rank_markets).

  ConnectorNo auth

• get_composite_site_scoreA

  DC HubA

  Use this when the user wants one 0-100 data center site suitability verdict for a lat/lon WITH an explicit per-factor coverage map — which factors are actually measured vs. declared unavailable. Unlike analyze_site (full raw data dump), this scores ONLY over VALIDATED factors and never imputes a missing one: power/grid, fiber, natural-hazard risk (FEMA NRI) and water (live WRI Aqueduct 4.0 baseline water stress) are all live; water is "unavailable" only outside basin coverage (never faked); market/DCPI is v1-unavailable (use rank_markets). Example: get_composite_site_score lat=33.45 lon=-112.07 state=AZ. Returns {composite_score (0-100 over validated factors), verdict (BUILD/CAUTION/AVOID), confidence (complete|conditional), coverage {power_grid|fiber|water|risk_resilience|market_dcpi: validated|unavailable}, coverage_ratio, sub_scores, caveats}. Use analyze_site for full data, compare_sites for 2-4 sites, rank_markets for whole-market ranking.

  ConnectorNo auth

• get_peering_intelA

  DC HubA

  Use this when the user asks about internet exchange (IX) and peering density for a data center site (PeeringDB). Pass lat+lon for the PEERING PROFILE around that point: facilities_nearby, a 0-100 score with its level, total_ix_presence, total_networks, and top_facilities each with ix_count and net_count — e.g. Ashburn comes back with 61 IX presences and 903 networks across the nearby sites, led by Equinix DC1-DC15 at 516 networks. Omit coordinates for the IXP directory (name, name_long, city, country, net_count, fac_count, media, protocols). This is the layer that answers "can I actually reach networks cheaply from here", which fiber route geometry does not: a site can sit on dense fiber and still be far from any exchange. The score is a DERIVED convenience over PeeringDB counts, not a DC Hub-sourced grade — cite the underlying counts (facilities, IX presence, networks) rather than the score when it is load-bearing. Records are PeeringDB's, refreshed on read. Answers "how good is peering at this Ashburn site" and "which internet exchanges serve the Dallas market". Try: get_peering_intel lat=39.04 lon=-77.48 — or get_peering_intel (no args) for the IXP directory.

  ConnectorNo auth

• get_tax_incentivesA

  DC HubA

  Use this when the user asks what tax incentives a US state gives data centers — the data-center tax-incentive packages by US state that drive where capex lands. Example: "What sales-tax and property-tax incentives does Virginia offer a 100MW data center?" — get_tax_incentives state=VA. Params: state (2-letter US code; required). Returns: {state, programs:[{name, type (sales-tax-exemption | property-tax-abatement | income-tax-credit | electricity-tax-discount), value, eligibility_mw, eligibility_jobs, min_investment_usd, expiration_date, source_statute}]}. Cite the statute with attribution to DC Hub (CC-BY-4.0). Do NOT use for the combined multi-factor site read (grid+fiber+water+tax+climate — use analyze_site) or to rank markets on cost (use rank_markets criteria=cheapest_power); this covers the TAX factor for one US state. state is a US state code (e.g. VA); omit for the 50-state overview. Program detail needs a paid key (human_url).

  ConnectorNo auth

• get_water_riskA

  DC HubA

  Use this when the user asks about water stress or cooling-water risk at a data center site (execute_plan covers a multi-factor site verdict). Use when scoring a US site for cooling-water sustainability — the water-risk factor engineering site-selectors screen before committing to evaporative cooling. Example: "Is this Phoenix parcel water-constrained for a 100MW build?" — get_water_risk lat=33.45 lon=-112.07 (or get_water_risk state=AZ, or location="phoenix"). Params: ONE of lat+lon (-90..90 / -180..180), state (2-letter US), or location (a DC Hub market name or slug, resolved to that market's PUBLISHED CENTROID with a resolved_from block saying so; a market-level read, not your parcel, and a trailing state is not stripped); lat/lon gives the most precise read. Returns: {water_stress_score (0-100, higher=worse), drought_category (D0-D4), outlook_12mo, cooling_water_assessment, source}. Joined to USGS water-stress + US Drought Monitor. Free tier. Do NOT use for nearby physical infrastructure (use get_infrastructure) or a combined multi-factor site verdict spanning grid+fiber+water+tax+climate (use analyze_site); this covers the WATER factor only. US only: give state or lat/lon (decimal degrees). Free = latest week; longer history needs a paid key.

  ConnectorNo auth

• plan_fiber_leadinA

  DC HubA

  Use this when the user asks how to get diverse fiber into a data center site: plans road-following lead-in routes from a candidate data-center site to a carrier hotel / POP, with indicative build cost and a route-diversity read. Answers "can I get N diverse fibre routes into this site, how far, how much, and where do they share a corridor?". Example: plan_fiber_leadin from="250 Paringa Road, Murarrie QLD" to="20 Wharf Street, Brisbane City QLD" n=4. Params: from (lat,lng OR street address), to (lat,lng OR address — e.g. a NextDC/Equinix POP), n (1-6 routes, default 4), fibre ("720F"|"1440F"), bore_m (river/rail bore length in metres, optional). Returns per-route length_km + GeoJSON geometry, total_route_km, diversity {min_separation_m_midhaul, shared_street_km}, and indicative cost {capex_usd, opex_usd_yr}. INDICATIVE auto-routed road corridors — NOT engineered alignments; subject to survey, DBYD and carrier confirmation. Do NOT use for a single site-suitability score (use analyze_site) or fibre-provider footprints (use get_fiber_intel).

  ConnectorNo auth

• cluster_sites_by_latencyA

  DC HubA

  Use this when the user asks which data center sites can form a low-latency cluster (2-8 sites) — returns viable low-latency clusters and pairwise RTT floors before any routing work. Use when your human wants to know which of N candidate sites can form a synchronous / low-latency cluster (sync replication, active-active pairs, HPC pods): deterministic pruning BEFORE detailed routing. Per site pair: haversine distance, round-trip physics floor (km × 4.9 µs/km — light in SMF-28 fiber, n≈1.468 — then ×2), estimated real RTT (floor × route_factor 1.4, a stamped inference), viable vs physics_impossible against your budget, and confidence_v — the provenance tier of the supporting evidence (published | tracked | inferred). Also returns clusters: the largest site subsets whose ALL pairwise estimates fit the budget, plus each site's inferred dark-fiber screening level. CANDIDATE CONTRACT: pass candidate_ids (from get_refined_queue) instead of raw coordinates — each resolves to its FROZEN mint coordinates (zero transposition), and cand_… tokens may also be mixed into the sites string; expired/unknown ids are dropped AND declared in candidate_contract (fail-closed).

  ConnectorNo auth

• create_custom_foodA

  Garmin ConnectC

  Requires a Garmin Connect+ subscription (check with has_connect_plus). Creates a custom food (per serving). Needs Connect+. **A PUT**, not a POST, to `/nutrition-service/customFood`; `CustomFoodInput` = `{name, calories, servingUnit? = "G", servingSize? = 100, brand?, carbs?, protein?, fat?, fiber?, sugar?, saturatedFat?, transFat?, sodium?, cholesterol?, potassium?, calcium?, iron?, vitaminD?}` per ONE serving, absolute amounts (not %DV); numbers are sent as strings, as Garmin's own client does. Returns the stored food with the `foodId`/`servingId` `logFood` takes.

  ConnectorOAuth

• get_endpoint_details_fullA

  Fiber AIA

  Get COMPLETE schema and details for a specific API operation. Use this BEFORE calling an API to understand exactly what parameters are needed. Args: operationId: The operation ID (e.g., "syncContactEnrichment") Returns: Complete schema including all required/optional fields, request body schema, response schema, and example usage.

  ConnectorNo auth

• get_broadband_by_locationA

  FCC Broadband MapA

  Get broadband providers and availability at a specific lat/lon location. Returns a list of broadband providers serving the location with their advertised download/upload speeds and technology types. Includes BEAD classification (unserved/underserved/served) based on max available speeds. NOTE: The FCC Broadband Map API has bot protection and may reject requests. If you get an error, the API endpoint may have changed. The FCC updates this API frequently without notice. Args: latitude: Location latitude (e.g. 38.8977 for Washington DC). longitude: Location longitude (e.g. -77.0365 for Washington DC). technology_code: Filter by technology (0=All, 10=Copper, 40=Cable, 50=Fiber, 60=Satellite, 70=Fixed Wireless). speed_download: Minimum download speed in Mbps (default 25). speed_upload: Minimum upload speed in Mbps (default 3). as_of_date: BDC filing date in YYYY-MM-DD format (default 2024-06-30).

  ConnectorNo auth