Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

instacart_trending

Fetch Instacart trending search terms for a US postal code across all serving retailers. See popular blank-state suggestions before typing.

Instructions

Get Instacart trending search terms near a postal code. Returns Instacart's own popular/trending search terms across every retailer serving a postal code -- the same blank-state suggestions shown before a user types anything into the search box. Public data sourced from Instacart's own cross-retailer search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
postal_codeYesUS postal/ZIP code to search near

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the data is public, comes from Instacart's cross-retailer search, and that results are popular/trending terms. No side effects or destructive actions are implied, which is appropriate for a read-only lookup. It doesn't cover rate limits or output formatting, but that's minor for this tool.

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?

Two sentences, no filler. Action verb and resource appear immediately, and every clause adds distinct value (scope, source, use case). Excellent front-loading.

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 single-parameter tool with no output schema, the description sufficiently conveys what is returned (trending search terms) and from where. It could specify whether results are ranked or limited, but this isn't essential for selection and invocation.

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% and the lone parameter postal_code already has a description. The tool description enhances it by noting results span 'every retailer serving a postal code,' clarifying the geographic scope and aggregation behavior beyond the schema.

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?

The description clearly states 'Get Instacart trending search terms near a postal code' with a specific verb, resource, and scope. It distinguishes from related tools like instacart_search by explaining it returns blank-state suggestions, not item search results.

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?

The description provides clear context on when to use it (to see popular/trending search terms across retailers for a location) and even illustrates the use case with 'blank-state suggestions.' It doesn't explicitly name alternative tools or exclusions, but the intent is unambiguous.

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