reefapi-mcp
Server Details
One MCP for 160+ live web-data APIs — clean JSON from sites that block scrapers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 5 of 5 tools scored.
Each tool has a clearly distinct purpose: search_engines for keyword-based discovery, get_catalog for a full list, get_engine_schema for action overview, get_action_schema for detailed parameters, and call_engine for execution. No overlap.
Consistent snake_case with verb_noun pattern: search_*, get_catalog, get_*schema, call_engine. All follow a predictable structure.
5 tools is well-scoped for an API discovery and invocation workflow. It covers search, exploration, and execution without being excessive or insufficient.
The tool surface covers the full lifecycle: engine discovery (search_engines, get_catalog), action schema (get_engine_schema, get_action_schema), and execution (call_engine). No obvious gaps.
Available Tools
5 toolscall_engineAInspect
Call a ReefAPI engine action — POST //v1/ with params. Returns the uniform
{ ok, data, meta, error } envelope. Get param names from get_engine_schema first. Needs YOUR
ReefAPI key (the local server reads REEFAPI_KEY; the hosted server reads the Authorization: Bearer ak_live_... header you configure on the connection). Get a key at https://reefapi.com.
Failed calls cost no credits.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action to run on that engine (e.g. 'search'), as listed by get_engine_schema. | |
| engine | Yes | The engine's name to call (e.g. 'zillow'), as returned by search_engines or get_catalog. | |
| params | No | The action's parameters as a JSON object, e.g. {'query': 'NYC'}. Get the valid param names and values from get_action_schema first. Omit or pass null for actions that take none. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it is a POST (mutation), requires authentication (ReefAPI key), details the return envelope, and notes that failed calls cost no credits. Annotations only mark readOnlyHint false and openWorldHint true, so the description fills in essential operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured: purpose in first sentence, supporting details in subsequent sentences. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the return envelope. It covers all parameters, authentication, error cost, and references sibling tools for preparatory steps. The tool is complex (POST with dynamic params), but the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds extra guidance: for params, it advises using get_action_schema first; for engine and action, it references sibling tools for selection. This adds meaning beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: calling a ReefAPI engine action via POST with params. It distinguishes itself from siblings by referencing get_engine_schema for param names and get_action_schema for valid parameters, making it clear this tool executes actions rather than queries metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to call engine actions after getting param names from get_engine_schema. It mentions authentication requirements, key retrieval, and that failed calls cost no credits. It does not explicitly state when NOT to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_action_schemaARead-onlyIdempotentInspect
FULL detail for ONE engine action: every parameter (type, required, description, allowed_values dropdown, default, example, min/max), what it returns, pricing, and a ready-to-run example_params. Call this right before call_engine so you send valid params — invalid enum values are rejected with the allowed list.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | The action's name on that engine (from get_engine_schema, e.g. 'search'). Returns the full param detail (type, required, allowed_values, default, example, min/max), what it returns, pricing, and ready-to-run example_params. | |
| engine | Yes | The engine's name (e.g. 'zillow'), as returned by search_engines or get_catalog. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and openWorldHint, covering safety and idempotency. The description adds that it returns pricing and example_params, and warns about rejection of invalid enum values in call_engine. No contradictions, and the behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and details all key outputs. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description thoroughly explains what the tool returns: parameter details, return info, pricing, and example_params. It also specifies when to use it. Given the tool's simplicity (2 params), it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about parameters (e.g., 'allowed_values dropdown') but largely reiterates the schema descriptions. It provides no additional nuance beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'FULL detail for ONE engine action' and lists specific outputs (parameters, returns, pricing, example_params). It distinguishes from the sibling tool get_engine_schema by specifying it is for a single action, and explicitly advises using it before call_engine.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call this right before call_engine so you send valid params'. It also mentions that invalid enum values are rejected, guiding correct usage. Does not explicitly mention when not to use or alternative tools, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_catalogARead-onlyIdempotentInspect
The FULL ReefAPI catalog — EVERY engine with its one-line title, grouped by category. This is the whole menu (≈ a few thousand tokens); SCAN IT AND PICK THE BEST ENGINE YOURSELF. You are an LLM, so you match the user's intent semantically — across ANY language, typo, or phrasing — far better than a keyword search can. Use this whenever search_engines didn't surface the right engine (or to be sure you didn't miss a better one). After you pick: get_engine_schema(engine) -> get_action_schema -> call_engine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: mentions output size (few thousand tokens), advises LLM to scan and semantically match intent. No contradiction with readOnlyHint/openWorldHint/idempotentHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with key info, but includes lengthy imperative instructions to the LLM. Could be slightly more concise, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully describes the tool's purpose, output, and usage workflow. With no parameters and no output schema, the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description explains what is returned (full catalog) which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the FULL catalog with all engines, one-line titles, grouped by category. It distinguishes from search_engines as the complete listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: after search_engines didn't find the right engine or to be thorough. Also provides a clear workflow: get_engine_schema -> get_action_schema -> call_engine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_engine_schemaARead-onlyIdempotentInspect
COMPACT overview of ONE engine: every action with its description, required params and what it returns — but NOT the full param detail (kept lean so a 90-action engine stays token-cheap). Call this after search_engines to pick the right ACTION, then get_action_schema(engine, action) for that action's full params before call_engine.
| Name | Required | Description | Default |
|---|---|---|---|
| engine | Yes | The engine's name (the `engine`/`name` field from search_engines or get_catalog, e.g. 'zillow', 'amazon'). Returns each action with its description, required params, and what it returns. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is well-understood as a safe, read-only operation. The description adds value by explaining the compact nature and the rationale ('kept lean so a 90-action engine stays token-cheap'), which aids expectation-setting. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states purpose, then clarifies scope and limitations, and finally provides workflow context. Every clause serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains what the output contains (actions with description, required params, what returns) and the compact nature. With one simple parameter and clear sibling relationships, all necessary context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for the 'engine' parameter, and the description further clarifies its source ('the `engine`/`name` field from search_engines or get_catalog') and gives examples. With 100% schema description coverage, the description adds concrete context, earning an above-baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'COMPACT overview of ONE engine: every action with its description, required params and what it returns'. It effectively distinguishes from sibling tools by specifying the call order: after search_engines, before get_action_schema. This identifies a specific verb (get) and resource (engine schema) with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Call this after search_engines to pick the right ACTION, then get_action_schema(engine, action) for that action's full params before call_engine.' It also explains what not to expect ('NOT the full param detail') and provides a workflow, thus offering strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_enginesARead-onlyIdempotentInspect
Find the right ReefAPI engine for a task — pass ENGLISH keywords or a short natural-language use-case ("detect a website's tech stack", "company reviews", "check a package for vulnerabilities", "is this domain available"). The catalog is in English: if the end-user asked in another language, translate their INTENT into English keywords first (you are an LLM — do this inline). Ranks engines by how well the query matches each engine's name/title/category/ACTION descriptions (stem-matched, so plurals/word-forms still hit). Empty query = list all. Returns name/title/category/actions + match score. Call this FIRST, then get_engine_schema(engine) to pick an action. This is a fast keyword pre-filter — if the right engine isn't in the results (or you want to be sure), call get_catalog and pick from the full list YOURSELF (you semantically match any language/phrasing better than keywords).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | English keywords or a short use-case, e.g. 'company reviews', 'detect a website's tech stack', or 'is this domain available'. Translate non-English intent to English first. Empty = list all engines. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals behavioral traits beyond the readOnlyHint, openWorldHint, and idempotentHint annotations. It explains that matching is stem-matched, results include a match score, and the tool works best with English keywords. It also advises fallback to get_catalog for better semantic matching, adding valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes all necessary details. While slightly lengthy, every sentence is informative. Minor redundancy in the translation instruction could be trimmed, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (1 parameter, no enums) and no output schema, the description fully explains what the tool returns (name/title/category/actions + match score) and the expected workflow. It covers the complete context needed for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the 'query' parameter with a detailed description. The tool description adds further meaning by elaborating on usage: pass English keywords or use-case, translate non-English intent, and empty query lists all. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find the right ReefAPI engine for a task' using natural-language keywords. It specifies the verb (search/find) and resource (engines), and distinguishes itself from sibling tools like get_catalog by positioning itself as a fast pre-filter to call first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this FIRST, then get_engine_schema(engine) to pick an action. This is a fast keyword pre-filter — if the right engine isn't in the results (or you want to be sure), call get_catalog.' It also instructs to translate non-English queries to English, leaving no ambiguity about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!