Skip to main content
Glama

apis-io

by io.apis
OverviewDiscussionsAdmin

request_check

INFLUENCE — ask APIs.io to (re)check something. Use it when a listing is wrong or stale, when a score looks incorrect, or to get a company profiled that is not in the catalog yet. A check can target a PROVIDER (the default) or a slice of the catalog: an industry, a tag, an area, or a company's estate — for an industry roster missing an obvious member, a tag that has drifted, or an area whose ranking looks wrong. This does NOT score anything on the spot: a check means re-running the enrichment pipeline against the live surface, which a person does by hand. You get a request id back immediately; poll check_status with it, and if you supply a contact email you are notified when the status changes. A slug we do not already hold is never refused — for ANY target type it is queued as a request to ADD that thing, whether that is a company nobody has catalogued, a new industry, or an estate nobody here has thought of. Near matches come back alongside it in did_you_mean, so a typo is visible without the request being dropped. Priced B4 (human work) — included in Influence; otherwise $99.00 as a one-off with its own receipt, never from a prepaid balance. If this is your own company and our data about it is wrong, report_correction is free. See apis://prices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe company or developer-portal URL — use this when there is no listing yet. Providers only; a url cannot name an industry.
kindNorecheck an existing listing, profile a new company, or correct a specific fact.
slugNoThe target slug — a provider (e.g. stripe), or an industry/tag/area/estate slug when target_type says so.
notesNoWhat is wrong, or what to look at. The more specific, the faster it is worked.
contactNoEmail to notify when the status changes. Optional; without it there is nothing to notify, so keep the id.
contextNoOptional: why you are asking. One sentence — the task you are trying to complete, or what you expect to get back. Never included in the answer and never used to rank; it is read only when a result turns out to be wrong, which is when knowing the intent is what makes the report actionable.
target_typeNoWhat `slug` names. Defaults to provider. `estate` is named for the company the estate roots at (e.g. cisco).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / slug / description
      Previous value: -"apis.io provider slug, if it is already listed (e.g. stripe)."New value: +"The target slug — a provider (e.g. stripe), or an industry/tag/area/estate slug when target_type says so."
    • addedInput schema / properties / target_type
      Added value: +{
+  "description": "What `slug` names. Defaults to provider. `estate` is named for the company the estate roots at (e.g. cisco).",
+  "enum": [
+    "provider",
+    "industry",
+    "tag",
+    "area",
+    "estate"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / url / description
      Previous value: -"The company or developer-portal URL — use this when there is no listing yet."New value: +"The company or developer-portal URL — use this when there is no listing yet. Providers only; a url cannot name an industry."
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the sparse annotations (readOnlyHint=false, destructiveHint=false): it reveals that the check is async and manually run against the live surface, returns a request id immediately, never refuses unknown slugs and instead queues an ADD, includes did_you_mean near matches, and may notify a contact email. It also discloses pricing and billing behavior, which an agent would not otherwise know. No contradiction with 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?

The description is long but earns its length: it opens with the core action, then gives usage cases, behavioral caveats, return behavior, pricing, and a routing alternative. Some repetition exists around unknown slugs and the 'check' concept, but nothing is filler, and the structure is logical.

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 a 7-parameter tool with no output schema, this description is quite complete: it explains the async response (request id, did_you_mean, optional notification), the human-run pipeline, and the pricing context. The main gap is that it doesn't specify how parameters should be combined (e.g., when url vs slug is appropriate relative to kind), leaving some inference to the agent despite the rich prose.

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 all parameters; the description adds genuine extra meaning by explaining that url is provider-only and cannot name an industry, that unknown slugs are treated as ADD requests for any target_type, and that estate is named after the root company. It does not map every kind/target_type combination, but it significantly enriches the schema.

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 names the action and resource clearly: 'ask APIs.io to (re)check something' and enumerates the target types (provider, industry, tag, area, estate). It also separates itself from related siblings by referencing check_status for polling and report_correction as the free alternative, so an agent can tell this tool apart without opening 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 Guidelines5/5

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

It gives explicit when-to-use conditions: stale listings, incorrect scores, or unlisted companies to profile, with concrete examples for each target type. It also states when not to use it ('does NOT score anything on the spot') and points to alternatives: poll check_status for the outcome and report_correction for free corrections about your own company.

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

All apis-io 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