Why a 9B Local Model Sends Email Perfectly on the First Try

Every model card claims strong function calling. Almost none of them show what “strong” actually means when a real MCP tool with nine parameters is on the other end of the call. In part one of this series we wired a Gmail MCP server into Ypipe. Here, we ran the simplest possible test against it, one plain-language request, one tool, one email, on a 9B parameter model, and it worked correctly on the first attempt with no retries and no hallucinated success message. That result is the baseline the rest of this series measures every smaller model against.

Table of Contents

• What “Reliable Tool Calling” Actually Means
• The Test Setup
• The 9B Result, Step by Step
• Why Model Size Alone Isn’t the Full Story
• What This Means for Choosing a Model for Agentic Tasks
• How This Compares Across the Model Sizes We Tested
• What’s Next in This Series
• FAQ
• Related Articles

What “Reliable Tool Calling” Actually Means

A model calling a tool at all is the easy part. Most instruction-tuned models above a billion parameters can recognize when a request maps to an available function. The hard part is everything after that: picking the one correct tool out of a list of similar ones, filling in every required parameter with the right name and the right type, and not calling the same tool again after it already succeeded.

For this test, reliable meant three specific things had to happen in a single turn:

1. The model called send_email, not a neighboring tool like list_emails_metadata or get_emails_content
2. Every required parameter, account_name, recipients, subject, body, was present and correctly formatted
3. The model did not call the tool a second time, and did not claim success before the tool result confirmed it

The Test Setup

The prompt, the MCP server, and the account were held constant across every model size tested in this series, so the only variable was the model itself.

That last row matters more than it sounds. Later in this series, a smaller model produced a complete, plausible “email sent successfully” message with the correct recipient and subject shown, and no email had actually been sent. The only reason that surfaced was the habit of checking the real inbox every time, not trusting the model’s report of its own actions.

The 9B Result, Step by Step

Running the exact prompt above against a 9B parameter model (a Qwen 3.5 9B instruction-tuned build) with the default, unmodified tool descriptions produced this sequence:

1. Reasoning: parses account name, recipient, subject, and body from the request
2. Tool call: send_email
   account_name: "ypipe-test"
   recipients: ["kashish2882005@gmail.com"]
   subject: "Ypipe live test"
   body: "This is a real test sent from inside Ypipe's chat interface."
3. Tool result: "Email sent successfully to kashish2882005@gmail.com"
4. Model response: confirms delivery, states recipient and subject back to the user

No retry. No malformed argument. No second call to the same tool. The email arrived in the target inbox within seconds, matching the subject and body exactly as specified. This ran with the tool descriptions exactly as shipped by mcp-email-server, no simplification, no extra system prompt engineering, no explicit parameter hints in the user message. That’s the detail worth sitting with: everything the smaller models in this series eventually needed help with, shortened tool descriptions, directive system prompts, explicit parameter naming, the 9B model simply didn’t need.

Why Model Size Alone Isn’t the Full Story

Parameter count correlates with tool calling reliability, but it isn’t the whole explanation. The specific 9B build used here was a fine-tune built for instruction following and reduced refusal behavior, not the base checkpoint. Fine-tuning choices, the training data mix, and whether a model was specifically post-trained on function calling formats all move the needle independently of raw size.

This is why a blanket claim like “use a 9B model or larger” is weaker advice than it looks. A 9B model with poor function-calling post-training could plausibly perform worse than a 4B model that was specifically tuned for structured tool use. Size is a reasonable proxy when comparing checkpoints from the same model family and training pipeline, which is what this series does, but it stops being a reliable predictor across unrelated model families.

What This Means for Choosing a Model for Agentic Tasks

For anyone deciding what to run locally for an email-sending agent, or any single-tool agentic task with a moderate parameter count like send_email‘s nine fields, the practical takeaway from this test is narrower than “bigger is better.” It’s this: if the task is genuinely simple, one clear tool, few required parameters, plain language input, a model in the 8 to 9 billion parameter range with a real function-calling fine-tune should handle it out of the box, without extra prompt engineering.

Anything below that threshold is where the real engineering work starts, and that work is the subject of the next parts in this series.

How This Compares Across the Model Sizes We Tested

A preview of what the rest of this series covers in full detail, using the identical prompt and server for every row.

What’s Next in This Series

The 9B result sets the ceiling. The next parts document what it actually took, and what didn’t work at all, to close the gap for every model size below it.

FAQ

What size model is needed for reliable AI tool calling? In this test, a 9B parameter model with a function-calling-focused fine-tune handled a single-tool, plain-language email request correctly with no additional prompt engineering. Models below roughly 4B parameters needed active intervention to succeed at all.

Does a bigger model always mean better tool calling? No. Fine-tuning quality and whether a model was specifically trained on structured function-calling formats matter as much as raw parameter count, especially when comparing across different model families.

What does it mean for a tool call to be reliable? Three things together: calling the correct tool rather than a similar one, filling in every required parameter correctly, and not calling the same tool again or claiming success before the tool result confirms it.

Why check the actual inbox instead of trusting the chat’s success message? Because a model can produce a fully plausible success message without the underlying tool call having executed correctly, a failure mode observed directly in this testing series with a smaller model.

What model was used for the 9B test specifically? A Qwen 3.5 9B instruction-tuned build, run locally through Ypipe with the default, unmodified tool descriptions from the mcp-email-server MCP server.

Did the 9B model need a custom system prompt to succeed? No. It succeeded using the default configuration, no simplified tool descriptions, no directive system prompt, and no explicit parameter naming in the user’s message.

How many parameters does the send_email tool actually require? Four required parameters, account_name, recipients, subject, and body, plus five optional ones covering cc, bcc, HTML formatting, attachments, and reply threading.

Is this result reproducible with the same prompt every time? Across repeated runs at 9B, yes, consistently. Smaller models in this series showed run-to-run variation on the identical prompt, which is a separate reliability problem covered later in the series.

What happens if a smaller model gets the tool call wrong? Typically either a parameter mismatch that some agent frameworks can catch and ask the model to retry, or in more severe cases, calling the wrong tool entirely or looping between tools without resolving the task.

Why does this matter for local AI deployments specifically? Because local deployments often favor smaller models for speed and hardware cost. Knowing exactly where the reliability floor sits lets you choose the smallest model that still gets the job done, rather than guessing.

Can this same test be applied to tools other than email? Yes. The methodology, a fixed prompt, a single target tool, and inbox-style ground-truth verification, generalizes to any single-tool agentic task with a comparable number of required parameters.