Skip to main content
Glama
wudaoyou

successfactors-mcp

by wudaoyou

odata_query

Run OData queries on SAP SuccessFactors with automatic pagination and effective-date handling, saving results to JSON for analysis.

Instructions

Run an OData query, following next links until exhausted or max_pages.

path is the entity set and may carry query options, e.g. "FOCompany" or "EmpJob?$select=userId,jobCode" (v4 tenant: service root first, "talent/cdp/Learning.svc/v1/Items") — those are parsed out of path and merged into the request; pass options either way, but prefer params (params win on conflicts). Always $select only the fields you need. Effective-dated entities (EmpJob, Position, FO*, MDF) return ONLY today's time slice unless you pass fromDate=1900-01-01 and toDate=9999-12-31 (or asOfDate) in params. Scope with a population filter pushed through navigation in $filter (e.g. personNav/employmentNav/jobInfoNav/company in (...)) rather than pulling whole entity sets — see the server instructions.

When max_pages > 1 and no $orderby is given, one is added from the entity's key properties (reported as orderby_added) so $skip paging can't duplicate or skip rows; if keys are unknown or unsortable, or SF rejects it, the query runs without and a warning says so — then pass $orderby yourself. Same condition, without $top/$skip, also adds paging=snapshot on v2 (reported as paging_added); if SF rejects it for that entity, the retry drops it and warns. Rows are checked for duplicate keys when every key field is in the records (duplicate_records

  • warning if found). A final page exactly $top-sized with no next link gets a truncation warning (some MDF entities stop early); resume with $skip and an explicit $orderby.

Records are written to a JSON file; the tool returns counts, the field names of the first record, and the path. preview accepts 0-20; values above zero return that many records inline only when their serialized UTF-8 size is at most 16 KiB. Otherwise, inspect the saved file locally.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
paramsNo
previewNoInline records; maximum 20.
max_pagesNo
company_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.2
    • addedInput schema / properties / preview / description
      Added value: +"Inline records; maximum 20."
    • addedInput schema / properties / preview / maximum
      Added value: +20
    • addedInput schema / properties / preview / minimum
      Added value: +0
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly, disclosing paging behavior, automatic $orderby/paging=snapshot insertion and retry logic, duplicate-key checks, truncation warnings, effective-date time-slice defaults, and output-to-file/preview-size constraints. It leaves little behavioral uncertainty for an agent invoking the 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?

It is front-loaded with the purpose in the first sentence and then organized by parameter/behavior topics. It is long and dense, but nearly every sentence adds a specific operational rule an agent needs, so it avoids true bloat.

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, absent annotations, sparse schema descriptions, and the existence of an output schema (so return values need not be fully explained), the description is mostly complete. It still omits any treatment of company_id and does not cover auth or rate limits, which are minor gaps for otherwise thorough coverage.

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 description coverage is only 20%, so the description must compensate, and it does for path, params, max_pages, and preview by explaining merging, precedence, paging, and the 16 KiB inline-preview limit. The company_id parameter is never mentioned, leaving one of five parameters semantically unexplained.

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 states a specific verb and resource: 'Run an OData query, following next links until exhausted or max_pages.' This distinguishes it from metadata-fetching siblings, but it never differentiates itself from the other query sibling (ce_query) or mentions when to prefer one query tool over the other.

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?

It provides rich operational guidance: how to pass path options, preferring params over inline options, always using $select, scoping with navigation filters, and how paging defaults interact with $orderby. However, it never names an alternative tool or states when this tool should not be used instead of ce_query or odata_metadata.

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