Skip to main content
Glama
Sign In

fourzerotwo

by si.fourzerotwo
OverviewDiscussionsAdmin

Server Details

400+ data APIs for agents: UK companies, property, trade, tenders, recalls, sanctions. Free tier

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
Uptime
100.0% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
ChatGPT
–
Claude
–

TDQS

A4.5/5.0

Scored across 3 tools

Disambiguation5/5

The three tools have clearly distinct roles: list_apis browses API groups, search_apis finds a specific endpoint by keyword, and call_api executes an endpoint. The descriptions explicitly guide agents on when to use each, eliminating overlap.

Naming Consistency5/5

All names follow a consistent snake_case verb_noun pattern (call_api, list_apis, search_apis). There are no deviations or mixed conventions.

Tool Count5/5

Three tools perfectly match the server's purpose as a generic API gateway: browse, search, and execute. Each tool earns its place, and the minimal surface avoids redundancy while covering all necessary actions.

Completeness5/5

The discovery (list/search) and execution (call) lifecycle is fully covered for a catalog of 500+ endpoints. No obvious gaps exist for the stated purpose, and payment handling is integrated into call_api.

Available Tools

3 tools
call_apiCall a data APIA
Read-onlyIdempotent
Inspect

Run one endpoint by the tool name that search_apis returned, with that endpoint's parameters, and get its data back as JSON (with source and licence attribution). Endpoints with free_tier "free" or "sample" cost nothing within the daily allowance (100 calls/day anonymously, 500 with a free key). Otherwise the result is a payment request: pay in USDC via x402 and retry with _meta["x402/payment"]. Invalid arguments are rejected before any charge, and failed upstream calls are never charged.

NameRequiredDescriptionDefault
toolYesEndpoint tool name from search_apis, e.g. "uk-postcodes__lookup" or "sanctions__screen".
argumentsNoThe endpoint's parameters as listed in search_apis results, e.g. {"postcode": "SW1A 1AA"}.

Output Schema

NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the read/idempotent/open-world safety profile; the description adds substantial behavioral context beyond them: the daily allowance (100 anonymous, 500 with a free key), the x402 USDC payment flow, and the guarantee that invalid arguments or failed upstream calls are never charged. These are exactly the operational traits an agent must know before invoking.

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-loads the core behavior (run an endpoint, get JSON), then adds cost/payment rules compactly. Three dense sentences with little waste, though the payment detail is packed tightly enough to require re-reading.

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 enumerated, yet the description still notes attribution content. Combined with cost, payment, and error-charging rules, an agent has everything needed to call this correctly in the intended discovery workflow.

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?

Schema coverage is 100%, so the schema already documents both parameters, and it correctly points to search_apis results for the endpoint-specific arguments. It also surfaces the _meta["x402/payment"] retry field, which is not present in the schema (additionalProperties: false), adding genuine meaning beyond structured data.

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 (run), resource (one endpoint from search_apis), and return form (JSON with source/licence attribution). It is clearly distinguishable from list_apis and search_apis, which discover rather than invoke endpoints.

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?

Explicitly ties invocation to the tool name returned by search_apis, which establishes the required discovery-then-call workflow. It also explains when a call is free versus chargeable and how to retry with payment, but never states exclusions (e.g. do not call with arbitrary tool names).

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

list_apisList API groupsA
Read-onlyIdempotent
Inspect

Overview of every API group in the catalog: name, category, summary, number of endpoints and whether it has a free tier. Always free to call. Use it to browse; use search_apis to find a specific endpoint.

NameRequiredDescriptionDefault
categoryNoOptional category filter, e.g. "property".

Output Schema

NameRequiredDescription
apisYes
categoriesYes

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower. The description adds genuinely new context on cost ('Always free to call') and scoping (every group in the catalog), though it omits pagination behavior for a list-everything call.

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 tight sentences with zero filler: scope and returned fields first, then the routing rule. Every clause earns its place.

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 no explanation, and annotations carry the safety profile. For a single optional-param browse tool, the description plus structured fields give the agent everything needed to call it 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?

Only one optional parameter (category) and schema description coverage is 100%, so the schema already carries the semantics. The description adds no extra detail about the filter, which is the expected baseline when structured data does the work.

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 (list/overview) and resource (API groups in the catalog), and enumerates the fields returned (name, category, summary, endpoint count, free tier). It clearly separates itself from search_apis, which targets a specific endpoint.

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

Usage Guidelines5/5

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

Explicit routing: 'Use it to browse; use search_apis to find a specific endpoint.' The alternative sibling is named with the condition that selects it, so an agent can choose without opening either schema.

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

search_apisSearch data APIsA
Read-onlyIdempotent
Inspect

Find the right data endpoint for a task. Searches 500+ endpoints (UK legislation, Companies House, property prices, sanctions lists, vehicle tax, weather, earthquakes, arXiv/PubMed/Crossref papers, IP geolocation, GB electricity, ONS/World Bank/ECB economics, and more) by keyword and returns each match's tool name, parameters, price and free_tier. Always free to call. Next step: pass a returned tool name to call_api.

