Skip to main content
Glama

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

by org.duckdns.gregswarm.api
OverviewDiscussionsAdmin

App Store App Search (iTunes API): prices, ratings, versions by country

app-store-search
Read-onlyIdempotent

Search Apple's App Store by keyword in any storefront country and get each app's developer, price, rating, version, release date, genre, size, minimum OS and store URL. Read from itunes.apple.com when called. Each result: app_id, name, developer, developer_id, bundle_id, price, formatted_price, currency, average_rating, rating_count, average_rating_current_version, rating_count_current_version, version, version_release_date, release_date, primary_genre, size_bytes, minimum_os, content_rating, seller_name, store_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.

Input Schema

NameRequiredDescriptionDefault
termNoKeyword to search for in the App Store (for example budget, photo editor, meditation). Example: "budget".
limitNoHow many apps to return (Apple allows up to 200 per search). Example: 50.
countryNoTwo-letter App Store country code, which sets the prices, currency and ratings returned. Example: "us".

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": {
+          "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"
+}
  3. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context: it hits the network on call ('read from itunes.apple.com'), requires a RapidAPI key via X-RapidAPI-Key, and caps at 50 requests/month. However, the RapidAPI signup URL points to an unrelated 'clinical-trials-eu-tenders-open-data-api', which is a misleading detail an agent might surface to a user.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, but it then enumerates all ~20 return fields, which duplicates the output schema and lengthens the definition without adding selection value. The auth and rate-limit notes earn their place; the field list does not.

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, so the field enumeration is redundant rather than necessary, and auth/rate-limit and country semantics are covered. Only gaps are the misleading API signup URL and no note on zero default limit behavior, but overall sufficient to call correctly.

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 examples for term, limit and country, so the schema does the heavy lifting. The description notes that country 'sets the prices, currency and ratings returned', which adds mild semantic value, but adds nothing about term or limit syntax. 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 (search) and resource (Apple's App Store) with clear scope: keyword search across storefront countries, returning a defined set of app attributes. It is unmistakable against the unrelated siblings like clinical-trials-monitor or domain-availability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context (keyword lookup in a given country storefront) but gives no explicit when-to-use/when-not guidance or alternatives. Since all sibling tools are in unrelated domains, there's little routing ambiguity, so implied usage is adequate but not strong.

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