Salesforce Object MCP Server

by davep-gh

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clear, distinct purposes, but get_object_details overlaps with list_fields and get_validation_rules by returning fields and validation rules as part of its comprehensive output. This creates minor boundary ambiguity, though descriptions help an agent choose between a targeted call and a comprehensive call.
Naming Consistency5/5
Every tool follows a consistent verb_noun snake_case pattern: list_, get_, find_, search_. The naming is predictable and makes the purpose of each tool immediately clear.
Tool Count5/5
Seven tools is well-scoped for a Salesforce metadata exploration server. Each tool covers a meaningful part of the domain without unnecessary bloat or obvious redundancy.
Completeness5/5
The surface covers the core metadata discovery workflow: listing objects, listing fields, getting field details, finding relationships, accessing validation rules, and searching metadata. For a read-only metadata exploration server, there are no significant gaps.
Average 3.6/5 across 7 of 7 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it lists fields but does not mention whether it is read-only, possible errors (e.g., invalid object name), pagination, or return format. For a list operation, the lack of any note about side effects or constraints leaves important behavioral information undisclosed.
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 sentence that immediately states the core action and the optional filter. There is no redundant text, and the most important information is front-loaded. It is appropriately concise for a tool with two parameters.
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 has only two parameters, no annotations, and no output schema, the description is relatively simple. However, it lacks explicit usage guidance relative to sibling tools and does not clarify expected behavior or error conditions. For a straightforward listing operation, it is minimally sufficient but not complete enough to warrant a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, and both objectName and fieldType are described in the schema. The description merely repeats the filter capability without adding new meaning. Per the baseline for high schema coverage, a score of 3 is appropriate; the description does not exceed the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists fields for a specific Salesforce object and optionally filters by type. It uses specific verbs and resources, which makes the purpose understandable. However, it does not explicitly differentiate from sibling tools like get_field_details or list_objects, so it earns a 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 mentions an optional filter but provides no guidance on when to use this tool versus alternatives. There is no mention of when to choose list_fields over get_field_details or list_objects, and no exclusions or contexts are stated. An agent would have to infer appropriate usage from the name and purpose alone.
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 behavioral burden. It does disclose a repository-scoped, read-only listing with optional filtering, which is the core behavioral profile. However, it adds nothing about pagination, returned item shape, ordering, or potential cost/scope of scanning the whole repository — gaps that matter for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, roughly 17 words, with the core action front-loaded in the first sentence and optional behaviors cleanly separated in the second. Every word earns its place; nothing is redundant or padded.
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 zero required parameters, the invocation surface is adequately covered: what it lists, where from, and both optional filters. But with no output schema, the description doesn't indicate what the returned object list contains, and it doesn't clarify when to prefer this over get_object_details. Adequate for a basic call, incomplete for confident self-service.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, including case-insensitive matching and the boolean default of true. The description's mention of filtering by pattern and excluding standard objects mildly reinforces the parameters but adds no new meaning beyond the schema. Baseline 3 applies.
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 states a specific verb (List) and a specific resource (Salesforce objects found in the repository), plus the two optional filtering behaviors. It distinguishes itself from siblings by resource type: list_fields targets fields, get_object_details targets a single object, find_relationships targets relationships, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its alternatives. The description never names a sibling (e.g., 'use get_object_details for a single object's details') or states a condition that should route an agent elsewhere. The filtering mention is parameter usage, not tool-selection 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates that this is a read-only retrieval operation and indicates the kinds of fields returned. However, it does not disclose potential pagination, permission requirements, error behavior, or whether the result is a list of all rules or filtered by some default.
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?
A single, front-loaded sentence with no filler. It states the action, the target resource, and the key content of the result efficiently. Every part of the sentence 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?
This is a simple one-parameter read-only tool with no output schema. The description says what the tool returns (validation rules including formulas, error messages, and active status), which is enough for an agent to invoke it correctly. It could add details about output shape or edge cases, but for this complexity level the description is largely 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 input schema already describes objectName as 'API name of the object', so schema coverage is 100%. The description adds nothing about parameter syntax or behavior beyond restating that the tool applies to 'an object'. Baseline 3 is appropriate because the schema carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a specific resource ('validation rules for an object'), and the content scope ('formulas, error messages, and active status'). This clearly distinguishes it from sibling tools like list_fields, get_field_details, or find_relationships, which deal with different metadata.
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?
There is no guidance on when to choose this tool over its siblings, nor any mention of alternatives or exclusions. The purpose is clear, but the description does not help an agent decide between get_validation_rules and other metadata-listing tools in the sibling set.
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 explaining behavior. It does clarify the direction semantics (outgoing vs incoming), but it omits other behavioral traits such as whether results are paginated, what fields are returned, or any required permissions. For a read-only tool, the lack of mutation is implied but not explicitly disclosed.
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?
A single well-structured sentence that front-loads the tool's primary purpose and then explains the key option (direction). Every part of the sentence contributes value with no repetition or filler.
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 input side is complete with a required objectName and an enumerated direction parameter with a default. However, there is no output schema and the description does not explain what the returned relationship data looks like. Given the tool's simplicity, this is a moderate gap rather than a critical one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented well in the schema. The description's explanation of outgoing and incoming relationships adds a little context, but largely restates the schema text, keeping this at 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 states a specific verb ('Find') and resource ('relationships for an object'), and further clarifies what outgoing and incoming relationships mean. This clearly distinguishes it from sibling tools like list_fields and get_object_details, which focus on other metadata aspects.
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 when to use it—when an agent needs relationship information for an object—but it does not explicitly mention alternatives or state when not to use it. With siblings that are all metadata-related, the intended use case is inferable but not directly contrasted.
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 description clearly frames the tool as a non-destructive metadata search and enumerates the content areas it covers. With no annotations, the description carries some behavioral burden, but it does not mention result-set behavior, search matching semantics, pagination, or access 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?
Two short sentences with no filler. The main action is front-loaded, and the second sentence adds valuable detail about what is being searched without repeating the schema.
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?
Inputs are fully documented by the schema, and the description explains what content is searched. However, there is no output schema and no description of what the search returns, which leaves the result shape and semantics somewhat unspecified for a tool that produces results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a helpful list of metadata types but provides no additional meaning for the query or scope parameters beyond what the schema already states.
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?
Names the exact operation ('Search'), the full resource ('all metadata'), and the dimensions searched (object names, labels, field names, descriptions, formulas). This makes it clearly distinct from the sibling list/get tools, which are narrower browsing or detail 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 use when you need keyword-based discovery across many metadata types, and the sibling names reinforce that this is the cross-cutting search option. However, it does not explicitly state when to use this vs list_fields/get_object_details, or when not to use 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 must carry the behavioral burden. It does convey that this is a read-only information retrieval and specifies the categories of information returned, but it remains silent on failure behavior, authentication requirements, or whether relationship details are recursive or limited.
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?
A single front-loaded sentence that states the resource and then lists the returned attribute categories. No filler or repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read tool with no output schema, the description's enumeration of returned details is a reasonable completeness signal. However, it would be more complete with a note about the tool's relationship to find_relationships or about error handling.
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 documentation covers 100% of parameters with clear definitions ('API name of the field' and 'API name of the object'), so the baseline is 3. The description adds no further parameter-level guidance such as naming conventions or required format.
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?
States a specific action ('Get detailed information about a specific field') with a concrete resource domain and enumerates the informational payload (type, length, formula, picklist values, relationships). This clearly separates it from list_fields and get_object_details by focusing on a single field's metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs detailed metadata for one named field, but it never names alternatives or exclusion conditions. Sibling tools like list_fields, find_relationships, and get_object_details overlap in surface area, so explicit routing would help.
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 the scope of the returned details (fields, validation rules, metadata) and 'Get' implies a read operation, but it does not explicitly state read-only behavior, permission requirements, or potential size/performance implications.
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 one compact sentence, front-loaded with the action and resource, and every word adds value. There is no repetition 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 simple single-parameter get tool with no output schema, the description adequately explains what is returned. It is missing only minor details such as error behavior for nonexistent objects, but is otherwise complete enough for correct 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 schema has 100% description coverage for the single parameter 'objectName', including an example format. The tool description adds no additional parameter-specific meaning, matching 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 uses a specific verb ('Get') and resource ('specific Salesforce object') and clearly states what is included ('all fields, validation rules, and metadata'). This distinguishes it from sibling tools that target narrower concerns like list_fields or get_validation_rules.
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 use when comprehensive object-level detail is needed, but it does not explicitly name sibling tools or state when to prefer a more specific tool. Guidance is implied, not explicit.
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:

[![SFObjectMCP MCP server](https://glama.ai/mcp/servers/davep-gh/SFObjectMCP/badges/card.svg)](https://glama.ai/mcp/servers/davep-gh/SFObjectMCP)

Score Badge

Copy to your README.md:

[![SFObjectMCP MCP server](https://glama.ai/mcp/servers/davep-gh/SFObjectMCP/badges/score.svg)](https://glama.ai/mcp/servers/davep-gh/SFObjectMCP)

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/davep-gh/SFObjectMCP'

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