Tendy - Israeli public tenders

Browse a tender collection

browse_collection

Read-onlyIdempotent

One public Tendy hub page in a single answer: the tenders of a category, of a publishing body, of an Israeli region, or all government or all municipal tenders. Returns the page's direct answer, counts as of today (shown, with a known future deadline, and the whole catalog including closed tenders), aggregate facts computed over at least 10 tenders, links to related hub pages, and up to 10 tenders per page as the public page lists them, each with a link and the publisher as a group such as רשות מקומית בצפון. Fits overview questions: how many tenders a field or a body has, what the government is buying, what typical guarantees look like. For free text, combined filters, deadline windows or supplier size, search_tenders fits better; for one tender's full details, get_tender. The key comes from list_collections or list_categories; a Hebrew category or body name also works.

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": {
      "kind": "<kind>"
    },
    "name": "browse_collection"
  }
}

Input Schema

Name	Required	Description
`key`	No	For category, publisher and region: the category slug or Hebrew name, the publishing body slug or Hebrew name, or the region name, as list_collections lists them. Not used for government and municipal.
`kind`	Yes	category (what is being bought), publisher (one publishing body), region (an Israeli district), government (all government bodies) or municipal (all local authorities).
`page`	No	Result page, from 1.

Output Schema

Name	Required	Description	Default
`notice`	Yes
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely behavioral detail beyond that: counts are as of today, aggregates are only computed over at least 10 tenders, pages cap at 10 results, and closed tenders are included in the catalog count. The only gap is it doesn't discuss page-range limits (1-50), which the schema covers anyway.

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

Conciseness3/5

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

Front-loaded correctly with purpose before routing, and no filler. However, the middle sentence is a long comma-chained enumeration of return fields (answer, three counts, aggregates, related links, ten tenders with publisher grouping) that partly duplicates the existing output schema and makes the definition heavier than it needs to be.

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?

An output schema exists and the parameters are fully documented, so the description only needs purpose, routing, and invocation hints — all of which are present. Nothing an agent needs to call this correctly, including key sourcing and the government/municipal exception, 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 real meaning beyond it: it explains that key accepts a slug or a Hebrew name, that it is sourced from list_collections or list_categories, and that it is unused for government and municipal kinds. That last point prevents a common invocation error.

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 (one public Tendy hub page) and enumerates the four scopes it covers (category, publisher, region, government/municipal). It explicitly distinguishes itself from search_tenders and get_tender, so an agent can pick it without opening another 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 concrete when-to-use examples ("how many tenders a field or a body has, what the government is buying, what typical guarantees look like") and names the exact conditions that route elsewhere: free text, combined filters, deadline windows, supplier size go to search_tenders; single-tender detail goes to get_tender. It also states where the key comes from.

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

All Tendy - Israeli public tenders 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.