Leadgen ONRC Romania

Collect watchlist changes

poll_watchlist

Collect everything the watch tools have found: call it to drain the changeset for every watch owned by your API key, most severe first. Company watches return an 'updated' entry with the changed fields and risk; CAEN and county watches return the 'new' firms registered since the last poll (200 a poll, the rest next).

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	No	true when the poll ran.
`asOf`	No	What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.
`error`	No	Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.
`owner`	No	Whose watches these are (key prefix or IP).
`total`	No	Number of watches with news.
`active`	No	Every watch you hold, changed or not: kind (company or caen), target (CUI or code), county, since, name. Remove one with unwatch.
`message`	No	A sentence for the caller.
`watches`	No	Per watch: an 'updated' company with its changed fields and risk, or the 'new' firms registered in a watched activity.
`attribution`	No	The credit line to keep when redistributing the data (CC BY 4.0).
`email_alerts`	No	How to get the same changes by email.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 17, 2026

addedOutput schema / properties / active

Added value: +{
+  "description": "Every watch you hold, changed or not: kind (company or caen), target (CUI or code), county, since, name. Remove one with unwatch.",
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / properties / attribution

Added value: +{
+  "description": "The credit line to keep when redistributing the data (CC BY 4.0).",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedOct 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "What changed for your watches since the last poll, most severe first.",
+  "properties": {
+    "asOf": {
+      "description": "What to cite: registry (ONRC snapshot date), financialYear (fiscal year of the figures), anaf (day of the ANAF data), snapshot, published, source.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "email_alerts": {
+      "description": "How to get the same changes by email.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "error": {
+      "description": "Set only when there is no answer (empty_query, invalid_cui, data_unavailable, plan_required ...); such a call is not counted.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "message": {
+      "description": "A sentence for the caller.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "ok": {
+      "description": "true when the poll ran.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "owner": {
+      "description": "Whose watches these are (key prefix or IP).",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "total": {
+      "description": "Number of watches with news.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "watches": {
+      "description": "Per watch: an 'updated' company with its changed fields and risk, or the 'new' firms registered in a watched activity.",
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, and the description explains exactly why: 'drain the changeset' discloses that collection consumes/mutates the pending changeset state, and 'since the last poll (200 a poll, the rest next)' discloses the non-idempotent pagination cap. It also describes ordering ('most severe first') and the differing output shapes for company vs CAEN/county watches, which is well beyond what the annotations convey.

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?

Two sentences, tightly front-loaded with what the tool does and why, followed by the output and pagination details. Every clause earns its place with no filler or repetition of the title.

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 return values need not be explained, yet the description still summarizes the two result shapes ('updated' entries with fields and risk, 'new' firms for CAEN/county) and the 200-per-poll limit. For a zero-parameter polling tool, nothing an agent needs to invoke it correctly 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?

The tool takes zero parameters, so per the baseline the description carries no parameter burden beyond baseline 4. Schema coverage is 100% (empty object), and there is nothing in the parameter surface for the description to compensate for.

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 uses a specific verb ('Collect... drain the changeset') and resource ('every watch owned by your API key'), and it explicitly frames itself against the sibling watch tools that create the watches. An agent can distinguish this from watch_company/watch_caen/unwatch without opening any schema.

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 clearly establishes the context of use: call this to drain what the watch tools have found for your API key. It implies the setup/consume relationship with the watch_* siblings, but it never states when not to call it or names an explicit alternative (e.g., unwatch to stop collection).

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

All Leadgen ONRC Romania 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.