Skip to main content
FrontMCP automatically wires up the Model Context Protocol discovery flows for every prompt or resource you register. Use these APIs to build picker UIs, hydrate autocomplete menus, or audit what your server is advertising.
See Prompts and Resources for authoring guidance. This page focuses on the MCP wire format and runtime behavior.

​
Prompt discovery

Call prompts/list to enumerate every prompt exposed by your server or its plugins: 
{
  "method": "prompts/list",
  "params": {}
}
FrontMCP responds with metadata pulled from your decorators: 
{
  "prompts": [
    {
      "name": "crm-summarize",
      "title": "Summarize CRM activity",
      "description": "Creates a recap of the selected user's timeline.",
      "arguments": [
        { "name": "userId", "description": "CRM user id", "required": true },
        { "name": "timezone", "required": false }
      ],
      "icons": [{ "type": "emoji", "value": "memo" }]
    },
    {
      "name": "plugins:crm-summarize",
      "title": "Summarize CRM activity",
      "description": "Same name from a plugin, namespaced by owner."
    }
  ]
}
When multiple owners register a prompt with the same name, FrontMCP prefixes the owner ID (ownerId:name) so clients can disambiguate the entries. To fetch the actual message content, call prompts/get with the name returned by prompts/list plus any arguments: 
{
  "method": "prompts/get",
  "params": {
    "name": "crm-summarize",
    "arguments": {
      "userId": "user_001",
      "timezone": "America/Los_Angeles"
    }
  }
}
The SDK validates arguments with the prompt’s Zod schema, executes the prompt, and returns a GetPromptResult payload containing messages, optional description, and any inline attachments.

​
Resource discovery

Call resources/list to enumerate every static resource: 
{
  "method": "resources/list",
  "params": {}
}

{
  "resources": [
    {
      "uri": "config://app",
      "name": "app-config",
      "title": "App configuration",
      "description": "Feature flags and limits",
      "mimeType": "application/json"
    },
    {
      "uri": "plugins:config://app",
      "name": "plugins:app-config",
      "title": "Plugin override"
    }
  ]
}
URI templates use a dedicated flow: 
{
  "method": "resources/templates/list",
  "params": {}
}

{
  "resourceTemplates": [
    {
      "uriTemplate": "users://{userId}/profile",
      "name": "user-profile",
      "description": "Fetch a CRM profile by ID",
      "mimeType": "application/json"
    }
  ]
}
Just like prompts, duplicate names are prefixed with the owner ID. After you discover a URI or template, call resources/read (or resources/subscribe) to stream the actual content.

​
Change notifications

FrontMCP lets clients react to live changes:
  • notifications/prompts/list_changed fires whenever prompts are added or removed (adapters, hot reloads, plugin lifecycle).
  • notifications/resources/list_changed fires when static resources or templates change.
  • notifications/resources/updated fires when a subscribed resource changes content.
Call resources/subscribe with a uri to start receiving resources/updated notifications.
Clients can safely cache prompts/list and resources/list results. Listen for the list_changed notifications to know when to refresh your cache.

​
Error handling and best practices

  • FrontMCP throws an InvalidMethodError if you send the wrong method (for example prompts/list payloads to the resource flow).
  • Arguments are validated with the same Zod schemas you declared on your prompts and resources; invalid inputs return structured errors before execution.
  • Duplicate names are automatically namespaced, but it’s still best to keep names globally unique for a smoother UX.
  • Include helpful description, title, and icons metadata. Clients rely on that information to render menus, especially when the user cannot see raw IDs.
By leaning on these discovery flows you can expose thousands of prompts and resources without manually synchronizing metadata between your server and clients.