Skip to main content
Glama

FMEPM Connect for Oracle EPM

Create a data feed

create_data_feed
Destructive

Saves a data slice or an Export Data job as a data feed that Power BI, Excel Power Query or any tool that reads a URL can refresh on a schedule. For a slice feed, I read the slice once to check it and pin the members it resolved. For a job feed, I save the job definition without running it. I store the feed under this user's connection and policy and return the link to the Feeds page where the user creates the feed key. The key is created in the portal, not in chat; this tool stores no secret. Use it when the user wants the numbers they are looking at to flow into Power BI or another BI tool. For a Power BI dashboard, first use find_members for Revenue, COGS and Opex and let the user choose their totals. The user chooses the account map. Dashboard feeds include every year and Actual, Plan (Budget when Plan is absent) and Forecast by default, without asking. Saved business definitions take precedence, then names or Default aliases. Only non-empty cells are kept. Ask for entity (offer the top entity), one version, one currency when present, and the other shared dimensions. Pass accountGroups and dashboard to build totals and children across the chosen entities, all YearTotal leaf periods, scenarios and years. I count the cells and refuse a dashboard that exceeds policy or the cache/body size limit. The demo uses the same flow; offer Revenue, COGS and OpEx for its account map. For a write, I require a preview first, then confirm: true and its confirmationToken. The token lasts ten minutes and works once.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_data_feed"
  }
}

Input Schema

NameRequiredDescriptionDefault
povNoMembers for any other dimension, for example { Version: "NSP_Base", Currency: "USD" }; dimensions you leave out use their top member
kindNoslice (the default) saves an export_data_slice; job saves an Export Data job definition run by export_data
nameYesA short name for the feed, unique per person, for example Revenue by month
rowsNoDimension names to put on rows, e.g. ["Account", "Department"]. Defaults to the account dimension.
yearNoYear member, e.g. FY26 or FY24
whereNoFor kind job: keep only rows whose column contains the text, e.g. { "Point-of-View": "FY24" }
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.
confirmNoSet true after the user has approved the previewed change
jobNameNoFor kind job: the Export Data job definition name, exactly as list_job_definitions shows it
maxRowsNoFor kind job: the most rows the feed returns (default 5000)
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
dashboardNoBuild a dashboard slice. Omit scenarios and years to include the default scenarios and every year without asking. Explicit lists narrow an oversized feed. Entity defaults to the top entity; Currency is required only when the cube has it. Use pov for any other shared dimensions.
connectionNoConnection id or label from list_connections. Defaults to the user's default connection.
povMembersNoFor kind job: Oracle's povMembers override, e.g. NSP_Actual,FY24,Subsidiary
rowMembersNoFor kind job: Oracle's rowMembers override, e.g. ILvl0Descendants(Account)
cacheSecondsNoHow long a result is served from cache before Oracle is read again, 0 to 3600 seconds, admins only. Omit to use the organization setting, then the server default (60). Zero reads Oracle on every refresh, up to 6 live runs a minute.
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.
accountGroupsNoOptional exact account totals. Use find_members and ask the user to choose each total. Required for a dashboard.
columnMembersNoFor kind job: Oracle's columnMembers override, e.g. TP1,TP2,TP3
confirmationTokenNoSingle-use token from this exact preview. Send it with confirm: true after the user approves. It expires after ten minutes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: slice feeds read the slice once and pin resolved members, job feeds save without running, no secret is stored, the feed key is created in the portal, and preview plus confirm/confirmationToken are required for writes. It also discloses policy and cache/body-size refusal behavior and token lifetime/single-use constraints, all important for a destructive, open-world mutation.

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 long but appropriately dense for a 25-parameter tool with slice/job/dashboard variants, and it front-loads the core purpose and main use case. It could be more scannable, but nearly every sentence carries behavioral or routing information rather than restating the schema.

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, nested schema, annotations, and lack of an output schema, the description is complete enough to guide correct invocation. It covers the feed outcome, slice versus job behavior, dashboard setup, defaults, limits, confirmation requirements, and the portal-created key.

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 description coverage is 100%, so the schema already defines all 25 parameters in detail; baseline is 3. The description still adds operational meaning beyond the schema by explaining dashboard default years/scenarios, business-definition precedence, accountGroups usage, and the preview-confirm-token flow.

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 gives a specific verb and resource: it saves a data slice or Export Data job as a refreshable data feed for Power BI, Excel Power Query, or URL-reading tools. It also distinguishes the two feed kinds and states the intended BI-refresh use case, so an agent can identify it without opening 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?

It clearly says when to use the tool: when the user wants the numbers they are looking at to flow into Power BI or another BI tool. It also routes the agent to find_members for Power BI dashboard account selection and explains the preview/confirm requirement for writes, though it does not explicitly state when not to use this tool versus nearby export tools.

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