Skip to main content
Glama
mattmahowald

Salesforce MCP Server

by mattmahowald
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Server Quality Checklist

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

  • Latest release: v1.0.0

  • Disambiguation5/5

    Each tool has a clearly distinct purpose with no overlap: describe provides metadata for a specific object, list_objects enumerates all available objects, and query executes data retrieval. An agent can easily differentiate between these three functions.

    Naming Consistency5/5

    All tools follow a consistent snake_case pattern with a 'salesforce_' prefix and clear verb_noun structure (describe, list_objects, query). This uniformity makes the tool set predictable and easy to understand.

    Tool Count2/5

    With only 3 tools, the server feels thin for a Salesforce integration, lacking essential CRUD operations like create, update, or delete. While the tools cover metadata and querying, the absence of data manipulation limits its utility for typical agent workflows.

    Completeness2/5

    The tool surface is severely incomplete for a Salesforce domain, missing core operations such as inserting, updating, or deleting records. Agents will hit dead ends when trying to perform basic data modifications, making this server inadequate for comprehensive Salesforce interactions.

  • Average 3/5 across 3 of 3 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

  • Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.

    If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.

    MCP servers without a LICENSE cannot be installed.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns field information, which implies a read-only operation, but doesn't clarify permissions, rate limits, error handling, or what 'Describe' entails beyond the output. For a tool with zero annotation coverage, this is inadequate, scoring 2.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and outcome, making it easy to parse. Every word earns its place, scoring 5.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's complexity (describing Salesforce objects), the description is minimal but functional. The presence of an output schema reduces the need to explain return values in the description. However, with no annotations and low parameter coverage, it lacks details on usage and behavior, making it barely adequate, scoring 3.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters2/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    The input schema has 1 parameter with 0% description coverage, meaning the parameter 'args' is undocumented in the schema. The description adds no information about parameters, such as what 'args' should contain or how to specify the SObject. It fails to compensate for the low schema coverage, scoring 2.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb ('Describe') and resource ('an SObject'), specifying what the tool does. It distinguishes from sibling tools like 'salesforce_list_objects' (which lists objects) and 'salesforce_query' (which queries data) by focusing on metadata/field information. However, it doesn't explicitly mention the sibling differentiation, keeping it at 4 rather than 5.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    The description provides no guidance on when to use this tool versus alternatives like 'salesforce_list_objects' or 'salesforce_query'. It doesn't specify prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone. This is minimal guidance, scoring 2.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    With no annotations, the description carries full burden but only states the basic action and output format. It lacks critical behavioral details: whether this is read-only or mutative, authentication requirements, rate limits, error handling, or pagination for large result sets. The description is minimal and doesn't compensate for the absence of annotations.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and outcome, making it easy to parse. Every word earns its place, though it may be overly concise given the tool's complexity.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's complexity (executing queries in Salesforce), no annotations, and 0% schema coverage, the description is incomplete. However, the presence of an output schema mitigates the need to explain return values. The description covers the basic purpose but lacks sufficient context for safe and effective use without additional documentation.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters2/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, and the description provides no parameter information beyond implying 'args' is for the query. It doesn't explain what 'QueryArgs' contains (e.g., query string, filters), syntax examples, or constraints. The description fails to compensate for the low schema coverage, leaving parameters largely undocumented.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb ('Run') and resource ('SOQL query') with the outcome ('return JSON rows'). It distinguishes from siblings like 'salesforce_describe' and 'salesforce_list_objects' by focusing on query execution rather than metadata operations. However, it doesn't specify what type of data the query targets (e.g., objects, records).

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives like 'salesforce_describe' or 'salesforce_list_objects'. The description implies it's for executing queries but doesn't specify scenarios, prerequisites, or exclusions. The agent must infer usage from tool names alone.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior2/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries full burden. It states it 'gets' a list, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, or what the output includes (e.g., format, sorting). This is a significant gap for a tool with no annotation coverage.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand quickly.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness3/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and an output schema, it doesn't explain return values or behavioral context, leaving gaps in completeness for a read operation 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?

    The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but with no params, a baseline of 4 is appropriate as it doesn't need to compensate for gaps.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the verb 'Get' and the resource 'list of all Salesforce object names (SObjects)', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'salesforce_describe' or 'salesforce_query', which likely provide more detailed object metadata or query capabilities, preventing a perfect score.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance is provided on when to use this tool versus alternatives. The description doesn't mention contexts like needing a high-level overview vs. detailed metadata or querying, and there are no exclusions or prerequisites stated, leaving usage unclear relative to siblings.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

sfmcp MCP server

Copy to your README.md:

Score Badge

sfmcp MCP server

Copy to your README.md:

Latest Blog Posts

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/mattmahowald/sfmcp'

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