LABSCO SUMMARY
Your input field descriptions become the tool documentation, which is a strange and useful consequence.
When an app becomes a server, the prompts you wrote for humans filling a form are what an agent reads to decide how to call it. That means vague field labels produce a badly-callable tool, and Dify says so. It also means the whole surface is yours to design rather than the vendor's. The security note is the important one: the URL carries the credential, so it belongs in a config file and not in a shared document.
What it is
Not a server but a publishing feature. Each app you build in Dify can be exposed as an MCP server with its own URL, and the tool surface is that app's own inputs — so there is no vendor tool catalogue by design.
What you get
Whatever your app takes as input, presented as tools. Dify's documentation advises writing clear input descriptions, because those descriptions are what a calling agent reads.
Requirements
A Dify app and its generated URL. The credential is embedded in that URL — Dify warns to treat it like an API key and regenerate it if it leaks.
Setup effort
Add the configuration to your client
USE CASES
01
Making an internal app callable by agents
Publish it as MCP rather than writing a server around it.
02
Making it callable well
Write the input descriptions for the agent that will read them, not just for a human filling a form.
03
Rotating access
The URL is the credential — regenerate it rather than trying to revoke a token.
BEFORE YOU INSTALL
What to know first
Requires
A per-app URL with the credential embedded — the vendor warns to treat the whole URL as an API key and regenerate it if exposed
INSTALLATION
Connect your client
MCP Clients
Cursor
CURSOR · JSON
{
"mcpServers": {
"<YOUR_SERVER_NAME>": {
"url": "<YOUR_SERVER_URL>"
}
}
}