How do I use mobility-operations-agent-platform?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mobility-operations-agent-platform What is the average pickup wait by city?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mobility-operations-agent-platform

by Praharsh-Projects

Overview Schema Related Servers Score Discussions

Python

Mobility Operations Agent Platform

Mobility Operations Agent Platform is a Python service for grounded analysis over synthetic electric-taxi operations data. It combines an LLM tool-calling loop, policy retrieval, structured warehouse tools, workflow guardrails, evaluation gates, MCP exposure, and a local Spark SQL data pipeline.

The repository focuses on engineering boundaries that matter when an AI feature can influence operations: models do not receive arbitrary database access, retrieved policy text is cited, personal-data requests are blocked, tool calls are traced, and workflow writes require explicit human approval.

No DRIVR affiliation, real taxi data, production deployment, or autonomous operational action is claimed.

What the project demonstrates

a multi-step agent loop with function calling and an Ollama adapter tested against qwen2.5:7b-instruct
retrieval-augmented generation using a versioned mobility-policy corpus and BM25 ranking
allowlisted tools for aggregated trip metrics, charging risk, policy retrieval, and draft case creation
input, output, SQL, personal-data, prompt-injection, and side-effect guardrails
FastAPI endpoints and an official MCP Python SDK server over the same service functions
a DuckDB analytical warehouse seeded with deterministic synthetic trips and charging sessions
a local PySpark pipeline that validates trip data and writes silver and gold Parquet datasets
deterministic regression evaluations for tool choice, retrieval, approval boundaries, and refusals
unit, integration, API, MCP, Spark, lint, Docker, and GitHub Actions checks

Related MCP server: uam-analyst

Architecture

flowchart LR
  U[Operations question] --> G[Input guardrails]
  G --> R[BM25 policy retrieval]
  R --> A[Agent loop]
  A --> L[Ollama or deterministic model]
  L --> T{Allowlisted tool call}
  T --> W[DuckDB warehouse]
  T --> P[Policy index]
  T --> C[Human-approved draft case]
  W --> A
  P --> A
  C --> A
  A --> O[Grounded answer and tool trace]
  M[MCP clients] --> T
  F[FastAPI clients] --> A
  S[Spark SQL pipeline] --> D[Silver and gold Parquet]

The agent never executes model-generated SQL. Tool arguments are validated with Pydantic and compiled into fixed, parameterised analytical queries. See docs/architecture.md for the request and data flows.

Quick start

Prerequisites:

Python 3.11 or 3.12
uv
Java 17 for the optional local Spark pipeline
Ollama with qwen2.5:7b-instruct for the live LLM path

Install and seed the deterministic local profile:

uv sync --extra dev --extra spark
uv run mobility-ai seed --rows 10000
uv run mobility-ai profile

Ask through the reproducible deterministic orchestration model:

uv run mobility-ai ask "What is the average pickup wait by city?"

Run the same agent loop with a local LLM:

ollama pull qwen2.5:7b-instruct
uv run mobility-ai ask --provider ollama "Which depot-day has the highest charging failure rate?"

The deterministic provider exists for repeatable tests and CI. It is not presented as an LLM. The live smoke report is produced separately with the Ollama provider.

FastAPI

Start the API:

uv run uvicorn mobility_ai.api:app --host 0.0.0.0 --port 8000

Then inspect the service and ask a question:

curl http://127.0.0.1:8000/health
curl -X POST http://127.0.0.1:8000/v1/chat \
  -H 'content-type: application/json' \
  -d '{"question":"What threshold applies to accessible-trip pickup waits?"}'

API details are documented in docs/api.md.

MCP server

The MCP server uses mcp.server.fastmcp.FastMCP from the official Python SDK and exposes aggregated metric, charging-risk, and policy-retrieval tools:

uv run mobility-ai-mcp

It defaults to stdio so an MCP client controls the transport lifecycle. The MCP tools call the same warehouse and retrieval functions used by the FastAPI agent.

Spark SQL pipeline

Export the seeded warehouse and build local silver/gold Parquet tables:

