4.0 - Function Calling Support and Context Rework ("Agent" Mode)

[jellydn]

We’ve reworked contexts into functions. Each function can have a schema and a URI, and can be provided to the LLM as a tool using the new @<function> notation. You can also group functions and provide them all at once with @<function_group>. Functions with a URI can be referenced directly in prompts using the #<function> notation (as before). The LLM can now return resources in its responses, which are automatically added as sticky prompts via the ##<uri> notation.

In summary:

• Every function can act as a tool for the LLM.
• Functions with a unique identifier (URI) can be referenced as resources, either by full URI or the simplified #<name>:[input] syntax.
• The workflow is explicit and transparent: you always know what is being shared and can control it.

Philosophy: Transparency and Control

A key goal of this redesign is to maximize transparency and user control. All tool and resource sharing is explicit - nothing is sent or shared in the background without your knowledge. You always see what is being provided to the LLM and can choose what to include or remove at every step. This approach may be more manual, but it ensures you remain in control of your data and workflow.

Workflow Example

Suppose you open chat in the CopilotChat.nvim directory and want an overview. You give the LLM access to the @copilot tool group (the built-in tools) and ask about the directory structure:

The LLM selects the appropriate tool, fills in its arguments, and asks you to confirm the call. The tool call is added to the prompt; you can remove it if you don't want to send it.

After confirmation, the response is a URI (because the glob function has a URI), which can be referenced as a sticky prompt. This means you can keep it for the rest of the conversation or remove it to save tokens. The reference is always up to date, as it is re-resolved each time.

You can continue asking about other things, like the README. The same process applies: tool call, confirmation, response, and sticky resource.

At any point, you can use gc to see all active tools, selections, resource contents, system prompt, etc.

mcphub.nvim Integration

Read the integration post by @ravitemer here.

The plugin interface is now closer to MCP, making integration with projects like mcphub.nvim seamless (with some deviations for simplicity and security). Thanks to mcphub.nvim, integrating MCP servers is easy (e.g., GitHub MCP server):

Other Notable Changes

• Resource processing is now disabled by default. Previously, some files were skipped if deemed irrelevant, which was confusing. With tool calling, RAG-like functionality is less necessary, so this feature may be removed in the future.
• Default completion mapping changed: Now <C-Space> instead of <Tab>, to avoid conflicts with copilot.vim. You can change it back if you prefer.
• copilot.vim (and copilot.lua) are no longer hard dependencies. The plugin now supports device authorization for Copilot tokens, so you no longer need to generate tokens via copilot.vim.
• Many other small changes, performance improvements, and bugfixes - see the full release notes for details.