NameRequiredDescriptionDefault
limitNoMaximum results (default 20).
queryNoKeywords describing the data you need; every word must match. Examples: "postcode", "sanctions screen", "sold prices", "earthquake", "bank holiday".
categoryNoOptional category filter, e.g. "legal", "property", "finance", "research", "energy", "network". See list_apis for all categories.

Output Schema

NameRequiredDescription
totalYes
resultsYes

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already carry the read-only/idempotent/open-world safety profile, yet the description still adds material context: 'Always free to call' (cost/auth expectation) and the shape of each result. It does not discuss result limits or how partial keyword matches are ranked, but the added cost and return-shape context is genuinely useful beyond the annotations.

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 action and next step, with no filler sentences. The long parenthetical catalogue of domains is verbose but earns its place by helping the agent judge coverage.

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 spelled out, yet the description still names the key returned fields. Between the description and schema, an agent has everything needed to search, interpret results, and know the follow-up call.

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 query, limit and category are already documented in the schema. The description reinforces the keyword-search behavior but adds no syntax, format or matching-rule detail beyond what the schema states (e.g. it doesn't restate the 'every word must match' semantics or the limit cap).

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 ('Find the right data endpoint... Searches 500+ endpoints... by keyword') and enumerates the covered domains, making it unmistakable against siblings call_api and list_apis. The description also specifies exactly what each match returns (tool name, parameters, price, free_tier).

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?

Gives clear sequencing guidance with 'Next step: pass a returned tool name to call_api', which routes the agent after the search. It does not, however, say when to prefer list_apis (e.g. browsing by category) over keyword search, leaving that comparison to inference.

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. 3 tool updates
    • Changedcall_api6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / arguments / additionalProperties
        Added value: +true
      • changedInput schema / properties / arguments / description
        Previous value: -"The endpoint's parameters"New value: +"The endpoint's parameters as listed in search_apis results, e.g. {\"postcode\": \"SW1A 1AA\"}."
      • changedInput schema / properties / tool / description
        Previous value: -"Tool name from search_apis, e.g. \"uk-police__street-crime\""New value: +"Endpoint tool name from search_apis, e.g. \"uk-postcodes__lookup\" or \"sanctions__screen\"."
      • addedInput schema / properties / tool / pattern
        Added value: +"^[a-z0-9-]+__[a-z0-9-]+$"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The endpoint's JSON response. Proxied sources return {data, source{name, licence, attribution}}; first-party endpoints return their own documented object. List responses are wrapped as {result: [...]}.",
+  "type": "object"
+}
    • Addedlist_apis
    • Changedsearch_apis5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • addedInput schema / properties / category
        Added value: +{
+  "description": "Optional category filter, e.g. \"legal\", \"property\", \"finance\", \"research\", \"energy\", \"network\". See list_apis for all categories.",
+  "type": "string"
+}
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 20,
+  "description": "Maximum results (default 20).",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
      • changedInput schema / properties / query / description
        Previous value: -"Keywords, e.g. \"probate\" or \"postcode\""New value: +"Keywords describing the data you need; every word must match. Examples: \"postcode\", \"sanctions screen\", \"sold prices\", \"earthquake\", \"bank holiday\"."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "items": {
+        "properties": {
+          "api": {
+            "type": "string"
+          },
+          "category": {
+            "type": "string"
+          },
+          "description": {
+            "type": "string"
+          },
+          "endpoint": {
+            "type": "string"
+          },
+          "free_tier": {
+            "enum": [
+              "free",
+              "sample",
+              null
+            ],
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "params": {
+            "type": "array"
+          },
+          "price_usd": {
+            "type": "string"
+          },
+          "tool": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "tool",
+          "api",
+          "endpoint",
+          "price_usd"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total",
+    "results"
+  ],
+  "type": "object"
+}
  2. 2 tool updates
    • First observedcall_api
    • First observedsearch_apis

Related MCP Connectors

Related MCP Servers

  • oro-intel-mcp by oro-intel

    oro-intel-mcpofficial

    oro-intel
    A
    license
    Not graded
    quality
    D
    maintenance
    UK public procurement data for AI agents. Tenders, contracts, buyer and supplier profiles over MCP and REST. 250 free credits.
    MIT

  • LiveDataLink

    blackboxfoundry
    A
    license
    Not graded
    quality
    A
    maintenance
    62 real-time data tools for AI agents via MCP. Finance, crypto, FMCSA, sanctions, courts, weather, vehicles, cybersecurity. One bearer token, one bill. Free tier available.
    MIT
  • gapup-mcp by getgapup

    gapup-mcpofficial

    getgapup
    F
    license
    Not graded
    quality
    C
    maintenance
    100+ agent-payable C-suite expertises with x402 micro-payments — competitive intel, SEC filings, sanctions, KYC, clinical evidence, real estate, ESG. 183 tools, free tier 100 calls/month.
    1
    -
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