Stipple — Document Verification & Extraction

Search AU/NZ tenders

find_tenders

Read-only

Search open tenders across Australia and New Zealand. 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.

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, a link, and source_id/source_tag/source_name/ source_url/source_refresh — plus link_is_listing when the portal publishes no per-tender URL and the link goes to the list it appeared on.

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`q`	No
`tier`	No
`limit`	No
`source`	No
`category`	No
`jurisdiction`	No
`closing_before`	No
`include_closed`	No
`first_seen_after`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 1, 2026

addedInput schema / properties / first_seen_after

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "First Seen After"
+}

AddedAug 26, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: the weekly free cap, the semantic meaning of first_seen (the 'honest clock for newness'), the deliberate absence of a location filter due to data sparsity, and the caveat about coverage when results are empty. This gives the agent more than the annotation alone and prevents misleading conclusions.

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

Conciseness5/5

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

The description is long but front-loaded: purpose first, then usage, then parameter semantics, then return contract and caveats. Each section earns its place, and the dense parameter notes are necessary because the schema offers no descriptions. There is no filler or repetition.

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?

The tool has nine parameters, zero schema descriptions, and only a readOnly annotation, so the description carries a heavy burden. It covers usage guidance, key parameter semantics, output shape, and important caveats like the missing location filter. However, leaving q, source, category, and include_closed undocumented means it is not fully complete for an agent trying to precisely construct a query.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It usefully documents jurisdiction (with the full allowed list), tier, closing_before, and first_seen_after, but it does not explain q, limit, source, category, or include_closed. This is a substantial gap: an agent still cannot fully map user intent to all nine parameters.

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 description opens with a specific verb and resource: 'Search open tenders across Australia and New Zealand.' It goes further by giving concrete example queries and explicitly distinguishing itself from match_tenders, so an agent can immediately tell what this tool does and what it is not for.

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?

It explicitly says 'USE THIS WHEN' and then provides representative user intents. It also names the alternative match_tenders and states the condition for choosing that instead ('which of these could MY company actually bid for'), which is clear when-to-use and when-not-to-use guidance.

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

All Stipple — Document Verification & Extraction tools Inspect

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.