Analytics Legends — SAP Analytics Intelligence

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 the entire corpus as of 2026-08-10, 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. 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 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.2/5.0

Behavior4/5

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

The readOnlyHint and idempotentHint annotations already establish safe behavior, and the description adds valuable behavioral detail: null fields mean 'not researched', absent filter results mean 'not declared', and person-shaped fields are never returned at any tier. There is no contradiction between the annotations and the description's behavioral claims.

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

Conciseness2/5

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

The description is excessively long and contains redundant, confusingly repeated content, especially around data completeness percentages and sparsity warnings. Statements like the repeated 'READ THE SPARSITY BEFORE QUOTING A ROW' block and the garbled 'it read ~39% ... below the truth' passage create noise rather than adding clear value. A tighter description would convey the same essential caveats more effectively.

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 tool's complexity, the description covers the essential operational context: access tier, sparse-data semantics, filter behavior, and data-population differences from sibling tools. It does not include the output schema details, but the description still gives enough context for an agent to understand what the endpoint will and will not return.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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

Every parameter in the schema has a detailed, meaningful description that goes beyond basic type information: name matching is case-insensitive, cursor must be passed back with identical filters, limit has a hard cap of 10, and mode/delivers are explicitly declared-only. These explanations remove ambiguity and give an agent precise instructions for composing valid requests.

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?

The description clearly identifies the tool as a paid intelligence profile for services firms, listing the exact data categories it provides (SAP practice size, partner level, delivery flags, day rate, clients, analytics summary, LinkedIn URL). It also distinguishes this tool from the public directory by stating that search_firms covers a different, wider population, so an agent can confidently choose it for firm-intelligence lookups.

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?

The description gives concrete usage guidance: requires a Legend-tier API key, search by name, and clarifies that omissions in filter results mean 'not declared' rather than 'cannot deliver'. It also warns against quoting sparse fields and states that person-shaped fields are never served, giving an agent clear guardrails for when to use and when not to use this endpoint.

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 Analytics Intelligence 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.