Skip to main content
Glama

Stonewake

by ai.stonewake
OverviewDiscussionsAdmin

Tender export preview

tender_export_preview
Read-onlyIdempotent

Preview a tender portal export for the caller team's own tender notices. Pass the file the portal exported (CSV, XLSX or the XML of one eForms notice, at most 700,000 bytes) base64 encoded in content_base64 and its name in file_name; the extension must match the content. Name the portal the file was exported from in source_portal; uploads from dtvp, vergabe24, dab, dtad, had and vergabe_saarland are not accepted for now. The header is matched against the known portal profiles; when none matches, the answer says mapping_required with the file's columns and the available_fields, and a second call passes mapping, an object from column name to field. Every row answers its outcome (new, update, unchanged, duplicate, skipped, invalid), the reference that identifies it and a reason; unknown columns are listed and never read, and counters name every dropped value. Rows are paged with limit and offset in file order; counts and total cover the whole file. Nothing is written, and confirming an upload happens in the Stonewake dashboard.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size, default 100, maximum 100.
offsetNoRows to skip, default 0.
mappingNoOptional. Column name of the file to upload field, as available_fields of a preview lists them.
file_nameYesThe exported file's name, for example treffer.xlsx.
source_portalYesThe portal the file was exported from; manual is a file the bank compiled itself.
content_base64YesThe exported file, base64 encoded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / offset / maximum
      Added value: +9223372036854776000
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/destructive/idempotent/openWorld, so the safety profile is covered; the description adds real behavioral context on top: 'Nothing is written', per-row outcomes, unknown columns 'never read', counters naming dropped values, and paging/count semantics in file order. It does not detail error behavior for size or extension violations beyond the stated limits.

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?

Front-loads the purpose before constraints, and each sentence carries distinct information (accepted portals, mapping fallback, row outcomes, paging). It is dense with semicolons and somewhat long, but little of it is expendable filler.

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?

With no output schema and a nested mapping object plus a two-call mapping flow, this tool is complex, yet the description covers the return shape (outcomes, reference, reason, counters, mapping_required with columns/available_fields), paging, size/format limits, and the no-write guarantee. Nothing an agent needs to invoke it correctly 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 meaning beyond the schema: content_base64 is the raw export file whose extension must match the content, source_portal names the origin portal and manual means bank-compiled, mapping maps column name to field, and limit/offset page rows 'in file order' with counts over the whole file.

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 ('Preview a tender portal export') plus scope ('for the caller team's own tender notices'), which cleanly separates it from sibling import/preview tools like portfolio_import_preview and from tender_matches. An agent can tell what it does 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use conditions (pass the portal-exported file, extension must match the content) and when-not (uploads from dtvp, vergabe24, dab, dtad, had, vergabe_saarland are not accepted). It also spells out the fallback workflow: a mapping_required response with columns and available_fields, then a second call with mapping.

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

All Stonewake toolsInspect
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