Skip to main content
Glama

Read tender documents

add_tender_documents
Destructive

Use this when the user shares text from a tender's documents, or wants Winquill to read the files the buyer published with the notice (read_published, signed in). Returns a checklist of everything the bid must include, each with its file, page and the buyer's own words, and the requirements the notice leaves out, such as turnover, insurance and certifications. When the workspace can use Winquill's AI, it also returns the questions the buyer scores and how they're marked. Not for documents unrelated to a tender. Example: {"tender_reference":"012345-2026","read_published":true}

Input Schema

NameRequiredDescriptionDefault
textNoThe document text the user shared, not a file link: an invitation to tender, selection questionnaire, specification or instructions to bidders. Needed unless read_published is true. Signed in, later fit and readiness checks for the tender include what Winquill reads; signed out, it keeps nothing.
titleNoThe document name, e.g. "Invitation to Tender Part 2".
workspaceNoThe Winquill workspace to use, by name, when the user is in more than one, e.g. "Northbridge Services".
read_publishedNotrue to have Winquill fetch and read the files the buyer published with the notice, up to 8 (PDF, Word, Excel, web pages and ZIPs of them). Needs sign-in. Reading the scored questions with Winquill's AI uses a check's worth of the workspace's usage.
tender_referenceYesThe notice ID, procurement identifier, solicitation number or the buyer's own reference, e.g. "012345-2026" on Find a Tender, "WS4851234567" on CanadaBuys or "140D0427Q0879" on SAM.gov.

Output Schema

NameRequiredDescriptionDefault
noteNo
filesNo
foundNo
notReadNo
scoringNoHow the buyer marks answers: its marks and what earns each, the pass mark, and how the award is split.
summaryYes
signedInNo
tenderIdNo
checklistNoEverything the bid must have, each with the file and page it's in, what to provide, and the buyer's own words (at most 280 characters).
questionsNoThe questions the buyer scores, with word limits and weights in per cent. Read by Winquill's AI; absent when it wasn't, and note says why.
referenceNo
requirementsFoundNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / read_published / description
      Previous value: -"true to have Tenda fetch and read the files the buyer published with the notice, up to 8 (PDF, Word, Excel, web pages and ZIPs of them). Needs sign-in. Reading the scored questions with Tenda's AI uses a check's worth of the workspace's usage."New value: +"true to have Winquill fetch and read the files the buyer published with the notice, up to 8 (PDF, Word, Excel, web pages and ZIPs of them). Needs sign-in. Reading the scored questions with Winquill's AI uses a check's worth of the workspace's usage."
    • changedInput schema / properties / text / description
      Previous value: -"The document text the user shared, not a file link: an invitation to tender, selection questionnaire, specification or instructions to bidders. Needed unless read_published is true. Signed in, later fit and readiness checks for the tender include what Tenda reads; signed out, it keeps nothing."New value: +"The document text the user shared, not a file link: an invitation to tender, selection questionnaire, specification or instructions to bidders. Needed unless read_published is true. Signed in, later fit and readiness checks for the tender include what Winquill reads; signed out, it keeps nothing."
    • changedInput schema / properties / workspace / description
      Previous value: -"The Tenda workspace to use, by name, when the user is in more than one, e.g. \"Northbridge Services\"."New value: +"The Winquill workspace to use, by name, when the user is in more than one, e.g. \"Northbridge Services\"."
    • changedOutput schema / properties / questions / description
      Previous value: -"The questions the buyer scores, with word limits and weights in per cent. Read by Tenda's AI; absent when it wasn't, and note says why."New value: +"The questions the buyer scores, with word limits and weights in per cent. Read by Winquill's AI; absent when it wasn't, and note says why."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Going beyond the annotations, it discloses sign-in requirements, that fetching published files pulls up to a limited set of external documents, and that scored questions only appear when the workspace has AI enabled and consume usage. It does not explain the persistent side of the operation implied by destructiveHint=true (that readings are stored and later reused), leaving the mutation profile partly implicit.

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-loaded with a 'Use this when' trigger, followed by return content and an exclusion, ending with a compact example. The middle sentences are long and stack several conditions at once, but no sentence is filler.

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 an output schema and annotations already carrying safety signals, the description covers triggers, return content and the AI-conditional path. The one material gap is the persistence/overwrite behavior implied by destructiveHint=true, which the agent would need to warn the user about.

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; the description adds real value by showing a worked example object and tying read_published to its behavioral consequence ('signed in'). It still does not clarify the relationship between providing text and read_published (mutually exclusive vs additive) beyond what the schema states.

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 ('read the files the buyer published with the notice', 'text from a tender's documents') and names exactly what comes back: a checklist of bid requirements plus the notice's omissions. An agent can tell this apart from get_tender_details or assess_tender_fit because the output shape (per-item file, page, buyer's words) is spelled out.

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 triggering conditions ('when the user shares text from a tender's documents, or wants Winquill to read the files the buyer published') and an exclusion ('Not for documents unrelated to a tender'), plus a concrete example call. It never names an alternative sibling tool for the adjacent cases (e.g. tender fit or readiness), so routing between siblings is still inferred.

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