Salesforce MCP Server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose. Potentially overlapping tools like salesforce_query_records and salesforce_aggregate_query are well-documented to differentiate use cases, and others like salesforce_run_analytics vs salesforce_rest_api have clear scope delineations.
Naming Consistency5/5
All tools follow a consistent salesforce_verb_noun pattern using snake_case. The naming is predictable and descriptive, e.g., salesforce_query_records, salesforce_dml_records, salesforce_write_apex.
Tool Count5/5
20 tools cover a broad yet focused range of Salesforce operations including CRUD, queries, metadata management, analytics, and Apex. The count is well-scoped for a comprehensive integration server.
Completeness4/5
The tool set covers essential CRM operations (CRUD, SOQL, SOSL, metadata, analytics, Apex) and includes a REST API passthrough for any gaps. Minor omissions like bulk API support exist, but the surface is otherwise thorough.
Average 4.2/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool searches by name pattern with substring matching, but does not disclose case sensitivity, wildcard support, or whether it returns API names or labels. The behavior is basic but not exhaustive.
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?
Two concise sentences with a clear, front-loaded purpose and an illustrative example. Every word adds value without redundancy.
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 simple search tool with well-documented parameters, the description is adequate. However, without an output schema, it does not specify the return structure (e.g., list of object names or full details). The lack of output description is a gap.
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 coverage is 100%, so the schema already documents all parameters. The description does not add significant extra meaning beyond the schema; it provides an example in the main description but the parameter descriptions in the schema are already clear.
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 action ('Search for Salesforce standard and custom objects'), the method ('by name pattern'), and provides concrete examples. It distinguishes itself from siblings like salesforce_query_records (which searches data) and salesforce_describe_object (which describes a specific object).
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 by giving examples, but it does not explicitly state when to use this tool versus alternatives like salesforce_search_all or the description tools. No guidance on prerequisites or limitations is provided.
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 provided, so description carries full burden. It discloses automatic field level security granting but does not mention rate limits, destructive potential of updates, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and uses bullet points for readability, but could be slightly more compact. Front-loaded with purpose.
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 complexity and 18 parameters, the description covers key aspects including field types, properties, and relationships. Lacks return value specifications but acceptable without output schema.
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 coverage is 100%, so baseline is 3. The description adds context like API name conventions and profile access defaults, but mostly reinforces schema information.
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 creates or modifies custom fields on Salesforce objects, with specific examples and a list of supported field types. It distinguishes itself from sibling tools by focusing on field 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 includes explicit use cases (create/modify fields) and notes default profile behavior. It lacks explicit 'when not to use' but is clear in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention potential side effects (e.g., mutations from POST/PUT/DELETE), authentication requirements, rate limits, or other important behaviors. This is a significant gap for a generic passthrough 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 well-structured with a clear opening statement, numbered examples, and bullet points. While it is somewhat lengthy, each section adds value. It is appropriately front-loaded with the main purpose.
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 complexity (6 parameters, no output schema, many sibling tools), the description provides extensive examples and clarifies endpoint construction. It covers key usage scenarios comprehensively, though it lacks information on response format and error handling.
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 already describes all 6 parameters with 100% coverage. The description adds value by explaining relative paths, rawPath behavior, and providing concrete examples for parameters like apiVersion and rawPath, going beyond 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: 'Make direct REST API calls to any Salesforce REST endpoint.' It differentiates from siblings by noting it covers endpoints not handled by other tools, and provides numerous examples of specific APIs.
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 explicitly instructs to use this tool for any Salesforce REST API without a dedicated tool, and lists many such APIs. However, it does not explicitly state when not to use it (e.g., preferring dedicated tools when available), though this is implied.
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. It discloses that updateable/viewable parameters will return errors and explains wildcard support and WITH clauses. However, it does not state whether the tool is read-only or mention authentication/rate limits.
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, but is somewhat lengthy. It front-loads the purpose and arranges information logically, though some redundancy exists.
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 no output schema and the tool's complexity, the description adequately covers usage scenarios. It explains SOSL specifics and provides enough detail for an agent to invoke the tool correctly, though return format is not described.
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 parameters are already documented. The description adds value by showing example usage patterns, explaining that each object can have its own WHERE/ORDER BY/LIMIT, and clarifying the reserved parameters' behavior.
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 it uses SOSL to search across multiple Salesforce objects, which distinguishes it from siblings like salesforce_query_records (SOQL) and salesforce_search_objects (likely simpler). The verb 'search' and resource 'multiple Salesforce objects' are specific.
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 provides examples and notes about reserved parameters, but lacks explicit guidance on when to use this tool vs alternatives like salesforce_query_records or salesforce_search_objects. Usage is implied rather than stated.
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?
Discloses that operation requires valid Apex code and className must match body, and status information is returned. However, with no annotations, it should also cover authentication needs, rate limits, or error handling. Missing details on side effects like overwriting existing classes.
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?
Well-structured with sections for description, examples, and notes. Front-loaded with purpose. Slightly lengthy due to examples but every sentence adds value. Could be slightly more concise.
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?
Input schema is rich with 100% coverage. Description addresses key constraints and return status. Missing output schema details, but overall complete for a complex tool with 4 params. Could elaborate on error scenarios.
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 3. Description adds significant value by explaining required vs optional, defaults (apiVersion defaults to latest), and constraints (className match). Examples further clarify parameter 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?
Clearly states 'Create or update Apex classes in Salesforce' with specific verb+resource. Distinguishes from siblings like salesforce_read_apex and salesforce_write_apex_trigger by focusing on Apex classes and providing examples.
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?
Implies usage via create/update operations but lacks explicit guidance on when to choose this tool over alternatives (e.g., for triggers vs classes). No exclusion statements or context for selecting this among siblings.
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?
The description discloses that operations modify data, requires Id for update/delete, and mentions external ID for upsert. However, it does not cover permissions, rate limits, or side effects, and there are no annotations to supplement.
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 as a bullet list with clear operation explanations and examples. It is reasonably concise, though examples could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input parameters well but lacks information about the return value (success/error structure) and potential error cases. This is a gap given there is no output schema or annotations.
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 by explaining each operation option and providing examples, which clarifies usage beyond the schema 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 performs data manipulation (insert, update, delete, upsert) on Salesforce records. It distinguishes itself from sibling query/search tools by focusing on write 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 for DML operations but does not explicitly state when to use this tool versus alternatives like query_records or search. No when-not guidance is provided.
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 must cover behavioral traits. It describes the output but does not disclose authorization needs, rate limits, or side effects. The read-only nature is implied but not explicit.
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-organized with separate sections for reports and dashboards, plus examples. It is concise yet informative, with no wasted sentences.
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 no output schema, the description explains what is returned for each type adequately. It covers key details but could mention error conditions or edge cases.
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 describes both parameters (type and resourceId). The description adds value beyond the schema by providing examples and clarifying the ID format and the two possible types.
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 it gets detailed metadata for Salesforce reports or dashboards, specifying the exact metadata returned for each type. This differentiates it from sibling tools like salesforce_run_analytics and salesforce_describe_object.
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 explicitly says to use this before running a report with salesforce_run_analytics, providing clear context. It lacks explicit exclusion or alternatives but is sufficient for 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?
With no annotations, the description must disclose behavior. It lists operations and mentions bulk updates, but lacks details on side effects (e.g., overwriting existing permissions), required permissions (e.g., ModifyAllData), or error conditions. The description 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?
Description is concise and well-structured with bullet points, examples, and clear separation of operations. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers operations and examples, but lacks details on return output for 'view' operation, error handling, prerequisites (permissions), and behavior when profiles overlap. Given the tool's complexity (6 params, multiple operations), more context is needed for full completeness.
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 covers all 6 parameters with descriptions (100% coverage), so baseline is 3. The description adds value by providing examples that reinforce parameter usage (e.g., listing profiles as array) and mentioning bulk updates, which goes beyond 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 clearly states the tool manages field-level security, listing operations (grant, revoke, view) and mentioning custom/standard fields. This distinguishes it from sibling tools like salesforce_manage_field which deals with field creation/deletion, not permissions.
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?
Description provides three concrete examples illustrating common use cases (grant admin access, give read-only, check access). While it doesn't explicitly state when not to use or alternatives, the examples give clear context for usage.
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?
Notes that changes affect metadata and require proper permissions, which adds some behavioral context. But without annotations, it does not fully disclose potential risks like destructiveness of updates, rate limits, or error handling behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, uses bullet points for clarity, and includes examples and a note on permissions. Every sentence serves a purpose with no redundancy.
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?
Covers the main operations and prerequisites but lacks details on return values, error scenarios, or behavior of optional parameters. Given the complexity of 9 parameters and no output schema, more context would be beneficial.
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?
With 100% schema coverage, the description adds value by grouping operations, providing examples of usage (e.g., 'Create Customer_Feedback__c object'), and clarifying context beyond the schema (e.g., API name without __c suffix is implied).
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 it creates or modifies custom objects in Salesforce, lists specific operations (Create and Update), and differentiates from sibling tools like salesforce_manage_field or salesforce_describe_object.
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 modifying custom objects) and gives examples. However, lacks explicit guidance on when not to use it or mention of alternatives like salesforce_manage_field for field-level changes.
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 behavioral transparency. It discloses the create/update distinction, parameter requirements, and that status info is returned. However, it does not mention potential side effects (e.g., overwriting existing triggers), authorization needs, or error scenarios, leaving some 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 a brief purpose statement, two illustrative examples, and a bulleted list of notes. It is concise with no redundant information and front-loads the most important 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 lack of output schema, the description only mentions 'status information is returned' without detailing the response structure or error handling. With 5 parameters and a fairly complex operation (create vs update), more detail on outputs and edge cases would improve completeness.
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 for all 5 parameters, providing clear definitions. The description adds value by giving concrete examples and clarifying conditional requirements (e.g., objectName needed only for create). This extra context justifies a score above the baseline of 3.
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 clear verb and resource: 'Create or update Apex triggers in Salesforce.' This directly states what the tool does and distinguishes it from sibling tools like salesforce_read_apex_trigger (read-only) and salesforce_write_apex (write 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 explicit guidance on when to use 'create' vs 'update' through notes and examples, listing required parameters for each. While it does not explicitly compare to other tools, the purpose and sibling context imply its unique role for trigger write operations.
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 provided. Description implies a read-only operation but does not disclose permissions, side effects, or safety.
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?
Two concise sentences that front-load purpose and provide helpful examples. No superfluous content.
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 no output schema, description adequately explains what is returned. Could mention format, but completeness is sufficient for a describe 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 covers parameter fully. Description adds value with concrete examples and hints at relationships, aiding correct 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 it retrieves detailed schema metadata including fields, relationships, and field properties. Examples differentiate it from sibling tools like query 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for metadata retrieval but does not explicitly state when not to use it or provide alternatives.
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?
No annotations are provided, so the description fully carries the behavioral disclosure burden. It covers user existence validation, default parameter values, and notes that the tool will ask for clarification if logLevel is missing for enable. However, it does not describe potential side effects like performance impact or what happens to existing logs on disable.
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 a clear purpose statement, followed by numbered examples and bulleted notes. Every section serves a purpose, though the number of examples could be slightly trimmed. Overall, it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the tool's return value or response format, especially critical for the retrieve operation (e.g., what the retrieved logs look like). No output schema exists to compensate, leaving a significant gap in completenss.
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?
The input schema covers 100% of parameters with descriptions, but the description adds significant value by providing examples that illustrate parameter combinations, defaults, and dependencies (e.g., logLevel required for enable, logId for retrieve). This goes beyond 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?
The description clearly states 'Manage debug logs for Salesforce users - enable, disable, or retrieve logs.' This specifies the verb (enable/disable/retrieve) and resource (debug logs for users), distinguishing it from sibling tools that handle queries, DML, analytics, etc.
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 examples and notes detailing when to use each operation (enable, disable, retrieve), required parameters, and default values. While it does not explicitly list alternatives or when not to use this tool, the context is sufficient given the sibling tool names.
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 full burden. It discloses that code executes anonymously and does not persist, debug logs are optional, and results include compilation/execution status. It implies DML effects ('data operations or updates') but does not explicitly state that data changes persist, which is a minor gap.
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, but slightly verbose. It earns its length by covering usage, parameters, and behavior, though it could be slightly trimmed without losing clarity.
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 no output schema, the description explains return values (execution results, debug logs). Parameters are fully covered. It could elaborate on error types or detailed restrictions, but overall provides sufficient context for a complex 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%, baseline 3. Description adds value by providing examples, noting apexCode must be valid Apex, and explaining the optional logLevel defaults to DEBUG, which enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute anonymous Apex code in Salesforce' with multiple examples and explicitly distinguishes this tool as a fallback when no other specific tool supports the user's request. It covers both data queries and updates.
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 advises using this tool for operations not supported by other tools and explains the anonymous context and security restrictions. However, it does not explicitly list when not to use it, but the fallback guidance is clear.
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?
Without annotations, the description carries the full burden. It clearly explains the read-like behavior (listing items, filtering, returning metadata) and implies no destructive actions. However, it does not mention authentication 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?
Description is concise and well-structured: a clear opening line, usage guideline, and bulleted examples. Every sentence is informative and earns its place.
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 simple list operation with two parameters and no output schema, the description is largely complete. It explains the purpose, usage, and sample scenarios. Minor omission: no mention of pagination or result limits, but this is acceptable for the tool's simplicity.
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?
Input schema has 100% description coverage. The description reiterates the parameter meanings but does not add new information beyond the schema. 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 lists Salesforce reports or dashboards and returns IDs, names, and metadata. It distinguishes itself from siblings by explicitly mentioning it is used to find IDs before describing or running them with related tools.
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 tells when to use this tool ('to find IDs') and provides alternative tools ('salesforce_describe_analytics', 'salesforce_run_analytics'). It also gives concrete examples covering typical use cases.
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?
Describes pagination behavior (default 200, limit/offset, not snapshot-consistent, stable pagination advice) and relationship query syntax. No annotations provided, so description carries burden; could mention read-only nature but covers key behaviors.
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?
Well-structured with brief intro, note on alternative, pagination details, examples, and syntax notes. Front-loaded with purpose. Could be slightly more concise but every part adds value.
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?
Covers input thoroughly but lacks explicit description of return format (though mentions total record count and next offset). No output schema; for a query tool, typical Salesforce response is expected but not documented.
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 has 100% coverage with descriptions, but description adds practical examples for each parameter (e.g., whereClause with relationships, limit/offset for pagination). Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries records from any Salesforce object using SOQL, including relationship queries. It distinguishes itself from sibling tool salesforce_aggregate_query by specifying when to use that instead.
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 not to use this tool (for GROUP BY, aggregate functions, HAVING) and directs to salesforce_aggregate_query. Provides pagination guidance and relationship query usage notes.
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?
No annotations are provided, so the description carries full burden. It discloses key behaviors: triggerName returns the full body, namePattern returns names without body, wildcard support, includeMetadata effect, and default behavior when no parameters are given. It does not cover rate limits or authentication, but these are implicit in Salesforce API context. The description adds value beyond the input schema.
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 separate sections for examples and notes. It is somewhat lengthy but every part adds value. Could be slightly more concise, but the clarity from examples justifies the 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?
Although there is no output schema, the description clarifies return formats (full body vs. names, metadata inclusion). It also mentions limit and offset for pagination, though not in detail. Error handling is not covered, but for this tool, the description is sufficiently complete to guide an agent.
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%, and the description adds significant meaning: it explains the difference between triggerName (returns full body) and namePattern (returns names only), wildcard usage, and the effect of includeMetadata. Examples also illustrate usage patterns. This goes well beyond the schema 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 verb 'Read' and resource 'Apex triggers from Salesforce'. It distinguishes from sibling tools like salesforce_read_apex (read Apex classes) and salesforce_write_apex_trigger (write triggers) by focusing on triggers and read-only operation. Examples further clarify the scope.
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 triggerName (specific trigger with full body), namePattern (listing with pattern), or neither (list all). It explains the outcomes for each scenario, but does not explicitly state when not to use this tool or mention alternatives like SOQL queries. Still, the usage context is well-defined.
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, the description fully discloses behavior: it states the difference between returning full body vs names only, metadata inclusion, wildcard support, and default pagination. No contradictions.
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 sentence, numbered examples, and bullet-point notes. Every sentence adds value, and there is no redundancy. It is appropriately sized for the tool's complexity.
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?
With no output schema, the description describes return values vaguely (full body, names, metadata). It covers the essentials but could be more precise about the exact structure. Nevertheless, given the examples, it is sufficient for an agent to understand the output.
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?
Despite 100% schema coverage, the description adds significant value by explaining interactions between parameters (e.g., className vs namePattern behavior), wildcard syntax, and default values. This goes beyond the schema's individual 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 starts with 'Read Apex classes from Salesforce,' which is a clear verb+resource. Examples show specific actions like reading by name, listing by pattern, and including metadata. This distinguishes it from siblings like salesforce_write_apex and salesforce_read_apex_trigger.
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 usage guidance through examples and notes, explaining when to use className vs namePattern, and the effect of includeMetadata. It does not explicitly mention when not to use or compare with other tools, but the context is fairly clear.
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 fully discloses behavior: refresh triggers a refresh and returns a status URL; status returns per-component status and data status. It does not cover permissions or side effects, but the tool is informational and non-destructive, so this is adequate.
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, with a clear purpose statement, two examples, and a notes section. Every sentence adds value without 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 tool with two simple parameters and no output schema, the description covers all necessary information: operations, usage, and post-action steps. It is complete and leaves no ambiguity.
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 through examples and notes, clarifying operation options and the dashboard ID format, but mostly repeats schema info. The examples provide practical context, earning a slightly higher score.
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 the tool's purpose: 'Refresh a Salesforce dashboard or check its refresh status.' It clearly distinguishes the two operations with examples, and differentiates from sibling tools like salesforce_run_analytics by noting its use after refresh.
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 clear usage guidance for both operations, including when to use each (refresh vs. status). It explicitly advises using salesforce_run_analytics to retrieve updated data, effectively guiding the agent on tool selection after refresh.
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?
Discloses that reports run synchronously, detail rows are capped at 2,000, aggregates always returned, and includes truncation warnings. For dashboards, it explicitly says no refresh is triggered. All key behaviors are stated.
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 fairly long but well-structured with clear sections for reports and dashboards, plus bulleted examples. Each sentence contributes useful information. Could be slightly more concise, but appropriate for complexity.
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?
Covers both resource types, all parameters with examples, and behavioral notes. No output schema exists, and the description does not detail return values, which is a minor gap. Overall very complete for the tool's complexity.
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 by explaining default behavior (includeDetails default false), cap on detail rows, and filter syntax. Examples demonstrate complex usage. However, the schema already provides good descriptions, so not a full 5.
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 it executes a Salesforce report or retrieves dashboard component data. It distinguishes between the two modes and references sibling tools like salesforce_refresh_dashboard for dashboard refresh.
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 on when to use reports vs dashboards. States that for dashboard refresh, one should use salesforce_refresh_dashboard. Examples cover common use cases and parameter combinations.
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?
Without annotations, the description fully discloses behavioral traits: it explains the query processing order, restrictions (e.g., no OFFSET with GROUP BY), and field inclusion rules. It also clarifies what the tool does not handle (regular queries). There is no contradiction with structured fields.
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 clear sections, bullet points, and numbered examples. It front-loads the core purpose and usage distinction. Every sentence adds value, and despite length, it is concise for the complexity of the tool.
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 the tool's complexity (7 parameters, no output schema), the description provides comprehensive coverage: examples for multiple use cases, important rules, and limitations. It sufficiently prepares an agent to use the tool correctly without needing external information.
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%, each parameter is described. The description adds significant meaning beyond the schema through detailed examples, formatting guidance (e.g., selectFields with aliases), and explanations of WHERE vs HAVING. This high-quality elaboration justifies above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes SOQL queries with GROUP BY and aggregate functions, contrasting with 'salesforce_query_records' for simple queries. It distinguishes by explicitly noting it's for summarizing data rather than returning individual records.
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 tells when to use this tool versus 'salesforce_query_records' and provides important rules for usage, such as requiring non-aggregate fields in GROUP BY, filtering order (WHERE before GROUP, HAVING after), and constraints on ORDER BY and OFFSET.
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/aaron-pienza/mcp-server-salesforce/badges/card.svg)](https://glama.ai/mcp/servers/aaron-pienza/mcp-server-salesforce)

Score Badge

Copy to your README.md:

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

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