Salesforce MCP Server

Server Quality Checklist

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

Latest release: v0.0.3
Disambiguation4/5
The tools are mostly distinct, with clear separation between query_records and aggregate_query, and between read/write pairs for Apex. However, salesforce_search_objects (metadata search) and salesforce_search_all (record search) could be confused by name, and salesforce_execute_anonymous serves as a catch-all that overlaps with other tools.
Naming Consistency5/5
All tools follow a consistent salesforce_<verb>_<noun> pattern. Verbs like search, query, describe, manage, read, write, execute, and dml are used systematically. Even with two search tools, the noun suffixes disambiguate (objects vs all).
Tool Count5/5
15 tools is at the upper end of the ideal range but appropriate for a Salesforce server that must cover metadata, records, search, Apex, and debugging. Each tool addresses a distinct aspect of the platform.
Completeness4/5
The server covers metadata discovery (search/describe objects), record operations (query, DML, search), field permissions, Apex class/trigger lifecycle, and debug logs. Minor gaps include lack of delete for objects/fields and no explicit relationship management outside of field creation, but core workflows are covered.
Average 4.3/5 across 15 of 15 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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?
No annotations are provided, so the description carries the full burden. It mentions grant/revoke actions but omits critical behavioral details such as immediate effect, required permissions, reversibility, or potential side effects on profiles/permission sets.
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 well-structured with bullets and practical examples, making it easy to scan. While slightly verbose, every section adds value and the examples aid comprehension.
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 6 parameters, no output schema, and moderate complexity, the description covers primary use cases and examples adequately. It lacks edge-case details (e.g., behavior when profileNames is omitted), but is sufficient for initial 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 input schema already provides descriptions for all parameters (100% coverage), so the description adds little beyond examples. The baseline of 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Manage Field Level Security (Field Permissions)' and lists specific operations (grant/revoke, view, bulk update), clearly distinguishing it from sibling tools like salesforce_manage_field which handles field definitions.
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?
It provides clear operational context through bullets and examples, indicating when to use it for permission management. It doesn't explicitly name alternatives, but the focused scope on field permissions is sufficient guidance.
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?
The note 'Changes affect metadata and require proper permissions' discloses the mutation nature and permission requirement. However, the claim 'with fields, relationships, and settings' is not supported by the input schema (no fields or relationships parameters), which could mislead an agent about capabilities. This prevents a higher score.
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 compact and well-structured: a clear verb phrase, bulleted operations, illustrative examples, and a critical permission note. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, no annotations, and no output schema, so the description must carry more weight. It gives high-level operations but fails to explain return behavior, error conditions, or the full scope of parameter usage. The unsupported 'relationships' claim further reduces completeness and trustworthiness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline would be 3. However, the description mentions creating objects 'with fields, relationships, and settings' but the schema offers no such parameters, adding misleading information. This overstates the tool's functionality and could lead to incorrect invocation, warranting a score below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create', 'modify') and resource ('custom objects in Salesforce'), clearly distinguishing this from sibling tools like search/query/describe. It states the two primary operations (create/update) with concrete examples, making the tool's purpose unmistakable.
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?
Provides clear context for when to use the tool (creating or updating objects) with examples and a permission note. However, it does not explicitly exclude alternatives or mention when to choose sibling tools like salesforce_manage_field or salesforce_describe_object, so it falls short of full 5.
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 of disclosing behavior. It explains the search action and gives examples of matches, but doesn't state whether the operation is read-only, its return format, or any limitations (e.g., case sensitivity, wildcard support). For a simple search tool, the core behavior is disclosed, but additional transparency is lacking.
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: one sentence stating the purpose and one sentence with examples. It is front-loaded with the verb and resource, and every word earns its place. No fluff or repetition.
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 tool with one parameter and no output schema, the description covers the main purpose and gives examples. However, it omits specifics about how the pattern matching works (e.g., substring vs. whole word, case sensitivity) and what the output shape is (e.g., just names or full metadata). These gaps prevent it from being fully complete.
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 only parameter `searchPattern` has a 100% schema description coverage, including an example. The tool description reiterates and supplements with examples ('Account' will find Account, AccountHistory), but doesn't add significant new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for Salesforce standard and custom objects by name pattern.' It provides concrete examples ('Account' will find Account, AccountHistory), which further clarifies the scope and distinguishes it from sibling tools like describe or query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context of when to use this tool (searching objects by name pattern) and provides examples of the expected input/output. It doesn't explicitly mention alternative tools or exclusions, but the use case is unambiguous enough for an agent to decide when to call it.
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 bears full responsibility for behavioral disclosure. It states that the tool returns all fields, relationships, and field properties, which clarifies the scope of information. It does not mention side effects, authentication, or output structure, but for a read-only describe operation this is minimal yet acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action and resource in the first sentence and concrete examples in the second. It is front-loaded and contains no filler, making it highly scannable.
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 a single parameter and no output schema, the description provides a sufficient overview of both input and output: it explains what the agent must provide (objectName) and what will be returned (all fields, relationships, field properties). It could detail the response format further, but for a simple describe endpoint this is adequate.
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 single parameter objectName is fully described in the schema with examples, yielding 100% schema coverage. The tool description adds its own examples ('Account', 'Case') that are redundant with the schema but do not introduce additional semantics. Thus the description contributes little beyond the structured field definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'detailed schema metadata' for a Salesforce object. It clearly distinguishes from sibling tools like query_records or search_objects by focusing on object structure rather than data or search results. Examples with 'Account' and 'Case' reinforce the purpose.
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 conveys its use case: retrieving schema metadata for any Salesforce object. It does not explicitly reference alternative tools or when to avoid using it, but the context is clear enough for an agent to select it when needing object structure. The examples provide practical guidance but no exclusion statements.
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 behavioral burden. It adds useful context like 'requires Id' for update/delete and 'external ID field' for upsert, but doesn't disclose potential side effects (e.g., permanent deletion), permission requirements, or error handling behavior. This is a meaningful but incomplete disclosure 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 well-structured with a clear introductory line, a concise bulleted list of operations, and practical examples. Every sentence contributes meaning, and the format is scannable without excessive length.
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 (4 parameters, no output schema, no annotations), the description covers the core operations, prerequisites, and use cases effectively. It lacks details about return values or failure modes, but for a DML tool with clear operation semantics, it provides sufficient context for an agent to select and invoke it correctly.
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?
Schema description coverage is 100%, so all parameters are documented. The description adds extra semantic value by explaining operation-specific requirements (e.g., update and delete require Id, upsert uses externalIdField), which enhances the schema's basic field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing DML operations (insert, update, delete, upsert) on Salesforce records, with a specific verb+resource structure. It distinguishes itself from sibling tools like salesforce_query_records and salesforce_search_objects by focusing on data manipulation rather than reading or describing.
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 concrete usage context with examples for each operation (Insert new Accounts, Update Case status, Delete old records, Upsert based on custom external ID). It implicitly contrasts with read-only tools, though it doesn't explicitly state when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does add useful context: valid API versions, the constraint that triggerName/objectName in the body must match the parameters, and that status information is returned. However, it does not disclose potential side effects of updating an existing trigger (e.g., trigger activation state or impact on running automation) or any permission requirements, which are significant for a mutating 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 well-structured: a one-sentence purpose statement, two concrete examples, and a bulleted list of caveats. Every section contributes directly to successful invocation, and the content is front-loaded. It is longer than average, but the complexity of a create/update tool with conditional parameters justifies each line.
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 (two operation modes, five parameters, no output schema), the description covers the essentials: required fields per operation, validation rules, default behavior for apiVersion, and the fact that status is returned. Minor gaps exist around effect on existing trigger state and permission requirements, but overall it is complete enough for an agent to invoke the tool correctly.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it clarifies conditional requirements by operation (objectName is only required for create), notes that apiVersion defaults to latest, and provides two full examples showing valid JSON payloads. This exceeds the baseline by giving actionable usage details.
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 opens with a specific verb-resource pair: 'Create or update Apex triggers in Salesforce.' This precisely identifies the operation and resource, and the sibling tools include salesforce_read_apex_trigger and salesforce_write_apex, so it clearly distinguishes an Apex-trigger-specific write tool from read or generic write alternatives.
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 clearly delimits usage by operation: create requires triggerName, objectName, and body; update requires triggerName and body. It also notes that apiVersion is optional and defaults to latest. While it does not explicitly name alternatives or exclusions, the operation-specific requirements and examples provide secure context for when to use each mode.
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, the description carries the full burden of behavioral disclosure. It discloses a key side effect: 'Automatically grants Field Level Security to System Administrator (or specified profiles).' It also lists the operations (create/update) and relationship behaviors. It does not mention potential destructive aspects (e.g., updating an existing field could overwrite configuration), but the description is reasonably transparent for a tool of this complexity.
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 structured with a clear opening statement, bulleted capabilities, and examples. It is longer than a two-sentence description but every section adds relevant information. The formatting improves scannability, and there is no redundant repetition of schema details.
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 (18 parameters, no output schema), the description covers the main aspects: field types, properties, relationships, FLS side-effect, and examples. It lacks a description of return values or error behavior, but for a management tool with rich input schema, the description is sufficiently complete.
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 schema covers 100% of parameters, so the baseline is 3. The description adds value by explicitly linking parameters to use cases, such as 'Use grantAccessTo parameter to specify profiles, defaults to System Administrator,' and providing examples that illustrate how parameters (e.g., type, objectName, fieldName) combine. It does not explain every parameter but enriches the schema with practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Create new custom fields or modify existing fields on any Salesforce object.' It also lists capabilities (field types, properties, relationships) and gives concrete examples ('Add Rating__c picklist to Account'), distinguishing it from sibling tools like salesforce_manage_object (which manages objects) and salesforce_manage_field_permissions (which handles FLS).
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 implies its use case (when you need to create or update custom fields) and mentions the auto-granting of FLS, which clarifies its relationship to salesforce_manage_field_permissions. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions, though the context signals (e.g., 'Create Account lookup on Custom Object') effectively guide usage.
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, the description carries the full burden of disclosing behavior. It states that code is executed in an anonymous context, does not persist, and returns compilation/success/failure and debug logs. It also mentions security restrictions. However, it does not explicitly warn about potential persistent side effects from DML operations (e.g., updates), which would be a useful caution for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with examples and notes. While some notes repeat schema details (e.g., 'apexCode parameter is required' and 'logLevel parameter is optional'), the examples add practical value and the additional notes (persistence, execution results, security) are informative. Every section earns its place, but it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two params and no output schema, the description is thorough. It covers purpose, examples for multiple levels of complexity, execution results, security considerations, and use cases. It clearly explains fallback scenarios relative to sibling tools. This is complete enough for an agent to decide when and how to use it effectively.
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 schema already covers both parameters with descriptions. The description adds value by providing concrete examples of apexCode usage, explaining that logLevel defaults to DEBUG, and noting the apexCode parameter is required. This goes beyond the schema's basic descriptions and helps the agent understand practical usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Execute anonymous Apex code in Salesforce.' It specifies the resource (Apex code) and the action (execute anonymously). It also distinguishes itself from siblings by noting it's a general fallback for data operations or queries not directly supported by other tools.
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: 'when there are no other specific tools available' and for requests 'not directly supported by other tools.' It does not name specific alternative tools or explicitly state when not to use it, but the context is clear. Security restrictions are also noted.
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, the description carries the full burden. It discloses key behaviors: operation restrictions, required fields, apiVersion default, body validity, className matching, and return of status info. This is substantial transparency, though it could also mention side effects like overwriting existing classes or permission requirements.
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 well-structured with a clear opening line, two illustrative examples, and concise notes. Every sentence provides useful information without redundancy. The length is appropriate for a tool with two operation modes and multiple validation rules.
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?
The description covers the core functionality, examples, validation rules, and return status. While no output schema exists, the description adequately describes what the tool returns. It could be more complete by addressing error cases or authentication, but for a create/update tool with this complexity, it is sufficiently complete.
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?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete examples, clarifying that apiVersion is optional and defaults to the latest, and highlighting the constraint that className in the body must match the className parameter. This extra context justifies a 4.
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 starts with a specific verb+resource: 'Create or update Apex classes in Salesforce.' This clearly distinguishes from siblings like salesforce_read_apex (read) and salesforce_write_apex_trigger (triggers).
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 clearly implies when to use the tool: when creating or updating Apex classes. It provides operation-specific guidance (create vs update) and notes about required/optional parameters. However, it does not explicitly mention alternatives or when not to use this tool, which prevents a 5.
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 states that 'The tool validates that the specified user exists before performing operations' and 'If logLevel is not specified when enabling logs, the tool will ask for clarification.' It also discloses defaults and operation-specific behaviors. However, it does not describe side effects (e.g., whether disabling removes prior configurations) or response formats, which are minor gaps.
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 well-structured with an introductory line, four concrete examples, and a bulleted list of notes. Every part adds value, and the content is front-loaded with the main purpose. It is appropriately sized for the complexity of the tool with no redundancy.
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?
The description is comprehensive for a tool with 7 parameters and no output schema. It covers all operations, parameters, defaults, and behavioral nuances. The only missing piece is a description of the output/return format, which would be helpful for an agent to invoke it fully, but given the absence of an output schema, the description is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already provides 100% parameter coverage, the description adds significant meaning beyond the schema. It explains operation-specific parameter usage, defaults, and examples. For instance, it clarifies that logLevel is required for 'enable' and lists all valid log levels. This enriches the schema definitions.
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: 'Manage debug logs for Salesforce users - enable, disable, or retrieve logs.' It uses a specific verb and resource, and the examples clarify each operation. The tool is distinct from its siblings (e.g., query, DML, Apex) by focusing on debug log management.
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 guidance on when to use each operation through examples and notes, including parameter requirements and defaults (e.g., 'logLevel is optional (defaults to DEBUG)' and 'limit is optional for retrieve'). It does not explicitly mention alternatives or when not to use the tool, but the operations are well-specified.
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 burden of behavioral transparency. It does disclose relationship query nuances (dot notation, subqueries, __r suffixes) but does not explicitly state whether the operation is read-only, what permissions are needed, or any limits/timeout behavior. 'Query' implies a read, but not all behavioral traits are covered.
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 long but every section earns its place: a clear purpose sentence, a critical exclusion note, four varied examples, and a concise summary of relationship field rules. The structure front-loads the main idea and then layers detail logically. Nothing is redundant or filler.
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 moderately complex tool with no output schema and no annotations, the description covers essential query construction, relationship semantics, and aggregate query alternatives. It does not explicitly describe the shape of the returned records, but that is generally implicit for a query tool. The examples and notes provide enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100% (baseline 3), the description adds substantial meaning beyond schema property descriptions. It provides detailed multi-level query examples for fields, explains how to construct relationship queries in whereClause, and introduces conventions like dot notation and subqueries that are not captured in the schema. This is exceptional parameter-level guidance.
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 opens with a specific verb-resource-scope statement: 'Query records from any Salesforce object using SOQL, including relationship queries.' It clearly distinguishes itself from sibling salesforce_aggregate_query by explicitly naming the alternative for aggregate queries, and from other tools like describe or search.
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 explicitly states when NOT to use this tool: 'For queries with GROUP BY, aggregate functions (COUNT, SUM, AVG, etc.), or HAVING clauses, use salesforce_aggregate_query instead.' This directly guides tool selection among siblings. Examples also clarify use cases for parent-child and child-parent queries.
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, the description carries the transparency burden. It discloses important behavioral details: SOSL syntax, wildcard support, per-object WHERE/ORDER BY/LIMIT, WITH clause types, and access filtering via updateable/viewable. It stops short of stating read-only nature explicitly, but 'search' strongly implies it. Overall, it provides above-average transparency.
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 longer than a minimal one, but the length is justified by the tool's complexity. It is front-loaded with a clear purpose, followed by structured examples and a concise bullet list of notes. Every section adds value, though some redundancy exists (e.g., wildcards are mentioned twice).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested object parameters and optional WITH clauses. The description covers the multidimensional usage thoroughly with examples, notes, and feature lists, providing enough context for an agent to construct valid invocations. Given no output schema, the description is sufficiently complete for this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a solid baseline. The description goes beyond the schema by including two detailed examples that show how objects, withClauses, and wildcards are used together, and it clarifies the meaning of updateable/viewable. This significantly enriches parameter understanding.
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 opens with a precise statement: 'Search across multiple Salesforce objects using SOSL (Salesforce Object Search Language).' This clearly identifies the tool's action, resource, and scope, and distinguishes it from sibling tools like salesforce_search_objects and salesforce_query_records by emphasizing multi-object SOSL search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is for searching across multiple objects, with examples showing the expected structure. However, it does not explicitly reference alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It clearly explains that className returns the full body, namePattern returns matching names without body, includeMetadata adds metadata, and wildcard behavior is specified. This is comprehensive for a read 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 well-structured with examples and notes. While slightly verbose, every example serves a purpose and the notes clarify behavior. The front-loaded main sentence followed by illustrative examples makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by explaining return behavior for every parameter scenario. It also covers edge cases (no parameters, wildcards) and metadata inclusion. This fully equips an agent to know what to expect from each call.
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?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful value beyond the schema by providing examples of combinations, explaining wildcard usage, and clarifying what output to expect for each parameter. This enriches understanding beyond the basic property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read Apex classes from Salesforce.' It uses a specific verb ('read') and resource ('Apex classes'), and distinguishes from sibling tools like salesforce_write_apex and salesforce_read_apex_trigger by focusing specifically on Apex classes.
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 thorough guidance on when to use each parameter combination (className, namePattern, includeMetadata), including what happens when neither is provided. It lacks explicit mention of when to prefer this tool over alternatives, but the name and context make this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description carries the full burden effectively. It discloses exactly what is returned for each parameter combination: full body for triggerName, names only for namePattern, metadata flag, and behavior when neither is provided. Wildcard semantics are also spelled out, giving complete behavioral 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 well-structured with an overview, four illustrative examples, and a list of notes. Every section contributes meaningful information without fluff. It's appropriately sized for a tool with 3 parameters and no output schema, and information is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description explains what the tool returns in every scenario, including specific trigger bodies, matching names, and metadata fields. It also covers wildcard support and default behavior, making it comprehensive for a read-only tool.
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?
Schema coverage is 100% with clear descriptions for each parameter. The description adds value beyond the schema by clarifying interactions (e.g., triggerName takes precedence, namePattern returns names only) and providing concrete examples of wildcard usage. This enhances parameter semantics without being redundant.
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 opens with 'Read Apex triggers from Salesforce,' using a specific verb and resource. It clearly differentiates from siblings like salesforce_read_apex (likely Apex classes) and salesforce_write_apex_trigger (write operation). The detailed examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives comprehensive examples for when to use triggerName vs namePattern vs neither, with notes on wildcards and metadata. However, it lacks explicit comparison to alternative tools (e.g., 'use salesforce_read_apex for classes'), so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses critical rules: non-aggregate selectFields must be in groupByFields, ORDER BY limits, OFFSET unsupported with GROUP BY, and the distinction between row-level vs group-level filtering. This goes beyond schema details to expose real 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?
Despite its length, the description is excellently structured with a purpose statement, alternative-tool note, numbered examples covering each feature, and an 'Important Rules' list. Every section is useful; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters and no output schema, the description covers all relevant aspects: what it does, when to use it, parameter semantics, behavioral constraints, and representative examples. The absence of return-value details is acceptable given no output schema and the query nature.
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?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by providing concrete examples of selectFields with aliases (e.g., 'COUNT(Id) OpportunityCount') and how groupByFields handle related objects and date functions. These clarify parameter formatting far better than the schema alone.
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?
Description opens with a specific verb-resource pair: 'Execute SOQL queries with GROUP BY, aggregate functions, and statistical analysis.' It clearly scopes the tool to summarizing/grouping queries and explicitly distinguishes it from salesforce_query_records for regular queries.
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?
Provides explicit guidance: 'For regular queries without GROUP BY or aggregates, use salesforce_query_records instead.' Also explains when to use whereClause vs havingClause (before vs after grouping), and enumerates supported grouping scenarios and examples.
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-server-salesforce MCP server](https://glama.ai/mcp/servers/JereSalguero30/mcp-server-salesforce/badges/card.svg)](https://glama.ai/mcp/servers/JereSalguero30/mcp-server-salesforce)

Score Badge

Copy to your README.md:

[![mcp-server-salesforce MCP server](https://glama.ai/mcp/servers/JereSalguero30/mcp-server-salesforce/badges/score.svg)](https://glama.ai/mcp/servers/JereSalguero30/mcp-server-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/JereSalguero30/mcp-server-salesforce'

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