MCP Salesforce Server

Server Quality Checklist

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

Latest release: v1.2.1
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between salesforce_describe and salesforce_installation_info, both providing schema details, which could cause confusion. Additionally, salesforce_learn and salesforce_learn_context both involve learning aspects, though their focuses differ slightly (installation vs. personal context).
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with a 'salesforce_' prefix, and they use clear verbs (e.g., create, delete, query) paired with nouns or actions. This predictability makes the set easy to navigate and understand.
Tool Count5/5
With 14 tools, the server is well-scoped for managing Salesforce operations, covering authentication, CRUD, querying, backups, and setup. Each tool serves a specific function without unnecessary bloat, fitting the domain's complexity appropriately.
Completeness5/5
The tool set provides comprehensive coverage for Salesforce interactions, including full CRUD operations (create, query, update, delete), schema exploration (describe, installation_info), backup management, authentication, setup, and advanced features like time machine queries. No significant gaps are apparent for the intended domain.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed 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 failing
This repository is licensed under BSD 2-Clause "Simplified" 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. It mentions 'Automatically handles required fields validation,' which adds some context about validation behavior. However, it lacks critical details: it doesn't specify whether this is a write operation (implied but not stated), what permissions are needed, whether it's idempotent, error handling, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
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 two sentences that are front-loaded and waste no words. The first sentence states the core purpose, and the second adds a key behavioral trait (validation handling). Every sentence earns its place, making it efficient and well-structured.
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 creating records in Salesforce (a mutation operation), no annotations, and no output schema, the description is incomplete. It should explain more about behavioral aspects like authentication needs, error cases, or what the return value looks like. The current description leaves too many gaps for effective tool use by an AI agent.
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 ('sobject' and 'data'). The description doesn't add any meaningful semantics beyond what's in the schema—it repeats the idea of creating a record but doesn't clarify parameter usage, constraints, or examples not already covered. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Create') and resource ('new record in any Salesforce object'), making the purpose explicit. It distinguishes from siblings like 'salesforce_update' and 'salesforce_delete' by focusing on creation. However, it doesn't specifically differentiate from all siblings (e.g., 'salesforce_setup' might also involve creation), so it's not a perfect 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 guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'salesforce_create' over 'salesforce_update' for existing records, or when to use 'salesforce_query' to check for duplicates first. There's also no mention of prerequisites like authentication or Salesforce object availability.
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 but only states what parameters to configure. It doesn't disclose whether this persists credentials, requires authentication, has side effects, returns confirmation, or handles errors. 'Configure' implies a write/mutation operation but lacks behavioral details.
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?
Extremely concise single sentence with zero waste. Every word contributes directly to the tool's purpose. The structure is front-loaded with the core action and immediately specifies what's being configured.
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 credential configuration tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after configuration, whether credentials are validated, what the expected outcome is, or how this interacts with other Salesforce tools. The complexity of credential management warrants more complete guidance.
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 parameters are fully documented in the schema. The description lists the three parameters by name but adds minimal semantic context beyond what's already in the schema descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('Configure') and the resource ('Salesforce credentials') with specific parameters listed. It distinguishes this as a setup/configuration tool rather than data operations like query or create, but doesn't explicitly differentiate from sibling 'salesforce_auth' which might have overlapping functionality.
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 on when to use this tool versus alternatives like 'salesforce_auth' or other setup-related tools. The description implies this is for initial credential configuration but doesn't specify prerequisites, timing, or whether this should be used before other Salesforce operations.
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 it 'Requires the record ID and field values to update,' implying a mutation operation, but doesn't cover critical aspects like permissions needed, whether updates are reversible, rate limits, error handling, or what the response looks like. This is a significant gap for a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded in a single sentence, with no wasted words. It efficiently conveys the core action and requirements, though it could be slightly more structured by separating purpose from prerequisites.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, authentication), doesn't explain return values, and provides minimal usage guidance, making it inadequate for safe and effective agent 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%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'Requires the record ID and field values to update,' which restates what the schema says. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Update') and resource ('existing record in any Salesforce object'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'salesforce_create' or 'salesforce_delete', which would require mentioning it modifies existing records rather than creating new ones or removing them.
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., authentication), compare to siblings like 'salesforce_create' for new records or 'salesforce_query' for reading, or specify scenarios where this update is appropriate, leaving the agent without contextual usage cues.
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 but lacks critical behavioral details. It doesn't disclose whether this is read-only (implied by 'query' but not stated), authentication requirements, rate limits, error handling, or what happens with malformed queries. The description adds minimal behavioral context beyond the basic operation.
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 appropriately concise with two sentences that efficiently convey core functionality. The first sentence states the purpose, and the second adds useful context about supported features. No wasted words, though it could be slightly more front-loaded with critical behavioral information.
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 query tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., query results format), error conditions, authentication needs, or limitations. Given the complexity of Salesforce queries and lack of structured fields, more contextual information is needed 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%, so the schema already fully documents the single 'query' parameter. The description adds marginal value by mentioning SOQL features (SELECT, WHERE, etc.) and implying broad object support, but doesn't provide additional syntax or format details beyond what's in the schema description. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Execute SOQL queries against any Salesforce object' with specific verb ('Execute') and resource ('SOQL queries against any Salesforce object'). It distinguishes from obvious siblings like create/delete/update by focusing on querying, though it doesn't explicitly differentiate from salesforce_time_machine_query.
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 description implies usage context by mentioning 'Supports SELECT, WHERE, ORDER BY, LIMIT, and other SOQL features,' suggesting this is for querying data. However, it doesn't provide explicit guidance on when to use this vs. alternatives like salesforce_time_machine_query or salesforce_describe, nor does it mention prerequisites like authentication.
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 full burden. It describes what information is returned but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, potential rate limits, pagination behavior, or error conditions. For a tool listing system backups with no annotation coverage, this leaves critical operational context 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, efficient sentence that immediately states the tool's purpose and what information it provides. Every word earns its place by specifying the resource (Salesforce backups) and the exact details included. There's no redundancy or unnecessary elaboration.
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 complexity (simple list operation with no parameters) and the absence of both annotations and output schema, the description is minimally adequate. It tells what the tool does and what information to expect, but doesn't address behavioral aspects like authentication requirements, response format, or error handling. For a backup listing tool in a Salesforce context, more operational context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the empty parameter set. The description appropriately doesn't discuss parameters since none exist, and it adds value by specifying what details are included in the response (timestamp, duration, file counts, sizes). This exceeds the baseline expectation for a zero-parameter tool.
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 ('List') and resource ('Salesforce backups') with specific details about what information is included (timestamp, duration, file counts, sizes). It distinguishes from siblings like 'salesforce_backup' (create backup) and 'salesforce_backup_status' (check status) by focusing on listing existing backups. However, it doesn't explicitly differentiate from all siblings like 'salesforce_query' which could also retrieve backup 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 when this tool is appropriate (e.g., 'to see all backups at once' vs. 'salesforce_backup_status' for a specific backup) or any prerequisites. With multiple sibling tools related to backups, this lack of differentiation is a significant gap.
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 the tool's capabilities (queries, comparisons, history tracking) but lacks critical behavioral details: it doesn't specify whether this is a read-only operation, what permissions are required, how results are returned (e.g., format, pagination), or any rate limits. For a complex query tool with 8 parameters, 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 appropriately sized and front-loaded: a single sentence states the core purpose, followed by a second sentence listing key operations. Every sentence earns its place by conveying essential information without redundancy or fluff. It's efficient and well-structured.
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 complexity (8 parameters, no annotations, no output schema), the description is incomplete. It covers the purpose and high-level operations but misses behavioral context (e.g., read/write nature, permissions, output format) and doesn't compensate for the lack of annotations or output schema. For a tool that queries historical data with multiple operation types, more guidance 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 documents all 8 parameters thoroughly. The description adds minimal value beyond the schema: it mentions 'point-in-time queries, comparisons, and record history tracking,' which loosely maps to the 'operation' enum values, but doesn't provide additional syntax, format, or usage details for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Query historical Salesforce data from backups using Time Machine functionality.' It specifies the verb ('query'), resource ('historical Salesforce data'), and mechanism ('Time Machine functionality'). However, it doesn't explicitly differentiate from sibling tools like 'salesforce_query' or 'salesforce_backup_list' beyond mentioning 'historical' data.
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 description implies usage context by listing supported operations ('point-in-time queries, comparisons, and record history tracking'), which helps identify when to use this tool. However, it doesn't provide explicit guidance on when to choose this over alternatives like 'salesforce_query' (for current data) or 'salesforce_backup_list' (for backup metadata), nor does it mention prerequisites or exclusions.
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. It describes the tool's behavior: checking status of backup jobs, monitoring running/completed/failed operations, and parameter usage. However, it lacks details on authentication requirements, rate limits, error handling, or response format. For a status-checking tool with no annotations, this is adequate but not comprehensive.
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 concise and well-structured: two sentences that efficiently cover purpose, usage, and parameter guidance without redundancy. Every sentence adds value, and it's front-loaded with the core purpose. No wasted words or unnecessary details.
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 moderate complexity (status monitoring with one parameter), no annotations, and no output schema, the description is minimally complete. It explains what the tool does and how to use parameters but lacks details on authentication, response structure, or error conditions. For a tool in a Salesforce context with siblings, it could benefit from more contextual guidance.
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 the schema fully documenting the single optional parameter 'job_id'. The description adds minimal value beyond the schema: it reiterates that no parameters show all jobs and specifying job_id gives detailed status. This aligns with the schema but doesn't provide additional semantics like format examples or edge cases. Baseline 3 is appropriate given 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 tool's purpose: 'Check the status of Salesforce backup jobs' with specific verbs ('check', 'monitor') and resource ('backup jobs'). It distinguishes from sibling 'salesforce_backup' (which likely initiates backups) and 'salesforce_backup_list' (which might list backup configurations rather than job status), though not explicitly named. The purpose is specific but could be more explicit about sibling differentiation.
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 provides clear context for usage: 'Use without parameters to see all jobs, or specify a job_id to get detailed status of a specific backup job.' This gives practical guidance on when to use each parameter mode. However, it doesn't explicitly state when to use this tool versus alternatives like 'salesforce_backup_list' or mention prerequisites (e.g., authentication).
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 of behavioral disclosure. It describes the tool as a read-only operation ('Returns comprehensive information'), which is appropriate, but lacks details on performance characteristics (e.g., response time for large installations), error handling, or data freshness. It adds some context about the scope of information returned but doesn't fully compensate for the absence of annotations.
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, well-structured sentence that front-loads the core purpose ('Returns comprehensive information') and efficiently lists the key components. There's no wasted verbiage, and every phrase adds value by specifying the scope of data returned.
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 complexity of a 7-parameter tool with no annotations and no output schema, the description is adequate but incomplete. It covers the tool's purpose and data scope well, but doesn't address behavioral aspects like response format, pagination, or error conditions. For a metadata retrieval tool with rich parameters, more context on output structure would be beneficial.
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 documents all 7 parameters thoroughly. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining interactions between parameters or providing usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 purpose with specific verbs ('Returns comprehensive information') and resources ('Salesforce installation, including all object details, field specifications, relationships, permissions, and customizations'). It distinguishes itself from siblings like salesforce_query or salesforce_describe by focusing on 'learned installation data' rather than live operations.
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 description implies usage context by specifying 'learned installation data,' suggesting it should be used for metadata retrieval rather than live Salesforce operations. However, it lacks explicit guidance on when to use this tool versus alternatives like salesforce_describe or salesforce_setup, and doesn't mention prerequisites such as needing prior learning via salesforce_learn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively communicates critical traits: the action is permanent and irreversible, which is essential for a destructive operation. However, it doesn't mention authentication requirements, error handling, or rate limits that would be helpful for complete 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 two sentences that each earn their place: the first states the purpose, and the second provides crucial behavioral warning. It's front-loaded with the core action and wastes no 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description covers the permanence aspect well but lacks details on authentication needs, error responses, or success indicators. Given the high stakes of deletion, more context on permissions or confirmation mechanisms would improve completeness.
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 documents both parameters (sobject and id) thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or constraints not covered there. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Delete a record') and resource ('from any Salesforce object'), distinguishing it from siblings like create, update, query, and backup tools. It uses precise language that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deletion scenarios but doesn't explicitly state when to use this tool versus alternatives like salesforce_update for soft deletes or salesforce_backup for data preservation. It provides a caution about permanence but lacks guidance on prerequisites or specific use cases.
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. It discloses key behavioral traits: it performs analysis and creates local documentation, implying a read-only or data-gathering operation without explicit mutation. However, it lacks details on permissions required, execution time, rate limits, or what 'local documentation' entails (e.g., format, location), leaving gaps in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that directly state the tool's purpose and usage guidelines without unnecessary details. Every sentence earns its place by providing essential information, making it efficient and well-structured for quick understanding.
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 complexity (analyzing a complete Salesforce installation) and the absence of both annotations and an output schema, the description is somewhat incomplete. It covers the high-level purpose and timing but lacks details on output format, error handling, or dependencies (e.g., requiring authentication via salesforce_auth). This leaves gaps for an AI agent to fully understand the tool's behavior and results.
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%, with all three parameters well-documented in the input schema (force_refresh, include_unused, detailed_relationships). The description does not add any parameter-specific information beyond what the schema provides, such as explaining interactions between parameters or default behaviors. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 purpose with specific verbs ('analyzes', 'creates') and resources ('complete Salesforce installation', 'local documentation of all objects, fields, and customizations'). It distinguishes itself from siblings like salesforce_describe or salesforce_query by focusing on comprehensive documentation creation rather than specific queries or descriptions.
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 provides explicit guidance on when to use the tool ('run once after initial setup to enable intelligent assistance'), which gives clear context for its primary use case. However, it does not specify when not to use it or mention alternatives among the sibling tools, such as when to choose salesforce_describe instead for less comprehensive analysis.
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. It describes the tool's behavior as retrieving schema information, which is a read-only operation, but does not disclose other traits such as authentication requirements, rate limits, or error handling. The description is accurate but lacks depth for a tool with no annotation support.
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, well-structured sentence that efficiently conveys the tool's purpose and key details. It is front-loaded with the main action and resource, with no redundant or unnecessary information, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (metadata retrieval with one optional parameter) and lack of annotations and output schema, the description is reasonably complete. It covers the purpose and parameter behavior, but could improve by mentioning authentication needs or output format. It is adequate for a read-only tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by clarifying that leaving the parameter empty returns a list of all available objects, which is not explicitly stated in the schema description. This enhances understanding beyond the schema's basic parameter documentation.
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 verb 'Get' and the resource 'detailed schema information for any Salesforce object', specifying the content includes 'all fields, data types, and permissions'. It distinguishes from siblings like salesforce_query (data retrieval) and salesforce_create/update/delete (mutations) by focusing on metadata.
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 description implies usage for schema exploration, but does not explicitly state when to use this tool versus alternatives. It mentions getting a list of all available objects when the parameter is empty, which provides some context, but lacks guidance on prerequisites (e.g., authentication) or comparisons to other tools like salesforce_setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behavioral traits: the tool stores context across sessions for better assistance, proactively captures insights during conversations, and automatically triggers 'store_learning' for valuable moments. However, it doesn't cover potential limitations like storage capacity, session persistence details, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but could be more front-loaded. The first sentence states the core purpose clearly, but the second sentence is lengthy and repetitive, detailing proactive capture scenarios that are somewhat redundant with the schema's 'store_learning' description. Some trimming could improve efficiency without losing key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description does a good job covering purpose and proactive usage. It explains the tool's role in context-aware assistance and when to invoke it, but lacks details on output format, error cases, or how stored context integrates with other tools. The schema compensates well for parameter documentation.
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 all 14 parameters thoroughly. The description adds minimal parameter-specific semantics beyond the schema, mainly emphasizing the 'store_learning' action for proactive capture. It doesn't provide additional meaning for parameters like 'section' or 'key' beyond what's in their schema descriptions.
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's purpose: 'Learn and store personal/business context about the user and their Salesforce data model relationships' and 'helps provide better context-aware assistance across sessions.' It specifies the verb ('learn and store') and resource ('context'), but doesn't explicitly differentiate from sibling tools like 'salesforce_learn' or 'salesforce_setup' beyond the context focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'PROACTIVELY CAPTURE AHA MOMENTS: Whenever you discover something important... automatically use store_learning to preserve this knowledge.' It lists specific scenarios (user reveals key information, expresses frustration, shares successful strategies, or has realizations) and names the specific action ('store_learning'), offering clear alternatives for other actions via the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes the tool's automatic detection capability and OAuth flow handling. However, it doesn't mention important behavioral aspects like whether this persists authentication across sessions, what permissions are required, or potential rate limits. The description doesn't contradict any annotations since none exist.
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 perfectly concise with three sentences that each serve distinct purposes: stating the core function, describing automatic behavior, and providing usage guidance. It's front-loaded with the primary purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool with no annotations and no output schema, the description provides good coverage of the tool's purpose and usage context. However, it doesn't describe what happens after authentication (e.g., token storage, session duration) or potential error scenarios, which would be helpful given the lack of structured metadata.
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%, with the single parameter 'force' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation when schema coverage is complete.
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 specific action ('Authenticate with Salesforce') and resource (Salesforce authentication system). It distinguishes this tool from all sibling tools which perform data operations (query, create, update, backup, etc.) rather than authentication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Call this tool if any Salesforce operations fail due to authentication issues') and when it automatically triggers ('Automatically detects if authentication is needed'). It also implicitly suggests alternatives by indicating this is specifically for authentication failures rather than general Salesforce operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it's an asynchronous operation ('Runs asynchronously in background'), returns immediately with a job ID, and requires follow-up with another tool. However, it doesn't mention potential side effects like API usage impact or resource consumption.
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?
Three tightly focused sentences with zero waste: first states purpose, second explains execution behavior, third provides usage guidance. Every sentence earns its place and information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex backup tool with 8 parameters and no output schema, the description provides good context about the asynchronous nature and workflow. However, it doesn't mention what the job ID looks like or potential error conditions, leaving some gaps for the agent to infer.
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 fully documents all 8 parameters. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score for high coverage.
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 specific action ('Start comprehensive backups'), resource ('Salesforce data including all file attachments'), and scope ('comprehensive'). It distinguishes from siblings like 'salesforce_backup_status' by indicating this initiates the backup while status checks progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Start comprehensive backups') versus alternatives ('Check progress with salesforce_backup_status'), providing clear guidance on the asynchronous workflow and sibling tool relationships.
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:

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

Score Badge

Copy to your README.md:

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

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

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