MCP Salesforce Connector

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'restful', 'apex_execute', and 'tooling_execute' as they all involve making API calls to Salesforce, which could cause confusion. The CRUD operations and query tools are clearly differentiated.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern, but there are minor deviations like 'restful' (adjective instead of verb) and 'tooling_execute' (noun_verb instead of verb_noun). Overall, the pattern is readable and predictable.
Tool Count5/5
With 10 tools, the count is well-scoped for a Salesforce connector, covering core operations like CRUD, queries, and API interactions. Each tool serves a specific function without being overwhelming.
Completeness5/5
The tool set provides comprehensive coverage for Salesforce operations, including CRUD, metadata retrieval (get_object_fields), querying (SOQL/SOSL), and various API calls (REST, Apex, Tooling). There are no obvious gaps for typical agent workflows.
Average 2.8/5 across 10 of 10 tools scored.
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 status not available
This repository is licensed under MIT License.
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

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 but fails to do so. It does not indicate whether this is a read-only or mutative operation, what permissions or authentication are required, potential rate limits, or error handling. The term 'executes' implies action but lacks detail on consequences, leaving the agent with insufficient context for safe invocation.
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 extremely concise with a single sentence, 'Executes a Tooling API request', which is front-loaded and wastes no words. While it lacks detail, every part of the sentence contributes to stating the tool's function, making it efficient in structure without unnecessary elaboration.
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 complexity of executing API requests with 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what the Tooling API is, what to expect in responses, or how errors might be handled. For a tool that likely involves network calls and data manipulation, this minimal description fails to provide adequate context 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting parameters like 'action', 'method', and 'data'. The description adds no additional meaning beyond this, as it does not explain parameter relationships or usage examples. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without description enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Executes a Tooling API request' is tautological—it essentially restates the tool name 'tooling_execute' without specifying what the Tooling API is or what kind of operations it performs. It lacks a specific verb-resource combination (e.g., 'call Salesforce Tooling API endpoints') and does not distinguish this tool from siblings like 'restful' or 'apex_execute', leaving its purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 context, prerequisites, or exclusions, nor does it reference sibling tools like 'restful' (which might handle general REST calls) or 'apex_execute' (for Apex execution). This absence of usage instructions makes it misleading for an agent trying to select the correct tool.
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 mentions 'executes' but doesn't clarify authentication requirements, rate limits, error handling, or what happens upon execution (e.g., side effects, response format). For a tool that likely interacts with Salesforce APIs, this is a significant gap in transparency.
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, efficient sentence: 'Executes an Apex REST request'. It's front-loaded with the core action and resource, with zero wasted words, making it highly concise and well-structured for quick understanding.
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 complexity of executing Apex REST requests (likely involving Salesforce custom code), no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain return values, error cases, or how it differs from similar tools, leaving critical context gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for 'action', 'method', and 'data' parameters. The description adds no additional meaning beyond the schema, such as examples of Apex endpoints or data formatting. Since the schema does the heavy lifting, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Executes an Apex REST request', which clearly indicates it performs an execution action on Apex REST endpoints. However, it lacks specificity about what Apex REST is (Salesforce custom API) and doesn't distinguish it from sibling tools like 'restful' or 'tooling_execute', making it somewhat vague for users unfamiliar with Salesforce terminology.
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. With siblings like 'restful' (likely for standard REST calls) and 'tooling_execute' (likely for Tooling API), the description offers no context on use cases, prerequisites, or exclusions, leaving users to guess based on tool names alone.
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. 'Deletes' implies a destructive mutation, but it doesn't specify critical details like whether deletion is permanent or reversible, required permissions, error handling, or side effects. This is a significant gap for a tool with no annotation coverage.
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 extremely concise with just two words ('Deletes a record'), making it front-loaded and efficient. Every word earns its place by conveying the core action, though this brevity contributes to gaps 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?
Given the complexity of a deletion operation with no annotations and no output schema, the description is incomplete. It lacks essential context such as behavioral traits (e.g., permanence, permissions), usage guidelines, and output expectations, making it inadequate for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what the input schema provides. Since schema description coverage is 100% (both parameters are documented with clear descriptions), the baseline score is 3. The description doesn't compensate with additional context like examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a record' clearly states the verb ('Deletes') and resource ('a record'), making the basic purpose understandable. However, it lacks specificity about what type of record (e.g., Salesforce object) and doesn't distinguish it from sibling tools like 'update_record' or 'create_record' beyond the obvious verb difference.
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 prerequisites (e.g., needing a record ID), exclusions, or comparisons to siblings like 'update_record' for modifications or 'get_record' for verification before deletion. Usage is implied by the verb but not explicitly stated.
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. 'Updates an existing record' implies a mutation operation, but it doesn't disclose critical traits like required permissions, whether updates are reversible, error handling for invalid IDs, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 extremely concise with just three words: 'Updates an existing record'. It's front-loaded and wastes no space, making it efficient for an agent to parse. However, this conciseness comes at the cost of completeness 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?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success or failure, return values, or system-specific behaviors (e.g., Salesforce validation rules). For a tool that modifies data, more context is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all three parameters (object_name, record_id, data). The description adds no additional meaning beyond what the schema provides, such as examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Updates an existing record' states the basic action (update) and resource (record), but it's vague about what kind of record system this operates on (Salesforce) and doesn't distinguish it from sibling tools like 'create_record' or 'delete_record' beyond the verb. It's minimally adequate but lacks specificity.
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 prerequisites (e.g., needing an existing record ID), exclusions, or comparisons to siblings like 'create_record' for new records or 'get_record' for retrieval. This leaves the agent with no contextual usage information.
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 states the action ('creates') but doesn't explain what 'creates' entails—such as whether it's a write operation that requires specific permissions, what happens on success/failure, or if there are side effects like triggering workflows. This leaves significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the key action ('creates') without any wasted language. Every word earns its place, making it efficient 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?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, error handling, or return values, which are crucial for safe and effective tool invocation in a context with sibling tools like 'delete_record' and 'update_record'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters ('object_name' and 'data') thoroughly. The description adds no additional meaning beyond what the schema provides, such as examples of valid object names or data constraints, which aligns with the baseline score when schema coverage is high.
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 verb ('creates') and resource ('new record'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update_record' in terms of when to create versus update, which prevents a perfect score.
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 like 'update_record' or 'delete_record'. It doesn't mention prerequisites, such as needing valid object names or data structures, leaving the agent to infer usage context from the schema alone.
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. While 'retrieves' implies a read-only operation, the description doesn't address important behavioral aspects like authentication requirements, error handling for invalid IDs, rate limits, or what format the record is returned in. This leaves significant gaps for a tool that interacts with a database system.
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 extremely concise at just 5 words, front-loading the essential information with zero wasted words. Every word earns its place, making it easy for an agent to quickly understand the core function.
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 database retrieval tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what format the record is returned in, whether it includes all fields or just specific ones, how to handle different Salesforce object types, or what happens when a record doesn't exist. Given the complexity of Salesforce data retrieval and the lack of structured metadata, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description adds no additional parameter information beyond what's in the schema - it doesn't explain the relationship between object_name and record_id, provide examples, or clarify constraints. This meets the baseline for high schema coverage.
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 verb ('retrieves') and resource ('a specific record by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar siblings like 'get_object_fields' or 'run_soql_query', which could also retrieve records in different ways.
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. With siblings like 'run_soql_query' for complex queries and 'get_object_fields' for metadata, the agent receives no help in selecting the right tool for retrieving a single record by ID versus other retrieval methods.
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 burden for behavioral disclosure but offers minimal information. It mentions it's a 'direct REST API call' which implies it can perform any HTTP operation, but doesn't discuss authentication requirements, rate limits, error handling, response formats, or what types of operations are supported/unsafe. For a flexible tool with 4 parameters and no annotations, this is inadequate.
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, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a tool that delegates complexity to its parameters, and the information is front-loaded with the essential action and target.
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 flexible REST API tool with 4 parameters, no annotations, no output schema, and multiple specialized sibling tools, the description is insufficient. It doesn't explain what the tool returns, when to use it versus alternatives, authentication requirements, or any behavioral constraints. The agent would struggle to use this tool effectively without significant trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, providing good documentation for all 4 parameters. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions (e.g., explaining path format, method usage, params/data distinction). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 ('Makes a direct REST API call') and target resource ('to Salesforce'), providing a specific verb+resource combination. However, it doesn't differentiate this generic REST call tool from more specialized sibling tools like create_record, update_record, or run_soql_query, which would require explicit comparison to achieve a perfect score.
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 the many specialized alternatives available (create_record, update_record, run_soql_query, etc.). It doesn't mention any prerequisites, limitations, or scenarios where this direct API approach is preferred over the more specific tools, leaving the agent without usage context.
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 states what the tool does but doesn't describe important behavioral traits: whether it's read-only or has side effects, authentication requirements, rate limits, error handling, or what the response format looks like. For a query execution tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 extremely concise - a single sentence with no wasted words. It's front-loaded with the core functionality and doesn't include unnecessary elaboration. While it could benefit from additional context, what's present is structured efficiently.
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 that executes queries against a complex system like Salesforce, the description is inadequate. With no annotations, no output schema, and no behavioral context, the agent lacks crucial information about what the tool returns, how to handle errors, authentication requirements, or performance considerations. The description doesn't compensate for these gaps in structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with the single parameter 'query' clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what the schema already provides - no examples of valid SOQL syntax, no constraints on query complexity, and no guidance on parameter usage. This meets the baseline for high schema coverage.
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 ('Executes') and target ('SOQL query against Salesforce'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from potential sibling tools like 'run_sosl_search' or 'tooling_execute' that might also execute queries, missing the opportunity to clarify its specific scope within the Salesforce ecosystem.
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 like 'run_sosl_search' (for SOSL queries) or 'restful' (for API calls). It doesn't mention prerequisites, limitations, or typical use cases, leaving the agent to infer usage context from the tool name alone.
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 burden for behavioral disclosure. It states what the tool does but reveals nothing about permissions required, rate limits, error conditions, response format, or whether this is a read-only versus mutation operation. For a search tool that likely queries sensitive Salesforce data, this lack of behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a single-parameter tool and front-loads the core functionality immediately. Every word earns its place in conveying the essential purpose.
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 no annotations, no output schema, and a sibling tool ('run_soql_query') that serves a similar purpose, the description is incomplete. It doesn't help the agent understand when to choose SOSL over SOQL, what the response contains, or any behavioral constraints. For a Salesforce search operation among multiple data access tools, this minimal description leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single well-documented parameter, so the baseline is 3. The description adds no parameter-specific information beyond what's in the schema - it doesn't explain SOSL syntax rules, provide additional examples beyond the schema's example, or clarify what 'against Salesforce' means for parameter construction.
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 ('Executes') and target ('a SOSL search against Salesforce'), providing a specific verb+resource combination. It distinguishes this from general search operations by specifying SOSL (Salesforce Object Search Language), though it doesn't explicitly differentiate from the sibling 'run_soql_query' tool which handles SOQL queries instead.
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 when SOSL searches are appropriate compared to SOQL queries (via 'run_soql_query'), when to use REST API calls (via 'restful'), or any prerequisites or constraints for SOSL execution. The agent must infer usage from the tool name alone.
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 states the tool 'Retrieves' data, implying a read-only operation, but doesn't clarify if it's safe (non-destructive), has rate limits, requires authentication, or what the output format looks like (e.g., JSON structure). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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, efficient sentence that front-loads the key action and resource. It wastes no words, avoids redundancy, and is appropriately sized for a simple tool with one parameter. Every part of the sentence contributes to understanding the tool's purpose.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks usage guidelines, behavioral details, and output information, which are important for an agent to use it effectively. With no output schema, the description should ideally hint at the return format, but it doesn't, leaving gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'object_name' well-documented in the schema itself. The description adds no additional parameter details beyond what's in the schema (e.g., examples beyond 'Account' or 'Contact', or handling of custom objects). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Retrieves') and the resource ('field Names, labels and types for a specific Salesforce object'), making the purpose immediately understandable. It distinguishes itself from siblings like get_record (which retrieves data records) or run_soql_query (which queries data) by focusing on metadata about object fields. However, it could be slightly more specific about what 'field Names, labels and types' entails (e.g., metadata vs. actual data).
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 prerequisites (e.g., needing object permissions), compare it to similar tools like tooling_execute (which might also retrieve metadata), or specify use cases (e.g., for building dynamic forms or validating field names). Without this, an agent might struggle to choose it appropriately among siblings.
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 MCP server](https://glama.ai/mcp/servers/ampcome-mcps/salesforce-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ampcome-mcps/salesforce-mcp)

Score Badge

Copy to your README.md:

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

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/ampcome-mcps/salesforce-mcp'

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