Hi Tip-Sheeters,

I reached a mini-milestone with my Air Travel anchor when I published the Tip Sheet MCP server newsletter #70

I have now developed and shared the major components of the anchor project:

• databases
• API
• CLI
• MCP Server

This is a good point to take a little stock of the project, and how I want to proceed from here. First a quick announcement of an upcoming speaking engagement.

What's the big idea?

When I started the new Anchor Project this year, I wanted to expand on the core techniques I taught in my book Hands-on APIs for API and Data Science to make the components more robust.

For Python and FastAPI, robustness requires asynchronous programming. So I have focused on building the API to fully use async and building the client code to call the APIs using async as well.

Overall, this diagram shows the components that I’ve built or at least drafted to focus on async processing.

The Emerging Theme: the central role of the SDK

I didn't expect that the Software Development Kit (SDK) would become such a focus, but as I built out the different components it kind of pushed its way into the conversation.

I have ended up using it to connect to the core API in three project components:

• MCP server
• CLI
• Jupyter notebooks

By using the SDK (instead of repeating the API-calling code in each component) I get consistency in the API calls, and each component is cleaner and simpler.

The simplicity really stood out on the MCP server and CLI, because both of those use frameworks dedicated to a single task and use Python decorators on basic Python functions to apply the secret sauce.

The FastMCP code for the MCP server and the Typer code in the CLI handle all the complexity and the Python functions use the SDK client to pull data from the API.

My basic takeaway is this: refine the SDK and you can reuse it in multiple places.

Tracking Upcoming Work with GitHub Issues

With the major components roughed out, the upcoming work is a combination of adding new features and testing and validating core components. A little farther out, I have some additional components I would like to add to the project. I have generated a first draft of some of these with LLMs, but they are mostly placeholders at this point.

These make a kind of rough roadmap for future work on the project. I looked at a few methods to keep track of these for future work:

• Trello - I’m a big fan of kanban boards for separating backlog items and limit work in progress. (That part is key for side project work like this because if you get too many items in flight, you can lose track and code dependencies get messy.
• GitHub Projects - Separate from your code repos, you can have a project with a kanban board and various team options.

My Choice: GitHub Issues

I decided to keep it as simple as possible, and I created GitHub issues in the anchor project repo.

Why GitHub Issues?

1. It’s a quick way to jot down ideas I have about what I want to do in the future.
2. It’s natural to create a pull request to complete the task and close out the issue with the PR.
3. I’ll probably test out at some point letting an AI agent take an issue and create a PR to fix it.

Here’s what the current issues list looks like:

I created a few custom tags to keep the type of work separate:

• new components - creating the full new pieces of the project, such as a new ML model
• enhancements - adding features to the existing components
• validation and testing - for comparing the API or MCP server against checklists or validators, and for performance testing

Keep an eye out in the future as I close out those issues and share what I learn with the Tip Sheeters.

​Keep coding,

Ryan Day

👉 https://tips.handsonapibook.com/ -- no spam, just a short email every week or so.