Provides tools to search, view, update, and create Salesforce records (accounts, contacts, opportunities, leads) and manage activities like tasks and recent activities.
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., "@MCP_Salesforce search for contacts at Acme Corp"
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.
A Model Context Protocol (MCP) server for Salesforce integration, designed for sales, marketing, and C-suite teams to seamlessly search, view, and update Salesforce records through Claude.
Search Functionality: Search across Accounts, Contacts, Opportunities, and Leads
Record Management: View detailed information and update records
Activity Management: Track recent activities and create new tasks
Global Search: Search across all Salesforce records simultaneously
Executive Dashboard: Access key metrics and data for decision-making
Related MCP server: Salesforce MCP Server
Node.js 18.0.0 or higher
A Salesforce account with API access
Connected App configured in Salesforce (see setup instructions below)
Log into your Salesforce org
Go to Setup → App Manager
Click New Connected App
Fill in the basic information:
Connected App Name: MCP Salesforce Integration
API Name: MCP_Salesforce_Integration
Contact Email: Your email address
Enable OAuth Settings:
Check Enable OAuth Settings
Callback URL: https://login.salesforce.com/services/oauth2/success
Selected OAuth Scopes: Add these scopes:
Access and manage your data (api)
Perform requests on your behalf at any time (refresh_token, offline_access)
Access your basic information (id, profile, email, address, phone)
Click Save
Wait for the Connected App to be created (may take 2-10 minutes)
After creating the Connected App:
Go to Setup → App Manager
Find your Connected App and click View
Copy the Consumer Key (this is your CLIENT_ID)
Copy the Consumer Secret (this is your CLIENT_SECRET)
Go to your personal settings by clicking your profile picture → Settings
In the left sidebar, click Reset My Security Token
Click Reset Security Token
Check your email for the security token
You can test your credentials using the Salesforce login:
Username: Your Salesforce username (usually your email)
Password: Your Salesforce password
Security Token: The token you received via email
Configure your Claude Desktop mcp_settings.json file:
{
"mcpServers": {
"MCP_Salesforce": {
"command": "npx",
"args": ["github:waaljair/MCP_Salesforce"],
"env": {
"SALESFORCE_LOGIN_URL": "https://login.salesforce.com",
"SALESFORCE_CLIENT_ID": "your_consumer_key_here",
"SALESFORCE_CLIENT_SECRET": "your_consumer_secret_here",
"SALESFORCE_USERNAME": "your_salesforce_username",
"SALESFORCE_PASSWORD": "your_salesforce_password",
"SALESFORCE_SECURITY_TOKEN": "your_security_token_here"
}
}
}
}Restart Claude Desktop
Clone the repository:
git clone https://github.com/waaljair/MCP_Salesforce.git
cd MCP_SalesforceInstall dependencies:
npm installBuild the project:
npm run buildConfigure your environment variables (create a .env file):
SALESFORCE_LOGIN_URL=https://login.salesforce.com
SALESFORCE_CLIENT_ID=your_consumer_key_here
SALESFORCE_CLIENT_SECRET=your_consumer_secret_here
SALESFORCE_USERNAME=your_salesforce_username
SALESFORCE_PASSWORD=your_salesforce_password
SALESFORCE_SECURITY_TOKEN=your_security_token_hereConfigure Claude Desktop to use the local server:
{
"mcpServers": {
"MCP_Salesforce": {
"command": "node",
"args": ["/path/to/MCP_Salesforce/dist/index.js"],
"env": {
"SALESFORCE_LOGIN_URL": "https://login.salesforce.com",
"SALESFORCE_CLIENT_ID": "your_consumer_key_here",
"SALESFORCE_CLIENT_SECRET": "your_consumer_secret_here",
"SALESFORCE_USERNAME": "your_salesforce_username",
"SALESFORCE_PASSWORD": "your_salesforce_password",
"SALESFORCE_SECURITY_TOKEN": "your_security_token_here"
}
}
}
}search_accounts - Search for accounts by name, industry, or other criteria
search_contacts - Search for contacts by name, email, or other criteria
search_opportunities - Search for opportunities by name, stage, or other criteria
search_leads - Search for leads by name, company, or other criteria
search_all_records - Global search across all Salesforce records
get_account_details - Get detailed information about a specific account
get_contact_details - Get detailed information about a specific contact
get_opportunity_details - Get detailed information about a specific opportunity
update_account - Update account information
update_contact - Update contact information
update_opportunity - Update opportunity information
create_account - Create new Salesforce accounts
create_contact - Create new Salesforce contacts
create_opportunity - Create new Salesforce opportunities
get_recent_activities - Get recent activities for any record
create_task - Create new tasks in Salesforce
"Search for all opportunities in the 'Negotiation' stage"
"Show me details for the Acme Corp account"
"Update the close date for opportunity XYZ to next month"
"Create a follow-up task for contact John Doe"
"Create a new opportunity for the Tech Solutions account"
"Create a new contact for the marketing director at Acme Corp"
"Find all leads from the technology industry"
"Search for contacts at companies with 'Software' in their name"
"Show me recent activities for our key accounts"
"Create a new account for the prospect company we just met"
"Create a new contact for the lead that just signed up"
"Search for all opportunities over $100,000"
"Find accounts in the financial services industry"
"Show me recent activities across all major accounts"
"Create a new strategic account for our enterprise prospect"
Variable | Description | Required |
| Salesforce login URL (usually https://login.salesforce.com) | Yes |
| Connected App Consumer Key | Yes |
| Connected App Consumer Secret | Yes |
| Your Salesforce username | Yes |
| Your Salesforce password | Yes |
| Your Salesforce security token | Yes |
Authentication Failed
Verify your username and password are correct
Ensure your security token is current (regenerate if needed)
Check that your Connected App is properly configured
Permission Errors
Ensure your user has appropriate permissions for the records you're trying to access
Check that your Connected App has the correct OAuth scopes
Connection Issues
Verify the SALESFORCE_LOGIN_URL is correct
For sandbox environments, use https://test.salesforce.com
If you encounter issues:
Check the Claude Desktop logs for error messages
Verify all environment variables are set correctly
Test your Salesforce credentials in the Salesforce web interface
Ensure your Connected App is active and properly configured
Never commit your Salesforce credentials to version control
Use environment variables for all sensitive configuration
Regularly rotate your security token
Monitor your Connected App usage in Salesforce
Fork the repository
Create a feature branch
Make your changes
Submit a pull request
MIT License - see LICENSE file for details
Jair Waal
Create a new Salesforce account
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Account name (required) | |
| type | No | Account type (e.g., Customer, Partner, Prospect) | |
| phone | No | Account phone number | |
| website | No | Account website URL | |
| industry | No | Account industry | |
| billingCity | No | Billing city | |
| description | No | Account description | |
| billingState | No | Billing state/province | |
| annualRevenue | No | Annual revenue | |
| billingStreet | No | Billing street address | |
| billingCountry | No | Billing country | |
| billingPostalCode | No | Billing postal code | |
| numberOfEmployees | No | Number of employees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden, yet it only states 'create' without explaining side effects, potential duplicates, required permissions, or return value. This is insufficient for a mutation tool.
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 a single, clear sentence with no unnecessary words. It is front-loaded and easy to parse.
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?
Despite being a 13-parameter create operation with no output schema or annotations, the description provides no behavioral context, usage constraints, or return information. The schema covers parameters, but broader context is lacking.
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?
All 13 parameters have descriptions in the schema (100% coverage), so the schema already handles parameter semantics. The description adds no extra parameter context, so the baseline score of 3 applies.
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 action (create) and resource (Salesforce account), using a specific verb and resource. While it doesn't explicitly contrast with sibling tools like create_contact, the resource name is sufficiently distinct.
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 regarding when to use this tool versus alternatives, such as update_account for existing accounts or create_contact for contacts. There are no prerequisites or constraints mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Salesforce contact
| Name | Required | Description | Default |
|---|---|---|---|
| No | Contact email address | ||
| phone | No | Contact phone number | |
| title | No | Contact job title | |
| lastName | Yes | Contact last name (required) | |
| accountId | No | Associated account ID | |
| firstName | No | Contact first name | |
| department | No | Contact department | |
| description | No | Contact description | |
| mailingCity | No | Mailing city | |
| mailingState | No | Mailing state/province | |
| mailingStreet | No | Mailing street address | |
| mailingCountry | No | Mailing country | |
| mailingPostalCode | No | Mailing postal code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must alone convey behavior, but it only states the bare action. It does not disclose that lastName is required, what the API returns on success/failure, or any side effects like creating a record in the CRM. No contradictions, but significantly under-informative.
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 a single, clear, front-loaded sentence with no extraneous words. It perfectly captures the core purpose without redundancy, though it sacrifices depth for brevity.
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?
For a tool with 13 parameters and no output schema or annotations, the one-sentence description is grossly insufficient. It doesn't mention that only lastName is required, potential relationships (accountId), or what the response looks like. The schema lists fields but does not explain the tool's overall context.
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?
The description adds no parameter information, but the input schema provides 100% coverage with descriptions for all 13 parameters, including the required lastName. Per the rubric, high schema coverage establishes a baseline of 3.
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 action (create) and the resource (Salesforce contact), making it easy to distinguish from sibling tools like update_contact or search_contacts. It is specific and unambiguous.
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 gives no guidance on when to use this tool versus alternatives (e.g., search_contacts to find an existing contact, update_contact to modify). It also omits any prerequisites, such as requiring an existing account for accountId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Salesforce opportunity
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Opportunity name (required) | |
| type | No | Opportunity type (e.g., New Business, Existing Business) | |
| amount | No | Opportunity amount | |
| nextStep | No | Next step in the sales process | |
| accountId | Yes | Associated account ID (required) | |
| closeDate | Yes | Close date in YYYY-MM-DD format (required) | |
| stageName | Yes | Opportunity stage (required) | |
| leadSource | No | Lead source | |
| description | No | Opportunity description | |
| probability | No | Probability percentage (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects and requirements, but it only states the action without mentioning permissions, validation rules, required account existence, or potential errors. This is a significant gap for a mutation tool.
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 a single, clear, front-loaded sentence with no wasted words. It could benefit from additional context, but it is concise and well-structured for its minimal content.
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 tool's 10 parameters, lack of output schema, and absence of annotations, the one-sentence description is insufficient for an agent to understand the full context, including required fields and behavior. More detail is needed.
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?
The schema fully documents all 10 parameters with descriptions, achieving 100% coverage, so the description doesn't need to add parameter details. However, the description contributes nothing beyond the schema, keeping the baseline score of 3.
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 uses a specific verb ('Create') and resource ('Salesforce opportunity'), making the tool's purpose immediately clear. It distinguishes itself from sibling create tools like create_account and create_contact by naming the exact object type.
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 provides no guidance on when to use this tool versus alternatives, such as update_opportunity for existing records or search_opportunities for querying. No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new task in Salesforce
| Name | Required | Description | Default |
|---|---|---|---|
| whoId | No | Contact or Lead ID this task is related to | |
| whatId | No | Account, Opportunity, or other record ID this task is related to | |
| dueDate | No | Due date in YYYY-MM-DD format | |
| subject | Yes | Task subject/title | |
| priority | No | Task priority (High, Normal, Low) | |
| description | No | Task description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new task' and does not mention side effects, required permissions, whether the operation is reversible, or what the return value is. This is a significant gap for a mutation tool.
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 a single sentence with no filler: 'Create a new task in Salesforce.' Every word contributes to the purpose, and it is appropriately front-loaded.
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?
While the schema provides robust parameter documentation, the description lacks context about return values and how to obtain related record IDs (e.g., via search tools). No output schema exists, so the description should compensate, but it does not. The tool is simple enough that the schema plus description provide a minimally viable understanding, but gaps remain.
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 100% (all 6 parameters have descriptions), so the baseline is 3 even though the description itself adds no parameter detail. The description does not explain any parameter semantics beyond what the schema already provides.
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 'Create a new task in Salesforce' uses a specific verb ('Create') and identifies the resource ('task in Salesforce'). It clearly distinguishes from sibling tools like create_account, create_contact, and create_opportunity, which target different object types.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like needing to search for related records (whoId, whatId) first. There are no exclusions or context hints for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Salesforce account
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | Yes | The Salesforce Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden. It only says 'get detailed information' which implies a read operation, but doesn't disclose permissions, rate limits, return fields, or error behavior. This is a significant gap for a no-annotation tool.
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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's function without unnecessary elaboration.
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?
The tool is simple with one parameter, but there is no output schema and the description doesn't explain what 'detailed information' includes or how it is returned. For a get-by-ID operation, this is a moderate gap in completeness.
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?
The schema provides 100% coverage with a clear description for accountId ('The Salesforce Account ID'). The description adds no additional meaning beyond the parameter name, so the baseline score of 3 applies.
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 purpose: 'Get detailed information about a specific Salesforce account'. It uses a specific verb ('get') and resource ('account'), and the qualifier 'specific' distinguishes it from search tools like search_accounts and from update/create tools.
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 usage when you have an account ID, but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention searching first or compare with get_contact_details or update_account, leaving the agent to infer context from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Salesforce contact
| Name | Required | Description | Default |
|---|---|---|---|
| contactId | Yes | The Salesforce Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention what 'detailed information' includes, potential errors, authentication requirements, or any side effects. The description only states the basic purpose without additional 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 a single, clear sentence with no redundant words. It conveys the essential purpose efficiently and is properly front-loaded.
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 lack of an output schema, the description should explain what return values to expect, but it only says 'detailed information' without specifying fields or structure. For a simple get tool, this is insufficient for an agent to fully understand the output, especially without annotations to fill the gap.
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 100% for the single parameter 'contactId', which is well-documented as 'The Salesforce Contact ID'. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
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 uses a specific verb ('Get') and clearly identifies the resource ('detailed information about a specific Salesforce contact'). It clearly distinguishes from sibling tools like search_contacts or get_account_details by specifying the resource and scope.
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 clearly implies the use case: when you have a Salesforce contact ID and need detailed information. It doesn't explicitly exclude alternatives, but the context is clear enough for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Salesforce opportunity
| Name | Required | Description | Default |
|---|---|---|---|
| opportunityId | Yes | The Salesforce Opportunity ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits, but it only says 'Get detailed information.' It does not explicitly state that the tool is read-only, describe the return format, or mention what happens if the opportunity ID is invalid. This lack of disclosure is a significant gap.
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 a single, front-loaded sentence that directly states the purpose. It is concise and easy to parse, though it lacks any additional context. It is appropriately sized for a simple getter, earning a 4.
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?
The tool is simple with one parameter and no output schema, but the description is too minimal to be fully contextually complete. It omits usage guidance and behavioral details, which are crucial for an agent to invoke it correctly, especially without annotations.
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?
The schema has full coverage for the single parameter 'opportunityId' with a clear description. The tool description adds little beyond that, but since the schema is self-explanatory, a baseline score of 3 is appropriate.
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 function: retrieving detailed information about a specific Salesforce opportunity. The verb 'Get' and resource 'Salesforce opportunity' are specific, and the word 'specific' differentiates it from search tools like search_opportunities.
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 gives no guidance on when to use this tool versus alternatives. It does not mention that it should be used when an opportunity ID is already known, nor does it reference sibling tools like search_opportunities for finding opportunities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent activities (tasks, events, calls) for an account or contact
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of activities to return (default: 10) | |
| recordId | Yes | The Salesforce Record ID (Account, Contact, or Opportunity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that it retrieves activities but does not clarify ordering, time range for 'recent', pagination, or that it also works for Opportunity. No return format or permissions are mentioned.
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 a single, front-loaded sentence that communicates the core purpose without wasted words. It includes key information (tasks, events, calls) efficiently.
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?
The tool has no output schema, so the description should mention what the response contains or any behavioral details. It does not, and it omits the Opportunity scope. For a list tool, this is a significant gap, making the description incomplete for an agent to fully understand what will be returned.
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 100% for both parameters, so the baseline is 3. The description adds minimal value beyond the schema, merely restating the record type scope. It does not explain how 'limit' behaves beyond the schema's own description.
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 retrieves recent activities (tasks, events, calls) for an account or contact, using an imperative verb 'Get' and a specific resource. It distinguishes from sibling search/detail tools, but fails to mention Opportunity, which the schema explicitly includes, creating slight ambiguity.
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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for activity history, nor does it contrast with sibling tools like get_account_details or search_all_records. Usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Salesforce accounts by name, industry, or other criteria
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query for account name or other fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds context that the search supports name, industry, or other criteria, but it does not disclose return format, pagination, ordering, or confirm the read-only nature explicitly. The read operation is implied by the verb 'search'.
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 a single sentence of 11 words, front-loaded with the verb 'search'. Every word adds value with no redundancy, making it perfectly concise and well-structured.
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?
For a simple search tool with no output schema and no annotations, the description provides the core purpose but omits what the tool returns (e.g., list of account records). It is adequate but not fully complete for an agent to know exactly what to expect.
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 100% with descriptions for both query and limit. The description adds 'industry' as an example field, but this is minor enhancement over the schema's 'account name or other fields'. Baseline 3 is appropriate.
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 it searches Salesforce accounts, with the verb 'search' and specific resource 'Salesforce accounts'. This unambiguously distinguishes it from sibling tools like search_contacts or search_opportunities.
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 usage for searching accounts but does not explicitly discuss when to use this tool versus alternatives like search_contacts or search_leads. No exclusion or alternative tool is mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across all Salesforce records using SOSL (global search)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 20) | |
| query | Yes | Search query to find across all records |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes the use of SOSL and 'global search', which adds some context, but it does not explicitly state that the operation is read-only, nor does it explain any limitations or pagination behavior beyond the schema's limit parameter.
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 a single, concise sentence that clearly states the purpose and method. It is front-loaded and contains no unnecessary words, making it easy to parse quickly.
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?
The description covers the core function but not the return format or behavior, especially given the lack of output schema and annotations. It adequately explains what it searches but leaves the exact result structure implicit.
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?
The input schema fully describes both parameters (query and limit) with 100% coverage, so the description does not need to add much. It provides no additional detail about query syntax or how the limit applies, making baseline 3 appropriate.
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 uses a specific verb ('Search') and a clear resource ('all Salesforce records'), explicitly differentiating it from sibling tools like search_accounts and search_contacts. It also specifies the method ('SOSL (global search)'), adding technical precision.
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 phrase 'across all records' implies this is for global search, but the description does not explicitly state when to use it over the per-object search tools or provide exclusions. Sibling tools are listed but not referenced, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Salesforce contacts by name, email, or other criteria
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query for contact name, email, or other fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of behavioral disclosure. It only states the search action and criteria but fails to mention that the operation is read-only, what data is returned, whether pagination exists, or any access requirements. This leaves significant behavioral ambiguity.
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?
A single, clear sentence that front-loads the core action and resource. It is appropriately sized for the tool's simplicity and contains no redundancy or filler.
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?
The description is too sparse given the absence of annotations and output schema. It does not clarify whether the tool returns full contact records or only references, nor how it interacts with sibling tools like get_contact_details. The context is incomplete for an agent to use it effectively.
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?
The input schema fully documents both parameters with descriptions (100% coverage). The tool description largely mirrors the query parameter description without adding new meaning. Thus it meets the baseline but does not exceed it.
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 uses a specific verb 'Search' targeting 'Salesforce contacts' and lists common search criteria (name, email, other), clearly distinguishing it from sibling tools that search other entities or retrieve details. It unambiguously identifies the tool's 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?
No guidance is provided on when to choose this tool over alternatives such as search_all_records or get_contact_details. The description does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Salesforce leads by name, company, or other criteria
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query for lead name, company, or other fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must disclose behavioral traits. It does not mention match type (fuzzy/exact), ordering, pagination, field coverage beyond vague 'other criteria', or response format. This is a significant gap.
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 a single, front-loaded sentence with no wasted words. It is appropriately concise, though it sacrifices useful detail by being so brief.
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?
With no output schema and no annotations, the description should explain what the tool returns or any special behaviors. It does not specify result format, error handling, or lead scope, leaving the agent under-informed.
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 100% for both parameters. The description's 'name, company, or other criteria' largely repeats the schema's own description of the query parameter, adding minimal new semantic value.
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 identifies the tool as searching Salesforce leads, with a specific verb ('Search') and resource ('leads'). It distinguishes from sibling tools by targeting the leads object, though it doesn't differentiate it from search_all_records.
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 context implies use when searching for leads, but there is no explicit guidance on when to use this tool versus alternatives like search_accounts or when not to use it. Lacks explicit boundary-setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Salesforce opportunities by name, stage, or other criteria
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query for opportunity name, stage, or other fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states that the tool searches, which implies read-only behavior, but it does not disclose other behavioral traits like result format, pagination, or limitations. The description adds no context beyond what the name already implies.
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 a single, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently and is appropriately sized for a simple search tool.
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?
The tool is relatively simple with only two parameters, but the description omits usage context and return expectations. Given no output schema, it would benefit from mentioning that it returns a list of matching opportunities, but the current level is minimally viable.
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 100%, so the baseline is 3. The description's 'by name, stage, or other criteria' replicates the schema's parameter description without adding new meaning or clarifying format/usage beyond the schema fields.
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 verb 'Search' and the resource 'Salesforce opportunities', with specific criteria ('by name, stage, or other criteria'). It distinguishes this tool from siblings like search_accounts and search_contacts by focusing on the opportunity object.
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 provides no explicit guidance on when to use this tool versus alternatives such as search_all_records or get_opportunity_details. There is no mention of exclusions or preferred use cases beyond the general search intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a Salesforce account with new information
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | Fields to update on the account | |
| accountId | Yes | The Salesforce Account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the mutation action without disclosing whether updates are partial or full replaces, any permission requirements, or what happens to unspecified fields. This is a significant gap for a write operation.
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 a single, concise sentence with no redundancy. However, it is also under-specified, providing only the most basic action without useful context, so it earns a 4 rather than 5.
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?
For a mutation tool with no annotations and no output schema, the description is too thin. It lacks operational context about the update semantics, return values, or any conditions for successful invocation. The schema covers parameter names but not the behavioral context needed for correct usage.
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?
The input schema fully documents both parameters (accountId and updates), and the description adds no additional parameter-level detail. With 100% schema coverage, the baseline score of 3 applies; the description does not degrade or enhance this.
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 uses a specific verb ('Update') and resource ('Salesforce account'), clearly distinguishing this from sibling tools like update_contact or update_opportunity. It explicitly focuses on accounts, making the purpose unambiguous.
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 like create_account or search_accounts. There is no mention of prerequisites (e.g., that the account must exist) or when updating is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a Salesforce contact with new information
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | Fields to update on the contact | |
| contactId | Yes | The Salesforce Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only says 'update with new information' but does not clarify if this is a partial update, whether unchanged fields are preserved, or what happens on invalid data. This leaves the agent guessing about side effects.
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 a single, front-loaded sentence with no filler or redundant information. Every word earns its place.
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?
The tool is simple, and the schema covers parameters, but the description does not explain expected behavior (e.g., partial vs. full replace, error handling) or when this tool should be selected over alternatives. Given the absence of an output schema, a bit more context would be helpful, though the tool is straightforward.
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?
The input schema already documents both parameters completely (contactId and updates object). The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
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 action ('Update') and the resource ('Salesforce contact'), making it obvious which tool to use. It distinguishes from siblings like update_account and update_opportunity by specifying the contact resource.
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 provides no guidance on when to use this tool versus alternatives such as create_contact or update_account. It lacks context on prerequisites like whether the contact must already exist or how partial updates behave.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a Salesforce opportunity with new information
| Name | Required | Description | Default |
|---|---|---|---|
| updates | Yes | Fields to update on the opportunity | |
| opportunityId | Yes | The Salesforce Opportunity ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'update', implying a write operation, but does not explain whether the update is partial or full, what happens if the ID doesn't exist, required field validations, side effects, or the return format. This is a significant gap for a mutation tool.
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 a single, concise sentence with no fluff or redundant content. However, it sacrifices useful detail for brevity, so while structurally efficient, it is somewhat under-specified.
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 tool has a nested parameter object, no annotations, and no output schema, the description is too sparse. It does not explain the return value, error handling, update semantics, or any operational context. The description is inadequate for an agent to fully trust and invoke the tool correctly.
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 100%, so the input schema already documents both parameters and the nested 'updates' object with field types. The description adds no extra meaning beyond the schema, but the baseline of 3 is appropriate since the schema carries the parameter semantics.
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 verb (Update), resource (Salesforce opportunity), and that it involves new information. While it doesn't add extra scope or detailed differentiation, it is specific enough to distinguish from sibling update tools like update_account and update_contact.
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 provides no guidance on when to use this tool versus alternatives (create, search, other update tools), nor any prerequisites or exclusions. The agent is left without context for selecting this tool appropriately.
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.
v1.0.0create_accountcreate_contactcreate_opportunitycreate_taskget_account_detailsget_contact_detailsget_opportunity_detailsget_recent_activitiessearch_accountssearch_all_recordssearch_contactssearch_leadssearch_opportunitiesupdate_accountupdate_contactupdate_opportunityEach tool clearly targets a distinct Salesforce object and action (search, get, update, create). The global search_all_records is distinct from object-specific searches by its SOSL nature. No two tools appear to overlap in purpose.
Tool names follow a consistent verb_noun pattern in snake_case (e.g., search_accounts, create_task). Minor deviations include get_recent_activities lacking the '_details' suffix used by other getters, and search_all_records being a slightly different phrase, but the overall convention is predictable.
Sixteen tools is slightly above the typical 3-15 range but justified for covering multiple CRM objects (Account, Contact, Opportunity, Lead, Task) with search, get, update, and create operations. The count is reasonable and not bloated.
Significant gaps exist: no delete operations for any object, Lead only has search (no get, update, or create), and Task only has create. This leaves agents unable to perform full lifecycle management, which is a notable deficiency for a Salesforce server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your professional network in Claude — search contacts, log notes, and send warm intros.
xmagnet — AI-powered B2B CRM for Claude. 35 tools that turn natural-language prompts into real CRM actions: prospect, enrich, score leads, manage deals, scan buying intent, run email campaigns and sequences, build forms and landing pages, refine ICP, and analyze performance — all directly inside Claude. 🚀 ONE-CLICK INSTALL: https://api.xmagnet.ai/claude The install page guides Claude users through 3 steps in under a minute: open Claude Connectors, paste the connector name, paste the server URL, sign in. A reviewer workspace is auto-provisioned on first sign-in with sample contacts, deals, campaigns, and ICP suggestions, so every tool works end-to-end with zero setup. No 2FA. No paid plan required. Free tier exposes all 35 tools. What you can do: • Prospecting — search_contacts, search_companies, search_investors, find_contacts_at_companies, enrich_contact, validate_email, find_competitors, company_intelligence • Pipeline — get_deals_pipeline, scan_deal_intent, get_ghost_pipeline, create_deal • Campaigns & sequences — create_campaign, generate_campaign_content, get_campaign_stats, get_bounce_stats, get_unsub_stats, create_sequence_draft, list_sequences • Top of funnel — suggest_icp, get_icp, create_form, list_forms, create_landing_page, list_landing_pages, show_suggestions • Operations — analyze_contacts, get_contact_details, update_contact, save_contacts_to_crm, export_contacts, get_dashboard_stats, get_credit_balance Example prompts to try: • "Find C-suite contacts at fintech companies that raised Series A in the last 6 months." • "Scan my open deals for buying intent and prioritize follow-ups." • "Generate a re-engagement campaign for contacts who opened my last newsletter but didn't reply." • "Show me my deals pipeline by stage with weighted value and win rate." • "Generate a landing page for my Q2 webinar with a registration form." Built for founders, SDRs, RevOps, and growth teams who want their CRM to take action — not just store records. Install: https://api.xmagnet.ai/claude · Site: https://xmagnet.ai · Privacy: https://xmagnet.ai/privacy-policy · Terms: https://xmagnet.ai/terms-of-service · Support: ashish.sinha@xmagnet.ai
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Search, summarize, and update your RevOrbit CRM (leads, deals, contacts, tasks) in plain language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/waaljair/MCP_Salesforce'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
