Roo Code: "You Did Not Use a Tool in Your Previous Response"

Roo Code prints "You did not use a tool in your previous response" when the turn it just read has no tool call in it. The mode is built as a loop that continues by calling tools. A message with only text, or with text the parser cannot turn into a tool, stops that loop. Roo Code sends the failure back so the model will try again. If the next turn is also empty, you get the same line again.

The sentence looks like a refusal from the model. It is a check in the tool loop. Two different problems produce it, and they need different fixes. Either the assistant turn was empty of a tool call, or the tool schema was not something the model could call, so it talked instead.

What the message is actually checking

Roo Code's agent modes expect the model to advance the task by invoking a tool: read a file, edit a file, run a command, or call a completion tool when the task is done. After the model responds, the client looks for a tool call in that response.

If it finds one, the tool runs and the result goes back into the conversation. If it does not, the client does not pretend the prose was progress. It tells the model that the previous response did not use a tool. That is the line you see.

So the first question is not "why is the API down." No API was called. The question is why the assistant message had nothing the client could execute.

There are two answers that cover almost every report of this string.

An empty assistant turn

The model replied with an explanation, a plan, or an apology, and no tool. In a chat product that would be a normal answer. In a mode that only moves forward through tools, it is an empty turn. The client rejects it and asks again.

This happens when:

• The user asked a question the model can answer from the conversation, and the model answered it, while the mode still required a tool.
• The model decided the task was finished and said so in prose, instead of calling the completion tool the mode is waiting for.
• The model emitted a tool call in a shape the parser does not accept. A fenced code block that looks like JSON, a tool name in backticks, or XML that does not match the tags Roo Code is reading, all count as "no tool" even though a person can see the intent.
• The response was cut off before the tool call. A short output limit, a stop sequence, or a truncated stream leaves the text and drops the call. The client sees an assistant message and no tool.

The retry then depends on the model noticing the correction. If the underlying reason is "I think I am done" or "I think a paragraph is a tool call," the next turn repeats the prose and the message repeats. You can watch that in the transcript: two assistant messages, neither with a tool, and this error between them.

What to change is the mode or the instruction, not the HTTP stack. If the task is a question, a mode that demands a tool on every turn will keep rejecting answers. If the task is done, the model has to call the completion tool the mode defines, not summarise. If the call is being truncated, raise the output budget or shorten the tool definitions so the call fits. If the format is wrong, the definition the model was given does not match the parser. Align those. A longer user prompt that says "please use a tool" loses to a schema the model is already failing to satisfy.

A schema the model will not call

The other cause is upstream of the empty turn. The model looked at the tools, could not construct a valid call, and wrote text instead. The client then reports the text. The schema error is why the text exists.

Typical mismatches:

• A required parameter the model does not have a value for. Faced with a call it believes will be rejected, some models describe what they would do. The sibling failure, where the model does emit the call and omits the field, is a different message, covered in 'Tried to Use Tool Without Required Parameter'. This page is the case where it never emits the call.
• A tool name that collides with a built-in, or a name the model has been told not to invent. It talks about the tool instead of calling it.
• A parameter object with no properties the model recognises, or a description that contradicts the schema. The model follows the description and produces prose.
• Too many tools, or tools whose descriptions are essays. The model picks none and answers the user. That is still an empty tool turn.
• An MCP tool whose input schema does not match the arguments the server will accept. The model may skip it after one failed attempt, and the following turn is text. The first failure might have been a real tool error. The second is this message.

Read the tool list the session actually loaded, not the one you meant to load. Roo Code merges mode tools, MCP servers, and project configuration. A stale server, a disabled tool, or a schema that changed on the server and not in the client all show up as "the model will not call it."

For an API tool, the schema has to be the real operation. A description you wrote from memory, with a path and a body the provider does not have, produces a model that either calls the wrong thing or gives up and talks. Grounding the tool in the operation you fetched, instead of a guessed endpoint, is the same problem as Why Your AI Agent Calls the Wrong API. Claude's version of picking the wrong tool versus filling the wrong arguments is Claude Tool Use Picks the Wrong Tool.

A Swytchcode method becomes a tool only after you add it. If the method is not in the project, it is not in the list, and the model cannot call it:

swy get <provider>
swy discover "<what the call does>" --project <provider>
swy info <id from discover>
swy add method <id from discover>

swy info works only after swy get. The id comes from swy discover, scoped with --project. Do not type an id from memory. If a required field is missing from the description the model sees, it will either omit it, which is the other article, or avoid the tool, which is this one. Adding the method does not put the API key in the prompt. Credentials are stored with swy auth connect, outside the project. That split is credential brokering.

How to tell the two causes apart

Open the previous assistant message, the one the error is complaining about.

If it is a paragraph, a plan, or "done," with no tool syntax, the turn is empty. Change the mode, the completion tool, or the output limit.

If it contains something that looks like a tool call and the client still said there was none, the parser and the format disagree. Compare the tags or the JSON shape to a call Roo Code has accepted in the same session.

If the message before that was a tool error about parameters, types, or an unknown tool, the model gave up. Fix the schema that produced the first error. Another copy of "please use a tool" will not add the missing field.

If the transcript shows the model calling a tool that is not in the enabled list, it may have described a tool it cannot use, and the client counted that as no tool. Remove the extra instruction that names tools the mode does not have, or enable the tool.

What does not fix it

Restarting the chat without changing the tool list repeats the loop. The correction message is already a retry. A second retry of the same schema fails the same way.

Pasting the API key into the Roo Code prompt does not create a tool call. The error happens before any request. Keys in the prompt are a separate problem, and they do not belong there.

Switching models sometimes clears an empty turn, because one model chats and another emits the tool format. It does not repair a required field that has no source, or a description that contradicts the schema. If a different model calls the tool and the call then fails on a missing parameter, you have moved from this error to the other one. That is progress. Fix the parameter next, using the missing-parameter write-up.

Widening the tool list "so it has something to call" makes the empty turn more likely. Fewer tools, each with a short description and a schema taken from the real operation, is the change that sticks.

FAQ

What does "You did not use a tool in your previous response" mean in Roo Code?

The mode expected a tool call and the previous assistant message did not contain one the client could run. No API request was sent for that turn. The loop is stalled on the response format, not on the provider.

Why does Roo Code keep repeating it?

The correction asks the model to call a tool, and the model produces another message without one. Either it still believes prose is the right answer, or it cannot build a valid call from the schema and falls back to text. The second case will not clear until the schema or the tool list changes.

Is this the same as a missing required parameter?

No. A missing required parameter means a tool call was parsed and then rejected because a field was absent. This message means no tool call was parsed. They sit next to each other: a schema the model will not fill often produces this message, and a schema it fills halfway produces the parameter error.

The model wrote a JSON tool call and Roo Code still complained. Why?

The client did not accept that text as a tool call. The format, the tags, or a truncated response can all look like a call to a person and like plain text to the parser. Compare it with a tool call from a turn that succeeded in the same mode.

Can an MCP server cause this?

Yes, if its schema is missing, huge, or inconsistent with the arguments the server accepts. The model skips the tool and answers in text. The following turn triggers this message. Check the schema the session loaded, then the required fields. For a catalog API, add the specific method and let the model call that, instead of describing the HTTP request in the prompt.

Should I put the API instructions in the system prompt so it uses a tool?

A short line that names the completion tool is useful when the model is ending the task in prose. A long description of an API is not a tool. If the tool is not in the enabled list, with a schema, the model cannot call it, and more prompt text is another empty turn.