Generates and deploys agent metadata to a Salesforce organization.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-creator-mcp Create a new agent to handle customer inquiries"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The agent-creator MCP server is designed to facilitate the creation and deployment of Agentforce. It interacts with users to gather requirements and generates agent metadata, which can then be deployed to a Salesforce organization.
When using the agent-creator-mcp server in Claude, you can:
Create an Agent: The server will guide you through a series of questions to understand your needs, such as:
"What business problem are you trying to solve with this AI agent?"
"What would make this AI agent successful for you?"
"What is the name of the company you work for?"
"What would you like to name this agent?"
Generate and Deploy Agent Metadata: After gathering the necessary information, the server generates the agent metadata and deploys it to your Salesforce organization.
Related MCP server: AI Agent Generator
To deploy an agent, you need to configure the server with your Salesforce credentials. There are two transport methods available: STDIO and SSE.
STDIO runs on your local machine and is managed automatically by the MCP client. Use the following configuration template in your MCP configuration file, replacing placeholders with your actual credentials:
"ai-assist": {
"command": "uv",
"args": [
"--directory",
"<github_repo_path>//agent-creator-mcp.",
"run",
"ai-assist"
],
"env": {
"SALESFORCE_USERNAME": "your_username",
"SALESFORCE_PASSWORD": "your_password"
}
}Server-Sent Events (SSE) transport can run locally or remotely and communicates over the network. This method is useful for viewing logs and sharing the server across machines.
Run the server with SSE transport:
SALESFORCE_USERNAME=your_username SALESFORCE_PASSWORD=your_password uv run ai-assist --transport sseAlternatively, you can load environment variables from a .env file and then run:
uv run agent-creator-mcp --transport sseYou can specify a custom port (default is 8000):
uv run agent-creator-mcp --transport sse --port 8080Add the following to your MCP configuration file:
"agent-creator-mcp": {
"url": "http://0.0.0.0:8000/sse"
}Make sure the port in the URL matches the port you specified when starting the server.
To set up the ai-assist MCP server in Claude Desktop, you need to add it to Claude's configuration file:
On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
You can access this file by:
Open the Claude menu on your computer and select "Settings..."
Click on "Developer" in the left-hand bar
Click on "Edit Config"
You can use either STDIO or SSE transport when configuring the server:
Using STDIO Transport (Runs Locally):
{
"mcpServers": {
"ai-assist": {
"command": "uv",
"args": [
"--directory",
"<github_repo_path>/agent-creator-mcp",
"run",
"agent-creator-mcp"
],
"env": {
"SALESFORCE_USERNAME": "your_username",
"SALESFORCE_PASSWORD": "your_password"
}
}
}
}Using SSE Transport (Can Run Locally or Remotely):
Start the server with SSE transport:
SALESFORCE_USERNAME=your_username SALESFORCE_PASSWORD=your_password uv run ai-assist --transport sseAdd this to your Claude Desktop configuration:
{
"mcpServers": {
"ai-assist": {
"url": "http://0.0.0.0:8000/sse"
}
}
}After updating the configuration, restart Claude Desktop completely.
For more detailed instructions on setting up MCP servers in Claude Desktop, refer to the official MCP documentation.
In Cursor the MCP server is experiencing some issues using STDIO, so it's recommended to use the SSE transport method instead. For detailed instructions on setting up MCP in Cursor, refer to the Cursor MCP documentation.
Run the server first using the SSE transport method as described in the section above.
Add the MCP configuration to Cursor's configuration file:
"mcp-test": {
"url": "http://0.0.0.0:8000/sse"
}Make sure to use the correct port in the URL that matches your server configuration.
For debugging, use the MCP Inspector to visualize and troubleshoot the server's operations. Launch it with:
npx @modelcontextprotocol/inspector uv --directory <github_repo_path>/agent-creator-mcp run agent-creator-mcp -e SALESFORCE_USERNAME your_username -e SALESFORCE_PASSWORD your_passwordUpon launching, the Inspector will display a URL that you can access in your browser to begin debugging.
In Cursor, you can create custom rules to enhance the agent creation process. For example:
# After the generate_agent_metadata is called:
- Create a folder in our project root if it does not exist called: agents
- Store the JSON output in the agents folder: agent_name.json
- Create a visual markdown of all the agent information including description, name, utterances, topics, and actions
- Generate a Mermaid diagram showing the Agent as a Node with Topics as sub-Nodes, and Actions as subnodes of the topics
- After it is generated, ask if the user wants to deploy the agentIn Claude, you can create a project with instructions to use other MCP servers to enhance the agent creation process:
- Guide the user to creating their agentforce agent.
- Use the get_agent_requirements tool to help gather requirements.
- Once enough requirements have been collected, call generate_agent_metadata to generate the whole metadata.
- Visualize the topics and agent metadata in the canvas with a React page showing the agent as a node, with topics as sub-nodes, and actions as sub-nodes of topics.
- Once the topics have been generated, call the deploy_agent to deploy the agent.
- Check if the agent deployment status is successful.Deploy a previously generated agent to Salesforce.
The agent must be generated by the generate_agent_metadata tool
Always ask the user first if they want to deploy the agent to their Salesforce org first
If the deployment fails, return the error message from the deploy_agent tool If there is no deployment result, return "Deployment failed" If the deployment Status is None, also return "Deployment failed", but keep the login URL so user can inspect the deployment logs In the deployment result, include the login URL of the Salesforce instance so the user can login to the agent.
Args:
agent_metadata: The agent metadata to deploy as a dictionary
Returns:
dict: The deployment status from Salesforce
| Name | Required | Description | Default |
|---|---|---|---|
| agent_metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses deployment behavior, error handling steps, and return value including login URL. Could mention potential side effects like modifying org.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet-point rules and explicit Args/Returns sections. Concisely communicates key information, though the two identical 'Deployment failed' returns are slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers prerequisite, user interaction, failure scenarios, and return format. Lacks details on agent_metadata structure, but overall sufficient for a deployment tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (agent_metadata) with no schema description (0% coverage). Description adds basic meaning as 'agent metadata to deploy as a dictionary' but lacks structure details or examples typical for a nested object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Deploy a previously generated agent to Salesforce.' It uses a specific verb (deploy) and resource (agent), and distinguishes from sibling tools: generate_agent_metadata creates metadata, get_agent_requirements retrieves requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (after generate_agent_metadata) and instructs to always ask user first. Provides handling for failure cases. Lacks explicit when not to use but covers key usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your job is to create a description of an AI Agent, generating sample utterances, and convert a list of topics into a specific JSON format. The description of the AI Agent and the sample utterances should be combined into the JSON object. The description and sample utterances should be grounded in the context of the conversation provided. Always ask for the company name first and what the name of the agent should be if we don't have it already.
When converting the Topics, description, scope, instructions and actions to JSON, DO NOT MODIFY any of the properties or language.
Never use or include emojis
Use the requirements gathered from the conversation to generate the agent metadata
Follow these instructions carefully to complete the task:
First, review the context of the conversation if provided, we provided the requirements for the agent. Come up with a name for the agent.
Now, examine the list of topics to be converted:
Convert each topic into the required JSON format
For each topic:
a. Use the topic name as provided in the list for the "name" field. The topic name must only use ASCII characters and _, if there are any other characters (accents, emojis, etc...), please convert them to plain ASCII or a _ if its a space.
b. Use the description provided in the description field. Do not change the description.
c. Use the scope provided in the scope field. Do not change the scope.
d. Include all of the instructions provided in the instructions list. Do not change any of the instructions
e. Generate a list of actions for the "actions" field, following the format described in step 5. Do not change any of the action properties.
f. Ensure you do not change the fields from the Topics
g. Remove all '/' from the actions.
h. Remove any actions that do Knowledge Lookups or search knowledge action. This includes but is not limited to: Knowledge_Lookup, Search_Knowledge... etc. If an instruction includes the "Knowledge_Lookup" action, modify the instruction to something like "search the knowledge base".
For each action, generate an example_output as a JSON object that demonstrates its full capabilities. Rules for the example output: a. Provide a detailed and realistic return value b. Include any relevant metadata or additional information that the function might reasonably return.
Generate only 1 or 2 topics if possible.
Given the Topics and the Context of the conversation, generate a 1-2 description of the AI Agent and what it does. The description should start with: "You are an AI Agent whose job is to help customers...."
Given the Topics, Instructions, and actions, generate 4-5 sample utterances a user might use to engage with the AI Agent. These sample utterances should tie directly back to an instruction or an action. When including IDs in the sample utterances, make the IDs realistic. Do not include any utterances about escalating or speaking to a human.
Ensure that all JSON is properly formatted and valid. Always return only JSON.
Each instruction should be a single topic-specific guideline, usually phrased as but not limited to "If x, then y…", "As a first step,…", "Once the customer does...", "When a customer...".
Instructions should be non-deterministic and should not include sensitive or deterministic business rules.
Instructions should also provide as much context as possible, which is derived from the transcript, so that the AI Agent can have a better understanding of the use case.
When writing instructions, ensure that they do not conflict with each other within a topic.
When writing instructions, include instructions to ask for the input of the actions in order to run the action.
Also use absolutes such as "Must, "Never", or "Always" sparingly -- instead use verbiage that allows more flexibility.
In every topic, except for an "Escalation" topic, include an instruction that enables the AI Agent to search knowledge to help the customer with their questions related to the .
Provide relevant actions to support the Topic, scope, and instructions.
Actions are effectively the function that gets invoked to do things for the topic.
Actions can have multiple inputs if needed.
Outputs represent what properties are sent as a response of the action
When writing action descriptions, include in the action description what inputs are needed. Example: "Retrieve the current status and tracking information of a customer's order for a given an orderId"
Input descriptions are 1-2 sentences that describe the input and how it is used.
Output descriptions are 1-2 sentences that describe the output and how it is used.
Action descriptions should provide context of when the action should be used and also what information is needed from the customer.
The AI Agent has access to the internet through an action. If there is an action that could be answered through a web search on company's website, such as troubleshooting steps or questions, company policy information, policy guidance, technical support or general company information, then always generate an action called "Knowledge_Lookup".
Generate 4-5 sample utterances for the agent based on the topics and instructions.
The sample utterances should tie directly back to an instruction or an action.
Generate a 1-2 sentence description of the agent based on the topics and instructions.
The description should start with: "You are an AI Agent whose job is to help ...."
Generate a System messages, such as welcome and error messages that are sent when your users begin using an agent and if they encounter system errors.
The system messages should be in the format of a JSON object with the following fields:
name: The name of the system message
content: The content of the system message
description: The description of the system message
Args: agent_metadata: The agent metadata as a dictionary Returns: The generated agent metadata
| Name | Required | Description | Default |
|---|---|---|---|
| agent_metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool will ask for company name and agent name, generate utterances, and produce JSON. It also lists extensive rules and steps. However, it doesn't mention side effects, authentication needs, or data handling beyond the task. Still, it provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (many paragraphs) with detailed instructions that could be shortened. It has some front-loading with the job statement, but then includes many rules, formatting notes, and examples that make it verbose. Many sentences could be removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should fully explain return values. It mentions the tool returns 'generated agent metadata' but does not specify the exact JSON format or fields. The complexity is moderate with one nested parameter. The description provides many procedural details but lacks some completeness on inputs/outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% – the description does not explain the 'agent_metadata' parameter meaningfully beyond a brief line at the end: 'Args: agent_metadata: The agent metadata as a dictionary'. With a nested object and additionalProperties: true, more context is needed. The description's bulk focuses on how to process the parameter, not what it is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's job: 'create a description of an AI Agent, generating sample utterances, and convert a list of topics into a specific JSON format.' This distinguishes it from sibling tools deploy_agent_tool and get_agent_requirements. However, the description is overloaded with instructions that could be seen as part of the tool's use rather than its core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to generate agent metadata given agent_metadata input, but it doesn't explicitly state when to use it vs alternatives. No 'when-not' or exclusions are provided. The sibling tools have different purposes, but the description lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
You are an AI Salesforce Solution Architect that helps gather requirements for an autonomous agent implementation through friendly, conversational discovery. The goal is to understand the user's business needs in depth so that we can define what kind of AI assistant to build and how it should behave.
Have a friendly, open conversation with the user to understand what kind of AI assistant they need. Keep it simple and helpful. Your goal is to gather clear requirements for their assistant — including business challenges, desired capabilities, and how success should be measured.
Use these simple guiding questions to explore the user's needs. Ask follow-ups based on their responses and validate your understanding along the way.
"What business problem are you trying to solve?"
"What would make this AI assistant successful for you?"
"What kind of interactions or tasks should the agent handle?"
"What's the name of the company you work for?"
"Can you tell me a little about what your company does?"
"Do you have a name in mind for the AI assistant?"
Ask follow-up questions to dig deeper into challenges, goals, and processes.
Keep the conversation focused on the user's needs — not tech features.
Summarize along the way to validate your understanding.
Make sure to gather:
The user's business problem(s)
Their desired outcomes
The channels the agent should live on (e.g., website, mobile, email)
Whether it should integrate with Salesforce, and how (e.g., Service Cloud, Knowledge)
Their company name and what the company does
Whether they have a name for the AI agent
Avoid jumping into solutions or features until the business context is clear.
User: I need an AI assistant for my Salesforce Commerce website.
AI: Great! I'd love to help with that. Before we dive into building the agent, I'll ask a few questions to understand your goals and business a bit better.
To start — could you tell me the name of your company and what you do?
User: We're called StyleNest. We sell mid-range fashion and accessories online — mostly shoes, bags, and seasonal clothing.
AI: Thanks! So StyleNest is an e-commerce company focused on fashion and accessories — got it.
What kind of challenge are you hoping this AI assistant will help solve?
User: Our CSAT scores have dropped. Customers say they struggle to get quick answers, especially for order-related stuff or returns.
AI: I see — so the core issue is that customers are having trouble finding the information they need, especially around orders and returns.
Quick question: how do customers typically reach out for support today?
User: Mostly through email and live chat. We also have help articles on the website, but they're kind of buried and hard to search.
AI: That helps. So it sounds like the AI assistant could help by:
Handling common support queries (orders, returns, delivery info)
Searching and summarizing help articles
Reducing reliance on live agents for repetitive questions
Would you want it to escalate to a human agent when needed?
User: Yes, especially for account-specific or complex questions.
AI: Makes sense. A couple more things to paint the full picture:
Are you using Salesforce Service Cloud for customer support?
And is your knowledge base stored in Salesforce Knowledge?
User: Yes to both.
AI: Got it. And where do you want this AI to live? On your website, in the mobile app, or somewhere else?
User: Just the website for now.
AI: Perfect. Just to recap what I've gathered so far:
Company: StyleNest, an e-commerce fashion retailer.
Challenge: Customers struggle to get quick support; CSAT is dropping.
Existing setup: Email/live chat support, help articles in Salesforce Knowledge.
Goal: AI assistant to help answer routine questions, intelligently search articles, and escalate complex issues.
Desired outcome: Reduce ticket volume and improve CSAT.
Deployment: Website chatbot, integrated with Service Cloud and Knowledge.
Before we move on to designing the assistant, one last thing — do you already have a name in mind for the AI assistant, or shall we come up with one together?
User: Let's call it "Nyla" — kind of goes with the fashion theme.
AI: Love it — "Nyla" it is! That gives us everything we need to start mapping out her capabilities.
Use the same conversation_id to keep adding more requirements to the same conversation or agent. This ensures that all gathered requirements are associated with the correct context and can be referenced or updated as needed.
When new requirements are identified, simply call the tool again with the existing conversation_id and the new requirements to append them to the ongoing conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| requirements | Yes | ||
| conversation_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that using the same conversation_id appends requirements, which is a behavioral trait. However, it does not disclose side effects, authentication needs, or what happens to existing data. With no annotations, the description carries full responsibility for behavioral disclosure, which it largely fails to meet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (over 1000 words) and poorly structured, with sections like 'Prompt' and 'Conversation Guide' that are irrelevant for a tool definition. It front-loads a system prompt instead of a concise tool description, wasting the agent's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter schema and no output schema, the description should clearly state what the tool does and returns. It fails to do so, omitting the return value, error handling, and core purpose. The description is not complete enough for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some context: conversation_id ties to a conversation and requirements are appended. But it does not explain the format or constraints of the requirements array, nor clarify what the tool returns. The meaning is partially conveyed but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a verbose system prompt for conducting a discovery conversation, not a clear statement of what the tool does. It fails to specify that the tool stores or retrieves agent requirements, and instead instructs the AI on how to have a conversation. This is severely misleading and does not communicate the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools (deploy_agent_tool, generate_agent_metadata) are listed, but the description does not differentiate this tool's role or provide context for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0deploy_agent_toolgenerate_agent_metadataget_agent_requirementsEach tool has a clear and distinct purpose: gathering requirements, generating metadata, and deploying. There is no overlap or ambiguity between them.
All tools use snake_case with a verb_noun pattern, but 'deploy_agent_tool' includes the redundant suffix 'tool', breaking consistency with the other two tools.
Three tools cover the essential steps of the agent creation workflow (requirements, metadata generation, deployment) without being excessive or insufficient.
The set covers the main lifecycle steps, but lacks tools for listing, updating, or deleting agents, which could be needed for ongoing management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
An app builder for agents. Your agent creates screens, a Postgres database, and a live URL.
The cloud for agents. Tools for AI agents to register, build, and deploy other agents. Zero human required.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/flemx/agent-creator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
