Skip to main content
Glama

Analytics Legends — SAP Analytics Intelligence

Search the Academy training catalogue

find_academy_modules
Read-onlyIdempotent

Search the Analytics Legends Academy — the written training modules on SAP Datasphere, Business Data Cloud, SAP Analytics Cloud, BW/4HANA and Databricks — by track, level and free text. _meta.tranche_total_row_count carries the live catalogue size on every call; it is the only count to quote. Returns the catalogue entry: id, slug, EN/FR title, track, level, duration in minutes, tags and the editor's summary. DO NOT CONFUSE IT WITH list_sap_modules, which serves a different population under the same word: that one is the 40-row PRODUCT taxonomy (codes such as SAC, DATASPHERE) used to normalise product wording. This one is the course catalogue. Without query, rows come back in the catalogue's own CURRICULUM order — the order a reader is meant to take them in — track by track. This catalogue is written training, NOT SAP certification tracks: this server publishes no certification data at any tier, so a certification question has no answer here rather than a partial one. CATALOGUE ONLY — the module BODY is subscriber content, served by get_academy_module on this same endpoint with a subscriber key (Consultant tier or above), which is the same door the €29.90 Consultant Pass opens on the site. On THIS endpoint the machine-access subscription is the MCP Pass (€39.90/month, analyticslegends.ai/pricing/), which opens the ENTIRE paid tranche from one key; the €29.90 Consultant Pass is its web-subscriber equivalent and opens the same tier floor here. status and is_preview are SERVED, never filtered on: they are the two flags the platform marks free access with, they do not coincide (measured 2026-08-16: 38 rows status='available', 56 rows is_preview), and you decide which one your answer needs. PAGINATED: pass _meta.next_cursor back as cursor with the same filters until it is null. Read _meta.available_tracks and _meta.available_levels — both counted on the served population at call time — before assuming a facet value exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
levelNoRestrict to one level, matched case-insensitively: Beginner · Intermediate · Advanced · Expert. Counts in `_meta.available_levels`.
limitNoMax rows (hard cap 50).
queryNoFree-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.
trackNoRestrict to one track, by SLUG (`databricks-data-eng`) or by English name (`Databricks & Data Eng.`), matched case-insensitively. The live vocabulary with per-track counts is `_meta.available_tracks` on every response. The numeric track_id is deliberately NOT accepted — it is an internal counter, and passing `6` would look like naming a subject.
cursorNoOpaque 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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYes
toolYes
_metaNo
_attributionYes
result_countYes

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses default ordering, pagination behavior via _meta.next_cursor, the live count semantics of tranche_total_row_count, that status and is_preview are served but not filterable, and the measured discrepancy between them. This is substantial behavioral context that the annotations alone do not provide.

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?

The description is dense and front-loaded with the core search purpose, and the critical disambiguation from list_sap_modules appears early. Some pricing/subscription detail is longer than strictly necessary for invoking this endpoint, but it supports correct routing to get_academy_module.

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?

The description covers filtering, pagination, ordering, live facet counts, the distinction from sibling tools, access limitations, and count semantics. With a rich output schema present, no essential calling context is missing for an agent to use this tool correctly.

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?

Although schema coverage is 100%, the description adds crucial parameter semantics: query words must all appear as substrings, track accepts slug or English name but deliberately not numeric track_id, and cursor must be passed back with identical filters or it is refused. These details are not inferable from the schema alone.

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 names a specific verb ('Search'), a resource (the Academy training catalogue), and the available facets (track, level, free text). It explicitly distinguishes it from list_sap_modules, so an agent can select between the two 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 Guidelines5/5

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

The description gives explicit guidance on when to use this tool versus list_sap_modules and get_academy_module, noting the product taxonomy and the subscriber-only module body respectively. It also states clearly that certification questions have no answer here, preventing misuse.

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

Try in Browser

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.