Skip to main content
Glama
Sign In

BuiltWith

by io.github.builtwith
OverviewDiscussionsAdmin

mcp-list-api

Search and browse remote MCP servers in the BuiltWith MCP registry (v2). Requires a BuiltWith API key supplied as a bearer token. Provide search, category, or both. Returns up to 100 results per page as a JSON array of {Domain, Category, Description, Endpoints: [{Endpoint, AuthRequired, Tools: [{Name, Description}]}], first_detected, last_detected}, and preserves the complete API response including any fields added in the future. Uses no API credits.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "mcp-list-api"
  }
}

Input Schema

NameRequiredDescriptionDefault
offsetNoZero-based pagination offset (default 0; page size is 100)
searchNoKeyword matched against MCP server domains and descriptions; required when category is omitted
categoryNoMCP registry category slug; required when search is omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

The description adds substantial context beyond the annotations: an API key delivered as a bearer token, a 100-result page cap, and the fact that the call consumes no API credits. It also discloses that the full upstream response is preserved, including future-added fields. The one gap is that annotations declare readOnlyHint=false for what reads like a pure search operation, and the description does nothing to clarify whether any side effects or state changes occur.

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 front-loaded with purpose, then moves through auth, parameter requirements, and response shape in a logical order with no filler sentences. The inline field enumeration of the return object is dense and slightly long, but it carries real information rather than padding.

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 no output schema, the description correctly takes on the burden of describing the return shape, pagination, auth, and credit cost, and it does so. The remaining gap is error behavior when neither search nor category is supplied, despite both being schema-optional. For a three-parameter read tool this is close to complete.

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 already 100%, so the baseline is 3, but the description earns more by stating that search, category, or both must be supplied even though the schema marks both as optional (required: []). It also restates the 100-item page size, which contextualizes the offset parameter. That constraint is genuine meaning added on top of the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 'Search and browse remote MCP servers in the BuiltWith MCP registry (v2).' That is far more informative than the name alone, and the registry scope implicitly separates it from the other BuiltWith API wrappers. It stops short of explicitly distinguishing itself from the sibling mcp-list-categories, so it is clear but not fully sibling-differentiated.

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?

'Provide search, category, or both' gives concrete invocation guidance and the bearer-token prerequisite is stated up front. However, there is no explicit when-to-use versus when-not-to-use guidance, and no pointer to mcp-list-categories for the case where the agent does not yet know a category slug. Usage is implied rather than spelled out.

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

All BuiltWith 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