Skip to main content
Glama

Open data: clinical trials, EU tenders, companies, fuel prices

by org.duckdns.gregswarm.api
OverviewDiscussionsAdmin

Bulk .com domain registration check via RDAP

domain-availability
Read-onlyIdempotent

Check a list of .com domains in bulk and get the registrar, creation and expiry dates, status codes and nameservers straight from the Verisign registry's public RDAP service. Read from rdap.verisign.com when called. Each result: domain, registered, registrar_id, registrar_name, created_at, expires_at, status, nameserver_1, nameserver_2. Needs a RapidAPI key for this API (https://rapidapi.com/IanGregory/api/clinical-trials-eu-tenders-open-data-api), sent as the X-RapidAPI-Key header; the free plan has 50 requests a month.

Input Schema

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
domainsNoRegistered .com domain names to look up, e.g. ["example.com", "google.com"]. A name the registry does not know (available) returns a 404 and no row. Example: ["example.com", "google.com", "apify.com"].

Output Schema

NameRequiredDescriptionDefault
countYeshow many results came back
itemsYesthe results, one object each
partialNosome of the source's requests failed: the results are incomplete
productNo
sourcesNowhere the data came from: each source's name, licence and the attribution to show with it
fetched_atNowhen the source was read (Unix seconds)
truncated_fromNothe answer was cut to fit: this many results came back in all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / sources
      Added value: +{
+  "description": "where the data came from: each source's name, licence and the attribution to show with it",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "how many results came back",
+      "type": "integer"
+    },
+    "fetched_at": {
+      "description": "when the source was read (Unix seconds)",
+      "type": "integer"
+    },
+    "items": {
+      "description": "the results, one object each",
+      "items": {
+        "properties": {
+          "created_at": {
+            "description": "created_at (datetime)"
+          },
+          "domain": {
+            "description": "domain (text)"
+          },
+          "expires_at": {
+            "description": "expires_at (datetime)"
+          },
+          "nameserver_1": {
+            "description": "nameserver_1 (text)"
+          },
+          "nameserver_2": {
+            "description": "nameserver_2 (text)"
+          },
+          "registered": {
+            "description": "registered (bool)"
+          },
+          "registrar_id": {
+            "description": "registrar_id (id)"
+          },
+          "registrar_name": {
+            "description": "registrar_name (text)"
+          },
+          "status": {
+            "description": "status (list)"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "partial": {
+      "description": "some of the source's requests failed: the results are incomplete",
+      "type": "boolean"
+    },
+    "product": {
+      "type": "string"
+    },
+    "truncated_from": {
+      "description": "the answer was cut to fit: this many results came back in all",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Adds real value beyond the annotations: the upstream data source (rdap.verisign.com), the auth requirement (RapidAPI key in the X-RapidAPI-Key header), and a concrete rate limit (free tier 50 requests/month). One flaw: the cited RapidAPI URL points at a clinical-trials/tenders API, which is inconsistent with a domain lookup and could confuse credential setup.

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?

Front-loaded with what it does and where the data comes from, then auth and limits — a sensible priority order. The enumeration of nine result fields is partly wasted effort since an output schema already exists.

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?

Annotations cover safety, an output schema covers return values, and the schema covers params; the description fills the remaining gaps an agent needs to call it correctly — credentials, rate ceiling, data source, and the 404-for-available case.

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%, so both params (domains, limit) are already documented with examples and bounds. The description reinforces the input as a list of registered .com names and explains the 404/no-row outcome, but never mentions `limit` or the default of 100, so it adds only marginal semantics.

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?

Opens with a specific verb, resource, and scope: bulk-checking .com domain registrations, plus the authoritative source (Verisign RDAP). None of the sibling tools operate in this space, so the agent can place it immediately without consulting the 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?

The intended use case (look up registration data for a list of registered .com names) and one important edge behavior — unknown/available names return 404 and no row — are stated. It doesn't name alternatives or exclusions, but the sibling set contains nothing competitive, so the gap is minor.

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

All Open data: clinical trials, EU tenders, companies, fuel prices toolsInspect
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.

Resources