Skip to main content
Glama
Sign In

LLCDrop

by com.llcdrop
OverviewDiscussionsAdmin

Search business websites

search_business_websites
Read-onlyIdempotent

Search business websites: business website rows, with filters. Paged by cursor. One row per business, with its best domain. Email addresses are never returned, only whether one exists. Follow next_cursor until has_more is false. Each row returned counts toward your record 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": "search_business_websites"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRows per page, 1 to 1000. Cut down to your plan's row limit.
cursorNoThe next_cursor of the previous page. Omit for the first page.
statusNoComma list of live, parked, no_dns, no_site.
has_emailNotrue for businesses with a known email, false for those without. The address is not returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only and idempotent safety, so the description earns credit for adding non-obvious traits: cursor pagination with has_more termination, email addresses withheld (existence only), and that each returned row consumes record credits. No mention of what 'best domain' means or what happens at cursor expiry.

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?

Six short sentences, front-loaded with purpose and scope, then paging rules and the credit cost warning. Minor friction: it says to follow 'next_cursor' while the input parameter is named 'cursor', which could momentarily confuse an agent assembling the next call.

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?

Given no output schema, the description covers the essentials an agent needs: row shape (one per business, best domain), email non-disclosure, pagination loop, and billing impact. Gaps are modest — it doesn't define which filter values combine or how status lists intersect.

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 coverage is 100%, so all four parameters are already documented, including enum-like values for status and has_email. The description adds only the framing that filters exist and reinforces the privacy behavior of has_email; it introduces no syntax or default details beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource ('Search business websites') and clarifies granularity: one row per business, with its best domain. That distinguishes it from get_business_websites (per-business lookup) without naming the sibling explicitly.

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?

Usage is implied through the filter-oriented framing, but there is no explicit statement of when to use this search instead of get_business_websites or search_businesses. The agent must infer the choice from naming alone.

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

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