Skip to main content

MCP

Updated May 24, 2026 ·

Overview​

MCP (Model Context Protocol) connects AI tools to external systems like databases, APIs, cloud services, and file systems.

  • AI uses natural language requests
  • MCP translates them into structured tool calls
  • MCP servers execute the actual operations
  • Results are returned in a readable format

Without MCP, users usually need to manually connect to services, run commands in separate tools, and copy results back into the conversation. MCP keeps everything in one workflow, which makes external systems easier to access and manage.

Similar to other AI tools, Claude AI itself cannot directly access external systems on its own. It is limited to the local environment where it runs.

:::

Different servers use different protocols like HTTP for APIs or TCP for databases, but Claude interacts with all of them in the same way.

MCP Ecosystem​

MCP supports a wide range of external system:

  • Databases: SQLite, PostgreSQL, MySQL
  • Services: GitHub, Slack, cloud platforms
  • Utilities: Web search, file system access

While SQL and APIs can be used directly, MCP reduces the friction by keeping everything inside one conversation.

Querying Databases with MCP​

MCP can connect AI tools to databases so queries can be performed using natural language instead of writing SQL manually.

  • SQLite is commonly used for local development
  • SQLite uses a single database file
  • MCP connects the AI tool to the database
  • Natural language replaces manual SQL queries

Example: Music Store Database​

Connecting to the Database​

A music store database can contain tables for artists, albums, tracks, customers, and purchases. Instead of manually exploring the schema and writing queries, questions can be asked directly in plain language.

This project uses the Chinook database, which models a digital music store with artists, albums, tracks, and customer records.

See code here: music-analytics-api-with-db-routed-validated

Sample queries include:

Show albums by a specific artist
Find artists with the most tracks 
List tracks from a specific artist

Claude uses MCP to inspect the schema, generate the correct query, execute it, and return the results in a readable format.

info

Before querying, the MCP server must be connected and verified. After setup, the AI tool can access database operations directly through MCP.

Building API Endpoints​

MCP can also assist in building API endpoints backed by database queries. The AI can generate code for the entire flow:

  • Read database schema through MCP
  • Generate database queries automatically
  • Create API routes and responses

In the example project structure below, Claude can read the chinook.db schema and generate code in db_routes.py to create API endpoints that query the database. For example, an endpoint can return albums for a specific artist.

music-analytics-api-with-db-routed
├── CLAUDE.md
├── analytics.py
├── app.py
├── chinook.db
├── config.py
├── middleware.py
├── models.py
├── routes.py
└── test_routes.py

The prompt could look like this:

Create a new db_routes.py Blueprint that adds an /artists/<artist_id>/albums endpoint.

The endpoint should query chinook.db and return all albums for the specified artist in JSON format.

Also update app.py to register the new Blueprint.

Validation can also be added to improve reliability. Response models help ensure returned data follows the expected structure.

  • Validate response fields
  • Return proper error responses

Back to the sample project, we can add Pydantic validation to ensure the response data is structured correctly and return a 404 error if the artist ID is not found.

Testing Database Endpoints​

Database-backed APIs should be tested across the full stack to verify routes, queries, validation, and responses work together correctly. We can run the following tests:

  • Unit tests to check isolated functions
  • Integration tests to verify the full request flow

Integration tests can send real requests through the application and validate the returned responses. This verifies that routing, database access, and validation all function together correctly.

Prompt:

Write and run an integration test using pytest for the endpoint in @db_routes.py. The test should send requests to the endpoint and verify both successful and error responses based on the data in chinook.db.

Next, we can add unit tests for the same endpoint to verify individual functions work as expected. This provides more granular coverage of the code.

Prompt:

Write a unit test for the same endpoint using pytest. This test should mock the database connection to isolate the endpoint logic.

As additional prompt, we can also ask Claude to explain the difference between unit and integration tests for the database-backed endpoint.

Testing completes the workflow by confirming that generated database features behave correctly in real application scenarios.