MCP server metadata
Standard discovery and execution
Hosts discover what your server offers through the usual MCP operations:
| Operation | Role |
|---|---|
tools/list | Tool names, titles, and input schemas; optional tool-level _meta (for example a pointer to a UI resource URI). |
resources/list | Resource URIs and metadata for readable assets (static files, HTML shells for widgets, templates). |
resources/read | Returns contents for a URI (e.g. HTML text) plus per-content _meta the host may use when embedding (template reference, domain allowlists, CSP-style rules for what the iframe may load or connect to). |
prompts/list | Optional; many tools + widget servers omit prompts entirely. |
Execution still flows through tools/call (and any other methods your server implements). Keep descriptions and schemas accurate so models and upstream mappings stay reliable.
MCP App (widget) servers vs tools-only servers
- Tools-only — Implements
tools/list/tools/call(and may still expose resources or prompts if useful). - MCP App with embedded UI — Same JSON-RPC surface, but typically also implements
resources/listandresources/readso the host can fetch HTML (or similar) for an iframe, whiletools/list(and oftentools/callresults) carry_metathat ties a tool to that resource URI.
Widget-oriented _meta, resources/read contents, and CSP / domain expectations are covered in MCP App (widgets) metadata.
Stability and upstream mapping
- Tool names and resource URIs — Treat as API; renames and removals break upstream connector mappings and host caches. See Versioning & compatibility.
- Meaningful
_metakeys — Hosts may depend on stable shapes; evolve carefully or version your app.
serverInfo and capabilities
Expose sensible server name, version, and capabilities per the MCP SDK you use. Version strings help debug mismatches between deployed servers and Agentsyx Creator configuration.
Tool descriptions and parameters
- Prefer clear parameter schemas (types, required fields, enums).
- Document side effects (writes, external API calls, cost) in the description so operators can price and gate tools correctly upstream.
Reference layout (example)
The Chat Vault reference uses two deployables: an MCP App server that exposes the widget (tools/list, resources/read, etc.) and a separate MCP tools URL for data operations—both are ordinary MCP servers; the split is a common way to separate host UI from downstream tool traffic.