Tool Call Tag may have a extranous [ #7579

Open
opened 2025-11-12 14:11:21 -06:00 by GiteaMirror · 1 comment
Owner

Originally created by @m4xw on GitHub (Jul 18, 2025).

Originally assigned to: @jmorganca on GitHub.

What is the issue?

Hi,
so using Devstral, tool calls (tested quite a few template variations) may get generated like [TOOL_CALLS]file_search[ARGS]{"query":"/{.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,.clinerules,.cursor/rules/,.windsurf/rules/,.clinerules/,README.md}"}

This causes the parser Tag für TOOL_CALLS to equal "[TOOL_CALLS][" in tools.go, its unclear to me where the extra [ is coming from, maybe from ARGS?

Either way, this trivial fix works

Image

And now Github copilot can correctly use the tools:

Image

Not sure if I should PR that or if theres a underlying issue going on.

Relevant log output


OS

No response

GPU

No response

CPU

No response

Ollama version

master branch 191d94289d

Originally created by @m4xw on GitHub (Jul 18, 2025). Originally assigned to: @jmorganca on GitHub. ### What is the issue? Hi, so using Devstral, tool calls (tested quite a few template variations) may get generated like `[TOOL_CALLS]file_search[ARGS]{"query":"/{.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,.clinerules,.cursor/rules/,.windsurf/rules/,.clinerules/,README.md}"}` This causes the parser Tag für TOOL_CALLS to equal "[TOOL_CALLS][" in tools.go, its unclear to me where the extra [ is coming from, maybe from ARGS? Either way, this trivial fix works <img width="490" height="343" alt="Image" src="https://github.com/user-attachments/assets/0a19828e-5101-4626-a0ba-311ac4e8c6a4" /> And now Github copilot can correctly use the tools: <img width="661" height="169" alt="Image" src="https://github.com/user-attachments/assets/4e9b9179-cb85-462a-a580-cdf0141077db" /> Not sure if I should PR that or if theres a underlying issue going on. ### Relevant log output ```shell ``` ### OS _No response_ ### GPU _No response_ ### CPU _No response_ ### Ollama version master branch 191d94289d016b59c0553b14d299d1bac07a7fcd
GiteaMirror added the toolsbug labels 2025-11-12 14:11:21 -06:00
Author
Owner

@m4xw commented on GitHub (Jul 21, 2025):

Ive been digging a bit more, the only place where the extra [ exists is in the default template for the model:

{{- else if .ToolCalls }}[TOOL_CALLS][
{{- range .ToolCalls }}{"name": "{{ .Function.Name }}", "arguments": {{ json .Function.Arguments }}}
{{- end }}]</s>

But it completely ignores that part in practice (i.e. changing this part causes no change to the model, maybe that part is only relevant to get the parser Tag?) and keeps emitting tool_calls like this:

[TOOL_CALLS]file_search[ARGS]{"query":"/{.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,.clinerules,.cursor/rules/,.windsurf/rules/,.clinerules/,README.md}"}

So i am not sure whats wrong. Either its not honoring the explicit template in modelfile or the model is doing some other weird stuff.
Maybe the template mistralai supplied doesnt match the format the model was trained on?

Edit: Looks like the template deteciton indeed shows a different template than any of the documented ones

source=model.go:82 msg="template detection" error="no matching template found" template="{%- set default_system_message = 'You are Devstral, a helpful agentic model trained by Mistral AI. If provided with tools, you will be able to interact with a computer to solve tasks.\\n\\n<ROLE>\\nYour primary role is to assist users by executing commands, modifying code, and solving technical problems effectively. You should be thorough, methodical, and prioritize quality over speed.\\n* If the user asks a question, like \\\"why is X happening\\\", don\\'t try to fix the problem. Just give an answer to the question.\\n</ROLE>\\n\\n<EFFICIENCY>\\n* Each action you take is somewhat expensive. Wherever possible, combine multiple actions into a single action, e.g. combine multiple bash commands into one, using sed and grep to edit/view multiple files at once.\\n* When exploring the codebase, use efficient tools like find, grep, and git commands with appropriate filters to minimize unnecessary operations.\\n</EFFICIENCY>\\n\\n<FILE_SYSTEM_GUIDELINES>\\n* When a user provides a file path, do NOT assume it\\'s relative to the current working directory. First explore the file system to locate the file before working on it.\\n* If asked to edit a file, edit the file directly, rather than creating a new file with a different filename.\\n* For global search-and-replace operations, consider using `sed` instead of opening file editors multiple times.\\n</FILE_SYSTEM_GUIDELINES>\\n\\n<CODE_QUALITY>\\n* Write clean, efficient code with minimal comments. Avoid redundancy in comments: Do not repeat information that can be easily inferred from the code itself.\\n* When implementing solutions, focus on making the minimal changes needed to solve the problem.\\n* Before implementing any changes, first thoroughly understand the codebase through exploration.\\n* If you are adding a lot of code to a function or file, consider splitting the function or file into smaller pieces when appropriate.\\n</CODE_QUALITY>\\n\\n<VERSION_CONTROL>\\n* Exercise caution with git operations. Do NOT make potentially dangerous changes (e.g., pushing to main, deleting repositories) unless explicitly asked to do so.\\n* When committing changes, use `git status` to see all modified files, and stage all files necessary for the commit. Use `git commit -a` whenever possible.\\n* Do NOT commit files that typically shouldn\\'t go into version control (e.g., node_modules/, .env files, build directories, cache files, large binaries) unless explicitly instructed by the user.\\n* If unsure about committing certain files, check for the presence of .gitignore files or ask the user for clarification.\\n</VERSION_CONTROL>\\n\\n<PULL_REQUESTS>\\n* When creating pull requests, create only ONE per session/issue unless explicitly instructed otherwise.\\n* When working with an existing PR, update it with new commits rather than creating additional PRs for the same issue.\\n* When updating a PR, preserve the original PR title and purpose, updating description only when necessary.\\n</PULL_REQUESTS>\\n\\n<PROBLEM_SOLVING_WORKFLOW>\\n1. EXPLORATION: Thoroughly explore relevant files and understand the context before proposing solutions\\n2. ANALYSIS: Consider multiple approaches and select the most promising one\\n3. TESTING:\\n   * For bug fixes: Create tests to verify issues before implementing fixes\\n   * For new features: Consider test-driven development when appropriate\\n   * If the repository lacks testing infrastructure and implementing tests would require extensive setup, consult with the user before investing time in building testing infrastructure\\n   * If the environment is not set up to run tests, consult with the user first before investing time to install all dependencies\\n4. IMPLEMENTATION: Make focused, minimal changes to address the problem\\n5. VERIFICATION: If the environment is set up to run tests, test your implementation thoroughly, including edge cases. If the environment is not set up to run tests, consult with the user first before investing time to run tests.\\n</PROBLEM_SOLVING_WORKFLOW>\\n\\n<SECURITY>\\n* Only use GITHUB_TOKEN and other credentials in ways the user has explicitly requested and would expect.\\n* Use APIs to work with GitHub or other platforms, unless the user asks otherwise or your task requires browsing.\\n</SECURITY>\\n\\n<ENVIRONMENT_SETUP>\\n* When user asks you to run an application, don\\'t stop if the application is not installed. Instead, please install the application and run the command again.\\n* If you encounter missing dependencies:\\n  1. First, look around in the repository for existing dependency files (requirements.txt, pyproject.toml, package.json, Gemfile, etc.)\\n  2. If dependency files exist, use them to install all dependencies at once (e.g., `pip install -r requirements.txt`, `npm install`, etc.)\\n  3. Only install individual packages directly if no dependency files are found or if only specific packages are needed\\n* Similarly, if you encounter missing dependencies for essential tools requested by the user, install them when possible.\\n</ENVIRONMENT_SETUP>\\n\\n<TROUBLESHOOTING>\\n* If you\\'ve made repeated attempts to solve a problem but tests still fail or the user reports it\\'s still broken:\\n  1. Step back and reflect on 5-7 different possible sources of the problem\\n  2. Assess the likelihood of each possible cause\\n  3. Methodically address the most likely causes, starting with the highest probability\\n  4. Document your reasoning process\\n* When you run into any major issue while executing a plan from the user, please don\\'t try to directly work around it. Instead, propose a new plan and confirm with the user before proceeding.\\n</TROUBLESHOOTING>' %}\n{{- bos_token }}\n{%- if messages[0]['role'] == 'system' %}\n    {%- if messages[0]['content'] is string %}\n        {%- set system_message = messages[0]['content'] %}\n    {%- else %}\n        {%- set system_message = messages[0]['content'][0]['text'] %}\n    {%- endif %}\n    {%- set loop_messages = messages[1:] %}\n{%- else %}\n    {%- set system_message = default_system_message %}\n    {%- set loop_messages = messages %}\n{%- endif %}\n{%- if tools %}\n    {%- set system_message = system_message + '\\n\\n<TOOL_CALL_FORMAT>\\nWhen calling tools, use the following format: [TOOL_CALLS]function_name[ARGS]{\"arg1\": \"value1\", \"arg2\": \"value2\"}[TOOL_CALLS]function_name2[ARGS]{\"arg1\": \"value1\"}...\\nFor example: [TOOL_CALLS]bash[ARGS]{\"command\": \"ls -la\"}[TOOL_CALLS]str_replace_editor[ARGS]{\"command\": \"view\", \"path\": \"file.py\"}\\n</TOOL_CALL_FORMAT>' %}\n{%- endif %}\n{{- '[SYSTEM_PROMPT]' + system_message + '[/SYSTEM_PROMPT]' }}\n{%- if tools %}\n    {{- '[AVAILABLE_TOOLS]' }}\n    {%- for tool in tools %}\n        {{- tool | tojson }}\n    {%- endfor %}\n    {{- '[/AVAILABLE_TOOLS]' }}\n{%- endif %}\n{%- for message in loop_messages %}\n    {%- if message['role'] == 'user' %}\n        {%- if message['content'] is string %}\n            {{- '[INST]' + message['content'] + '[/INST]' }}\n        {%- else %}\n            {{- '[INST]' }}\n        {%- for block in message['content'] %}\n            {%- if block['type'] == 'text' %}\n                {{- block['text'] }}\n            {%- else %}\n                {{- raise_exception('Only text is supported in message content!') }}\n            {%- endif %}\n        {%- endfor %}\n        {{- '[/INST]' }}\n        {%- endif %}\n    {%- elif message['role'] == 'system' %}\n        {%- if message['content'] is string %}\n            {{- '[SYSTEM_PROMPT]' + message['content'] + '[/SYSTEM_PROMPT]' }}\n        {%- else %}\n            {{- '[SYSTEM_PROMPT]' + message['content'][0]['text'] + '[/SYSTEM_PROMPT]' }}\n    {%- endif %}\n    {%- elif message['role'] == 'assistant' %}\n        {%- if message.get('tool_calls') %}\n            {%- if message['content'] is string and message['content'] %}\n                {{- message['content'] }}\n            {%- elif message['content'] and message['content'][0]['text'] %}\n                {{- message['content'][0]['text'] }}\n            {%- endif %}\n            {%- for tool_call in message['tool_calls'] %}\n                {{- '[TOOL_CALLS]' + tool_call['function']['name'] + '[ARGS]' + (tool_call['function']['arguments'] | tojson) }}\n            {%- endfor %}\n            {{- eos_token }}\n        {%- else %}\n            {%- if message['content'] is string %}\n                {{- message['content'] + eos_token }}\n            {%- else %}\n                {{- message['content'][0]['text'] + eos_token }}\n            {%- endif %}\n        {%- endif %}\n    {%- elif message['role'] == 'tool' %}\n        {{- '[TOOL_RESULTS]' + message['content'] + '[/TOOL_RESULTS]' }}\n    {%- else %}\n        {{- raise_exception('Only user, system, assistant and tool roles are supported!') }}\n    {%- endif %}\n{%- endfor %}"
@m4xw commented on GitHub (Jul 21, 2025): Ive been digging a bit more, the only place where the extra [ exists is in the default template for the model: ``` {{- else if .ToolCalls }}[TOOL_CALLS][ {{- range .ToolCalls }}{"name": "{{ .Function.Name }}", "arguments": {{ json .Function.Arguments }}} {{- end }}]</s> ``` But it **completely ignores that part** in practice (i.e. changing this part causes no change to the model, maybe that part is only relevant to get the parser Tag?) and keeps emitting tool_calls like this: `[TOOL_CALLS]file_search[ARGS]{"query":"/{.github/copilot-instructions.md,AGENT.md,AGENTS.md,CLAUDE.md,.cursorrules,.windsurfrules,.clinerules,.cursor/rules/,.windsurf/rules/,.clinerules/,README.md}"}` So i am not sure whats wrong. Either its not honoring the explicit template in modelfile or the model is doing some other weird stuff. Maybe the template mistralai supplied doesnt match the format the model was trained on? Edit: Looks like the template deteciton indeed shows a different template than any of the documented ones ``` source=model.go:82 msg="template detection" error="no matching template found" template="{%- set default_system_message = 'You are Devstral, a helpful agentic model trained by Mistral AI. If provided with tools, you will be able to interact with a computer to solve tasks.\\n\\n<ROLE>\\nYour primary role is to assist users by executing commands, modifying code, and solving technical problems effectively. You should be thorough, methodical, and prioritize quality over speed.\\n* If the user asks a question, like \\\"why is X happening\\\", don\\'t try to fix the problem. Just give an answer to the question.\\n</ROLE>\\n\\n<EFFICIENCY>\\n* Each action you take is somewhat expensive. Wherever possible, combine multiple actions into a single action, e.g. combine multiple bash commands into one, using sed and grep to edit/view multiple files at once.\\n* When exploring the codebase, use efficient tools like find, grep, and git commands with appropriate filters to minimize unnecessary operations.\\n</EFFICIENCY>\\n\\n<FILE_SYSTEM_GUIDELINES>\\n* When a user provides a file path, do NOT assume it\\'s relative to the current working directory. First explore the file system to locate the file before working on it.\\n* If asked to edit a file, edit the file directly, rather than creating a new file with a different filename.\\n* For global search-and-replace operations, consider using `sed` instead of opening file editors multiple times.\\n</FILE_SYSTEM_GUIDELINES>\\n\\n<CODE_QUALITY>\\n* Write clean, efficient code with minimal comments. Avoid redundancy in comments: Do not repeat information that can be easily inferred from the code itself.\\n* When implementing solutions, focus on making the minimal changes needed to solve the problem.\\n* Before implementing any changes, first thoroughly understand the codebase through exploration.\\n* If you are adding a lot of code to a function or file, consider splitting the function or file into smaller pieces when appropriate.\\n</CODE_QUALITY>\\n\\n<VERSION_CONTROL>\\n* Exercise caution with git operations. Do NOT make potentially dangerous changes (e.g., pushing to main, deleting repositories) unless explicitly asked to do so.\\n* When committing changes, use `git status` to see all modified files, and stage all files necessary for the commit. Use `git commit -a` whenever possible.\\n* Do NOT commit files that typically shouldn\\'t go into version control (e.g., node_modules/, .env files, build directories, cache files, large binaries) unless explicitly instructed by the user.\\n* If unsure about committing certain files, check for the presence of .gitignore files or ask the user for clarification.\\n</VERSION_CONTROL>\\n\\n<PULL_REQUESTS>\\n* When creating pull requests, create only ONE per session/issue unless explicitly instructed otherwise.\\n* When working with an existing PR, update it with new commits rather than creating additional PRs for the same issue.\\n* When updating a PR, preserve the original PR title and purpose, updating description only when necessary.\\n</PULL_REQUESTS>\\n\\n<PROBLEM_SOLVING_WORKFLOW>\\n1. EXPLORATION: Thoroughly explore relevant files and understand the context before proposing solutions\\n2. ANALYSIS: Consider multiple approaches and select the most promising one\\n3. TESTING:\\n * For bug fixes: Create tests to verify issues before implementing fixes\\n * For new features: Consider test-driven development when appropriate\\n * If the repository lacks testing infrastructure and implementing tests would require extensive setup, consult with the user before investing time in building testing infrastructure\\n * If the environment is not set up to run tests, consult with the user first before investing time to install all dependencies\\n4. IMPLEMENTATION: Make focused, minimal changes to address the problem\\n5. VERIFICATION: If the environment is set up to run tests, test your implementation thoroughly, including edge cases. If the environment is not set up to run tests, consult with the user first before investing time to run tests.\\n</PROBLEM_SOLVING_WORKFLOW>\\n\\n<SECURITY>\\n* Only use GITHUB_TOKEN and other credentials in ways the user has explicitly requested and would expect.\\n* Use APIs to work with GitHub or other platforms, unless the user asks otherwise or your task requires browsing.\\n</SECURITY>\\n\\n<ENVIRONMENT_SETUP>\\n* When user asks you to run an application, don\\'t stop if the application is not installed. Instead, please install the application and run the command again.\\n* If you encounter missing dependencies:\\n 1. First, look around in the repository for existing dependency files (requirements.txt, pyproject.toml, package.json, Gemfile, etc.)\\n 2. If dependency files exist, use them to install all dependencies at once (e.g., `pip install -r requirements.txt`, `npm install`, etc.)\\n 3. Only install individual packages directly if no dependency files are found or if only specific packages are needed\\n* Similarly, if you encounter missing dependencies for essential tools requested by the user, install them when possible.\\n</ENVIRONMENT_SETUP>\\n\\n<TROUBLESHOOTING>\\n* If you\\'ve made repeated attempts to solve a problem but tests still fail or the user reports it\\'s still broken:\\n 1. Step back and reflect on 5-7 different possible sources of the problem\\n 2. Assess the likelihood of each possible cause\\n 3. Methodically address the most likely causes, starting with the highest probability\\n 4. Document your reasoning process\\n* When you run into any major issue while executing a plan from the user, please don\\'t try to directly work around it. Instead, propose a new plan and confirm with the user before proceeding.\\n</TROUBLESHOOTING>' %}\n{{- bos_token }}\n{%- if messages[0]['role'] == 'system' %}\n {%- if messages[0]['content'] is string %}\n {%- set system_message = messages[0]['content'] %}\n {%- else %}\n {%- set system_message = messages[0]['content'][0]['text'] %}\n {%- endif %}\n {%- set loop_messages = messages[1:] %}\n{%- else %}\n {%- set system_message = default_system_message %}\n {%- set loop_messages = messages %}\n{%- endif %}\n{%- if tools %}\n {%- set system_message = system_message + '\\n\\n<TOOL_CALL_FORMAT>\\nWhen calling tools, use the following format: [TOOL_CALLS]function_name[ARGS]{\"arg1\": \"value1\", \"arg2\": \"value2\"}[TOOL_CALLS]function_name2[ARGS]{\"arg1\": \"value1\"}...\\nFor example: [TOOL_CALLS]bash[ARGS]{\"command\": \"ls -la\"}[TOOL_CALLS]str_replace_editor[ARGS]{\"command\": \"view\", \"path\": \"file.py\"}\\n</TOOL_CALL_FORMAT>' %}\n{%- endif %}\n{{- '[SYSTEM_PROMPT]' + system_message + '[/SYSTEM_PROMPT]' }}\n{%- if tools %}\n {{- '[AVAILABLE_TOOLS]' }}\n {%- for tool in tools %}\n {{- tool | tojson }}\n {%- endfor %}\n {{- '[/AVAILABLE_TOOLS]' }}\n{%- endif %}\n{%- for message in loop_messages %}\n {%- if message['role'] == 'user' %}\n {%- if message['content'] is string %}\n {{- '[INST]' + message['content'] + '[/INST]' }}\n {%- else %}\n {{- '[INST]' }}\n {%- for block in message['content'] %}\n {%- if block['type'] == 'text' %}\n {{- block['text'] }}\n {%- else %}\n {{- raise_exception('Only text is supported in message content!') }}\n {%- endif %}\n {%- endfor %}\n {{- '[/INST]' }}\n {%- endif %}\n {%- elif message['role'] == 'system' %}\n {%- if message['content'] is string %}\n {{- '[SYSTEM_PROMPT]' + message['content'] + '[/SYSTEM_PROMPT]' }}\n {%- else %}\n {{- '[SYSTEM_PROMPT]' + message['content'][0]['text'] + '[/SYSTEM_PROMPT]' }}\n {%- endif %}\n {%- elif message['role'] == 'assistant' %}\n {%- if message.get('tool_calls') %}\n {%- if message['content'] is string and message['content'] %}\n {{- message['content'] }}\n {%- elif message['content'] and message['content'][0]['text'] %}\n {{- message['content'][0]['text'] }}\n {%- endif %}\n {%- for tool_call in message['tool_calls'] %}\n {{- '[TOOL_CALLS]' + tool_call['function']['name'] + '[ARGS]' + (tool_call['function']['arguments'] | tojson) }}\n {%- endfor %}\n {{- eos_token }}\n {%- else %}\n {%- if message['content'] is string %}\n {{- message['content'] + eos_token }}\n {%- else %}\n {{- message['content'][0]['text'] + eos_token }}\n {%- endif %}\n {%- endif %}\n {%- elif message['role'] == 'tool' %}\n {{- '[TOOL_RESULTS]' + message['content'] + '[/TOOL_RESULTS]' }}\n {%- else %}\n {{- raise_exception('Only user, system, assistant and tool roles are supported!') }}\n {%- endif %}\n{%- endfor %}" ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama-ollama#7579