uv run mobility-ai export-spark-source --destination data/runtime/trips.csv
uv run mobility-ai spark-pipeline \
  --source data/runtime/trips.csv \
  --output data/runtime/lakehouse

The pipeline runs Spark locally, not on Databricks or a production cluster. It validates required fields and non-negative measures, partitions the silver table by city, and writes daily city metrics to the gold layer.

Evaluation and tests

Run the reproducible quality gates:

uv run ruff check .
uv run pytest -m "not spark and not live_llm" \
  --cov=mobility_ai --cov-report=term-missing --cov-fail-under=85
uv run pytest -m spark
uv run mobility-ai eval --cases evals/cases.json --report-dir reports

Run the live local-model smoke scenarios:

uv run python scripts/live_ollama_smoke.py

The deterministic evaluation set covers metric tools, policy retrieval, tool chaining, human approval, prompt injection, personal-data requests, direct side effects, and arbitrary-SQL requests. See docs/evaluation.md and the generated reports under reports/.

Repository layout

src/mobility_ai/
  agent.py           bounded tool-calling loop and RAG context
  api.py             FastAPI surface
  evaluation.py      regression evaluation runner and reports
  guardrails.py      prompt, personal-data, and side-effect policies
  llm.py             deterministic and Ollama providers
  mcp_server.py      official MCP SDK tools
  retrieval.py       BM25 policy index
  spark_pipeline.py  local silver/gold Spark SQL pipeline
  tools.py           schemas, validation, and tool allowlist
  warehouse.py       DuckDB schema, seed data, and analytical queries
data/policies/       versioned synthetic operating policies
evals/               regression cases
tests/               unit and integration tests

Limitations

All trip, charging, policy, and workflow data are synthetic.
The repository has no connection to DRIVR systems and does not model their internal architecture.
Ollama verification is a local model smoke test, not a hosted production LLM deployment.
Spark runs in local mode and writes Parquet; no Databricks workspace or distributed cluster is claimed.
DuckDB is appropriate for this reproducible portfolio scope, not a substitute for a production warehouse governance model.
Draft operations cases are the only write workflow and require explicit human approval.

See docs/limitations.md for the complete evidence boundary.

Available Tools

3 tools

query_charging_riskC

Return depot-day charging failure and state-of-charge metrics.

ParametersJSON Schema

Name	Required	Description	Default
`city`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only states what is returned but does not disclose any behavioral traits such as side effects, data freshness, error conditions, or pagination. With no annotations, the description should provide more behavioral context but fails to do so.

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 a single, concise sentence. It provides the core purpose without verbosity. However, it could include more value without being overly long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, return values are covered externally. But the description lacks information on how to use the optional city parameter and what constitutes 'charging failure' or 'state-of-charge metrics'. The context is incomplete for effective usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The single optional parameter 'city' is not explained in the description. The agent has no indication of what the parameter does or how it affects results. The description completely fails to add meaning beyond the bare schema.

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 'Return depot-day charging failure and state-of-charge metrics' clearly states the tool returns specific metrics (charging failure and SOC) at depot-day level. It distinguishes itself from siblings: query_mobility_metrics (likely general mobility) and retrieve_mobility_policy (policy retrieval).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus its siblings or any prerequisites. The description does not mention any context or exclusion criteria for using the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_mobility_metricsC

Query an allowlisted aggregated metric from the synthetic mobility warehouse.

ParametersJSON Schema

