Analytics Legends — SAP AI & Analytics MCP Server

Firm intelligence profile (Legend tier)

get_firm_intel

Read-onlyIdempotent

The paid intelligence profile of a services firm — SAP practice size and partner level, delivery flags per product, typical day rate and seniority, notable clients, analytics practice summary, and a LinkedIn company URL (present on ~71% of the corpus, re-measured 2026-09-05 on 9,104 profiles — it read ~39% from 2026-08-10 to 2026-09-05, i.e. a third of the corpus below the truth, because an enrichment pass filled the column and no reader of this sentence was told — glassdoor_rating, glassdoor_reviews_count and linkedin_followers are null on all but a handful of profiles, absence here is a data gap, not a signal). READ THE SPARSITY BEFORE QUOTING A ROW: on the 9,103 profiles measured 2026-08-23, typical_day_rate_eur is null on 78.0% and sap_partner_level on 85.7% — the two headline fields are the exception, not the rule, and a null means 'not researched', never 'no partner level'. Requires a subscriber API key, Legend tier or above. Person-shaped fields (contacts, founders, leadership, recruiters, postal addresses) are NEVER served by this endpoint at any tier — they remain behind the platform's signed-URL path. Search by name; the public directory (search_firms) is a different, wider population.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Keep only firms whose profile declares this engagement mode (mode_freelance / mode_permanent / mode_subcontract). Same reading as `delivers`: declared-only.
`name`	No	Firm name, matched case-insensitively; an exact name ranks first, then a name starting with it, then the other matches. Omit to browse the corpus by data completeness.
`limit`	No	Max rows (hard cap 10 — these rows are wide).
`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.
`delivers`	No	Keep only firms whose profile DECLARES delivery of this product (the `delivers_*` flags every row already carries). An undeclared flag drops the row: absence from the result means the profile does not declare it, not that the firm cannot deliver it.

Output Schema

TableJSON 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 changedOct 2, 2026

changedInput schema / properties / name / description

Previous value: -"Firm name, matched case-insensitively. Omit to browse the corpus by data completeness."New value: +"Firm name, matched case-insensitively; an exact name ranks first, then a name starting with it, then the other matches. Omit to browse the corpus by data completeness."

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."

Changed2 schema fields changedAug 17, 2026

addedInput schema / properties / delivers

Added value: +{
+  "description": "Keep only firms whose profile DECLARES delivery of this product (the `delivers_*` flags every row already carries). An undeclared flag drops the row: absence from the result means the profile does not declare it, not that the firm cannot deliver it.",
+  "enum": [
+    "datasphere",
+    "bdc",
+    "sac",
+    "bw",
+    "bw4hana",
+    "s4hana",
+    "ecc",
+    "hana",
+    "joule",
+    "businessobjects",
+    "bpc",
+    "successfactors",
+    "ariba",
+    "concur"
+  ],
+  "type": "string"
+}

addedInput schema / properties / mode

Added value: +{
+  "description": "Keep only firms whose profile declares this engagement mode (mode_freelance / mode_permanent / mode_subcontract). Same reading as `delivers`: declared-only.",
+  "enum": [
+    "freelance",
+    "permanent",
+    "subcontract"
+  ],
+  "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"
+}

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

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description layers on substantial extra behavior: the auth/tier requirement, the null-on-all-but-a-few fields, the critical sparsity warning (78% null day rate, 85.7% null partner level), the 'null = not researched, never no partner level' interpretation rule, and the signed-URL exclusion for person fields.

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

Conciseness3/5

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

The purpose is front-loaded and much of the content (sparsity warning, tier requirement, field exclusions) earns its place. However the long parenthetical reciting measurement dates and self-referential commentary ('no reader of this sentence was told') is editorial bloat that an agent does not need in order to invoke the tool.

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 values need no explanation, and the description still covers auth tier, field availability, data-gap semantics, pagination via cursor, and the sibling directory boundary. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100%, so every parameter (mode, name, limit, cursor, country, delivers) is already documented in the schema with its declared-only semantics. The description adds only the top-level 'search by name' hint and sparsity framing, which is not parameter-level detail beyond the schema.

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 ('The paid intelligence profile of a services firm') and enumerates the exact fields returned (SAP practice size, partner level, day rate, clients, LinkedIn URL). It also explicitly differentiates itself from the sibling search_firms ('a different, wider population'), so an agent can route without opening either 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?

Gives concrete usage conditions: requires a Legend-tier subscriber key, search by name, and the alternative public directory is search_firms. It also carves out a hard exclusion (person-shaped fields never served at any tier). It stops short of a crisp 'use this instead of get_firm when...' rule against the closest sibling.

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.