FMEPM Connect for Oracle EPM

Change approval or export intersections

change_planning

Destructive

Changes one planning unit's approval status or creates a valid-intersection export file, after a preview and confirm:true. These are writes. For approvals, select an actionId from read_planning; the server checks available actions again before submitting it. Approval actions can lock work or move it to another owner. Exporting definitions changes a file but no rule. Use it after reviewing the exact unit and action or export name. Oracle roles and pod write switches still apply. https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/prest/change_planning_unit_status.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": "change_planning"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Change an approval unit, or export definitions to a new ZIP.
`names`	No	Optional exact valid-intersection rule names to export. Omit for all.
`entity`	No	One planning unit entity.
`confirm`	No	Set true after the user has approved the previewed change
`version`	No	Version for approvals.
`actionId`	No	Oracle action id from the unit's available actions.
`comments`	No	Optional approval comment. Avoid secrets or financial values.
`fileName`	No	Existing intersection export ZIP or XLSX, or new ZIP name. No URL or path.
`scenario`	No	Scenario for approvals.
`secondary`	No	Optional secondary dimension member for that entity.
`connection`	No	Connection id or label from list_connections. Defaults to the user's default connection.
`application`	No	Application name. 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.7/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, and the description adds substantial context beyond them: the server re-validates available actions before submitting, approval actions can lock work or reassign ownership, exports mutate a file but no rule, and the confirmation token is single-use and expires in ten minutes. These are exactly the consequences an agent needs before committing a write.

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 critical facts are front-loaded: what it does, that it is a write, and the preview/confirm requirement. There is some redundancy — the preview/confirm flow is stated at the top and restated in the final sentence, and the doc URL plus 'Use it after reviewing the exact unit' add little — but nothing is misleading and the length is proportionate to a destructive 13-parameter tool.

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 destructive write with two distinct modes, 13 parameters and no output schema, the description covers the full commit flow, authorization gates, side effects and token lifecycle. The only real gap is what the caller gets back after success (e.g. a job id to poll with check_job_status), which an agent must currently infer.

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 schema already documents all 13 parameters and the baseline is 3. The description nonetheless adds provenance and lifecycle meaning the schema cannot: actionId must come from read_planning and is re-checked server-side, and confirmationToken must be the one from 'this exact preview' and is single-use within ten minutes.

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 opens with a specific verb and two concrete resources: changing one planning unit's approval status, or creating a valid-intersection export file. It explicitly contrasts the export path ('changes a file but no rule') against the approval path and points at read_planning as the source of actionId, so an agent can tell this apart from read_planning and the export_* siblings.

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?

It states the mandatory sequence (preview first, then confirm:true with its confirmationToken) and the precondition for approvals ('select an actionId from read_planning') and for exports ('use it after reviewing the exact unit and action or export name'). It also names the governing constraints (Oracle roles, pod write switches) that decide whether the call can proceed at all.

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?