Using MCP Tools to Let an AI Agent Plan a Portland Walking Route

When AI Agents Learn to Take a Walk in the Real World

You give the AI a single prompt, and what it hands back is no longer text or an image, but a real afternoon walking route that exists on the streets of Portland. Every stop on this route is a real place, every walking time is calculated, and even the order of the stops wasn't arranged by a human.

This is exactly the kind of change that MCP (Model Context Protocol) tools are bringing about. A developer connected Claude Code to GeoAppify's MCP service and, with just one prompt, generated a complete Portland walking plan. The whole process involved only a handful of tool calls and consumed about 13 credits, yet it wove together the spatial logic connecting four real locations.

One Prompt, Seven Tool Calls

The core of this experiment isn't complicated: connect GeoAppify's MCP server in Claude Code, then have the AI agent search for four types of real locations. The agent made a total of seven tool calls. GeoAppify handled finding locations and walking times, while the model itself decided the visiting order of those locations.

This division of labor is worth noting. Geographic locations and travel times are hard data, handled by dedicated MCP tools; itinerary arrangement, location pairing, and ordering are soft decisions, left to the language model. The boundary between the two is clear, and each does what it does best.

The end result is a genuinely walkable route. No need for a human to mark each spot on a map one by one, and no need to manually estimate how long it takes to walk between two locations. One prompt became a walking plan in real space.

MCP (Model Context Protocol) is a protocol open-sourced by Anthropic at the end of 2024, which can be roughly understood as "a USB-C interface between AI models and external tools." It defines a standard client-server communication specification that lets any model supporting MCP call external capabilities such as file systems, databases, and APIs in a unified way. Before MCP emerged, developers often had to write plugins or function-calling adaptation layers separately for each model, and interfaces between models were mutually incompatible. MCP abstracts actions like tool discovery (tools/list) and tool invocation (tools/call) into protocol primitives. The model side only needs to implement a client once, and the tool side only needs to implement a server once, after which the two can be freely combined. GeoAppify in this case is exactly such an MCP server—it packages "location search" and "walking time calculation" into standard tools exposed to Claude, and the model completed seven calls based on that.

Portland's Strange Parks

There's a very interesting stop on this route: Mill Ends Park. Data the agent retrieved on its own shows that this place was once called "the world's smallest park."

But the story isn't over. The third stop on the route is also a park, and it's only two feet wide. An afternoon walking route packed in two parks famous for being "small," and placed one after another—this combination is clearly not random, but a choice the model made after understanding the characteristics of the locations.

This shows that once an AI agent has structured access to geographic data, it can filter and connect locations based on their semantic attributes, rather than simply arranging them by distance. The "former world's smallest park" label of Mill Ends and the "two feet wide" feature of the third stop create a thematic echo with each other.

What GeoAppify MCP Is Doing

GeoAppify plays the role of the geographic data layer in this workflow. It exposes location search and walking time calculation capabilities to the AI agent, allowing the model to query real-world location information at any point during its reasoning.

From a technical architecture perspective, the value of the MCP protocol is very clear here: it standardizes the capabilities of external tools, allowing models like Claude to call geographic services through a unified interface. Developers don't need to adapt separately for each model, nor do they need to write a large amount of glue code between map APIs and language models.

The cost structure of seven calls and about 13 credits also shows that the resource consumption of this kind of task is controllable. For developers who want to build travel planning agents, this is a reference solution that can actually be implemented.

The "about 13 credits" mentioned in the article refers to the billing unit for MCP tool calls. Most third-party MCP services (such as GeoAppify) charge by number of calls or amount of returned data, and credits are their billing tokens. A location search or a walking time query usually consumes one or several credits each, so seven calls costing about 13 credits is a typical scale. This usage-based billing model means that the operating cost of agentic applications is directly tied to the number of tool calls they actually make, and developers can control expenses by optimizing prompts and reducing unnecessary calls. Compared with billing by token for calling the large model itself, credits on the tool side usually have a lower unit price, but for planning tasks that require repeated geographic data queries, they still cannot be ignored—this is also one of the factors that must be considered when evaluating whether an AI agent solution can scale.

Implications for AI Travel Agents

The pattern demonstrated by this Portland walking experiment can extend to broader travel planning scenarios. The key is not the merits of any specific tool, but that the MCP protocol makes the paradigm of "model orchestration + specialized tool execution" feasible.

Tasks like location search, route calculation, and time estimation are handed to dedicated MCP tools, while the model focuses on understanding user preferences, combining locations, and generating narratives. This division of labor is far more reliable than having the model directly handle everything.

Another noteworthy point is the model's autonomy in sequencing. It did not arrange stops according to the simplest "nearest first" strategy, but instead organized them thematically based on location characteristics. This means that when an AI agent has sufficient tool support, its planning ability can go beyond mechanical optimization and show an arrangement approach somewhat close to that of a human tour guide.

For developers exploring the boundaries of AI agent applications, this two-foot-wide park route in Portland may illustrate the point better than any technical document: when a model can access real-world data and tools, it can do far more than generate text.

"Model orchestration + specialized tool execution" is a mainstream paradigm in current AI agent design, also known as the orchestrator–worker pattern. The core idea is that the language model does not directly "hard-calculate" factual questions (for example, how many minutes it takes to walk between two points, or which street a certain park is on). Instead, it is responsible for understanding intent, breaking down tasks, deciding which tool to call, and then combining and narrating the returned results. Factual, verifiable calculations are left to deterministic tools, while ambiguous decisions requiring trade-offs are left to the model. The advantage of this division is high reliability—tools do not "hallucinate," while the model focuses on semantic understanding and planning, which it is truly good at. Travel planning is an ideal scenario for this paradigm: geographic data requires precision, while itinerary arrangement requires human-centered judgment, and the two are naturally suited to being split across different execution layers.

One-line Summary

A single prompt, through MCP tool calls, lets an AI agent autonomously plan a real walking route in Portland.

Paragraph Summary

The article documents an experiment in which a developer connected Claude Code to GeoAppify's MCP service and generated a complete Portland walking route with just one prompt. The agent made seven tool calls in total; GeoAppify handled location search and walking time calculation, while the model autonomously decided the order of stops and thematic arrangement, at a total cost of about 13 credits. One highlight of the experiment is that the route simultaneously includes Mill Ends Park (once called the world's smallest park) and a park only two feet wide, demonstrating that the model makes thematic combinations based on the semantic attributes of locations rather than simply sorting by distance. Based on this, the article points out that the MCP protocol makes the division-of-labor paradigm of "model orchestration + specialized tool execution" feasible and lowers the barrier to building travel planning agents.