Analytics Legends — SAP AI & Analytics MCP Server

Search the SAP end-customer corpus (MCP Pass)

find_sap_clients

Read-onlyIdempotent

Search the SAP END-CUSTOMER corpus — the companies that RUN SAP, not the firms that sell services (those are search_firms). This is the paid Legend+ dataset locked away from the public surface on 2026-07-08; it requires the API key of an MCP Pass or Firm account. Verification status is SERVED, never silently filtered: sap_client_verification_status and status are columns on every row ('verified' on a few hundred of ~15k rows — the exact counts are in _meta on every call, never in this text), and you decide what standard of proof your answer needs. product filters on the detected-adoption flags every profile already carries (the uses_* columns get_sap_client_profile serves): it keeps only rows where that product was DETECTED. A row it drops is 'not detected by our detection pass', never 'does not use it' — detection is a positive signal with no negative counterpart.

Input Schema

Name	Required	Description
`limit`	No	Max rows (hard cap 50).
`query`	No	Free-text filter, case-insensitive. EVERY word must appear in the record (substring per word, any order), so a natural-language phrase narrows the answer instead of having to match verbatim.
`cursor`	No	Opaque token from a previous response's `_meta.next_cursor`. Pass it back with the SAME filter arguments; `null` means the last page. Changing a filter refuses the cursor.
`country`	No	ISO-3166-1 alpha-2 country code, e.g. DE, FR, CH.
`product`	No	Keep only end-customers where this SAP product was DETECTED in use. Absence from the result means undetected, not unused.
`industry`	No	Industry or sector filter, matched case-insensitively.

Output Schema

Name	Required	Description	Default
`rows`	Yes
`tool`	Yes
`_meta`	No
`_attribution`	Yes
`result_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 26, 2026

changedInput schema / properties / query / description

Previous value: -"Free-text filter, matched case-insensitively."New value: +"Free-text filter, case-insensitive. EVERY word must appear in the record (substring per word, any order), so a natural-language phrase narrows the answer instead of having to match verbatim."

Changed1 schema field changedAug 23, 2026

changedInput schema / properties / cursor / description

Previous value: -"Opaque token from a previous response's `_meta.next_cursor`. Pass it back with the SAME filter arguments to read the next page; a null `next_cursor` means you have reached the end. It is bound to those filters and refused if they change — a cursor names a POSITION in one ordering, and applying it to another query would start the page in the wrong place."New value: +"Opaque token from a previous response's `_meta.next_cursor`. Pass it back with the SAME filter arguments; `null` means the last page. Changing a filter refuses the cursor."

Changed1 schema field changedAug 17, 2026

addedInput schema / properties / product

Added value: +{
+  "description": "Keep only end-customers where this SAP product was DETECTED in use. Absence from the result means undetected, not unused.",
+  "enum": [
+    "datasphere",
+    "bdc",
+    "sac",
+    "bw",
+    "bw4hana",
+    "s4hana",
+    "ecc",
+    "hana",
+    "joule",
+    "businessobjects",
+    "bpc",
+    "successfactors",
+    "ariba",
+    "concur"
+  ],
+  "type": "string"
+}

Changed1 schema field changedAug 9, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "Opaque token from a previous response's `_meta.next_cursor`. Pass it back with the SAME filter arguments to read the next page; a null `next_cursor` means you have reached the end. It is bound to those filters and refused if they change — a cursor names a POSITION in one ordering, and applying it to another query would start the page in the wrong place.",
+  "maxLength": 512,
+  "type": "string"
+}

Changed6 schema fields changedJul 31, 2026
- removedOutput schema / properties / rows / items / properties / citation_note
```
Removed value: -{
-  "type": "string"
-}
```
- changedOutput schema / properties / rows / items / properties / country_code / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / rows / items / properties / id / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / rows / items / properties / industry / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / rows / items / properties / name / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- changedOutput schema / properties / rows / items / properties / sap_client_verification_status / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
AddedJul 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds substantial context they cannot: paid-tier auth requirement, the 2026-07-08 lock date, that verification status is served as columns rather than silently filtered, and that per-call counts live in _meta. The product-detection caveat (a dropped row means 'not detected', never 'does not use it') is exactly the kind of behavioral nuance an agent would otherwise misreport.

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?

Front-loaded with the core differentiator (end-customers vs. firms) and dense throughout, with no filler sentences. A few editorial asides ("never in this text", the exact lock date) are slightly verbose but each still carries routing or trust information.

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?

With an output schema present, return shape and pagination need not be described, and annotations cover safety. The description fills the remaining gaps an agent actually needs: access tier, verification-status handling, and the asymmetry of product detection. Nothing required to call it correctly is missing.

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 coverage is 100%, so this is already baseline 3; the description earns extra by explaining that `product` filters on positive detection flags only, that a dropped row means 'not detected by our detection pass', and that the flags correspond to uses_* columns served elsewhere. Query/cursor/country semantics stay with the schema, which handles them well.

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 verb and resource ("Search the SAP END-CUSTOMER corpus") and immediately disambiguates the exact noun that could confuse an agent: the companies that RUN SAP, not firms that sell services. It names the sibling it is not (search_firms) and the detail tool it complements (get_sap_client_profile), so it is distinguishable without opening any schema.

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?

Explicitly routes firm/vendor lookups to search_firms and states the access precondition (API key of an MCP Pass or Firm account, paid Legend+ dataset). It stops short of stating when to prefer get_sap_client_profile over this list tool, or when not to search at all (e.g. tiny result sets vs. bulk export), so it is strong but not complete routing guidance.

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

All Analytics Legends — SAP AI & Analytics MCP Server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.