20250309 - MCP for Mercury Bank
I wanted to get my feet wet(ter) with building MCPs and decided to make one for Mercury, my business bank. Mercury has a simple API to get the info you’d expect…at least I expect it from a modern bank.
The point of an MCP is that it’s a standard way to expose tools to AIs. Pretty cool - we’ll see if it actually becomes a standard.
You can wrap MCPs around APIs to make something a chatbot, or other AI tool, can interact with. Just follow the steps to create an MCP server, fire up Cursor or other AI coding tool, and feed your AI partner prompts.
Tip: Write the initial code and first tool yourself and then ask your AI to use it as a reference to write subsequent tools. LLMs don’t yet know enough about MCPs to write working code from scratch.
If you use Mercury and want to use this MCP, you can grab it here.
Examples Using Claude Desktop as the MCP Client
After installing my MCP in Claude (which basically meant editing a config file), it can see and use the tools.
Under the hood, Claude has an agent that takes in the user request, thinks about how to solve it and either answers directly or uses an available tool to help.
The result is not just nifty, it’s an example of the major shift that’s happening to put conversational interfaces on data sources.
(Written by Cursor Journal)
Cursor Journal Summary:
During this period, I worked extensively on developing a Model Context Protocol project (MCP) to interact with the Mercury API.
The focus was on developing and troubleshooting the MCP server for the Mercury API. Key activities included:
1. **Server Setup and Configuration**: I was working on creating a read-only MCP server to interact with the Mercury banking API, ensuring that it adhered to provided documentation. The server was intended to expose functionalities for Accounts, Recipients, and Statements.
2. **API Documentation and Response Handling**: I queried various Mercury API endpoints, such as the recipients and transactions, and implemented their schemas correctly in the MCP tools. There was significant back-and-forth about integrating details from the API documentation, leading to multiple updates in the expected response structures.
3. **Error Debugging and Troubleshooting**: I encountered several issues, such as attribute errors in the MCP server setup. Frustration was felt during debugging sessions due to unmet expectations in functioning code.
4. **Enhancing Tools and Features**: Added MCP tools for credit, treasury data, and transactions retrieval. The objective was to ensure comprehensive coverage of the Mercury API functions.
5. **String Conversions and Environment Variables**: Navigated early problems with Claude 3.7 Sonnet writing buggy code around using the MCP SDK and managing response data structures.
6. **Logging and Documentation Verification**: Throughout development, I aimed to implement proper logging strategies and maintain consistency with documentation references provided for the Mercury API.
7. **Final Review and Adjustments**: After several iterations, I finalized the necessary tools while continually assessing the accuracy and completeness of the function implementations against the API documentation.
Frustration was evident when the code regularly failed to meet expected outputs, leading to repeated adjustments and corrections.
nice!!! good summary of your process and learnings