Skip to main content
Glama
julianboudara-code

mcp-server-salesforce

by julianboudara-code
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

salesforce_aggregate_query

Read-only

Summarize Salesforce records using SOQL aggregate queries with GROUP BY, COUNT, SUM, AVG, MIN, MAX, and HAVING clauses. Group data by standard fields, related objects, or date periods to produce analyzed totals.

Instructions

Execute SOQL queries with GROUP BY, aggregate functions, and statistical analysis. Use this tool for queries that summarize and group data rather than returning individual records.

NOTE: For regular queries without GROUP BY or aggregates, use salesforce_query_records instead.

This tool handles:

  1. GROUP BY queries (single/multiple fields, related objects, date functions)

  2. Aggregate functions: COUNT(), COUNT_DISTINCT(), SUM(), AVG(), MIN(), MAX()

  3. HAVING clauses for filtering grouped results

  4. Date/time grouping: CALENDAR_YEAR(), CALENDAR_MONTH(), CALENDAR_QUARTER(), FISCAL_YEAR(), FISCAL_QUARTER()

Examples:

  1. Count opportunities by stage:

    • objectName: "Opportunity"

    • selectFields: ["StageName", "COUNT(Id) OpportunityCount"]

    • groupByFields: ["StageName"]

  2. Analyze cases by priority and status:

    • objectName: "Case"

    • selectFields: ["Priority", "Status", "COUNT(Id) CaseCount", "AVG(Days_Open__c) AvgDaysOpen"]

    • groupByFields: ["Priority", "Status"]

  3. Count contacts by account industry:

    • objectName: "Contact"

    • selectFields: ["Account.Industry", "COUNT(Id) ContactCount"]

    • groupByFields: ["Account.Industry"]

  4. Quarterly opportunity analysis:

    • objectName: "Opportunity"

    • selectFields: ["CALENDAR_YEAR(CloseDate) Year", "CALENDAR_QUARTER(CloseDate) Quarter", "SUM(Amount) Revenue"]

    • groupByFields: ["CALENDAR_YEAR(CloseDate)", "CALENDAR_QUARTER(CloseDate)"]

  5. Find accounts with more than 10 opportunities:

    • objectName: "Opportunity"

    • selectFields: ["Account.Name", "COUNT(Id) OpportunityCount"]

    • groupByFields: ["Account.Name"]

    • havingClause: "COUNT(Id) > 10"

Important Rules:

  • All non-aggregate fields in selectFields MUST be included in groupByFields

  • Use whereClause to filter rows BEFORE grouping

  • Use havingClause to filter AFTER grouping (for aggregate conditions)

  • ORDER BY can only use fields from groupByFields or aggregate functions

  • OFFSET is not supported with GROUP BY in Salesforce

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of grouped results to return
orderByNoORDER BY clause - can only use grouped fields or aggregate functions
objectNameYesAPI name of the object to query
whereClauseNoWHERE clause to filter rows BEFORE grouping (cannot contain aggregate functions)
havingClauseNoHAVING clause to filter results AFTER grouping (use for aggregate conditions)
selectFieldsYesFields to select - mix of group fields and aggregates. Format: 'FieldName' or 'COUNT(Id) AliasName'
groupByFieldsYesFields to group by - must include all non-aggregate fields from selectFields

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.0.7

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses query behavior, grouping requirements, filtering semantics before and after grouping, supported date functions, and limitations such as OFFSET not being supported. This gives the agent a clear model of how the tool behaves in execution.

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

Conciseness5/5

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

The description is long but well-structured, front-loaded with purpose and usage distinction, followed by examples and rules. Every section earns its place; there is no filler or redundancy that would distract an agent.

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

Completeness5/5

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

For a complex aggregate-query tool, the description is remarkably complete: it covers supported aggregate functions, date grouping, related-object grouping, HAVING usage, field-aliasing, and key Salesforce-specific restrictions. Without an output schema, the examples and rules still provide enough context to call the tool correctly.

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

Parameters5/5

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

Although the schema already documents all parameters, the description adds substantial semantic value: it maps parameters to concrete examples, explains the selectFields alias format, clarifies when whereClause versus havingClause should be used, and states the relationship between selectFields and groupByFields.

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 and resource: execute SOQL queries with GROUP BY and aggregate functions. It clearly distinguishes itself from salesforce_query_records by noting that regular queries without GROUP BY or aggregates should use the sibling tool 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?

It explicitly says when to use this tool versus salesforce_query_records. It also provides detailed guidance through examples and Important Rules for when to apply WHERE versus HAVING, GROUP BY constraints, ORDER BY constraints, and unsupported OFFSET behavior.

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

Install Server

Other Tools

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/julianboudara-code/mcp-server-salesforce'

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