MCP (Model Context Protocol)

Before such a standard, every application that wanted to give a model access to a calendar, a database or a code repository had to write its own connector. MCP splits the work in two. A server wraps one capability, such as a file system or a ticket tracker, and describes what it offers. A client inside the AI application discovers that description and passes it to the model, which can then call the capabilities. Servers can offer tools that perform actions, resources that supply data to read, and prompts that package ready-made instructions. Typical servers connect a calendar, a note-taking app, a bug tracker, a spreadsheet, a database, a mail inbox, a code repository or a web browser, each exposed in the same predictable way. Resources can be files, table rows, screenshots or logs; prompts can be templates such as a code-review checklist or a meeting summary. Think of a drawer of incompatible chargers replaced by one universal socket.

Servers run either on your own machine, talking to the application through standard input and output, or remotely over HTTP. This is a different layer from tool calling. Tool calling is how a model asks for a function in a request; MCP is how the application finds and reaches many such functions in the first place. The application usually translates the MCP tools it discovered into ordinary tool definitions for the model, so the two work together, and the model never connects to a server directly. Remote servers also raise the question of authentication, so find out how a server proves who is calling it and where your credentials end up. A local helper suits the first option, a shared team service the second.

The convenience brings risks that deserve attention. A server can read and change whatever you give it access to, and a malicious or careless one can leak data or run harmful actions. Descriptions and results coming from a server are text that a model will read, so they can hide instructions meant to steer it. Install servers from sources you trust, grant the narrowest permissions, review what each tool does, and prefer approval prompts for anything that writes, sends or deletes. A useful habit is to read the list of tools a server announces before enabling it, the way you would read the permissions of a phone app. The best-known trap is prompt injection, where a poisoned result tells the model to leak a file.

To be precise about what exists today: In Missions, NeverNo can connect to a remote MCP server that you add yourself (its address and an optional token), while the API does not host or connect to MCP servers itself. What it offers is function calling on chat completions, where your own code defines the tools and runs them, plus an Anthropic-compatible Messages endpoint. The models whose capabilities.tools is true in the /models list accept tools.

A tool you run yourself that speaks MCP can still use NeverNo as its model by pointing its base URL at https://neverno.ai/api/v1, since the endpoints follow the OpenAI and Anthropic formats. The MCP connections then live in that tool, not at NeverNo. DeepSeek V4 Flash, a free private model with a context window of 128,000 tokens, is one of the models on the list.