A transit rider-alert agent receives ambiguous requests that sometimes need schedule lookup, sometimes disruption status, and sometimes both. How should tool selection be designed?

A transit rider-alert agent faces requests that may need schedule lookup, disruption status, both, or neither depending on wording. Tool selection should therefore be model-driven: Claude inspects the rider's message and prior context and chooses which MCP tools to call rather than following a fixed decision tree or always-on sequence. That design matches agentic architecture principles—tools are capabilities the model invokes when needed, not a rigid municipal script.

Model-driven selection works for ambiguous civic language because riders rarely speak in schema fields. The same sentence may imply a delayed train, a missing trip, or a general timetable question. Letting Claude choose preserves flexibility and reduces unnecessary API calls when only one lookup is required for the rider-alert response.

Hard-coding a fixed three-tool sequence for every message fails because it burns latency and quota on irrelevant calls and can surface conflicting data the rider did not ask for. Disabling tools and answering only from the system prompt fails when live schedules or disruption feeds are the authoritative source; stale prompt text is not an operations feed. Requiring a human dispatcher to choose tools before Claude sees the request defeats the purpose of an agentic transit assistant and recreates a manual bottleneck for every ambiguous phrase.

Exam caveat: model-driven still assumes tools are correctly described, authorized, and observable—freedom to choose is not freedom from governance. Operational check: for sample rider utterances covering schedule-only, disruption-only, and combined intents, verify the agent invokes different tool subsets rather than always running the full trio.