Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"mbta-mcp-server": {
"command": "<see-readme>",
"args": []
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
An MCP server that communicates with the MBTA API to provide Boston-area transit information.
No automated test available for this server. Check the GitHub README for setup instructions.
Five weighted categories — click any category to see the underlying evidence.
No known CVEs.
No package registry to scan.
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in maps
Real-time BART departures, trip planning, fares, stations, and advisories.
A Model Context Protocol (MCP) server providing TomTom's location services, search, routing, and traffic data to AI agents.
MCP server for the VesselAPI — maritime vessel tracking, port events, emissions, and navigation data
Global weather API: forecasts, historical data, marine, ski, astronomy and timezone.
MCP Security Weekly
Get CVE alerts and security updates for Mbta Mcp Server and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
An MCP server that communicates with the MBTA API to provide Boston-area transit information.
This Machine Learning Control Protocol (MCP) server integrates with the Massachusetts Bay Transportation Authority (MBTA) API to provide real-time and scheduled transit information for the Boston area. It enables AI assistants to access MBTA data through a standardized interface.
docker pull ghcr.io/crdant/mbta-mcp-server:latest
docker run -e MBTA_API_KEY="your-api-key" ghcr.io/crdant/mbta-mcp-server:latest
go install github.com/username/mbta-mcp-server@latest
Set your MBTA API key in the environment:
export MBTA_API_KEY="your-api-key"
The server implements the MCP stdio protocol for local usage with AI assistants.
For more detailed information, see the specification.
All container images are signed using Sigstore's Cosign with keyless signing. This allows users to verify that the container image was built by our GitHub Actions CI/CD pipeline.
We follow the best practice for container image signing:
We sign only the image digest (content hash) - This is the most secure approach since the digest is a unique, immutable identifier for the specific content. By signing only the digest, we avoid any potential security issues that could arise from mutable tags like latest.
To verify our container images, always verify by digest:
# Get the digest first (using any tag to lookup the image)
DIGEST=$(crane digest ghcr.io/crdant/mbta-mcp-server:1.2.3)
# Verify the image by digest
cosign verify \
--certificate-identity "https://github.com/crdant/mbta-mcp-server/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
ghcr.io/crdant/mbta-mcp-server@$DIGEST
Each build generates a comprehensive Software Bill of Materials (SBOM) that lists all components included in the container image. The SBOM is:
To verify the SBOM attestation:
# Get the digest first (most reliable approach)
DIGEST=$(crane digest ghcr.io/crdant/mbta-mcp-server:1.2.3)
# Verify the SBOM attestation by digest
cosign verify-attestation \
--certificate-identity "https://github.com/crdant/mbta-mcp-server/.github/workflows/build.yml@refs/heads/main" \
--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
--type spdx \
ghcr.io/crdant/mbta-mcp-server@$DIGEST
We use Trivy to scan our container images for vulnerabilities:
These security measures help ensure our software supply chain is secure and transparent from source code to container deployment.