Skip to main content
Glama

FMEPM Connect for Oracle EPM

Export data slice

export_data_slice
Read-onlyIdempotent

Exports a slice of numbers from any cube of the connected application. It reads the cube's dimensions first, puts the account dimension on rows and the period dimension on columns, maps scenario, year and entity to the cube's matching dimensions whatever they are called (Entity or Subsidiary, Year or Fiscal Year), and gives every other dimension its top member unless pov names a member for it, for example pov: { Version: "NSP_Base", Currency: "USD" }. Returns the rows as a table and as structured data, cut to the policy's cell limit with a note when that happens, and reports which member was used for each dimension. Scenario, Version and Currency usually need a leaf member (Actual, Base, USD) because their top members hold no data, and in many applications the top member of a custom dimension holds no total either. When a slice comes back empty, the result names the dimensions left at their top member with their first children; pass members for them, or browse a dimension with list_dimension_members when it is available. Use it to read actuals, plan or forecast numbers for analysis or commentary.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
povNoMembers for any other dimension, for example { Version: "NSP_Base", Currency: "USD" }; dimensions you leave out use their top member
rowsNoDimension names to put on rows, e.g. ["Account", "Department"]. Defaults to the account dimension.
yearNoYear member, e.g. FY26 or FY24
freshNoSet true to ignore the scenario, year, entity, cube and pov remembered from the user's previous request, start from scratch and read Oracle again even inside the policy's cache window.
entityNoEntity member, e.g. North America. Goes to the cube's entity-like dimension (Entity, Subsidiary, Company).
periodNoPeriod member or comma-separated list, e.g. Jan, Q1 or TP1,TP2,TP3. Member functions such as ILvl0Descendants(YearTotal) work. Defaults to level 0 members under YearTotal.
accountNoAccount member or comma-separated list, e.g. Revenue or Descendants(Net Income). Defaults to all level 0 accounts.
appNameNoApplication name. Defaults to the connection's application.
columnsNoDimension names to put on columns, e.g. ["Period"] or ["Period", "Scenario"]. Defaults to the period dimension.
planTypeNoCube (plan type) to export from, e.g. Plan1 or NSP_NFS. When the application has one cube it is used; with several, pass one. Otherwise Plan1.
scenarioNoScenario member, e.g. Actual, Plan, NSP_Actual
connectionNoConnection id or label from list_connections. Defaults to the user's default connection.
planningDataNoSet true to read through the application's form engine (Smart List labels, form-level security) instead of the plain cube export. The cube export is the default because the form engine returns nothing when a parent member is in the point of view.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description goes well beyond them: it discloses the policy cell-limit truncation with a note, the top-member/leaf-member data-availability trap, the caching behavior that 'fresh' overrides, and the planningData form-engine caveat where a parent in the POV returns nothing. These are non-obvious behavioral traits an agent could not infer from structured fields.

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?

It is one long paragraph, but the core purpose and default behavior are front-loaded and nearly every clause conveys operational information (mapping rules, empty-slice recovery, cell-limit note). A little denser than ideal — splitting the empty-result recovery advice out would read better.

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?

13 parameters, zero required, nested POV object, no output schema — the description compensates fully: it describes the return shape (table plus structured data, truncated with a note, per-dimension member report) and covers the main failure mode. Nothing material is missing for a correct invocation.

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 baseline is 3; the description earns extra by explaining the POV fallback-to-top-member rule, the requirement for leaf members on Scenario/Version/Currency, and worked examples like pov: { Version: "NSP_Base", Currency: "USD" } that show how dimensions map regardless of naming.

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 ('Exports a slice of numbers from any cube') and then details exactly what the slice consists of — rows/columns defaults, scenario/year/entity mapping to cube-specific names, other dimensions at top member. An agent can tell this apart from point_of_view or run_business_rule without reading the 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 a clear use case ('read actuals, plan or forecast numbers for analysis or commentary') and actionable guidance for the empty-result case (pass members or browse with list_dimension_members). It does not explicitly contrast itself with the sibling point_of_view or remembered_results tools, so routing among those is left to inference.

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.

Resources