Skip to main content
Glama

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

by org.duckdns.gregswarm.api
OverviewDiscussionsAdmin

Server Details

Official open data as JSON: clinical trials, EU tenders, papers, apps, French firms, fuel, domains.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4/5.0

Scored across 7 tools

Disambiguation5/5

Each tool targets a completely different external data source and resource type (App Store apps, clinical trials, domains, fuel stations, French companies, scholarly works, EU tenders). There is no plausible overlap or risk of misselection between any pair.

Naming Consistency4/5

Names mostly follow a consistent lowercase hyphenated [subject]-[action] pattern (clinical-trials-monitor, eu-fuel-monitor, ted-tender-monitor, app-store-search, fr-company-search, scholarly-search). The only deviation is domain-availability, which lacks a clear action verb, but the overall convention is readable and predictable.

Tool Count5/5

Seven tools is a well-scoped count; each tool maps to a distinct open-data source and none feels redundant or padding. It stays comfortably within the 3-15 sweet spot.

Completeness3/5

The surface is a loose bundle of read-only sources rather than a coherent lifecycle, and several tools (clinical-trials-monitor, eu-fuel-monitor, ted-tender-monitor) are delta-only with no baseline listing or fetch-by-id, which are notable gaps. No get-detail operations exist for most resources, so agents cannot drill into a specific record.

Available Tools

7 tools
clinical-trials-monitorClinicalTrials.gov Study MonitorA
Read-onlyIdempotent
Inspect

Studies from the official ClinicalTrials.gov API v2 for a condition, phase and status, returning only the studies whose status, phase, enrollment or last update changed since your last run. Read from clinicaltrials.gov when called. Each result: nct_id, title, sponsor, phase, status, enrollment, start_date, completion_date, last_update_date, conditions, lead_intervention, first_country. 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.

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
phaseNoStudy phase to follow. Example: "PHASE2".
statusNoRecruitment status to follow. Example: "RECRUITING".
conditionNoDisease or condition to follow (for example breast cancer, type 2 diabetes, Alzheimer). Example: "breast cancer".
updated_sinceNoOnly studies whose record was last updated on or after this date (YYYY-MM-DD). Example: "2025-01-01".

Output Schema

NameRequiredDescription
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

TDQS

A4.1/5.0
Behavior4/5

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

Adds real context beyond annotations: a live call to clinicaltrials.gov on every invocation, a required RapidAPI key via X-RapidAPI-Key, and a free-tier limit of 50 requests/month. The one gap is the delta mechanism itself — it says results are filtered to what changed 'since your last run' but never explains how the last run is tracked, which matters for a read-only call with no state parameter.

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 the core purpose and delta behavior, then auth and rate-limit details. Dense but every clause carries information; the field list in the middle is slightly at odds with the existing output schema but not wasteful.

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 an open-world read tool it covers the essentials an agent needs to call it correctly: source, freshness semantics, auth header, quota. The unexplained 'last run' state tracking is the only remaining hole, and the output schema already covers return shape.

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% and both enums are documented inline, so the schema carries parameter meaning. The description restates the filter dimensions (condition, phase, status) without adding syntax, defaults, or interaction rules beyond the schema. Baseline 3 applies.

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+resource (studies from the ClinicalTrials.gov API v2) constrained by condition, phase and status, plus a distinctive delta filter: only studies whose status, phase, enrollment or last update changed. Siblings are all in unrelated domains (app store, fuel, tenders), so no ambiguity for selection.

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 'changed since your last run' framing makes the monitoring use case clear and distinguishes it from a plain one-shot search. However, it never explicitly says when not to use it, nor does it reference an alternative for a full unfiltered pull.

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

domain-availabilityBulk .com domain registration check via RDAPA
Read-onlyIdempotent
Inspect

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.

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

NameRequiredDescription
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

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.

eu-fuel-monitorEU Fuel Price Change Monitor (France, Spain)A
Read-onlyIdempotent
Inspect

Each run returns only the stations whose fuel prices changed since the last run, from the French and Spanish open government feeds, filtered by postcode prefix. Read from donnees.roulez-eco.fr, sedeaplicaciones.minetur.gob.es when called. Each result: country, station_id, postcode, address, city, lat, lon, diesel_eur_l, sp95_e5_eur_l, e10_eur_l, sp98_eur_l. 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.

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
countryNoWhich national feeds to read (empty: all). Example: ["FR", "ES"].
postcodeNoKeep stations whose postcode starts with this (28 is Madrid in Spain, Eure-et-Loir in France; 75 Paris; empty keeps all). Example: "28".

Output Schema

NameRequiredDescription
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

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the low-risk read profile is covered structurally. The description adds valuable non-schema behavior: live reads from two external government feeds, cross-run statefulness (only changed stations are returned), and an authentication requirement with a concrete rate limit. The RapidAPI URL given actually points at a 'clinical-trials-eu-tenders-open-data-api' listing, which is inconsistent with this tool and could mislead an agent setting up credentials.

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?

