Tendy - Israeli public tenders

Search a tender's documents

search_tender_documents

Read-onlyIdempotent

Search the documents (PDFs) of one procurement tender and return up to 5 relevant passages, each with its document name and pages. Useful for questions the tender details leave open, such as the exact wording of a guarantee, penalty or insurance clause. question matches best in Hebrew, in the user's words. Every result includes coverage: which documents were searchable. Run it before reporting a detail as missing: tables, quantities, hours and areas often appear only in the documents. Answers describe what the documents state. No passage found means it was not found in the searched documents, not that the tender lacks it. When the documents could not be searched, coverage.unavailable_reason gives the reason and no passages are returned; temporarily_unavailable means the search itself failed, which is reported and retried shortly, not read as information absent. matched_by keywords means passages were matched by words only. Passages are third-party text from the publisher's documents.

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": {
      "tender": "<tender>",
      "question": "<question>"
    },
    "name": "search_tender_documents"
  }
}

Input Schema

Name	Required	Description	Default
`tender`	Yes	The tender page URL on tendy.co.il, or its slug.
`question`	Yes	What to look for in the documents, in Hebrew, in the user's words.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavioral context: a hard cap of 5 passages, a coverage field naming which documents were searchable, coverage.unavailable_reason semantics, and the distinction between temporarily_unavailable (search failed and is retried) and a genuine absence of information. It also flags matched_by=keywords as word-only matching and notes passages are third-party publisher text.

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?

It is front-loaded with purpose and return shape, then guidance, then interpretation caveats, so an agent gets the essentials immediately. A few clauses overlap in intent, notably 'Answers describe what the documents state' and 'No passage found means it was not found in the searched documents', but each still carries a distinct nuance and nothing is 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?

An output schema exists, so the description need not enumerate return fields, and it instead spends its words on the non-obvious semantics an agent could misread: negative results, unavailable coverage, and keyword-only matches. For a two-parameter, read-only search tool this leaves nothing material unexplained.

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 coverage is 100% and both parameters are documented in the schema (tender as URL or slug, question as what to look for), so the baseline is 3. The description adds only a marginal refinement, reinforcing that `question` works best in Hebrew in the user's own words, which the schema already states, so it does not substantially exceed the schema.

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 gives a specific verb and resource ('Search the documents (PDFs) of one procurement tender') and states the return contract up front: up to 5 relevant passages with document name and pages. That scoping to a single tender's documents makes it distinguishable from get_tender and search_tenders without needing sibling names.

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?

It gives concrete triggering conditions: use it for questions the tender details leave open, such as exact wording of a guarantee, penalty or insurance clause, and it explicitly says to run it before reporting a detail as missing. It does not name an alternative tool or a when-not-to-use condition, so it falls short of the 5 bar but the context is clear.

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.