Skip to main content
Glama
Sign In
SuccessFactors MCP Server

SuccessFactors MCP Server

by david-rodrig
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

get_user_statistics

Retrieve aggregate statistics for all SuccessFactors users, including total count and active user counts. Apply optional filters to get targeted numbers for reporting and analysis.

Instructions

Get aggregate statistics about all users in SuccessFactors (total count, active users, etc.)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_user_statistics"
  }
}

Input Schema

NameRequiredDescriptionDefault
filtersNoOptional filters for statistics (e.g., {status: "A"})

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
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 disclosure burden. It does state the aggregate, all-user scope and gives examples of returned statistics, but it does not explain the output structure, how filters alter results, or error/access 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 a single focused sentence that front-loads the action and resource, includes useful examples, and contains no filler or redundant information.

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?

With only one optional parameter and no annotations, the description covers the core invocation but leaves the exact shape of the returned statistics and the effect of filters unspecified. Since there is no output schema, a bit more return-value detail would improve completeness.

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%, and the schema already documents the optional filters parameter with an example. The tool description adds no additional parameter semantics beyond 'total count, active users, etc.,' so it meets but does not exceed the baseline.

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 uses a specific verb and resource: 'Get aggregate statistics about all users in SuccessFactors,' with concrete examples like total count and active users. It is clear enough to separate from sibling tools that fetch individual user data, although it does not explicitly name an alternative.

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 the tool is for aggregate user counts and statistics, so an agent can infer when it is appropriate. However, it gives no explicit guidance about when not to use it or which sibling tool to use instead for individual user retrieval.

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

Deploy Server

Other Tools