Salesforce MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct operation: SOQL query, SOSL search, record CRUD by ID, bulk create, pagination, describe, list objects, run report, execute Apex, and limits. The boundaries are clear; even query and query_more are distinguished by pagination.
Naming Consistency4/5
The naming pattern is largely consistent with salesforce_ prefix and verb_noun structure (e.g., create_record, update_record). However, 'salesforce_limits' is a noun-only exception, and 'salesforce_query_more' uses an adverb qualifier, which slightly deviates from the strict verb_noun pattern.
Tool Count5/5
Thirteen tools is well-scoped for a Salesforce MCP server, covering a broad range of operations without bloat. The count sits comfortably in the ideal 3-15 range and each tool serves a distinct purpose.
Completeness4/5
The tool surface covers core CRUD, querying, searching, pagination, object metadata, bulk insert, report execution, anonymous Apex, and API limits. Missing are bulk update/delete and upsert operations, but the coverage is solid for most typical Salesforce automation scenarios.
Average 2.9/5 across 13 of 13 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. Executing anonymous Apex can trigger side effects such as data modification, DML operations, and side effects on shared org resources, but the description says nothing about these risks, required permissions, or potential governor limits. This is a dangerous gap for a code-execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It contains only the bare verb and resource, with no additional context or structure. A one-sentence description can be appropriate, but here it wastes the opportunity to convey critical usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool executes arbitrary code with potential side effects, the description is grossly incomplete. It lacks usage context, parameter semantics, behavioral disclosures, and any mention of return format (despite having an output schema). The description would be inadequate for even a simple read tool, and is severely deficient for a code-execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not reference any parameter names or meanings. Although 'apex_body' is inferable from 'Apex code', the optional 'org' parameter and format expectations (e.g., full Apex script vs. single statements) are completely unexplained. The description adds no value to the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute anonymous Apex code' clearly states the verb (execute) and the resource (anonymous Apex code), which is specific and distinguishes this from sibling tools like salesforce_query or salesforce_create_record. The term 'anonymous Apex' precisely identifies the Salesforce feature and makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention scenarios like running dynamic code, debugging, or performing bulk operations, nor does it state exclusions or prerequisites. Users are left without any indication of appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the operation without mentioning side effects, authorization requirements, output format, or error behavior. This is insufficient for a tool that executes a report, which likely has side effects like runtime limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is under-specified. It is not a tautology, yet it offers little structured information. While it is front-loaded, it does not earn its place due to minimal content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is too thin to provide complete context for a 3-parameter tool. It does not explain the relationship between org, filters, and report_id, nor does it cover potential pitfalls like filter syntax or org selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the three parameters (org, filters, report_id). Schema description coverage is 0%, so the agent receives no semantic guidance beyond the parameter names and types, which is inadequate for constructing a correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' and identifies the resource as 'a Salesforce analytics report,' which clearly distinguishes it from sibling tools like salesforce_query (which runs SOQL) and salesforce_search. However, it lacks scope details such as whether it returns data or just executes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, typical use cases, or when to prefer salesforce_query or salesforce_execute_apex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Return', which implies a read-only operation, but it does not state safety, permissions, or side effects. This is a minimal disclosure that does not proactively inform the agent about constraints or risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clean sentence that is front-loaded with the core purpose. It has no wasted words, though it is so brief that it borders on under-specification, which is more penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return value description is not strictly necessary, but the description still lacks essential context about parameters and when to use the tool. For a simple describe operation, the description is too sparse to fully prepare the agent, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of 'object_type' or 'org'. With two parameters and no guidance, the agent is left to guess what values to provide, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Return') and the resource ('field/metadata information for a Salesforce object'), which distinguishes it from data retrieval tools like salesforce_query. However, it doesn't explicitly differentiate from sibling tools such as salesforce_list_objects, which also deals with objects, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no information about when to use this tool versus alternatives like salesforce_list_objects or salesforce_query. There is no mention of typical use cases, prerequisites, or exclusions, leaving the agent without guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It says 'Return' which implies read-only, but doesn't explicitly state safety, permissions, or any side effects. It also doesn't clarify if calling this tool consumes API limits or any other important behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loaded with the action. However, it is so sparse that it borders on under-specification, though not as extreme as a tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema exists for return values, the description is incomplete for a tool with a parameter. It doesn't explain the org parameter's role or any context for using the tool, making it insufficient for correct invocation beyond the simplest case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional 'org' parameter with 0% coverage in the description. The description never mentions the parameter, leaving the agent uncertain whether 'org' is an ID, name, or something else, and how null affects the call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Salesforce organization's API limits and usage, using a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools, though the purpose is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives like salesforce_query or salesforce_describe_object. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the basic create action and does not disclose side effects (e.g., record ID assignment), permission requirements, error handling, or return format. The presence of an output schema is not leveraged in the description, leaving agents unaware of what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the tool's action. It has no filler or redundant phrasing, making it highly concise and appropriately front-loaded with the verb 'Create'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 3 parameters, nested object in 'data', and the existence of sibling tools (especially bulk_create), the description is overly brief. It does not explain the expected structure of 'data' or how this tool compares to bulk creation. The output schema's presence might cover return values, but other contextual details (e.g., required field handling) are absent, making the description incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter meanings. It only references 'object_type' implicitly ('given object type') but does not explain 'data' (an object with additionalProperties) or 'org' (optional, default null). The description adds minimal meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 ('a new Salesforce record') with a qualifier ('of the given object type'). It distinguishes the tool from update/delete/query siblings by its create semantics, but does not explicitly differentiate from the sibling 'salesforce_bulk_create', relying on the tool name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention bulk_create for multiple records, nor does it note any prerequisites or context (e.g., needing a describe call first). The usage is implied ('create a record') but no exclusions or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It omits critical details like the permanent nature of deletion, potential cascading effects, or required permissions. The word 'Delete' implies but does not specify the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 compact, though it could add more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation, the description is notably incomplete. It does not explain consequences, prerequisites, or when to avoid use. The presence of an output schema alleviates the need for return-value details, but other essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it only mentions 'by ID,' hinting at record_id. It ignores object_type and org entirely, leaving their roles undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a Salesforce record by ID' uses a specific verb and resource, clearly distinguishing it from sibling tools like get, create, and update. It accurately captures the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., soft-delete via update, bulk delete). It lacks context about prerequisites such as knowing the object_type or the need for record_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but adds no behavioral context. It doesn't mention read-only nature, object scope, limits, or error conditions, which is a significant gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. However, its brevity borders on under-specification, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too thin to be complete. It omits usage guidelines, parameter semantics, and any behavioral nuances, leaving critical decisions to the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. 'Search Query' and 'Org' remain undefined except by their names, so the agent gains no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a SOSL search, with a specific verb ('execute') and resource ('SOSL'). The acronym expansion distinguishes it from salesforce_query, which presumably handles SOQL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like salesforce_query or other siblings. It merely states the action, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'Insert multiple records' without mentioning that Bulk API 2.0 is asynchronous, returns a job ID, processes in batches, or handles partial errors. This omits critical behavioral traits that an agent would need to know to correctly use the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the core action ('Insert multiple records') and the API ('Salesforce Bulk API 2.0'). It is free of fluff, though it may be too brief given the tool's complexity, earning a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of a bulk API operation and the total absence of annotations, the description is inadequate. It does not explain the asynchronous nature, batch size implications, return value structure, or error reporting. The output schema exists but the description still needs to provide behavioral context that it currently lacks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. It does not explain that 'records' must be field-value maps, what 'batch_size' controls, how 'org' selects a Salesforce org, or what format 'object_type' expects. The agent must infer all parameter semantics from the bare schema, which is insufficient for a complex bulk operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and resource ('multiple records') and explicitly names Salesforce Bulk API 2.0, clearly distinguishing it from sibling tools like salesforce_create_record which handles single records. The scope and primary action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Insert multiple records' implies this tool is for bulk operations, contrasting with single-record create, but it does not provide explicit guidance on when to choose Bulk API over standard CRUD tools, nor does it mention efficiency thresholds, batching, or error handling. No alternatives are explicitly named or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'optionally limiting returned fields,' which hints at field selection, but it does not explain default field behavior, error handling (e.g., record not found), authentication requirements, or org selection behavior. The read-only nature is implied but not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the operation and the key variation (optional fields). It is concise, front-loaded, and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (2 required) and many sibling tools, this description is incomplete. It omits the purpose of the 'org' parameter, does not specify how field selection works, and provides no guidance on when to use this tool versus alternatives. The existence of an output schema covers return structure, but this does not compensate for the lack of usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only clarifies the 'fields' parameter ('optionally limiting returned fields') but does not explain 'object_type', 'record_id', or 'org'. The parameter names are self-explanatory, but the description adds minimal value beyond them, leaving key semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Retrieve a Salesforce record by ID' uses a specific verb and resource, and adds the optional field limitation. This distinguishes it from sibling tools like salesforce_query (which searches) and salesforce_describe_object (which describes schema).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The phrase 'by ID' implies usage for direct record retrieval, but there is no mention of when to prefer it over salesforce_query or salesforce_search. The description lacks context for choosing among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does convey that results are filtered by the user's access ('visible to the authenticated user'), which is a relevant behavioral trait. However, it does not disclose pagination, return format, or any potential side effects, leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, crisp sentence that immediately conveys the tool's main action and scope. There is no extraneous text, and it is well structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but omits guidance on the 'org' parameter and provides no usage context. It does not explain how to handle the output or when to use it among the many sibling Salesforce tools. Given the availability of an output schema, the return format may be covered, but the overall definition feels thin for an agent needing to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter 'org' with no description in the schema (0% coverage). The tool description does not mention this parameter at all, leaving the agent without any explanation of what 'org' refers to or how to use it. This is a complete failure to compensate for the schema's lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), identifies the resource ('Salesforce objects'), and defines scope ('visible to the authenticated user'), clearly distinguishing it from sibling tools like salesforce_describe_object which targets a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, and it does not mention any prerequisites or exclusion cases. The only contextual hint is the scope 'visible to the authenticated user,' but there is no explicit when/how to choose it over salesforce_describe_object or salesforce_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Update fields' and does not reveal whether the update is partial or full replacement, what happens if the record does not exist, whether permissions are required, or how the org parameter affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It delivers the core action and target in a compact form, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with four parameters, a nested data object, no annotations, and an output schema, yet the description is extremely sparse. It does not explain update semantics (partial vs. replace), error behavior, or how this tool fits with sibling tools like salesforce_create_record and salesforce_delete_record. The presence of an output schema reduces the need to describe return values, but other essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 for undocumented parameters. It does not explain the structure of 'data', the format of 'record_id', valid values for 'object_type', or the meaning of 'org'. The word 'fields' weakly hints at the 'data' parameter but adds little beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Update fields'), the target resource ('existing Salesforce record'), and distinguishes itself from sibling tools like create, delete, get, and query. It is a precise, non-tautological statement of the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing' implies this tool is for records that already exist, providing a minimal usage hint, but it does not explicitly state when to prefer this over salesforce_create_record or mention any alternatives. There are no clear 'when to use' or 'when not to use' guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Retrieve' conveys a read-only action, which is useful, but it does not disclose what happens if the URL is invalid or whether any side effects occur. The description is adequate for a simple pagination fetch but leaves some behavioral assumptions unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of nine words. It is front-loaded with the action and resource, with zero fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values are covered. However, the description does not connect to its sibling 'salesforce_query' or explain where next_records_url originates. Given the moderate complexity, the description is adequate but lacks the contextual linkage that would make it truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain either parameter. 'next_records_url' is somewhat self-explanatory, but the description fails to mention that it should come from the previous query response. The optional 'org' parameter is entirely unaddressed. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and clearly identifies the resource as 'the next page of a paginated SOQL query'. This distinguishes it from sibling tools like 'salesforce_query' which performs the initial query. The purpose is immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'next page' implies this tool is used after an initial paginated query, but it does not explicitly state that it should be used when a previous query returns a nextRecordsUrl, nor does it point to salesforce_query as the origin. The usage context is clear in general terms but lacks specific guidance on when to invoke this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the include_deleted behavior, which is useful, but does not mention other behavioral aspects such as read-only nature, result limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the main action. It is efficient and to the point with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. However, the description is very minimal and does not mention pagination or when to use salesforce_query_more, which is a notable gap given the sibling tool list. It covers the basic action but lacks depth for a complex querying tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 clarity for include_deleted, but leaves org and query semantics unexplained beyond their parameter names. The query parameter is required and intuitively understandable, but no syntax or example is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a SOQL query, using a specific verb and resource. This distinguishes it from sibling tools like salesforce_search or salesforce_get_record, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using SOQL queries but does not explicitly mention alternatives or when not to use it. It could have benefited from a note about salesforce_query_more for pagination, but the core usage is immediately evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![salesforce-mcp-server MCP server](https://glama.ai/mcp/servers/LokiMCPUniverse/salesforce-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/LokiMCPUniverse/salesforce-mcp-server)

Score Badge

Copy to your README.md:

[![salesforce-mcp-server MCP server](https://glama.ai/mcp/servers/LokiMCPUniverse/salesforce-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/LokiMCPUniverse/salesforce-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LokiMCPUniverse/salesforce-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server