Skip to main content
Glama
Sign In

LocationLists

by io.github.kylehawke-stack
OverviewDiscussionsAdmin

Price a list the user wants to sell (free)

price_my_list
Read-onlyIdempotent

For a user who HAS a list of business locations and wants to sell it on LocationLists. Free, nothing is stored. Give what the list is (one sentence), about how many rows, and the price they have in mind in US dollars: the result says whether that price holds up against our ladder and the closest lists already on the site, what the seller would keep (80%), and the price we would list it at. Prices end in 9, $9 to $999. Then sell_list hands the file over. The same check in a browser: https://locationlists.com/sell.

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": {
      "what": "<what>",
      "rows": "<rows>",
      "target_usd": "<target_usd>"
    },
    "name": "price_my_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
rowsYesAbout how many rows (locations) the list has
whatYesWhat the list is, in the user's words: 'Florida marinas with slip counts, from marina websites and county records'
target_usdYesThe price the user has in mind for the whole file, US dollars

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: it is free, nothing is stored, and it spells out the return contents (price validation against the ladder and existing lists, 80% seller take, proposed listing price). The pricing constraint ('Prices end in 9, $9 to $999') is behavior an agent could not infer from 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?

Front-loads the audience and the free/no-storage guarantee, then the inputs, then the outputs. The middle sentence is long and packs several clauses together, but nearly every clause carries information an agent needs.

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?

There is no output schema, so the description carries the return-value burden and does so fully: it names the three result components and the pricing rule. Combined with the explicit next-step tool and browser fallback, an agent has everything needed to call and interpret it.

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, but the description adds real meaning: 'what' should be one sentence, 'rows' is approximate, and 'target_usd' is the seller's intended whole-file price in USD. It also implies the valid price band, which helps the agent shape inputs rather than just pass them through.

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 ('price a list the user wants to sell'), names the platform, and explicitly distinguishes itself from the sibling sell_list ('Then sell_list hands the file over'). An agent can tell exactly what this does 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 Guidelines4/5

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

Gives a clear precondition ('For a user who HAS a list of business locations and wants to sell it') and routes to the follow-up tool sell_list, plus a browser alternative URL. It stops short of stating when NOT to use it (e.g., for buyers or users without a list), but the context is unambiguous.

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

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