Skip to main content
Glama
Sign In
easor

easor

by Markku-hur
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Get voucher image

get_voucher_image
Read-only

Retrieve a voucher's PDF image using its organization number and voucher ID; set openFile=false to return base64 data for embedded display. Memorial vouchers have no image.

Instructions

Returns the PDF image of a voucher from Easor. The voucherId can be obtained from any Easor response that includes a voucher identifier (for example the voucherId field on general ledger event rows). Memorial vouchers (muistioviennit) never have an image. The organizationNumber must match the organization the voucher belongs to. Set openFile=false to receive only the base64 PDF data without saving to disk or opening a viewer (intended for embedded display in a web page; default true opens the PDF in the system viewer).

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": {
      "organizationNumber": "<organizationNumber>",
      "voucherId": "<voucherId>"
    },
    "name": "get_voucher_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
openFileNoWhen false, return base64 data only without saving to disk or opening a viewer. Defaults to true.
voucherIdYes
organizationNumberYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint true, destructiveHint false), yet the description adds a critical non-obvious side effect: with the default openFile=true the PDF opens in the system viewer, which matters for an agent that assumed a passive read. It further discloses a constraint (organizationNumber must match the owning organization) and a structural dead end (memorial vouchers never have images).

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?

Four front-loaded sentences in a logical order: what it returns, where the ID comes from, the exclusion, then the org constraint and flag semantics. No filler, though the openFile sentence partially duplicates the schema's own parameter description.

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 three-parameter read tool with no output schema, this is nearly complete: it says what comes back (PDF or base64 without disk write), how to obtain the required IDs, and when the call is impossible. The only gap is that it does not describe the error or response shape when the voucherId is unknown.

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?

With only 33% schema coverage, the description carries most of the load and largely succeeds: it gives voucherId a provenance (the voucherId field on general ledger event rows), gives organizationNumber a correctness constraint, and frames openFile around web embedding. The openFile explanation partly restates the schema, so the marginal value there is small, but the other two parameters are well covered.

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 ("Returns the PDF image of a voucher from Easor") and implicitly situates it against the ledger-listing siblings by explaining that voucherId comes from general ledger event rows. An agent can tell this is the media-retrieval call rather than another metadata read.

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 clear when-to-use context (fetching a voucher's PDF for a known voucherId) and an explicit when-not: memorial vouchers (muistioviennit) never have an image. It also explains the openFile=false path for embedded web display versus the default viewer path. It stops short of naming a sibling alternative, but no close alternative appears to exist.

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

Deploy Server

Other Tools