大模型算法面经:Function Call、MCP、A2A (English)

Generated: 2026-06-21 20:02:25

---

The Blood and Tears of LLM Interviewing: Function Call, MCP, A2A – I Almost Died Under the Interviewer's Next Question!

Believe it or not? One casual follow-up question from an interviewer can bring your entire answer—no matter how brilliantly you started—crashing down to zero.

Last year, I was interviewing at a big tech company. The conversation was going great, until the interviewer narrowed his eyes and asked:

"If the JSON Schema of a Function Call is poorly designed, what exactly goes wrong?"

My brain went bzzzzt. Anyone can recite the textbook answer—"It causes the model to fail parsing..."

But then he immediately followed up: "How does it fail specifically? Have you ever encountered it?"

I. Froze. Solid.

At that moment, I wanted to crawl into a hole. Here I was, with Agent experience on my resume, and I hadn't even personally stepped into the most basic pitfalls.

So I made a vow: Dig into Function Calling, MCP, and A2A from theory to practice. Build my own projects. Step on every landmine myself. Then go back to the interviewer with an answer that says, "I don't just know it—I've done it."

Today, I'm laying out all those hard-earned lessons for you. No fluff. Just pure, hardcore engineering wisdom plus real crash-and-burn stories.

---

Level 1: How Do You Actually Train Function Call? What the Interviewer Really Wants to Hear Is: You Made the Data Yourself!

On this question, nine out of ten candidates only get the first half right.

The textbook answer: Supervised fine-tuning (SFT). First teach the model intent recognition (should it call a tool or not?), then teach it parameter extraction (spit out a JSON-formatted argument).

Okay, the interviewer hears that and immediately knows you just memorized the eight-legged essay.

What he really wants to hear is: Can you say, "I made the data myself, and I stepped in the mud"?

I did. And the biggest pitfall? You won't believe it: inconsistent data formatting.

Back when I was fine-tuning Llama 3.1 8B, my dataset looked like this:

User: Check the weather in Beijing tomorrow
Available functions: [{"name": "get_weather", "description": "Query weather for a given city", "parameters": {"type": "object", "properties": {"city": {"type": "string"}, "date": {"type": "string", "format": "YYYY-MM-DD"}}, "required": ["city"]}}]
Expected output: {"function": "get_weather", "arguments": {"city": "Beijing", "date": "2024-01-15"}}

Looks perfect, right? But the model's output was a mess—function names switching between camelCase and snakecase, arguments in random order. It even wrote name as functionname.

I spent a week tracking it down, and finally found the culprit: the JSON key order in the training data was inconsistent! Some samples had function first, others had name first. The model learned "anything goes" and produced every variation imaginable.

The fix: I standardized every sample using the same template with fixed key order. I copied OpenAI's tools field spec—name always first, description second, parameters third. Every single line obeyed the order. The model finally learned to "follow the rules."

Another pitfall: negative sample ratio. At first I only prepared samples that required a function call, with negative samples at just 10%. The model ended up wanting to call a function for everything—even a simple "hello." It was a tool maniac! I bumped the negative samples up to 30–40%, and the effect was immediate.

My advice: In the interview, just drop three keywords—SFT, data format standardization, negative sample ratio—and the interviewer's eyes will light up. Because those are the details that only someone who's actually done it would mention.

If you want to get your hands dirty, go straight for LoRA fine-tuning. Fewer parameters, faster iteration. Back in the day, I ran QLoRA on a single A100 for three hours, and the model was good to go. Felt amazing.

---

Level 2: What Is MCP, Anyway? And It's NOT a Replacement for Function Call!

This question exploded in popularity this year. After Anthropic pushed MCP, every job description at big tech companies now says "MCP experience preferred."

Let me give you the conclusion first, so you can memorize it: MCP is not a replacement for Function Call—it's a layer of abstraction above it.

Think about it. Function Call is one-to-one: the model calls one tool, done.

MCP is many-to-many: the model discovers a bunch of tools, connects to a bunch of tools, calls a bunch of tools—and those tools might come from different vendors.

Here's a quick diagram:

• Function Call: Model → Tool A
• MCP: Model → MCP Client → MCP Server → Tool A / Tool B / Tool C

The core of MCP is standardization. It defines a protocol that lets any model call any tool through the same interface. It's like a USB port—whether you plug in a mouse or a keyboard, the connector looks the same.

Speaking of which, let me tell you about my first MCP crash-and-burn.

I initially thought MCP was just like Function Call—pass a JSON, done. But it uses a client-server architecture! You need to start an MCP Server process and communicate via SSE or WebSocket.

During local testing, the MCP Server silently died. The client didn't report an error; the model kept outputting tool-call JSONs, but the tools never executed. I spent three hours debugging, only to find out the OS had killed the server process.

Lesson learned: With MCP, you must add heartbeat detection and reconnection logic. In my current project, I'm using mcp-python-sdk 0.3.0, and I modified the Transport layer to add auto-reconnect. Finally, peace of mind.

Common interviewer follow-ups, with ready-to-use answers:

• "How do you choose between MCP and Function Calling?"

If you only have 1–2 tools, Function Call is simpler and lighter. If you have more than 10 tools, or tools developed by different teams, go with MCP. Don't over-engineer just to show off.

• "What communication methods does MCP support?"

Two main ones: SSE (server-sent events) for push notifications, and WebSocket for bidirectional communication. SSE is good for tool state change notifications; WebSocket works for interactive scenarios. Just remember those two.

---

Level 3: What Is the A2A Protocol, and How Does It Relate to MCP?

This question is this year's "new favorite." After Google pushed A2A (Agent-to-Agent), interviewers have been drilling candidates on it.

Let's get this straight: MCP is a protocol between models and tools; A2A is a protocol between agents and agents.

Think of it this way:

• MCP: How an agent uses a hammer, a wrench, a power drill (tools).
• A2A: How an agent chats, collaborates, and passes messages to the agent next door.

The core of A2A is interoperability. Say you have a customer service agent, and I have an order management agent. Your agent wants to look up order info from mine. It doesn't need to know how my agent is implemented—it just sends a message via the A2A protocol.

I actually tested this: I ran Google's A2A example with a "translation agent" and a "summarization agent" working together. The translation agent turned an English document into Chinese, then called the summarization agent to generate a summary. Sounded cool, right?

But in practice, it was a mess!

1. Latency doubled: Every agent call required context transfer, pushing total latency 40% higher than a single agent. Slower than a snail.
2. Context loss: A