Using the application as an MCP server
The application can consume an MCP server or expose its own server to an external client.
What you will learn
- Explain: host, client and server
- Apply the idea in an example: Using the application as an MCP server
- Recognize limitations and verify the exercise outcome
The application can consume an MCP server or expose its own server to an external client. These are opposite directions.
These steps refer to features identified in the application code. This material has not been validated on a live instance; check the documentation and the options in your version.
How it works, step by step
Host, client and server
MCP is a protocol connecting AI applications to external capabilities. The host provides the experience, the client manages the connection, and the server exposes tools, resources or prompts according to support. Tools execute operations; resources provide addressable content; prompts provide templates. Not every server implements all three. Transport carries messages, authentication identifies callers, and authorization controls access. Check protocol revision and supported extensions at both ends. Compatibility cannot be inferred from an “MCP” label alone.
Check access before use
Permissions must be enforced by servers and the data layer. Do not let the model decide whether a user may see a document. Filter sources before they enter context, not after generating the answer. Use minimal-access credentials, keep them out of prompts, screenshots and browser code, and rotate exposed keys. A widget domain allowlist does not replace API authentication. Authentication identifies you; authorization determines the operations and data you can use. Test denied access too.
The model proposes, the tool executes
Tool calling produces a call request with a name and arguments. The application validates the schema, permissions and limits before execution. The result returns to context for the next step. For example, get_product_stock takes a SKU and returns a quantity; its description should explain that it does not reserve products. Distinguish empty results, validation errors, missing access and timeouts. Valid JSON does not prove the arguments are correct or the action is authorized. For external effects, also consider duplicate execution.
The visual map
Follow the solid arrows for the main flow. Dashed blue arrows supply data or context; dashed pink arrows show feedback or returning results. Colors and shapes distinguish models, stores, decisions and outputs. On smaller screens, scroll horizontally to follow the entire diagram.
A complete example
Local /api/mcp is protected by a deployment-configured key. Tools expose agent, RAG, workflow, widget and MCP-server administration; some create or delete data.
Try it yourself
- Configure a test client with the administrator-provided secret and inspect tools before calls.
- Record the input, source and expected outcome before running the experiment. Use only the fictional data in the example.
- Follow the diagram stages. At every step record what information is received and produced; do not confuse intermediate output with the final outcome.
- Repeat after removing necessary information or making the input ambiguous. Check whether the system clarifies, stops or invents an answer.
- Compare with the explained solution. Keep the configuration, date, result and an explanation for differences. Change one thing and retest.
An explained solution
Start with discovery and reads; check organization/project arguments and do not assume an ordinary user key. A successful exercise lets you show the connection between input, stages and outcome. When information is missing, a cautious answer is more useful than invented details. Compare more than style: check conditions, sources and operations too.
When it helps and what can go wrong
The local server advertises tools; do not assume resources, prompts or complete OAuth. Choose this approach when it improves a measured need. Keep a simple baseline and compare outcomes using identical inputs. One successful example does not establish reliability in every situation.
Check your understanding
Does a server with tools automatically offer resources and prompts?
No. Capabilities are optional and must be discovered and checked.
Why is removing a private source after answering too late?
The data has already entered model context and can be disclosed.
What outcome should this exercise produce?
Start with discovery and reads; check organization/project arguments and do not assume an ordinary user key.
Words to remember
- MCP server: A service exposing capabilities through Model Context Protocol.
- Autorizare / Authorization: Checking the right to access an operation or resource.
- Tool calling: A structured request to use an external capability.
Sources and your next step
To prepare: M04 — Building a minimal MCP server