Market and Regulatory Data Feeds — Zinin M2M Hub

Tender Change Alert

tender-alert

Watches public tender feeds for a saved filter and returns only what changed since the previous check — new tenders, closed ones, changed deadlines. The first run on a new filter creates the baseline and says so. — $0.05/call, x402 (USDC on base).

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max number of notices gov-tender-radar returns per query, per run. Higher means more thorough coverage but more of OUR compute (never billed to you beyond the per-tender price below).
`country`	No	ISO 3-letter buyer-country code to AND into every query, e.g. "DEU", "FRA". Leave empty for all EU countries.
`queries`	Yes	Keywords or TED expert-query expressions defining which tenders to watch — same syntax as gov-tender-radar (e.g. "software", "classification-cpv=72000000", "cloud AND classification-cpv=72*"). Every scheduled run re-checks these same queries and reports ONLY tenders not seen on a previous run for this watch.
`max_items`	No	Caps how many NEW-tender rows a single run will deliver and charge for, even if more were found.
`baseline_key`	No	A name for THIS watch, so you can run several independent tender watches from one Actor (e.g. "eu-it-services", "germany-construction") without one overwriting another's memory of what's already been seen. Each name is scoped to YOUR OWN Apify account — nobody else's watch is visible to you and vice versa. The prefilled value is only there so this Actor's own daily test run has a stable, obviously-a-test name; replace it with your own watch name.

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations, the description discloses stateful behavior (baseline creation on first run) and pricing ($0.05/call, USDC on base). Annotations are generic, so the description adds valuable context about side effects and cost. No contradiction.

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 two sentences plus a pricing note, front-loaded with the core functionality, followed by baseline behavior and cost. Every word earns its place, with no redundancy or fluff.

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?

For a stateful, paid alert tool with 5 parameters and no output schema, the description covers the essential behavior (change detection), baseline mechanics, and pricing. It could mention return format or explicitly direct to alternatives, but the schema and annotations fill most gaps, making it reasonably complete.

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 100%, so the baseline is 3. The description itself does not add parameter-specific details beyond the schema; it refers to a 'saved filter' but the schema already thoroughly explains queries, baseline_key, and limits. No extra semantic value is provided.

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 clearly states the tool watches public tender feeds and returns only what changed since the previous check, listing specific change types (new, closed, changed deadlines). This is a specific verb-resource pair and distinguishes it from sibling search tools like gov-tender-radar.

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?

The description makes clear this is for change monitoring rather than one-time searches ("only what changed since the previous check"), and mentions the baseline creation. However, it does not explicitly name alternatives or state when NOT to use it, so it lacks explicit exclusion guidance.

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

All Market and Regulatory Data Feeds — Zinin M2M Hub tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation2/5

Many tools have overlapping purposes, with over a dozen real-estate scrapers and half a dozen job boards differentiated only by geography. While descriptions are clear, an agent would struggle to pick the correct tool without prior knowledge of the specific site or region, leading to frequent misselection.

Naming Consistency2/5

Tool names use a mix of lowercase-hyphenated (boss-az, clinical-trials-monitor), underscore (pricing_info), and long descriptive phrases (official-gazette-regulatory-action-router). No consistent verb_noun pattern exists; some start with source domains, others with action nouns. This lack of predictability makes navigation confusing.

Tool Count3/5

36 tools is on the heavy side for a server that could have been more focused. While a 'data hub' can justify many endpoints, the high number of near-identical scrapers (12+ real estate, 6+ job boards) suggests bloat rather than well-scoped functionality. A leaner set with parameterized regional filters would be more appropriate.

Completeness2/5

The claimed domain 'Market and Regulatory Data Feeds' is poorly served: there are no stock/forex/commodity price feeds, few global regulatory sources (only FDA, SEC, EU tenders), and many tools are for job and property listings which are tangential. The set feels like a random aggregation rather than a coherent surface, with obvious gaps for core market and regulatory data.

Resources

Need Help?