profullstack-mcp

Search Public Libraries

libraries_search

Read-onlyIdempotent

Public library branches within a radius (IMLS FY2024 survey). Bookmobiles excluded unless type includes "bookmobile". Distance is straight-line; card eligibility is reported separately.

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": "libraries_search"
  }
}

Input Schema

Name	Required	Description
`q`	No	Name, system or city filter
`lat`	No	Latitude in decimal degrees (use with lng)
`lng`	No	Longitude in decimal degrees (use with lat)
`zip`	No	5-digit U.S. ZIP code, e.g. "95032"
`city`	No	City name; needs state
`type`	No	Comma list of: central, branch, bookmobile, books_by_mail, other
`limit`	No	Results per page, 1-100 (default 25)
`state`	No	Two-letter state code, e.g. "CA"
`cursor`	No	next_cursor from a previous response
`strict`	No	Fail instead of returning partial coverage
`system`	No	Library system id or IMLS FSCSKEY, e.g. CA0115
`address`	No	Street address; needs zip or city+state. Sent to the U.S. Census Geocoder.
`country`	No	ISO country code; only "US" is supported
`radius_miles`	No	Search radius in miles (default 20, max 250)
`include_unresolved`	No	Also list records without coordinates (never counted as matches)

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the bar is lower, yet the description adds real substance: the data source and survey year, the default exclusion of bookmobiles with the override condition, the fact that distances are straight-line rather than routed, and that card eligibility is a separate reported field. It does not describe result ordering or what a partial-coverage response looks like, which is the main residual gap.

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 short sentences, front-loaded with the resource and data provenance, then the exclusion rule, then the two semantic caveats. No filler and no restatement of the tool name or annotations.

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?

For a 15-parameter, zero-required geospatial search with no output schema, the description covers provenance, default exclusions, distance semantics, and one return-value caveat (card eligibility). What is missing is any indication of the response shape or pagination behavior, which the absent output schema would otherwise have carried.

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 description coverage is 100%, so the baseline is 3. The description does add interpretive meaning for two parameters — it clarifies that type must include "bookmobile" to surface those records and that radius_miles is measured as straight-line distance — but it leaves the other thirteen parameters entirely to 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?

States a specific verb (search) and resource (public library branches) plus the underlying dataset vintage (IMLS FY2024 survey) and the primary scoping mechanism (radius). It is clearly a search endpoint distinct from the sibling library_get, though it does not name that sibling explicitly to route the agent.

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 rather than prescribed: the radius framing and the bookmobile note tell the agent what the default result set contains, but there is no explicit when-to-use guidance, no statement of when to prefer library_get or another source, and no prerequisites for the geo inputs.

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

All profullstack-mcp 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?