FMEPM Connect for Oracle EPM

Export access or audit report

export_access_report

Destructive

Creates a user access, role audit, group audit, invalid sign-in or application audit report file after a preview and confirm:true. It changes no user, group or role. Oracle permissions still apply. Application audit files can contain changed cell values, which the read tool omits. Use a new file name to avoid replacing an export. Use it to prepare an audit file, then check its returned job namespace and read the saved metadata with read_access_reports. https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/prest/lcm_provision_report_v2.html 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": {
      "kind": "<kind>"
    },
    "name": "export_access_report"
  }
}

Input Schema

Name	Required	Description
`to`	No	Date in YYYY-MM-DD form. Required with the other bound for sign-ins and dated exports.
`from`	No	Date in YYYY-MM-DD form. Required with the other bound for sign-ins and dated exports.
`kind`	Yes	Report to create. No security assignments are changed.
`confirm`	No	Set true after the user has approved the previewed change
`fileName`	No	Existing or new Oracle report file name ending in .csv or .zip. No path or URL.
`connection`	No	Connection id or label from list_connections. Defaults to the user's default connection.
`application`	No	Application for application_audit. Defaults to the connection.
`confirmationToken`	No	Single-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.

AddedOct 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds important behavior beyond the annotations: it states that Oracle permissions still apply, that no security assignments are changed, that existing export files can be replaced unless a new file name is used, and that application audit files may contain changed cell values omitted by the read tool. It also discloses the preview requirement, single-use confirmation token, and ten-minute expiry.

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 definition is front-loaded with the core action and report kinds, and most sentences add useful constraints. It is somewhat repetitive around the preview/confirm/token flow, restating the preview and confirmation requirements in more than one place, but it remains readable and not bloated.

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?

For a no-output-schema tool, the description does enough by explaining that the result includes a job namespace and that saved metadata should be read with read_access_reports. The main remaining gap is that it says a preview is required without naming the preview tool or fully explaining the end-to-end preview invocation flow.

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 documents the parameters well. The description adds practical semantics beyond the schema, especially that reusing a fileName can replace an export, that application audit content differs from the read tool, and that confirm must be paired with a single-use confirmationToken from the preview.

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 creates access, role, group, invalid sign-in, or application audit report files. It distinguishes the tool from the read path by saying application audit files can contain changed cell values that the read tool omits, and it clarifies that no user, group, or role assignments are changed.

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 to use the tool to prepare an audit file, then check the returned job namespace and read saved metadata with read_access_reports. It also warns to use a new file name to avoid replacing an export and states the preview-then-confirm workflow, though it does not name the preview mechanism or explicitly enumerate when other export tools should be used instead.

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

All FMEPM Connect for Oracle EPM 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.

Resources

Need Help?