A
licenseA
qualityB
maintenanceEnables querying verified-live US traffic cameras by state, route, or named corridor, with camera status and state fleet uptime from official DOT feeds.
5
52 npm
MIT
CitySignal AI
Server Details
Live road, transit, weather, power and water signals for US cities, plus your own spots and routes.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over the last 24 hours
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A3.9/5.0
Scored across 23 tools
Disambiguation4/5
Namespacing (city_* public data, my_* personal, circle_* social, get_* detail lookups) plus detailed descriptions make most tools clearly distinct, and overlapping-sounding pairs like my_along_the_way vs my_detours are explicitly differentiated (errands riding a trip vs event/crowd offers). The main fuzziness is my_brief vs my_day vs city_now, which all answer 'what's going on today' at different scopes, and city_pictures vs get_signal vs city_cameras, which all surface imagery.
Naming Consistency4/5
Everything is snake_case and consistently grouped by domain prefix (city_, my_, circle_, get_), which is predictable and readable. Minor deviation: verbs are mixed — imperative actions (add_errand, save_spot, get_signal, list_cities) coexist with bare noun names (city_week, my_list, my_brief), so the pattern is namespaced rather than uniformly verb_noun.
Tool Count3/5
At 23 tools this is on the heavy end for the stated scope; the breadth (public city data, personal layer, Circle, detours, shopping) justifies most of them, but a few are narrow or near-duplicative (cities_report vs city_week, city_pictures vs get_signal's picture payload, my_brief vs my_day). Some consolidation would reduce selection burden.
Completeness3/5
Read coverage is excellent (alerts, incidents, week-over-week, cameras, pictures, events, personal brief/day/routes/list/spots), and there are two create operations (add_errand, save_spot). However there are no update/delete counterparts — no way to complete or remove an errand/list item, no delete_spot — and no geocoding tool despite several tools requiring lat/lon, leaving agents at dead ends for common correction tasks.
Available Tools
23 toolsadd_errandAdd an errand to my listAInspect
Adds one errand to the connected person's own list, in their words ('milk and eggs', 'pick up lotion at the pharmacy'), the way the app, Siri and a text to Scout do: Scout reads the store kind from the words and fits the errand into a drive they already make. Optional 'by': a day word (today, tomorrow, Friday) or a date (YYYY-MM-DD). Returns the item as the list shows it, a confirmation line, and whether a stop on one of today's drives already fits; a stop is named only when Scout matched one, never guessed. Call this only when the person asks to add something. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | A day word (today, tomorrow, Friday, next Monday) or an ISO date. Omit when they named no day. | |
| text | Yes | What they need, in their words. A store named after 'at' or 'from' is kept and honoured. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the write/duplicate profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety bar is lower. The description adds real value on top: it discloses account requirements, that store kind is inferred by Scout, that a drive match happens automatically, and that a stop is 'named only when Scout matched one, never guessed'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and mostly free of filler, though the 'the way the app, Siri and a text to Scout do' clause and the return-value sentence add length. The three-part return explanation is arguably redundant given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, gating, prerequisites, parameter intent and behavior for a low-complexity two-parameter tool, and it restates return values even though an output schema exists. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description goes slightly beyond the schema by clarifying that 'by' accepts a day word or YYYY-MM-DD and should be omitted when no day is given, and by explaining that text is interpreted in the user's own words with store names after 'at'/'from' preserved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Adds one errand to the connected person's own list') and explains the natural-language capture model ('milk and eggs', 'pick up lotion at the pharmacy'). This cleanly separates it from siblings like my_list (viewing) and circle_needs (shared/observed needs), so an agent can disambiguate without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit gating condition – 'Call this only when the person asks to add something' – plus the prerequisite 'Needs a connected account'. It does not name a specific sibling alternative (e.g. save_spot vs. my_list) for the adjacent cases, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
circle_along_the_wayWho in my Circle is already goingARead-onlyIdempotentInspect
Trips people in the connected person's Circle already plan today or tomorrow that fit an errand: a store run someone's item could ride along on, a return or post office stop, a trip they both make. Returns the person's first name, the trip label, an approximate time only if they share times, the kind of store, and which of the connected person's items could ride along. Never a location. Use for 'is anyone passing a pharmacy today', 'who could grab the milk', 'anyone going to Target'. Asking the person happens in the CitySignal app. Needs a connected account with Circle access.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | ||
| category | No | A store kind or word: pharmacy, grocery, Target, post office. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read-only, idempotent operation, and the description adds genuinely new behavior: the privacy constraint ('Never a location'), the returned fields (first name, trip label, approximate time only when times are shared, store kind, ride-along items), and the auth prerequisite. This is rich context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then return contents, usage examples, and prerequisite in a tight sequence. The colon-separated list of trip types in the first sentence is slightly redundant with the example phrases later, but nearly every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be spelled out, yet the description still names them, and it covers usage triggers, the privacy boundary, and the account prerequisite. Nothing an agent needs to select or call this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'category' is documented in the schema with the same examples the description repeats ('pharmacy, grocery, Target, post office'), and 'day' is a self-describing today/tomorrow enum. The description's phrase 'today or tomorrow' loosely maps to 'day' but adds no syntax or semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: trips already planned by people in a connected person's Circle today or tomorrow that fit an errand. The word 'Circle' implicitly separates it from the sibling 'my_along_the_way', and the enumerated trip types (store run, return/post office) make the intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete trigger phrases ('is anyone passing a pharmacy today', 'who could grab the milk', 'anyone going to Target'), names the follow-up path ('Asking the person happens in the CitySignal app'), and states the prerequisite ('Needs a connected account with Circle access'). When-to-use and prerequisites are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
circle_needsWhat my Circle needsARead-onlyIdempotentInspect
Open errands and list items of people in the connected person's Circle, for people who turned on assistant access for them, with how long each has waited and whether it was already asked of or accepted by the connected person. When an errand lists what it is for, 'items' names them (a 'Groceries' errand with items oat milk, eggs, paper towels): name those items in the answer. An empty 'items' means no items are shared for that errand. Use for 'what does everyone need', 'what has Mom asked for', 'did anyone already get the milk'. People who did not turn on access do not appear. Needs a connected account with Circle access.
| Name | Required | Description | Default |
|---|---|---|---|
| person | No | First name to narrow to one person. | |
| category | No | A kind of errand or a word from it: grocery, pharmacy, returns, milk. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, non-open-world), and the description adds domain behavior they cannot: access-gating (only consenting people appear), the wait-time and asked/accepted state per errand, and the semantics of an empty 'items' array vs. a populated one. That is real operational context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then the access caveat and the 'items' handling rule, then examples. Dense but every sentence carries information; the mid-clause parenthetical about 'Groceries' is slightly verbose but clarifies the items rule usefully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return structure need not be described, and annotations cover the safety profile. The description is complete on scope, consent filtering, and item semantics; the main remaining gap is that it never routes to a sibling for adjacent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'person' and 'category' are already documented in the schema. The example queries demonstrate filtering by person ('what has Mom asked for') but do not add syntax, matching rules, or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific retrieval: open errands and list items belonging to other people in the connected person's Circle, scoped to those who enabled assistant access. This clearly separates it from siblings like my_list (the caller's own list) and add_errand (a write). The verb+resource+scope are all present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger phrases ('what does everyone need', 'what has Mom asked for', 'did anyone already get the milk') and states an exclusion ('People who did not turn on access do not appear'). It never names an alternative sibling to redirect to, so it falls short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cities_reportReport across every cityARead-onlyIdempotentInspect
Report mode: how every live CitySignal city is doing, in one call. The CitySignal Index for the last complete week (Sunday to Saturday): each city scored against its own typical week (Quiet, Typical, Busy, Heavy, with how many times typical), per category (roads, water, power, construction, transit), the biggest departure, week over week, plus what is live in each city right now. Use for reporters and anyone asking 'how is everything across cities', 'which city had the roughest week', 'compare Atlanta and Dallas this week'. Compare cities only by how far each is from its own typical week, never by raw counts: what each city publishes differs. Say when a city is Counting (not scored yet) or a category is Not covered. Cite it as the CitySignal Index and give index_url.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary (default): the storylines and one line per city, for a quick read. detailed: every city's categories too, for a reporter writing it up. trend: each city's recent weekly totals, oldest first, for 'is this getting worse'. | summary |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world, so the bar is behavioral context. The description delivers it: the scoring methodology (each city vs its own typical week, Quiet/Typical/Busy/Heavy plus frequency of typical), the caveat to compare only by deviation and never raw counts because 'what each city publishes differs', handling of Counting/Not covered states, and citation requirements (call it the CitySignal Index, give index_url).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line scope, then scoring, then usage examples, then caveats — a logical order. It is dense and long, and the usage examples arguably belong before the methodology, but no sentence is pure filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained; the description still covers scope, scoring basis, data-completeness edge cases (Counting / Not covered), comparison rules, and citation. Nothing an agent needs to select or call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'mode' enum fully documents summary/detailed/trend with guidance on when each is useful. The description adds no param-level meaning beyond this, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource scope: 'Report mode: how every live CitySignal city is doing, in one call.' It distinguishes itself from single-city siblings (city_now, city_week) by making the all-cities scope explicit, and names the concrete artifact produced (the CitySignal Index for the last complete week Sunday-to-Saturday).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear situational triggers with three example user phrasings ('how is everything across cities', 'which city had the roughest week', 'compare Atlanta and Dallas this week') aimed at reporters. It does not name a competing sibling tool or state when to prefer city_week / city_now instead, so it falls short of an explicit when/when-not rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_camerasRoad cameras and camera checks near a pointARead-onlyIdempotentInspect
Road cameras within a radius of a latitude and longitude (default 1 mile, max 5), nearest first, each with a link to its current still and whether it has live video; plus the camera checks CitySignal ran on alerts there in the last N hours (default 24, max 72): what the camera showed and whether it matched the alert. CitySignal does not record video, so footage of a past moment exists only as a check's saved frame, viewable in the signed-in app. Use for 'is there a camera on this spot', 'do we have footage of this', 'what did the camera show'. It does not geocode: resolve the place to lat and lon first.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| hours | No | ||
| limit | No | Max cameras and max checks (default 10). | |
| radius_mi | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| as_of | Yes | |
| center | Yes | |
| checks | Yes | |
| cameras | Yes | |
| preview | No | |
| radius_mi | Yes | |
| records_video | Yes |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, and the description adds substantive context beyond them: default and maximum radius, default and maximum lookback hours, nearest-first ordering, and the key caveat that CitySignal does not record video so past footage exists only as a check's saved frame viewable in the signed-in app.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope, limits, and caveats are front-loaded, and the usage sentence comes after the behavioral facts. It is dense but nearly every clause carries information; the one area that could be tightened is the video-recording caveat, which takes multiple clauses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter lookup tool with an output schema and full annotations, the description covers scope, ordering, defaults/caps, the no-video caveat, and the geocoding prerequisite. An agent has enough to decide when to call it and how to prepare inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description compensates for the undocumented radius_mi and hours parameters by stating their defaults and caps (1 mi default/5 max; 24h default/72h max) and the ordering of results. It does not explain the city slug or limit parameters beyond the schema, so coverage is not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope: road cameras within a radius of a lat/lon, nearest first, plus camera checks from the last N hours. It also distinguishes itself from nearby siblings like city_pictures and city_incidents by emphasizing camera assets and recorded checks rather than general imagery or incidents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete trigger phrases ('is there a camera on this spot', 'do we have footage of this', 'what did the camera show') and a clear prerequisite/limitation: it does not geocode, so the caller must resolve lat/lon first. It stops short of naming a specific sibling alternative when geocoding is needed, so the routing is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_eventsUpcoming events and gamesARead-onlyIdempotentInspect
Events, concerts and home games coming up in a city within the next N days (default 7, max 14), with venue area, ticket price range and a ticket link when listed, and expected local traffic impact when known. Each event carries placeholder_url, a CitySignal summary card (not a picture) you may link as a tappable markdown link.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| days | No | ||
| limit | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| days | Yes | |
| as_of | Yes | |
| events | Yes | |
| preview | No |
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and openWorld=false, so the bar is lower. The description adds genuine context beyond them: the default and cap on the day window and the instruction that placeholder_url is a summary card intended to be rendered as a tappable markdown link rather than an image. It does not mention rate limits or coverage caveats, but the rendering guidance is real added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource and window before the result-field detail and the link-rendering note. Dense but each clause carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and full read-only annotations, the description only needs to explain scope, constraints and rendering quirks, which it does. The only meaningful gap is the unexplained limit parameter and any pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%. The description compensates for the days parameter by supplying the default of 7 and cap of 14 that the schema omits, but the limit parameter is undocumented in both schema and description, leaving one of three parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (events, concerts, home games) with a time window and enumerates what each result contains (venue area, price range, ticket link, traffic impact). This clearly distinguishes it from siblings like city_incidents or city_now without naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the resource (finding things to do in a city over the next N days), but there is no explicit when-to-use/when-not guidance and no named alternative such as city_week or city_now when the agent wants a broader or narrower view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_incidentsWhat happened, by kindARead-onlyIdempotentInspect
Four weeks of what happened in a city, sorted by kind, for one category. roads (default): crashes, stalled vehicles, hazards and debris, closures, vehicle fires. power: outages by size (one home, small, neighborhood, large), planned outages, downed or sparking lines. transit: delays, canceled trips, reduced service, detours, stop and station changes, planned work. roadwork: lane, ramp and full road closures. water: main breaks and leaks, outages and shutoffs, boil water advisories. Reports that did not say are counted as Type not given. With the busiest and quietest hours of the week, each day of the week's average (by_weekday, busiest_weekday) and each hour of the day's average (by_hour, busiest_time), the full hour-of-the-week grid (hour_grid) and a count for every day (daily), how many new ones a typical instance of an hour sees (pass hour_of_week, or it uses the current hour in the city), the median time until it ended by kind, the places with the most, and for roads how much of the road they took. Use for 'what kind of incidents does Atlanta get', 'when are crashes worst in Dallas', 'how long do Houston power outages last', 'is transit worse on Mondays in Chicago', 'which day of the week has the most incidents', 'what time of day is worst', 'how much night roadwork does Seattle do'. Compare cities by mix and timing, never raw totals: what each city's reports cover differs. Cite it as the CitySignal Index and give page_url.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| category | No | roads (default), power, transit, roadwork or water. | roads |
| hour_of_week | No | 0 = Sunday midnight in the city's own time, 17 = Sunday 5 PM, 137 = Friday 5 PM. Omit for the current hour. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a read-only, idempotent, non-destructive closed-world read, so the description's job is extra context and it does supply some: coverage differs per city, unlabeled reports fall into 'Type not given', and results must be cited as the CitySignal Index with page_url. The default behavior for hour_of_week (falls back to the current hour in the city's own time) is genuinely useful. It does not address how fresh the four-week window is, which matters for a time-series tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening is well front-loaded, but the middle is one enormous run-on sentence listing output fields (by_weekday, busiest_weekday, by_hour, busiest_time, hour_grid, daily) that an output schema already documents. That enumeration is hard to parse and partly redundant, and the split of purpose vs. caveats vs. citation rules into one block of prose obscures the citation requirement that matters most at invocation time.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, a full output schema, and 100% schema coverage, the description covers scope, category semantics, the hour_of_week fallback, and the cross-city comparability caveat — enough to call correctly. Minor shortfall: it never says how far back the 'current hour' is anchored or that preview cities have limited trackers, which is buried in the city parameter schema rather than surfaced here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already enumerates cities and the category enum, so the baseline would be 3. The description earns a 4 by attaching meaning to the enum values (power broken into one-home/small/neighborhood/large outages; roadwork meaning lane, ramp and full closures) and by explaining hour_of_week as an indexing concept tied to the returned grid, which the schema states only as arithmetic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a concrete scope: "Four weeks of what happened in a city, sorted by kind, for one category," and then defines every category (roads, power, transit, roadwork, water) so an agent knows exactly what resource it retrieves. It does not name a sibling tool, so differentiation from city_events, city_now or city_week must be inferred from the example queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides seven concrete example phrasings ('when are crashes worst in Dallas', 'is transit worse on Mondays in Chicago') that map queries to this tool, and adds a usage constraint — compare cities by mix and timing, never raw totals. What is missing is an explicit when-not or a named alternative for area-level lookups (city_near, city_events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_nearAlerts near a pointARead-onlyIdempotentInspect
Alerts within a radius of a latitude and longitude in a city, nearest first, each with its distance in miles: live ones (bucket now, ongoing or ahead) and ones that ended in the last 12 hours (bucket recap, so 'was there anything here this afternoon' can be answered). Default radius 3 miles, max 25. Use when the person names a place, an address or 'near me' and you have coordinates. It does not geocode: resolve the address to lat and lon first.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| limit | No | Max items per bucket (default 25). | |
| category | No | Only this category: road, transit, weather, power, water, construction, emergency, film, sanitation, government_notice. Omit for all. | |
| radius_mi | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| as_of | Yes | |
| items | Yes | |
| center | Yes | |
| preview | No | |
| radius_mi | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent, non-destructive annotations, it discloses result ordering, distance units, two result buckets, the 12-hour recap window, and default/max radius behavior. It also clarifies the important limitation that geocoding is not performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core operation and result shape, then adds usage conditions and constraints. It is dense and informative, though the parenthetical rationale makes it slightly longer than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations cover safety, the description supplies the missing operational context: bucketing, time window, radius defaults/limits, and coordinate prerequirements. An agent has enough information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 50% schema description coverage, the description adds useful meaning for radius (default 3 miles, max 25) and coordinates (must be resolved first). However, it does not explain the limit or category parameters, leaving those to the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific retrieval operation: alerts within a radius of lat/lon, returned nearest first with distance. It clearly scopes the result to live alerts plus those ended in the last 12 hours, which distinguishes it from broad city feeds and incident/camera/event siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this when the user names a place, address, or says 'near me' and coordinates are available. It also states a clear precondition that it does not geocode and requires resolving lat/lon first. It does not name a specific alternative sibling, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_nowWhat is happening in the city right nowARead-onlyIdempotentInspect
Live alerts in a city, deduplicated from official feeds (roads, transit, weather, power, water, construction) and placed by the app's own rule into four buckets: now (live and current), ongoing (live for more than two days, or unconfirmed), ahead (starts later, within 7 days, grouped by day) and recap (ended in the last 12 hours). Each item carries a stable signal_id. Use this for any 'what is going on in ' or 'anything I should know before I head out' question. Events and games are in city_events. Items with a real picture carry picture_url. Images in the result are visible to the assistant only: give the person picture_url as a tappable markdown link next to the item. Never say an image is shown. Show only CitySignal pictures for an incident (picture_url, gallery_url, placeholder_url): never add images from the web or any other source, not even as illustrations. In apps that show CitySignal cards natively, the cards appear on their own; still add one line per card.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| limit | No | Max items per bucket (default 25). | |
| category | No | Only this category: road, transit, weather, power, water, construction, emergency, film, sanitation, government_notice. Omit for all. |
Output Schema
| Name | Required | Description |
|---|---|---|
| now | Yes | |
| city | Yes | |
| ahead | Yes | |
| as_of | Yes | |
| recap | Yes | |
| counts | Yes | |
| ongoing | Yes | |
| preview | No | |
| gallery_url | No | |
| express_lanes | No |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, but the description adds real behavioral context beyond them: deduplication across official feeds, the deterministic bucketing rules including the two-day and seven-day and twelve-hour thresholds, stable signal_id for cross-referencing, and a strict image-provenance policy (CitySignal pictures only, never web images). It also discloses rendering behavior in native-card apps and the assistant-only visibility of images, which no annotation covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, bucketing, and routing are front-loaded in the first three sentences, which is the right ordering. The trailing image-handling block is necessarily verbose but contains a few overlapping restatements (picture_url named three times, two separate 'never add images' clauses) that could be tightened without losing the rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers everything else an agent needs: scope, routing, bucket semantics, ID stability, and the presentation rules for images and native cards. Nothing material is missing for a three-optional-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the city slug enum list, the per-bucket limit range, and the category enum all documented in the schema itself. The description adds essentially nothing about these three parameters, so the baseline of 3 applies — it neither compensates nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Live alerts in a city, deduplicated from official feeds') and enumerates the source domains (roads, transit, weather, power, water, construction) and the four output buckets. It explicitly distinguishes itself from the sibling tool city_events, so an agent can route without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use triggers ('what is going on in <city>' / 'anything I should know before I head out') and an explicit exclusion routing events and games to city_events. The bucket definitions (now vs ongoing vs ahead vs recap) further tell the agent when each part of the result is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_picturesPictures of what is happeningARead-onlyIdempotentInspect
Up to six CitySignal picture cards for incidents in a city, including ones that already cleared: the frame a camera check kept, or a live view while the incident is still going. Each card has a headline, time, city, and a Cleared / Earlier today tag when it's over. Incidents with no picture are left out.
Images in this tool's result are visible to the assistant only, not to the person. To show a card, give the person its picture_url as a tappable markdown link with a short label (road, cross street, time), e.g. I-20 WB at US-29 (live). Never tell the person a picture is "shown" or "above." Describe what each image shows in one line next to its link. In apps that show CitySignal cards natively, the cards appear on their own; still add one line per card. If gallery_url is present, give it first as the one link that opens all cards. Show only CitySignal pictures for an incident (picture_url, gallery_url, placeholder_url): never add images from the web or any other source, not even as illustrations.
Use for "show me what's happening," "any pictures," "what did it look like." hours (default 12, max 72) is how far back camera checks count.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| hours | No | How far back, in hours (default 12). |
Output Schema
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| as_of | Yes | |
| hours | Yes | |
| items | Yes | |
| preview | No | |
| gallery_url | No |
TDQS
A4.1/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), yet the description still adds non-obvious behaviour: images are visible to the assistant only, cards must be surfaced as tappable markdown links labelled with road/cross-street/time, gallery_url goes first when present, the assistant must never claim a picture is "shown" or "above," and only CitySignal image URLs may be used. That is substantial delivery context that no structured field carries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Opens with what the tool returns, then rendering rules, then use cases — front-loaded and mostly free of filler. The trigger phrases would land better next to the opening rather than as the final paragraph, and the markdown-link example sentence is dense, but each instruction serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and the description instead covers the behavioural rules that matter (assistant-only images, link format, source restriction) plus result limits. It does not say what the agent should do when no pictures come back or whether widening hours is the remedy, which is the main remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the full city slug enum and the hours range. The description restates the hours default/max and adds the nuance that hours counts back over camera checks, but adds nothing about the city slug parameter. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (CitySignal picture cards for city incidents) and its scope: up to six cards, including cleared incidents, each with headline, time, city and a Cleared/Earlier today tag, with pictureless incidents omitted. That is concrete and distinct from a bare list tool, but it never names the neighbouring tools (city_cameras, city_incidents, city_now) that an agent would have to choose between.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit trigger phrases are given: "show me what's happening," "any pictures," "what did it look like," which makes the use case easy to match. It also explains the hours window (default 12, max 72). It stops short of exclusions — nothing says when to prefer city_cameras or city_incidents instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_weekThis week against last weekARead-onlyIdempotentInspect
Week-over-week memory for a city: counts by category for the last 7 days and the 7 before, a plain-language read of the week, measured insights, where it concentrated (areas and corridors), why an unusual week was unusual, and what a newsroom published about it. Use for 'how has this week been', 'is this normal', 'where do outages keep happening'.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds the temporal window (7 days vs. prior 7) and the breadth of returned analysis, but says nothing about latency, caching, preview-city limitations, or coverage gaps — items the schema hints at only indirectly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core concept ('Week-over-week memory for a city') followed by a dense enumeration and then usage triggers. One long sentence listing six facets is slightly list-heavy but every clause conveys real content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool complexity is high (multi-part analytical report) and an output schema exists, so return shape needn't be detailed; the description still summarizes the report's components, which helps intent matching. Remaining gap is minimal — mainly caveats about preview cities and data freshness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single optional parameter with 100% schema description coverage, including the full city slug enum and the preview list, so the schema carries the burden. The description adds no meaning about how city selection affects output beyond what the schema states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Week-over-week memory for a city: counts by category for the last 7 days and the 7 before', then enumerates the payload (plain-language read, insights, areas/corridors, unusual-week explanation, newsroom coverage). This clearly distinguishes it from snapshot siblings like city_now, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggering questions ('how has this week been', 'is this normal', 'where do outages keep happening'), which maps intent to tool well. It stops short of exclusions or pointing to alternatives such as city_now for current-state questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_detourWhat a detour code opensARead-onlyIdempotentInspect
Resolves a DETOUR-XXX code for the connected person: which drive it is on, the event, whether it is worth it (a stop) or dodge it (a way around), the streak and offer lines, and the link that opens it. Codes are per person and per day; a code that has passed says so. Use when the person says or pastes a code. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The code, like DETOUR-KQM. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent, non-destructive read. The description adds genuinely non-obvious behavior: codes are scoped per person and per day, an expired code reports that it has passed, and a connected account is required. Return contents are partly described, but with an output schema present the remaining burden is light.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the resolution outcome, then the per-person/per-day constraint, then the trigger and the account prerequisite. Dense but every clause carries information; the middle clause listing all return fields is slightly list-heavy but still earns its place given no prose elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be spelled out, and the description still covers auth requirement, code scoping, and expiry behavior. The only real gap is not naming a sibling for browsing versus resolving codes, which is minor for a single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the code param already documents the DETOUR-KQM format), so baseline is 3. The description adds the meaningful scoping semantics that the schema cannot express: the code is per person and per day and may be expired, which tells the agent what a valid vs. stale input means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (resolves a DETOUR-XXX code) and then enumerates exactly what resolution yields: drive, event, stop-vs-dodge verdict, streak/offer lines, and the opening link. This makes it clearly distinct from siblings like my_detours (listing) and circle_along_the_way, so an agent can route between them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger: 'Use when the person says or pastes a code.' That is clear usage context. It does not, however, name the alternative to use for browsing codes (my_detours) or state when not to call it, so it stops short of explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_profileWho is connectedARead-onlyIdempotentInspect
The connected CitySignal account: a stable opaque id and display name. Call this to confirm which account is linked before reading personal tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context about the returned identity fields and the recommended precondition before using personal tools, though it does not discuss auth or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both useful: the first states what identity data is returned, and the second states when to call it. The usage guidance is front-loaded enough and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema and rich annotations already present, the description supplies the remaining context an agent needs: it identifies the returned account fields and explains when to invoke the tool. Nothing essential is missing for a zero-parameter identity check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are inherently minimal and the schema already reflects an empty input object. A baseline of 4 is appropriate because there are no parameters for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the connected CitySignal account and specifies the returned fields: a stable opaque id and display name. It distinguishes the tool from personal reading tools by framing it as an account-confirmation prerequisite, though it does not use an explicit action verb in the opening sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this before reading personal tools to confirm which account is linked, giving clear usage context. It does not name exclusions or alternatives, but no obvious sibling performs the same identity-confirmation role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signalOne signal in fullARead-onlyIdempotentInspect
Full detail for one signal by its signal_id (from any other tool): summary, place, area, corridor, timing, source link, confidence and whether a live camera check confirmed or contradicted it. When a real picture exists it carries picture_url, label and link (a ready markdown link), and the card comes back inline for you only: give the person the link and never say an image is shown. In apps that show CitySignal cards natively, the card appears on its own; still add one line about it. With no picture it carries placeholder_url, a summary card, not a picture. Show only CitySignal pictures for an incident (picture_url, gallery_url, placeholder_url): never add images from the web or any other source, not even as illustrations.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami. | atlanta |
| signal_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds meaningful behavior beyond that: what the card yields when a real picture exists versus when only a placeholder does, and the critical rule that the inline card is for the agent only and the person must be given the link. It doesn't cover failure modes (unknown id, wrong city), which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause, followed by return contents and then display rules. It is longer than typical and repeats the image-source prohibition twice ('never add images from the web', 'not even as illustrations'), but each sentence carries operational instruction rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the field enumeration (summary, place, corridor, confidence, picture_url) is partly redundant, but the description supplies the non-structured display contract that no schema can express. For a two-parameter read tool with full annotations, this is nearly complete; only error and mismatch behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the city parameter is fully documented in the schema (slug list plus preview cities) while signal_id carries only length constraints. The description compensates partially by telling the agent the id comes from another tool, but adds nothing about the city parameter or what happens when city and id disagree. Baseline 3 is appropriate when the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'full detail for one signal by its signal_id'. The parenthetical '(from any other tool)' makes clear this is the single-record fetcher in a family of list tools such as city_incidents. It stops short of naming a specific sibling to disambiguate against, so it falls just under a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the agent infers it should call this once it holds a signal_id from another tool. There is no explicit when-to-use versus when-not, and no guidance on what to do if the id is unknown or the signal is missing. The bulk of the text is presentation guidance (how to show the card/image) rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_citiesList covered citiesARead-onlyIdempotentInspect
The cities CitySignal covers, with their slug, timezone, center point, the official sources it reads, and status: live, or preview (still being checked, open to sign-ups, trackers not yet public). Call this when unsure which city slug to pass.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| cities | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuinely useful domain context: the live vs preview status distinction and the fact that preview cities accept sign-ups but have no public trackers yet. It does not mention rate limits or freshness of the catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned and closing with the usage trigger. The parenthetical defining preview is the only heavy passage, and it is justified, though the field list partially duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only catalog tool with rich annotations and an output schema, the description supplies the trigger condition, the status vocabulary, and the result contents. Nothing an agent needs to select or call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description instead documents the shape of the result set (slug, timezone, center point, sources, status), which is helpful though partly redundant with the existing output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource (the cities CitySignal covers) and enumerates the payload it returns: slug, timezone, center point, official sources, and live/preview status. It is not a tautology of the name. It does not, however, differentiate itself from ambiguous siblings such as cities_report or city_now, so an agent must infer that this is the canonical slug index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this when unsure which city slug to pass' gives a clear, actionable trigger condition. There is no explicit when-not guidance and no sibling is named as an alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_along_the_wayErrands that fit today's tripsARead-onlyIdempotentInspect
Errands on the connected person's list that fit a trip they already make today, with the store, the detour in minutes, why that store, and a price line when one is known. Use for 'what can I pick up on the way', 'any errands I can do today'. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds real context beyond that: it requires a connected account and it discloses the shape of the result (store, detour in minutes, why that store, optional price).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads what the result contains, the second front-loads usage triggers followed by the auth requirement. No filler or restated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be documented, yet the description still summarizes them usefully. Auth prerequisite and read-only nature are covered, leaving only the absence of sibling routing as a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4; the description has no parameter semantics to explain and correctly spends no words on them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope: errands on the connected person's list filtered to trips already made today, and it enumerates the returned fields (store, detour minutes, rationale, price line). It is clear what the tool returns, but it does not explicitly distinguish itself from close siblings such as circle_along_the_way or my_detours.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete user phrasings that should trigger the tool ('what can I pick up on the way', 'any errands I can do today') plus the prerequisite of a connected account. It does not, however, state when NOT to use it or name an alternative for the shared-audience case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_briefMy brief for todayARead-onlyIdempotentInspect
Today's written brief for the connected person: top alerts, citywide items, what is near their spots with why it matters and a recommended action, events, what is ongoing, what came and went since the last brief. Use when they ask for their briefing or a summary of their day. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered structurally. The description adds useful behavioral context: the brief is personalized to the connected person, includes 'why it matters' and a recommended action, and tracks what changed since the last brief.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the resource and its contents, then the usage trigger and prerequisite. The long enumeration sentence is dense but each listed element helps an agent understand what the brief contains; there is little wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema available, return values need not be explained. Annotations cover the safety profile, the prerequisite is stated, and the content scope is clear enough for an agent to select and invoke this no-parameter tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4; no parameter semantics are needed. The description appropriately explains the content dimensions rather than inventing input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource — today's written brief — and enumerates its contents (alerts, citywide items, nearby spots, events, ongoing items, deltas since the last brief). This distinguishes it from narrower siblings such as city_now or city_near by making clear that this is a bundled daily briefing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger: 'Use when they ask for their briefing or a summary of their day,' and states the prerequisite 'Needs a connected account.' It does not explicitly say when to prefer my_day or city_now instead, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_dayMy day: what touches my spotsARead-onlyIdempotentInspect
The connected person's own Now / Ongoing / Ahead / Recap: live signals that touch their saved spots and routes, in the same buckets the app shows, plus today's calendar line. Use for 'anything I should know today', 'what's near my places', 'is my area affected'. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds the prerequisite that a connected account is required and characterizes the payload as live signals organized into the app's own buckets — context the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The content is front-loaded with what the tool returns, followed by usage triggers and the account prerequisite — a sensible ordering with no filler sentences. It is somewhat jargon-dense ('buckets', 'Now / Ongoing / Ahead / Recap') which costs a little readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail need not be spelled out, and with zero params and full annotation coverage the structural burden is low. The description covers purpose, triggers and the auth prerequisite, leaving only sibling disambiguation unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema imposes nothing for the description to explain. Baseline for a no-parameter tool is 4; the description correctly implies no input is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource — the connected person's own Now/Ongoing/Ahead/Recap signal digest plus today's calendar line — which is concrete enough that an agent can distinguish it from city_now or city_incidents. It stops short of explicitly contrasting itself with the closest siblings (my_brief, my_along_the_way, my_routes_now), so the differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Three quoted trigger phrasings ('anything I should know today', 'what's near my places', 'is my area affected') give the agent clear activation contexts. However, it never states when NOT to use this tool or which sibling to prefer for overlapping intents such as a general brief or along-the-way lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_detoursScout's detours for todayARead-onlyIdempotentInspect
Scout's detour offers on the connected person's drives today, as the Scout page shows them: the streak line (how many drives or weeks straight home), the offer (worth it: an event they marked interest in, near a drive, as a stop; dodge it: a big crowd a drive passes, with the way around), the DETOUR-XXX code and what the code opens. The route's own state never changes because of an event. Use for 'any detours today', 'what is that DETOUR code', 'anything worth stopping for on the way home'. Empty when there is no offer. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description still adds genuinely new context: "Empty when there is no offer", "Needs a connected account", and the invariant that "The route's own state never changes because of an event". These exceed what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single run-on sentence stuffed with deeply nested parentheticals ("the offer (worth it: ...; dodge it: ...)") that are hard to parse. The key facts are present but the structure is dense and not front-loaded as a clean statement of purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail is not required, and the description still covers auth ("Needs a connected account") and the empty-result case. For a 0-param read-only tool this is nearly complete; only sibling routing remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters (empty schema, 100% coverage), so there is nothing for the description to document. Per the calibration rule, a 0-param tool gets the baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description conveys the resource well: today's detour offers on the connected person's drives, including the DETOUR-XXX code and what it opens. However, it opens with no clean verb ("Scout's detour offers ... as the Scout page shows them") and uses idiosyncratic in-group terms ("streak line", "worth it/dodge it"). It never distinguishes itself from the sibling get_detour, so it lands at clear-but-undifferentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit trigger phrases: "any detours today", "what is that DETOUR code", "anything worth stopping for on the way home". That is clear context for when to reach for it. But it names no when-not condition and no alternative sibling (e.g., get_detour), so it stops short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_listMy priced listARead-onlyIdempotentInspect
The connected person's shopping list as Scout priced it at their home Kroger: each item with product, size, price and whether it is on sale, plus the running total. Non-private lists include a revocable share link that expires after seven days. Use for 'what's on my list', 'how much will groceries be', 'is anything on sale'. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive, closed-world behaviour, so the bar is lower; the description still adds real context by stating the auth requirement and the share-link behaviour (revocable, seven-day expiry) for non-private lists. It stops short of describing pagination or list-size limits, which would be the remaining useful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with what is returned, then the share-link caveat, then usage cues and the auth note. Each sentence carries information, though the share-link detail is slightly peripheral for a read-only list call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no further explanation, annotations cover the safety profile, and there are no parameters to document. The description still adds the auth precondition and the conditional share-link output, leaving nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is an empty object, so there is nothing to disambiguate; the baseline for parameterless tools is 4. The description adds the useful clarification that the scope is fixed to the connected user's home Kroger rather than being selectable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and its exact contents: the connected person's shopping list as priced at their home Kroger, with product, size, price, sale status and running total. That precision makes it unmistakable against near-neighbours like circle_needs or my_along_the_way, which operate on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies three concrete triggering phrases ('what's on my list', 'how much will groceries be', 'is anything on sale') and a prerequisite ('Needs a connected account'). It does not name an alternative tool or an explicit when-not-to-use condition, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_routes_nowMy routes right nowARead-onlyIdempotentInspect
Each of the connected person's saved routes with its current state (Clear, Minor delay, Expect delays, Consider another route) and what changes how the road drives on its corridor now and ahead: crashes, lane closures, roadwork, weather over the route's counties, and event crowds around the trip time. Power, water and other at-a-place notices are NOT route delays; they belong to the person's spots (see my_brief, near_your_spots), except a large outage along the way, listed in along_the_way_notes because traffic lights may be dark. Use for 'how is my commute', 'should I leave now', 'anything on the way to work'. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the account requirement, the along_the_way_notes exception for large outages affecting traffic lights, and the scope of factors considered. It stops short of describing output shape or freshness/caching, but goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return value and status labels, then scope, exclusions and usage in descending order of importance. Some sentences are dense and clause-heavy (the corridor-factors list, the outage exception), but every sentence carries information rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no further explanation, and the description still supplies the status vocabulary, factor coverage, account requirement and the sibling hand-offs for out-of-scope notices. An agent has everything needed to call and interpret this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so there is no signature to explain and the schema closes out trivially. Baseline for a zero-parameter tool is 4; the description can add nothing further here, and does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns each of the person's saved routes with its current state, and enumerates the four possible status labels. It explicitly distinguishes route delays from at-a-place notices handled by my_brief and near_your_spots, so an agent can tell it apart from siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit trigger phrases ('how is my commute', 'should I leave now', 'anything on the way to work'), routes the out-of-scope power/water questions to my_brief and near_your_spots, and states the 'connected account' prerequisite. When-to-use, when-not-to-use, and alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
my_spots_and_routesMy saved spots and routesARead-onlyIdempotentInspect
The connected person's saved spots (name, kind, part of town, alert radius) and routes (name, from, to, schedule). Use to understand what 'home', 'work' or 'my commute' refer to before answering about them. Addresses are not included. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: it discloses a data limitation ('Addresses are not included') and an authentication precondition ('Needs a connected account'), neither of which the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: what it returns, when to use it, and constraints. The parenthetical field enumerations add useful specificity without bloat. Minor density in the opening sentence but nothing that should be cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and the zero-parameter schema removes any input ambiguity. It covers the auth requirement and a key omission (addresses), which is what an agent most needs to avoid a wrong answer. It does not mention edge cases such as an unconnected account or empty spot/route lists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so per the baseline this dimension sits at 4. The description's parenthetical field lists describe the shape of the returned data rather than parameters, and the output schema already documents returns, so there is no parameter gap to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific resource retrieved — the connected person's saved spots (with enumerated fields) and routes (with enumerated fields) — so the agent knows exactly what this returns. It is distinguishable from most siblings, but it never explicitly contrasts itself with close siblings like my_list, my_along_the_way, or my_routes_now, which occupy adjacent 'my stuff' territory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use context: 'Use to understand what home, work or my commute refer to before answering about them.' It also implies a prerequisite (a connected account). It stops short of naming alternatives or stating when not to use it, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_spotSave a spot at an addressAInspect
Saves a spot (a place that matters to the connected person, where Scout looks out for them) at an address they typed, with a kind: home, work, school, church, gym or other, and an optional name. The address must resolve to one confident, house-level match in their home city; when it does not, nothing is saved and the result lists the top suggestions with their lat and lon. Then ask the person which one they meant and call save_spot again with that suggestion's lat and lon (never coordinates from anywhere else). Ten spots per account; a spot already within a tenth of a mile is reported, not duplicated. Call this only when the person asks to save a place. Needs a connected account.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Only from a suggestion this tool returned, to confirm it. | |
| lon | No | Only from a suggestion this tool returned, to confirm it. | |
| kind | Yes | home, work, school, church, gym or other. | |
| name | No | A nickname. Defaults to the kind (Home, Work, School, Church, Gym); required for other. | |
| address | Yes | The street address or place name they typed. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-read-only, open-world, non-idempotent write; the description adds far more: the single-confident-match requirement, that nothing is saved on failure, the suggestion payload with lat/lon, the ten-spot-per-account cap, and 0.1-mile dedupe reporting instead of duplicating. This is exactly the behavioral context annotations can't carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph, front-loaded with what the tool does and immediately followed by the failure-mode procedure; no filler sentences. It is on the long side for scanning, but essentially every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with a stateful retry loop, the description covers prerequisites, failure behavior, limits, and idempotency-by-dedupe; an output schema already exists so return shape details are correctly omitted. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning the schema's terse hints don't fully convey: it explains the save-then-confirm workflow that makes lat/lon valid only as echoes of a prior suggestion ('never coordinates from anywhere else'). Kind/name semantics largely duplicate the schema, hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Saves a spot ... at an address') and even disambiguates the domain concept ('a place that matters to the connected person, where Scout looks out for them'). The enumerated kinds and the optional name make it immediately distinguishable from siblings like add_errand or my_spots_and_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit gate ('Call this only when the person asks to save a place') and a full recovery procedure for the failure path: when the address doesn't resolve, ask the person which suggestion they meant and call save_spot again with that suggestion's lat/lon. Prerequisite ('Needs a connected account') is also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
8 tool updates
- Changed
city_cameras1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_events1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_incidents1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_near1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_now1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_pictures1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_week1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
get_signal1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): wilmington, madison, milwaukee, los-angeles, charleston, columbus-ga, chattanooga, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
8 tool updates
- Changed
city_cameras1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_events1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_incidents1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_near1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_now1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_pictures1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
city_week1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
- Changed
get_signal1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, jacksonville, sarasota, lakeland, melbourne, miami."
8 tool updates
- Changed
city_cameras1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_events1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_incidents1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_near1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_now1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_pictures1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_week1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
get_signal1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
8 tool updates
- Changed
city_cameras1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_events1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_incidents1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_near1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_now1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_pictures1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
city_week1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
- Changed
get_signal1 field changed- changed
Input schema / properties / city / descriptionPrevious value: -"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."New value: +"City slug. One of: atlanta, nashville, charlotte, dallas, austin, seattle, chicago, san-francisco, raleigh-durham, houston, greensboro, birmingham, pensacola, louisville, san-jose, memphis, knoxville, wilmington, asheville, salt-lake-city, ogden, provo-orem, las-vegas, phoenix, madison, milwaukee, los-angeles, riverside-san-bernardino, san-diego, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, greenville-sc, columbia, myrtle-beach, denver, colorado-springs, savannah, augusta, columbus-ga, macon, portland, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami. Defaults to atlanta. In preview (still being checked, open to sign-ups, trackers not yet public): san-jose, wilmington, las-vegas, madison, milwaukee, los-angeles, riverside-san-bernardino, sacramento, columbus-oh, cincinnati, cleveland, toledo, akron, charleston, columbus-ga, chattanooga, el-paso, new-york, minneapolis, stockton, fresno, bakersfield, oxnard, spokane, orlando, tampa, jacksonville, sarasota, lakeland, daytona, melbourne, miami."
23 tool updates
- First observed
add_errand - First observed
circle_along_the_way - First observed
circle_needs - First observed
cities_report - First observed
city_cameras - First observed
city_events - First observed
city_incidents - First observed
city_near - First observed
city_now - First observed
city_pictures - First observed
city_week - First observed
get_detour - First observed
get_profile - First observed
get_signal - First observed
list_cities - First observed
my_along_the_way - First observed
my_brief - First observed
my_day - First observed
my_detours - First observed
my_list - First observed
my_routes_now - First observed
my_spots_and_routes - First observed
save_spot
Related MCP Connectors
Trip planning and best time to leave, with live road data from 37 US states, traffic, weather.
US & Canada 511 road data: incidents, closures, cameras, truck restrictions. Paid API key.
Live status of the physical world: ski lifts, theme park rides, national parks, campgrounds, surf.
Trips, departures, alerts and vehicles for NYC, DC and the SF Bay Area.
Related MCP Servers
ThinAir Geoofficial
AlicenseAqualityBmaintenanceLocation & routing intelligence for AI agents — geocoding, truck routing, traffic, weather, and place search.1932 npm1MIT- AlicenseAqualityBmaintenanceProvides live California road conditions, route planning, and an AI assistant over MCP, enabling natural-language queries about traffic, closures, chain controls, and more.185MIT
@pipeworx/mcp-trimetofficial
AlicenseNot gradedqualityCmaintenanceProvides live TriMet transit data for Portland, Oregon, including real-time arrivals, nearby stops, vehicle positions, and service alerts for buses, MAX light rail, WES commuter rail, and Portland Streetcar.301 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.