Front-loaded with the core behavior (delta results from two national feeds) and then layered with return fields, sources, and auth requirements. Three dense sentences with no filler; the only wasted content is the mismatched RapidAPI link.

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?

An output schema exists, yet the description also enumerates the returned fields, which is redundant but harmless. Sources, auth, rate limit, and delta semantics make it complete for correct invocation. The only real defect is the RapidAPI URL naming a different API, which leaves credential setup ambiguous.

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%: limit bounds and default, country enum values and empty-means-all semantics, and postcode prefix behavior are all documented in the schema. The description only restates the postcode-prefix filter. Baseline 3 is appropriate since the schema carries the parameter meaning.

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+resource (returns fuel stations whose prices changed), scoped to French and Spanish open government feeds and postcode-prefix filtering. It also names the upstream data sources (donnees.roulez-eco.fr, sedeaplicaciones.minetur.gob.es), so the agent knows exactly what is being read and no sibling tool overlaps this domain.

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 key usage context is explicit: results are delta-based ('changed since the last run') and filtered by postcode prefix, so an agent knows repeated polling is the intended pattern. Operational constraints (RapidAPI key via X-RapidAPI-Key header, 50 requests/month on the free plan) are stated. It stops short of explicit when-not-to-use or alternative-tool guidance, but no sibling is a plausible substitute.

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

ted-tender-monitorEU Public Tender Monitor (TED)A
Read-onlyIdempotent
Inspect

New public procurement notices from the EU's official TED search API for a CPV code prefix, buyer country and keyword, returning only the notices that are new or changed since your last run. Read from api.ted.europa.eu when called. Each result: notice_id, publication_date, buyer, country_code, title, cpv_codes, procedure, deadline, estimated_value, currency, url. 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.

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
countryNoCountry of the buying organisation, as a three-letter ISO code. Example: "FRA".
keywordNoOptional word that the notice title must contain. Leave empty to keep all notices. Example: "services".
cpv_prefixNoStart of the CPV code to follow (for example 72 for IT services, 45 for construction, 33 for medical equipment). Example: "72".
published_sinceNoOnly notices published on or after this date, written YYYYMMDD. Example: "20250101".

Output Schema

NameRequiredDescription
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

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, yet the description adds materially: it reads from api.ted.europa.eu at call time, requires a RapidAPI key sent as the X-RapidAPI-Key header, and discloses the free-plan limit of 50 requests per month. The delta-return semantics ('new or changed since your last run') is also behavioral context not expressed by any annotation. Minor tension with idempotentHint=true is arguable but not a contradiction, since this is a read-only query over changing data.

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 lead sentence is front-loaded with purpose, filters, and delta behavior; the auth and rate-limit facts follow in their own sentence. The enumerated result fields are the only borderline padding given a separate output schema exists, but they are compact and readable in one clause.

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?

With an output schema present, the description needn't explain returns, yet it also covers endpoint, auth, and quota — a lot for a single-tool definition. The remaining gap is statefulness: how 'last run' is tracked and what a first call returns is unstated, which matters for a zero-required-parameter tool.

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%, with every parameter documented including the CPV prefix examples and country enum, so the schema does the heavy lifting. The description restates the filter concepts but adds no syntax, default, or interaction detail beyond what the schema already provides, so the baseline 3 applies.

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 ('new public procurement notices from the EU's official TED search API') plus the three filter dimensions (CPV prefix, buyer country, keyword) and the delta scope ('only the notices that are new or changed since your last run'). An agent can distinguish it from siblings like clinical-trials-monitor or eu-fuel-monitor purely on domain 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?

Usage context is clear: it is a monitoring tool that returns deltas since the last run, with the keyword filter explicitly optional ('leave empty to keep all notices'). However, there is no explicit when-not guidance and no statement of what happens on a first run with no prior state, which is the one decision point an agent actually faces.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updates
    • Changedapp-store-search1 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"
+}
    • Changedclinical-trials-monitor1 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"
+}
    • Changeddomain-availability1 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"
+}
    • Changedeu-fuel-monitor1 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"
+}
    • Addedfr-company-search
    • Changedscholarly-search1 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"
+}
    • Changedted-tender-monitor1 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. 6 tool updates
    • Changedapp-store-search1 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": {
