Summary
The Persona type already has a defaultMcpServerIds?: string[] field, but sendPersonaTurn in the multi-persona extension doesn't apply it. Currently all personas in a panel share the same enabledMcpServerIds from the conversation request.
Expected behaviour
When a persona has defaultMcpServerIds set, those server IDs should be merged with the conversation's enabled MCP servers for that persona's turn. Other personas in the same panel are unaffected.
Proposed change
In sendPersonaTurn (multi-persona index.tsx), when building personaRequest:
const personaRequest: ChatRequest = {
...request,
messageId,
providerId: persona.defaultProviderId ?? request.providerId,
model: persona.defaultModel ?? request.model,
parameters: { ...request.parameters, ...(persona.parameters ?? {}) },
systemPrompt,
enabledMcpServerIds: [
...new Set([...request.enabledMcpServerIds, ...(persona.defaultMcpServerIds ?? [])]),
],
};
Use case
A "SCF Expert" persona can have a Salesforce-specific MCP server (e.g. one that queries Salesforce schema or documentation) auto-enabled, while a "Team Expert" persona has a different set of tools, all within the same multi-persona conversation.
Summary
The
Personatype already has adefaultMcpServerIds?: string[]field, butsendPersonaTurnin the multi-persona extension doesn't apply it. Currently all personas in a panel share the sameenabledMcpServerIdsfrom the conversation request.Expected behaviour
When a persona has
defaultMcpServerIdsset, those server IDs should be merged with the conversation's enabled MCP servers for that persona's turn. Other personas in the same panel are unaffected.Proposed change
In
sendPersonaTurn(multi-personaindex.tsx), when buildingpersonaRequest:Use case
A "SCF Expert" persona can have a Salesforce-specific MCP server (e.g. one that queries Salesforce schema or documentation) auto-enabled, while a "Team Expert" persona has a different set of tools, all within the same multi-persona conversation.