Skip to main content
Glama

FMEPM Connect for Oracle EPM

Download a file

download_file
Read-onlyIdempotent

Reads a file from the application's outbox or inbox (for example the zip an Export Data job wrote, or a dataset from a Groovy rule). Zip exports are extracted: with several files inside, the entry list comes back and entry picks one; csv and txt entries are parsed into rows and paged with offset and maxRows under the policy's cell limit. where narrows a large export to the rows whose columns contain given text (for example a year or account in the Point-of-View column) and columns picks the columns to return. JSON files are parsed, text files are previewed and other binary files report their size only. For snapshots up to 512 MB, archive:entries pages through ZIP names without expanding all files; archive:text with an exact entry pages through XML, rules and other text; archive:search finds literal text, including extensionless Calculation Manager exports. For a plain text file, archive:text needs no entry. Follow nextEntryOffset and nextOffset, and check skipped on every search page. entryContains narrows local scanning; each page downloads the whole file. Current selective exports reduce transfer size for artifact checks. A saved snapshot can miss later forms; compare its entries with a fresh list_forms inventory. Member functions are matched as text. Large ZIPs list entries by default. Raw returns a signed one-hour link up to 50 MB; larger snapshots use archive reads. Archive text is returned as data. Use it to inspect exported form and rule definitions or a Groovy rule's output.

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": {
      "fileName": "<fileName>"
    },
    "name": "download_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
rawNoReturn the original bytes through a signed one-hour download link, without parsing or extracting them.
entryNoName of the file inside the zip to read, from the entry list. Defaults to the only entry, or the largest csv/txt.
whereNoKeep only rows whose column contains the text, case-insensitive, e.g. { "Point-of-View": "FY24", "Account": "4310" }. Paging, totalRows and nextOffset then count the matching rows.
offsetNoData rows to skip before the first returned row (default 0). Use nextOffset from the previous result to page.
searchNoLiteral text, case-insensitive, for archive search. No regular expressions or member-function expansion.
archiveNoBrowse ZIP names, read an exact entry as paged text, or search text entries. No full-archive extraction.
columnsNoColumns to return, in this order, e.g. ["Account", "TP1", "Point-of-View"]. Defaults to every column.
maxRowsNoRows to return per call (default 200, at most 2000). The policy cell limit can lower it.
fileNameYesFile name as shown in the EPM inbox/outbox explorer, e.g. Claude_Expenses_TTM.zip or fmepm_dataset.json
maxCharsNoMaximum characters in one archive page, also capped by policy. Text offsets count characters.
connectionNoConnection id or label from list_connections. Defaults to the user's default connection.
entryOffsetNoZIP entry or search cursor. Copy nextEntryOffset; search also copies nextOffset into offset.
entryContainsNoKeep ZIP paths containing this text, case-insensitive. Use the same filter on every page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/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 substantial behavior: ZIP extraction and entry selection, CSV/TXT parsing with offset/maxRows under a policy cell limit, JSON vs binary handling, the 512 MB and 50 MB thresholds, the one-hour link expiry, and the cost note that each page downloads the whole file. It also warns that a saved snapshot can miss later forms.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense paragraph of telegraphic clauses with no structural grouping ('Current selective exports reduce transfer size for artifact checks' and 'Archive text is returned as data' are cryptic). For a 13-parameter tool some length is warranted, yet several sentences do not clearly earn their place.

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?

With 13 parameters, nested objects, archive enums, and no output schema, the description does a good job covering return behavior (entry lists, parsed rows, nextEntryOffset, skipped) and limits. It leaves some ambiguity about the exact response shape for non-paged modes, but nothing critical for a correct call is missing.

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 baseline is 3, but the description adds integration semantics the schema cannot: the paging loop between offset and entryOffset, following nextEntryOffset and nextOffset, checking skipped on search pages, and reusing entryContains on every page. Some sentences (e.g. 'Member functions are matched as text') are too terse to be actionable.

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 opening sentence names a specific verb and resource ('Reads a file from the application's outbox or inbox') and immediately distinguishes the content types it can return. It is clearly separable from siblings like upload_file and export_data, and it names list_forms as a companion for snapshot comparison.

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 gives concrete routing rules: raw for a one-hour signed link up to 50 MB, archive reads for larger snapshots, archive:entries/text/search for different inspection goals, and a closing recommendation to use it for inspecting exported form and rule definitions. It stops short of explicit when-not-to-use guidance against named alternatives such as export_data.

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