Skip to main content

MCP Workshop Answers for DevFest Taipei 2025

• 4 min read
MCP DevFest Taipei

1. Which MCP servers have you found most useful in your own development workflow? Have you used your own MCP servers with function calling for this as well?

I use one fairly regularly: the Chrome DevTools MCP server. I’ve bolted it onto Claude Code so that in my development workflow I can run a11y audits, performance checks, and have Claude Code automatically address the findings.

2. How does the LLM know which functions to call, for what purpose, and in what order? Do you need a gemini.md file to provide additional context for MCP?

The LLM learns this from three things:

  1. Tool definitions:

    • Name
    • Description (very important)
    • Input schema (fields and types)

  2. The system prompt / “instructions”:

    • “You are an assistant that can manage watches via tools A, B, C…”
    • “Use tools when you need fresh data; don’t guess IDs; call X before Y,” etc.

  3. The user’s prompt itself. Take “Add this new watch and then value it”. The model infers a sequence like create_watch followed by estimate_valuation. Given good tool definitions, it’ll call and pass the right arguments to these functions.

Order isn’t hard-coded; the model plans the sequence based on natural language plus the tool descriptions. For more complex workflows, you’d typically bolt on orchestration on the host side (an agent graph or a small planner) rather than expecting the model to discover perfect orderings on its own.

gemini.md isn’t required by MCP. It’s just a convention for giving extra instructions to Gemini. It can help a lot (think of it as a README with usage guidelines for tools), but MCP itself only requires the JSON tool metadata. If you rely on Gemini heavily, a docs file with examples often improves tool selection, but it’s optional.

3. How do you manage token usage when working with an MCP server? Do you have a strategy for controlling cost?

This is tricky. You can still limit what the LLM responds with by specifying things like “be concise” in the system prompt, or capping the number of tokens in the response. For more complex systems, it gets harder: there could be multiple tool calls to achieve a specific task, and limiting them may yield unexpected results.

4-5) If a system already has OpenAPI-defined backend APIs, should they be directly converted into MCP tools one-to-one, or should we design a separate set of APIs specifically for MCP tools?

You usually don’t want a 1:1 mapping from OpenAPI to MCP tools. Think in terms of “capabilities” and “tasks”, not endpoints.

  • Bad: 30 CRUD endpoints mapped 1:1.
  • Better: a handful of tools like create_invoice, list_overdue_invoices, get_customer_overview, which internally orchestrate multiple HTTP calls.

Or group related operations:

  • Instead of getById, getByEmail, getByExternalId, consider one get_customer tool with a discriminated input or a clear primary key.

6. Where do you recommend MCP servers live? Embedded inside the same package/container as the backend OR separate package + separate Docker container?

Both are valid; it depends on your constraints.

Embedded with the backend (same process/container) works well when:

  • Tools are purely internal to that service.
  • You control deployment and scaling tightly.
  • You want minimal network hops.

Separate server/container is usually better when:

  • You want to reuse the same MCP integration from multiple hosts (IDE, chatbot, internal tool, etc.).
  • You want language freedom (backend in Go, MCP server in Node/Python, etc.).
  • You view MCP servers as “AI-ready microservices” that evolve independently.

7. What is the relationship between the host, client, and server in MCP?

A server exposes resources, prompts, and tools. It says: whoever connects to me, I can offer you tools A, B, and C.

The client talks to the MCP server and can grab (via listTools()) all the tools the server exposes (along with resources and prompts).

Here's an example data flow: User - Host (chat UI / IDE - this is also your client) - LLM - LLM decides it needs to call a tool - MCP Server(s) - tool response goes back to LLM → Client shows resposne to User.

8. What if our tool involves larger binary files; how would MCP handle this?

MCP is JSON-based, so pushing huge binaries directly through the protocol isn’t ideal. You’ll hit limitations even if you base64-encode a file (I wouldn’t recommend it). For large files, store them and reference them via a URL. Gemini can actually do uploads and also cache large files.