LLCDrop

Create a personalized sample page (LLCDrop staff keys only)

create_sample_page

Builds a personalized /s/ page of new Florida businesses from filters (county, city or zip; filing dates; industry) and returns its URL, expiry, row count and the filing range used. Without filed_from and filed_to it picks the latest complete Monday to Sunday week that is at least 90% classified, else the week before. Creates a public page: ask before calling. Customer keys get 403.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipient_name": "<recipient_name>",
      "recipient_company": "<recipient_company>",
      "sender": "<sender>",
      "title": "<title>",
      "vertical": "<vertical>"
    },
    "name": "create_sample_page"
  }
}

Input Schema

Name	Required	Description
`zip`	No	5-digit ZIP or a 3 to 4 digit prefix.
`city`	No	City of the businesses.
`intro`	No	Short intro paragraph.
`limit`	No	Most rows on the page (default 250).
`title`	Yes	Page headline.
`county`	No	Florida county of the businesses. County, city or zip is required.
`sender`	Yes	Who signs the page.
`filed_to`	No	Last filing day, YYYY-MM-DD.
`industry`	No	An industry key from list_industries.
`ttl_days`	No	Days until the page expires.
`vertical`	Yes	The recipient's own line of business.
`filed_from`	No	First filing day, YYYY-MM-DD. Send with filed_to, or neither.
`hide_pricing`	No	Enterprise prospects: no prices on the page.
`recipient_name`	Yes	Recipient's first name, shown on the page.
`exclude_sectors`	No	Sector keys to leave out. Default: holding_unknown, real_estate.
`recipient_email`	No	Recipient address, enables the follow-up sequence.
`show_enrichment`	No	Add the lead enrichment walkthrough (fictional sample) after the list.
`recipient_company`	Yes	Recipient's company.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond annotations: it discloses the public-facing side effect, the need to confirm before calling, the 403 for customer keys, and the fallback logic for choosing the latest complete Monday-to-Sunday week. It also summarizes the return values (URL, expiry, row count, filing range), which annotations alone do not cover.

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?

Three tight sentences, front-loaded with what the tool builds and returns, followed by the date default and the critical safety/auth warning. Every sentence supplies actionable information with no filler.

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?

For an 18-parameter creation tool with no output schema, the description covers the action, output shape, default date behavior, public-page risk, and auth constraint. What remains missing is delegated to a schema with full description coverage, so an agent has enough to call it correctly.

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 baseline is 3. The description adds meaning by explaining the county/city/zip filter combination and the default date-range selection when filed_from and filed_to are omitted, which is not captured in the schema. It does not discuss many optional parameters, but the schema carries those details.

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 ('Builds a personalized /s/<token> page of new Florida businesses'), names the filter dimensions, and distinguishes itself from the read-only siblings by calling out that it creates a public page. An agent can tell immediately that this is the sole page-generation tool in the set.

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 explicit operational guidance: 'ask before calling' for a public page, and 'Customer keys get 403' for auth. It does not name an alternative or state a when-not scenario beyond auth, but no sibling performs this creation, so the routing guidance is sufficient.

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

All LLCDrop tools Inspect

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

Need Help?