+          "app_id": {
+            "description": "app_id (id)"
+          },
+          "average_rating": {
+            "description": "average_rating (number)"
+          },
+          "average_rating_current_version": {
+            "description": "average_rating_current_version (number)"
+          },
+          "bundle_id": {
+            "description": "bundle_id (text)"
+          },
+          "content_rating": {
+            "description": "content_rating (text)"
+          },
+          "currency": {
+            "description": "currency (currency)"
+          },
+          "developer": {
+            "description": "developer (text)"
+          },
+          "developer_id": {
+            "description": "developer_id (id)"
+          },
+          "formatted_price": {
+            "description": "formatted_price (text)"
+          },
+          "minimum_os": {
+            "description": "minimum_os (text)"
+          },
+          "name": {
+            "description": "name (text)"
+          },
+          "price": {
+            "description": "price (price)"
+          },
+          "primary_genre": {
+            "description": "primary_genre (text)"
+          },
+          "rating_count": {
+            "description": "rating_count (integer)"
+          },
+          "rating_count_current_version": {
+            "description": "rating_count_current_version (integer)"
+          },
+          "release_date": {
+            "description": "release_date (datetime)"
+          },
+          "seller_name": {
+            "description": "seller_name (text)"
+          },
+          "size_bytes": {
+            "description": "size_bytes (integer)"
+          },
+          "store_url": {
+            "description": "store_url (url)"
+          },
+          "version": {
+            "description": "version (text)"
+          },
+          "version_release_date": {
+            "description": "version_release_date (datetime)"
+          }
+        },
+        "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"
+}
    • Changedclinical-trials-monitor1 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": {
+          "completion_date": {
+            "description": "completion_date (date)"
+          },
+          "conditions": {
+            "description": "conditions (list)"
+          },
+          "enrollment": {
+            "description": "enrollment (integer)"
+          },
+          "first_country": {
+            "description": "first_country (text)"
+          },
+          "last_update_date": {
+            "description": "last_update_date (date)"
+          },
+          "lead_intervention": {
+            "description": "lead_intervention (text)"
+          },
+          "nct_id": {
+            "description": "nct_id (id)"
+          },
+          "phase": {
+            "description": "phase (list)"
+          },
+          "sponsor": {
+            "description": "sponsor (text)"
+          },
+          "start_date": {
+            "description": "start_date (date)"
+          },
+          "status": {
+            "description": "status (text)"
+          },
+          "title": {
+            "description": "title (text)"
+          }
+        },
+        "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"
+}
    • Changeddomain-availability1 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"
+}
    • Changedeu-fuel-monitor1 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": {
+          "address": {
+            "description": "address (text)"
+          },
+          "city": {
+            "description": "city (text)"
+          },
+          "country": {
+            "description": "country (country)"
+          },
+          "diesel_eur_l": {
+            "description": "diesel_eur_l (price)"
+          },
+          "e10_eur_l": {
+            "description": "e10_eur_l (price)"
+          },
+          "lat": {
+            "description": "lat (lat)"
+          },
+          "lon": {
+            "description": "lon (lon)"
+          },
+          "postcode": {
+            "description": "postcode (id)"
+          },
+          "sp95_e5_eur_l": {
+            "description": "sp95_e5_eur_l (price)"
+          },
+          "sp98_eur_l": {
+            "description": "sp98_eur_l (price)"
+          },
+          "station_id": {
+            "description": "station_id (id)"
+          }
+        },
+        "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"
+}
    • Changedscholarly-search1 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": {
+          "cited_by_count": {
+            "description": "cited_by_count (integer)"
+          },
+          "doi": {
+            "description": "doi (text)"
+          },
+          "is_open_access": {
+            "description": "is_open_access (bool)"
+          },
+          "language": {
+            "description": "language (text)"
+          },
+          "oa_status": {
+            "description": "oa_status (text)"
+          },
+          "open_access_url": {
+            "description": "open_access_url (url)"
+          },
+          "openalex_id": {
+            "description": "openalex_id (url)"
+          },
+          "publication_date": {
+            "description": "publication_date (date)"
+          },
+          "title": {
+            "description": "title (text)"
+          },
+          "type": {
+            "description": "type (text)"
+          },
+          "venue": {
+            "description": "venue (text)"
+          },
+          "year": {
+            "description": "year (integer)"
+          }
+        },
+        "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"
+}
    • Changedted-tender-monitor1 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": {
+          "buyer": {
+            "description": "buyer (text)"
+          },
+          "country_code": {
+            "description": "country_code (text)"
+          },
+          "cpv_codes": {
+            "description": "cpv_codes (list)"
+          },
+          "currency": {
+            "description": "currency (text)"
+          },
+          "deadline": {
+            "description": "deadline (date)"
+          },
+          "estimated_value": {
+            "description": "estimated_value (number)"
+          },
+          "notice_id": {
+            "description": "notice_id (id)"
+          },
+          "procedure": {
+            "description": "procedure (text)"
+          },
+          "publication_date": {
+            "description": "publication_date (date)"
+          },
+          "title": {
+            "description": "title (text)"
+          },
+          "url": {
+            "description": "url (url)"
+          }
+        },
+        "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. 6 tool updates
    • First observedapp-store-search
    • First observedclinical-trials-monitor
    • First observeddomain-availability
    • First observedeu-fuel-monitor
    • First observedscholarly-search
    • First observedted-tender-monitor

Related MCP Connectors

Related MCP Servers

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