First MCP Server, First ADK Agent: A Guided Tour with a Live Crypto Example

Building an AI agent is often presented as a simple formula: choose a model, give it tools, and let it work. The more useful question is different: how do we give an AI application access to live information without giving it uncontrolled access, unclear responsibilities, or permission to make things up?

This project is a small answer to that question. I built a public, read-only Crypto Market MCP server and a guided agent for the Emz Systems Demo Apps Portal. Together, they retrieve current crypto-market data, compare a small set of supported markets, and explain the result in short factual language.

Open Demo Apps Portal ↗

The deliberate narrowness is the point. A small, well-defined workflow is easier to understand, test, secure, and improve than an unrestricted chatbot.

The first decision was not which model to use. It was what the system should be allowed to do.

Crypto markets make that boundary easy to see. A general-purpose agent could be asked anything: whether to buy an asset, which coin will rise tomorrow, how to transfer funds, or how to execute a trade. Those are not capabilities this demo should provide.

Instead, the experience is guided around a small set of factual questions: current price, seven-day performance, recent movement, order-book summary, and a curated market overview. The user selects a supported cryptocurrency and an approved model, but cannot submit arbitrary instructions.

That reduces ambiguity for the agent, narrows the data it needs, and makes the outcome easier to evaluate. A guided agent is not less capable because it has limits. It is more dependable because its purpose is clear.

Model Context Protocol, or MCP, is a standard for exposing tools, resources, and prompts to AI clients. In practical terms, it lets an application say: “Here are the specific things an AI client is allowed to ask this service to do.”

The Crypto Market MCP server exposes a remote /mcp endpoint using Streamable HTTP. It provides read-only public spot-market data from Binance’s documented REST API, without API keys, account access, or trading capability.

The server also provides MCP resources for its policy and tool guide. These help a compatible client understand the service’s purpose, limitations, and available capabilities.

The important design choice is not the number of tools. It is that each tool has a narrow, understandable responsibility. The agent does not receive a generic web browser or an unrestricted exchange API. It receives a small, validated set of market-data operations.

Software often has the data, but not the explanation.

The Crypto Market Explorer can retrieve live prices, recent movement, and order-book data. The agent’s job is to turn those separate facts into one short, readable answer for the chosen cryptocurrency.

It does not replace the data source or make decisions for the user. It helps bridge the gap between “here are the numbers” and “here is what they mean.”

The agent is built with Google’s Agent Development Kit, but it is intentionally not a general-purpose chat assistant.

A user can select any supported cryptocurrency—BTC, ETH, SOL, BNB, XRP, ADA, DOGE, AVAX, LINK, or TRX—then choose a guided question such as current price, seven-day performance, recent movement, or order-book summary.

The agent receives only the selected market and the tool calls needed for that question. A recent-movement question retrieves a snapshot and 24 hourly candles for the chosen asset; a price or order-book question uses one read-only tool. It has enough information to answer accurately, but no unnecessary capabilities.

That gives the application several useful properties: tool selection is easier to evaluate, live-data calls remain efficient, and provider failures can return an explicit unavailable state rather than a plausible-sounding guess. The live MCP result is the evidence; the model’s role is to explain it, not replace it.

The same MCP tools can be used with different models. In the Demo Apps Portal, the user can choose Gemini 2.5 Flash through Google Vertex AI; GPT-5.6 Luna through Google ADK’s LiteLLM connector; DeepSeek V4 Flash and GLM 5.3 Flash through OpenRouter; or Claude Haiku 4.5 through ADK’s LiteLLM connector and the Anthropic API.

The client cannot select an arbitrary model name or provider. It sends only an allowlisted model ID to the service. This keeps the market data and permitted tool calls consistent while allowing a practical comparison of clarity, speed, and cost for the same bounded task.

For short guided tool use, a lower-cost, faster model can be a sensible default. More capable models may still be useful where reasoning complexity, response quality, or evaluation results justify them. The right choice should be measured against the actual workflow, not assumed from a tier name.

The browser does not call the MCP server directly. The portal authenticates users with Firebase. The agent service verifies the Firebase token, applies a per-account rate limit, and scopes each saved interaction to that user.

Model-provider keys and the MongoDB connection string are stored as server-side secrets. Completed guided interactions are retained for a limited period—currently 30 days—and include token-accounting information, not conversation memory fed back into later model calls.

Saving a record of what happened can support a user-facing history and operational review. It does not mean the agent should silently build long-term memory of prior conversations.

The MCP server and agent service run as separate Python services on Google Cloud Run. They can scale down when not in use, which makes them a practical fit for a low-volume public demo.

The public MCP endpoint is exposed through a Cloudflare Worker proxy at crypto-markets.emz-systems.com/mcp. Cloudflare provides the public TLS endpoint and adds a rate-limit boundary. The Cloud Run origin is protected so that direct traffic cannot bypass the proxy.

The agent service uses Cloud Run, Vertex AI for the Gemini option, server-side secrets, Firebase authentication, and MongoDB for guided-interaction history. GitHub Actions runs checks and deploys changes from the main branch through workload identity federation, avoiding a long-lived Google Cloud key in the repository.

The infrastructure can begin within managed-service free allowances or low variable usage, but “free” is not the design goal. The goal is a small, observable system with clear upgrade points: Cloud Run usage, model API consumption, market-data provider limits, MongoDB storage, rate-limit constraints, and real user demand.

Crypto market data is simply an understandable live-data example. The same design pattern can support more valuable AI automation workflows: retrieving approved information from a CRM, issue tracker, product catalogue, quality dashboard, monitoring platform, or internal API.

The key questions remain the same: what information should the agent access; which actions should remain impossible; what evidence does a human need before acting; and where are credentials, retention, rate limits, and audit boundaries enforced?

This is my first MCP server and first Google ADK agent, but it is not an experiment in handing control to a model. It is an experiment in designing the right constraints around one.