List the SuccessFactors instances this server can reach.

Call this first: the company_id values it returns are what the other tools take as their company_id argument. An empty company_id always means the instance configured in the server's own .env, reported here as "default". "plugins" reports each installed plugin and whether it loaded. "production" is the tenant's declared environment; odata_query and ce_query refuse a tenant where it is null or "config_error" is set.

Fetch OData $metadata (EDMX) and reduce it to a compact field map.

entity="" pulls the whole service metadata (large — hundreds of entity types); entity="EmpJob" pulls just that entity set. The full {entity: {field: attributes}} map is written to a JSON file, and a small map is returned inline as well, so two instances can be compared without ever loading raw EDMX into the conversation. When entity is given, its navigation properties (name, target entity type, filterable) are listed too — entity-scoped $metadata doesn't carry them, so this resolves them from the full service $metadata instead (fetched once per company_id per process, then cached); a lookup failure is reported as a warning and never blocks the field output above. Use the navigation names to scope filters into other entities via $filter (see the server's "Scope with EmpJob first" guidance and odata_query's docstring) instead of pulling whole entity sets and joining locally.

On a v4 tenant, entity is a service path: its root for the whole service ("talent/cdp/Learning.svc/v1"), or root plus entity set for one (".../Learning.svc/v1/Items"); both read that service's $metadata.

Compare the OData configuration of two instances and return the drift.

entity="EmpJob" compares one entity set; entity="" compares the whole service (v4: a service path, as in odata_metadata). The comparison runs here, not in the conversation: one instance's EmpJob metadata alone is ~40 KB, so diffing two of them in context is both expensive and easy to get wrong.

Returns in_sync plus, per entity, the fields missing on either side and the fields whose attributes differ, each as [value_in_a, value_in_b]. The sap: attributes are the configuration itself — required, visible, upsertable, picklist, MaxLength — so a changed picklist or a field that never left the dev instance shows up here.

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.

Query the EC Compound Employee (SOAP) API and save the payload to disk.

person_id_external / user_id are comma-separated and take precedence over every other filter when set. last_modified_on is an ISO datetime for a delta pull (SAP allows at most 3 months of look-back). With no filter at all this is a full extract, capped by max_pages.

CompoundEmployee SFQL allows only ONE condition on last_modified_on in the WHERE clause — a query with both a lower and an upper bound (last_modified_on>X and last_modified_on<=Y) fails with INVALID_SFQL: Only one condition is allowed. This tool only ever emits the lower bound; apply any upper bound to the returned rows client-side, not by adding a second last_modified_on condition.

last_modified_on's filtering also depends on an SFQL parameter, isNotFirstQuery, that this tool does not currently set: per tenant testing, a query without isNotFirstQuery ignores last_modified_on entirely and returns a full snapshot of the matching window, while isNotFirstQuery=true makes last_modified_on act as a real delta filter. Until this tool exposes that parameter, treat last_modified_on here as a full-window snapshot, not a guaranteed delta — don't rely on it alone to mean "only changed rows".

select_segments defaults to the widely supported COMMON_SEGMENTS. If SF answers INVALID_SFQL naming a segment, that module is not enabled on the tenant — pass a narrower list. Only documented segment names are accepted, and person_id_external / user_id values may contain only letters, digits, space and _ . @ : / + -.

Each queryMore page is written as its own XML file. The tool returns counts and paths only: one employee's payload is ~80 KB of HR data.