Name	Required	Default
`city`	No
`metric`	Yes
`end_date`	No
`group_by`	No	none
`start_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior, but it only mentions 'allowlisted' without explaining the whitelist or constraints. No mention of data scoping, rate limits, or side effects of parameters like null city or date range.

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 description is a single sentence, which is concise but under-specified for a 5-parameter tool. It lacks structure and front-loads no key details beyond the basic action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no schema coverage or annotations, the description is insufficient. It does not explain allowlisting, date range behavior, grouping, or city filtering, making it incomplete for effective tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds no information about parameters. Despite the schema having enums for metric and group_by, the description fails to explain them, leaving the agent without guidance.

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 states it queries a metric from the mobility warehouse. However, it does not differentiate from sibling tools like query_charging_risk, missing context on what makes this tool unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites, typical use cases, or scenarios where querying mobility metrics is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

retrieve_mobility_policyC

Retrieve policy passages for grounded mobility-operations guidance.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`top_k`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies read-only retrieval but does not state this explicitly, nor does it mention auth requirements, rate limits, or any side effects. The description is too sparse to inform the agent of behavioral traits.

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 description is a single sentence, making it concise. However, it is too terse and omits critical information about parameters and usage, making it under-specified rather than efficiently brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has 2 parameters with no descriptions and sibling tools that differ in purpose, the description is incomplete. It does not explain the output format (though an output schema exists) nor how to effectively use the parameters. The minimal information forces the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both parameters ('query' and 'top_k') and the description adds no explanation of their meaning or usage. For a tool with two parameters, the absence of any parameter semantics severely hampers correct invocation.

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?

Description clearly states the tool retrieves policy passages for grounded mobility-operations guidance. The verb 'Retrieve' and resource 'policy passages' are specific, and the scope distinguishes it from sibling tools (query_charging_risk, query_mobility_metrics) which focus on risk and metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description mentions the domain (mobility-operations guidance) but does not provide exclusions, prerequisites, or comparative context with siblings.

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. Dates show when Glama detected each change.

3 tool updatesv1.0.0Jul 25, 2026
- First observedquery_charging_risk
- First observedquery_mobility_metrics
- First observedretrieve_mobility_policy

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct domain area: charging risk, mobility metrics, and policy retrieval. No overlap or ambiguity exists between their purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: 'query_' or 'retrieve_' followed by a specific noun. No mixing of conventions.

Tool Count5/5

Three tools is appropriate for a focused mobility operations domain. Each tool provides essential, non-redundant functionality without overwhelming the agent.

Completeness4/5

The tool set covers key informational needs (charging risk, metrics, policy) but lacks any action-oriented tools (e.g., update, create). This is acceptable for a query-focused agent, but operations may require more than just retrieval.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2

Related MCP Servers

CorporateTravel Dispatch MCPofficial
Travel & Transportation Weather Services
CorporateTravelDC
A
license
A
quality
F
maintenance
MCP server exposing CS Executive Services dispatch platform and airplanes.live flight tracking as portable, agent-agnostic tools.
Updated 20 days ago (2026-08-17 03:25 UTC)
25
MIT
uam-analyst
urban-ai-institute
F
license
Not graded
quality
A
maintenance
MCP server that exposes the UAM vertiport simulator as tools for AI-assisted analysis, enabling simulations, KPI analysis, and what-if studies via Claude Desktop.
Updated 2 months ago (2026-07-20 13:17 UTC)
-
bizidashboard-mcp
Travel & Transportation Open Data
gcaguilar
A
license
A
quality
B
maintenance
MCP server that exposes BiziDashboard's historical and analytical data for the Zaragoza Bizi bike-share system as tools for LLM clients, enabling queries on rankings, occupancy patterns, mobility signals, alert history, and station rebalancing diagnostics.
Updated 3 days ago (2026-09-03 12:12 UTC)
9
13
GPL 3.0
GridWatch MCP
Energy Observability
mohithchow
A
license
Not graded
quality
C
maintenance
MCP server exposing distributed industrial asset data (battery storage, EV chargers, solar arrays) with tools for asset status, geospatial search, alerts, anomaly explanation, and load simulation.
Updated a month ago (2026-08-10 10:13 UTC)
516
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Praharsh-Projects/mobility-operations-agent-platform'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Mobility Operations Agent Platform

What the project demonstrates

Architecture

Quick start

FastAPI

MCP server

Spark SQL pipeline

Evaluation and tests

Repository layout

Limitations

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CorporateTravel Dispatch MCPofficial

uam-analyst

bizidashboard-mcp

GridWatch MCP

Latest Blog Posts

MCP directory API