Skip to main content
Glama

Analytics Legends — SAP Analytics Intelligence

by ai.analyticslegends

Public SAP analytics day-rate aggregate

get_day_rate_benchmark
Read-onlyIdempotent

The PUBLIC day-rate aggregate for SAP analytics freelance work: min/max daily rate by country, specialisation and seniority, each row carrying its own currency, source, source date and confidence. This is the free aggregate published at analyticslegends.ai/api/market-rates.json, and it is SMALL — a few dozen rows at most, every one of them a secondary source (a published market study or a job-board scan), and sample_size is null on most of them. NO COUNT IS WRITTEN HERE ON PURPOSE: _meta.tranche_total_row_count and the rows themselves are the live measure. A frozen pair stood here until 2026-08-27 — '11 rows on 2026-08-09 … sample_size null on 8 of them' — and the second half was WRONG (7 of 11) while the first was still right, which is the whole argument against writing either. NOTHING IS HELD BACK BEHIND IT: there is no paid counterpart to this aggregate. The community-contribution path exists (public.rate_contributions) but publishes nothing yet — v_community_rate_aggregates and v_rate_index are still empty, because a contributed rate only surfaces once a cell holds enough submissions to be reported without identifying anyone. So whatever percentile a source row happens to carry is served here, free, to everyone. The GB row carries a median, p10 and p90, and its own note says its min/max ARE the 25th and 75th percentiles. What is missing from this answer is missing from THIS aggregate; it is not a paid tier. THIS IS NOT THE ONLY RATE THE PLATFORM PUBLISHES, AND ON THE QUESTIONS THIS MARKET ASKS MOST IT IS THE THINNER ONE. find_opportunities returns a rate_band on most live radar postings — a panel-inferred P25–P75 band per (seniority × product × region) cell, Eursap n=312 plus the Analytics Legends operator panel, and it is what each posting's public page leads with. It prices exactly the cells this small aggregate cannot — Senior Datasphere DACH, Senior BDC DACH — where specialisation:"bdc" here returns nothing. When this tool comes back empty for a country × product, say the AGGREGATE holds no row and go read the radar band — do not report that the platform cannot price it. The two are different instruments: this one is a published market study, that one is an editorial benchmark attached to a live posting. Read _meta.available_countries / available_specialisations / available_seniorities — they are computed from the aggregate on every call — before concluding that a rate is unpublished, and quote each row with its own currency, its confidence and its source date.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countryNoISO-3166-1 alpha-2 country code, e.g. DE, FR, CH.
seniorityNoe.g. senior, principal.
specialisationNoOne of the codes the aggregate actually holds — analytics_all, bw, bw4hana, bw4hana_sac, sac, datasphere (2026-08-09; the live list comes back as `_meta.available_specialisations` on every call). They are NOT evenly spread across countries: DE holds analytics_all only, at three seniorities, and datasphere exists for FR alone, as a median with confidence 'low'. There is no bdc row and no joule row in THIS aggregate — but the platform does price BDC: `find_opportunities` carries a panel-inferred band on the live postings, €1,000–€1,400/day P25–P75 for Senior BDC on 52 German postings (2026-08-10). A code this aggregate does not hold returns 0 rows and the available codes; it never widens to a neighbouring band, and 0 here does not mean the platform is silent.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
toolYes
_metaNo
_attributionYes
result_countYes

TDQS

A4.6/5.0
Behavior5/5

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

The description goes far beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false). It discloses the deliberate absence of a written count and explains why with a concrete historical counter-example, states that sample_size is null on most rows, explains the GB row's special percentile semantics (min/max are the 25th/75th percentiles), discloses there is no paid tier behind the tool, and spells out the open-world empty-result behavior: unknown codes return 0 rows plus available codes and never widen to a neighbouring band. This richly contextualizes the openWorldHint.

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 very long and repetitive, with multiple ALL-CAPS admonitions restating the same points ('it is not a paid tier', '0 here does not mean the platform is silent'). The frozen-pair historical anecdote about the wrong row count is verbose for the point it makes, and some detail (e.g., 'Eursap n=312 plus the Analytics Legends operator panel') is tangential to invoking the tool. It is front-loaded with the core purpose, but every sentence does not earn its place.

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?

Given the tool's complexity — open-world behavior, optional parameters, subtle empty-result semantics, and a close sibling that answers the same market questions — the description covers purpose, scoping, alternatives, result-interpretation rules, and meta-field guidance. Output schema exists, so return-value structure need not be restated. Nothing an agent needs to call this correctly or interpret its results 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 the baseline is 3, and the description adds genuine value on top: it explains that specialisation codes are not evenly spread across countries (DE holds analytics_all only, datasphere exists for FR alone as a low-confidence median), gives concrete negative examples (no bdc/joule rows), and defines empty-result semantics for unsupported codes. The main description and parameter descriptions are somewhat redundant with each other, which keeps this from a 5.

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 opening sentence names a specific resource (public day-rate aggregate for SAP analytics freelance work) with explicit scope: min/max daily rate by country, specialisation and seniority, each row carrying currency, source, source date and confidence. It directly differentiates itself from find_opportunities, calling itself 'the thinner one' on the questions the market asks most, so an agent can pick the right instrument without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing guidance is provided: when the aggregate returns empty for a country × product, the agent must say the aggregate holds no row and 'go read the radar band' via find_opportunities, and must not report that the platform cannot price it. It also instructs reading `_meta.available_countries` / `available_specialisations` / `available_seniorities` before concluding a rate is unpublished. This is model-level when-to-use vs. when-not-to-use guidance with a named alternative.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Each tool targets a distinct resource or action (firms, clients, modules, concepts, studies, opportunities, rates, news, knowledge graph). Some pairs like find_academy_modules vs list_sap_modules and find_sap_clients vs search_firms could be confused, but the descriptions explicitly disambiguate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case: find_, get_, list_, search_, count_, query_. Verbs are consistently used for their roles (find/search for querying, get for single items, list for enumerations), with no mixed casing or style.

Tool Count4/5

20 tools is on the higher end, but the server covers a broad domain with multiple distinct datasets (directory, clients, academy, concepts, studies, opportunities, rates, news, graph). Each tool earns its place, though the count is slightly above the ideal 3-15 range.

Completeness5/5

The domain is a read-only intelligence platform, and it provides search/list and get operations for every major entity: firms, clients, modules, concepts, studies, and opportunities. The knowledge graph adds relational querying, and rates/news are covered. No essential lifecycle operations are missing for the stated purpose.

Resources