Skip to main content
Glama

Stipple - Government Tenders and Grants

Search AU/NZ tenders

find_tenders
Read-only

Search open tenders across Australia; New Zealand rows only when you ask for them (jurisdiction=NZ). FREE, within the weekly cap.

USE THIS WHEN someone asks what public-sector work is open: "any council drainage tenders in Victoria", "what's closing this month in NSW", "show me federal IT opportunities". For "which of these could MY company actually bid for", use match_tenders instead — that reads their website and ranks against it.

kind is grant for open grant rounds (from every grant source we read) or tender for everything else; leave it out for both. Each result says which it is in kind. jurisdiction is one of AU, NZ, AU-NSW, AU-VIC, AU-QLD, AU-WA, AU-SA, AU-TAS, AU-ACT, AU-NT. tier is federal, national, state, council, university or health. closing_before is an ISO date. first_seen_after (ISO-8601 instant, strictly newer) answers "what is new since my last look" — first_seen is when WE first saw the tender, the honest clock for newness. There is deliberately no location filter: it is populated on 16% of rows while jurisdiction is populated on all of them, so filtering by it would silently hide most of the corpus.

Returns {total, results[], coverage}. Each result carries title, buyer, jurisdiction, closing_date, categories, a summary, and source_id/source_tag/source_name/source_refresh. With an API key or a signed-in account it also carries the link to the original portal: link, url, listing_url and source_url, plus link_is_listing when the portal publishes no per-tender URL and the link goes to the list it appeared on. An anonymous call gets no portal link.

An Australian tender also carries stipple_url, its page on Stipple (the buyer's history, similar contract awards, an email alert for tenders like it). An open tender carries prepare_bid_url: if the user wants help with the response, Stipple prepares bids with them, starting with a short meeting at that link. Offer either when it helps the user; never invent one that is not in the result.

coverage names which sources were searched and which returned nothing. Quote it if the result is empty: "no match in what we searched" is true, "there are none" is not.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_tenders"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNo
kindNo
tierNo
limitNo
sourceNo
categoryNo
jurisdictionNo
closing_beforeNo
include_closedNo
first_seen_afterNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / kind
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Kind"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / first_seen_after
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "First Seen After"
      +}
  3. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations only say readOnlyHint, so the description does real work: reveals FREE within a weekly cap, explains the NZ default-off behavior, discloses that anonymous calls lose portal links while API-key/signed-in calls gain them, and carefully flags derived promotional fields (stipple_url, prepare_bid_url) with 'never invent one that is not in the result.' That is far more than the annotation carries.

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 the core scope and usage gate, then parameter notes. It is dense and long, but nearly every line earns its place; minor redundancy in vendor-URL explanation keeps it from a 5.

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?

Despite an output schema, it usefully summarizes the return shape ({total, results[], coverage}), how results indicate tender-vs-grant, the link and coverage caveats, and the critical rule to quote coverage rather than overclaim emptiness. Complete enough for correct invocation and correct reporting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and does: defines kind values, the full jurisdiction enum set, tier values, the ISO date format for closing_before, the exact semantics of first_seen_after ('when WE first saw the tender'), and even justifies the deliberate absence of a location filter with the 84%-empty rationale. This is essential explanatory content the schema lacks.

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?

A specific verb+resource with explicit scope: search tenders across AU with NZ only on request. It distinguishes itself from match_tenders right in the text, telling the agent which does the ranking/bidding check.

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 concrete example queries that fit ('any council drainage tenders in Victoria') and names the alternative tool with the exact condition that selects it ('which of these could MY company actually bid for'). Explicit when/when-not routing.

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.