Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

dollartree_search

Search Dollar Tree products and facets, or browse categories by navigation ID to retrieve products, pagination metadata, and filter options for follow-up filter requests.

Instructions

Search Dollar Tree products and facets. Searches the public Dollar Tree catalog or browses a category using its search dimension id. Returns products, pagination metadata, every context-specific filter group and option, and each option's upstream navigation state for follow-up filter requests. Sort values are the exact values used by Dollar Tree's storefront.

Input Schema

NameRequiredDescriptionDefault
qNoProduct search query; omit to browse the selected category or navigation state
sortNoExact storefront sort value (omit for relevance)
offsetNoZero-based upstream result offset
page_sizeNoResults per page
navigation_idNoSearch navigation id from dollartree_categories or a filter option
navigation_stateNoExact navigation_state returned by a filter option; mutually exclusive with navigation_id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does a fair job: it discloses what comes back (products, pagination metadata, filter groups/options, per-option navigation_state) and that sort values must match storefront-exact values. It doesn't mention rate limits or auth expectations, but for a public read endpoint those are minor omissions.

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?

Three sentences, front-loaded with purpose then return shape then sort caveat. Slightly dense but no wasted filler; the return-value enumeration is long yet informative.

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?

No output schema and no annotations, but the description compensates by describing return contents and pagination/follow-up flow. An agent can call it correctly and understand what to do with the response; only auth/error behavior is unaddressed.

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 every parameter including sort enums and navigation_id vs. navigation_state exclusivity is already documented. The description adds only marginal value, reinforcing that sort strings are exact storefront values and that navigation_state supports chained filter requests.

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 and resource ('Search Dollar Tree products and facets') and distinguishes two modes: catalog search vs. browsing a category via a search dimension id. It doesn't name sibling tools like dollartree_categories or dollartree_product in the description, so differentiation is only partial, but an agent can still tell what the tool does.

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?

Clearly frames the two usage contexts (query search vs. category/navigation browse) and hints at follow-up filter requests via navigation_state. It stops short of explicit when-not guidance or naming the sibling that supplies navigation_id, so it sits at 'clear context, no exclusions' rather than 5.

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

Deploy Server

Other Tools