Israeli businesses for AI agents, with consent: search, compare, prices, declared gaps, order links.
Scored across 6 tools
Each tool targets a distinct user need: browsing without a name, searching a named product, fetching a specific product, getting store-level facts, getting recommendations, and starting an order. The descriptions explicitly differentiate the overlapping discovery tools, so an agent should rarely misselect.
All tool names follow the same clean verb_noun pattern: browse_products, get_product, get_store_info, recommend_products, search_products, start_order. The naming is predictable and immediately signals the action and resource involved.
Six tools is well-scoped for a catalog-and-order scaffold: discovery, product detail, store context, recommendations, search, and order initiation are each represented once. No tool feels redundant or missing at a high level.
The surface covers the full shopping-agent workflow from open-ended browsing to named search to product lookup to order start, while also providing store-level context and explicit unknown fields. The design intentionally delegates checkout and contact entry to the store's own pages, so there are no dead ends within its stated purpose.
Walk the catalog without naming a product: cheapest first, most expensive first, within a price range, or inside one category. Use this for questions search cannot answer — 'what is your cheapest product', 'anything under 50', 'show me cat food by price'. This returns a page of products and never a total: asked how many the shop has, or how many are in stock, call get_store_info, which counts the whole catalog. Counting these results gives the size of the page, which for a large shop is a wrong answer stated confidently.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Default 'spread' — a range across the catalog rather than a price order. | |
| limit | No | How many to return (1-50, default 20). | |
| category | No | Optional words the product should match, e.g. 'מזון לחתולים'. | |
| max_price | No | ||
| min_price | No | ||
| in_stock_only | No | Default true. Out-of-stock products cannot be bought. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool returns a page of products, never a total, and warns that counting results yields a wrong answer. It does not cover output shape or error behavior, but the core behavioral caveat is clearly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but every sentence earns its place: it gives examples, routes to siblings, and warns about a common mistake. It could tighten some phrasing, but the structure front-loads the core purpose before caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description covers the essential selection and invocation behavior well. It lacks explicit return-field details and any mention of pagination mechanics beyond 'a page', but the tool's optional-parameter complexity is modest and the core caveat about totals is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with min_price and max_price lacking descriptions. The description compensates by explaining price-range and category semantics through examples and by describing the 'spread' sort concept. It adds practical meaning beyond the raw enum and field names, though min/max are only implied rather than explicitly named.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses the catalog without requiring a product name, listing concrete modes: cheapest, most expensive, price range, or category. It also differentiates from siblings by explicitly saying this is for questions search cannot answer and contrasting it with get_store_info for counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance with real example queries ('what is your cheapest product', 'anything under 50') and names the alternative for counting ('call get_store_info'). It also warns against a misuse: counting the returned page as the total catalog size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one product by its id, with every field the store's feed carries.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It communicates that the operation is a read-only fetch and that the result contains every field carried by the store's feed, which is useful behavioral context. It does not mention not-found behavior or data freshness, but for a simple get-by-id tool the stated behavior is largely sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every part adds information: the operation, the target, and the completeness guarantee. It is appropriately sized for the tool's low complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and no output schema. The description tells an agent what it will receive and what the input means. It does not enumerate the feed fields or define the id format, but given the low complexity and clear sibling set, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does identify id as the lookup key, but it adds little beyond the schema property name: it does not specify id format, source, or uniqueness assumptions. For a single required string parameter this is adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Fetch one product by its id.' The additional clause 'with every field the store's feed carries' clarifies that this returns the complete product record, which distinguishes it from browsing, searching, or recommending actions among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that this tool is for retrieving a single product when its id is known. It does not explicitly mention alternatives or exclusions, but the contrast with browse_products and search_products is strongly implied. An agent can reasonably infer when to choose this tool over list-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything the store says about itself, not about one item: what the business is, where it is, its capacity, what is included, its policies and hours, how an order reaches it and on what number, how many products it carries and how many of those are in stock, its price range — and, importantly, a list of what it has NOT stated. This is the tool for 'how many do you have', 'how do I order' and 'what is your phone number'. Call it before answering a question about suitability, and never fill a gap the 'unknown' or 'not_stated' lists name; tell the shopper to ask the business instead.
| Name | Required | Description | Default |
|---|---|---|---|
| store | No | Which business, by name or part of it. Omit to get every business on this endpoint; an endpoint that serves one shop ignores it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden, and it does so well by explaining that the tool returns self-reported facts, including what the store has NOT stated. It also prescribes the agent's behavior around unknown/not_stated gaps. It does not explicitly state read-only status or mention authorization, but the 'store says about itself' framing and get_ name imply a safe, non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but each clause earns its place: scope boundary, content inventory, example queries, and the critical unknown/not_stated policy. It front-loads the core 'not about one item' distinction. It could be tightened slightly, but there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by detailing what the agent will find: business identity, location, capacity, policies, hours, ordering contact, product counts, price range, and notably what is not stated. Combined with 100% parameter schema coverage and explicit usage rules, the agent has enough to call the tool and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 even without parameter detail in the description. The sole parameter 'store' is already documented in the schema, including the omit behavior for multi-store endpoints. Nothing further is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific operation: retrieving a business's self-declared information, not item-level data. It explicitly distinguishes itself from item-focused siblings via 'not about one item' and enumerates the information categories an agent can expect. The 'get' + resource framing makes selection obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: call it for 'how many do you have', 'how do I order', and 'what is your phone number', and before answering suitability questions. It also states a clear when-not-to-act rule: never fill gaps the 'unknown' or 'not_stated' lists name, and instead tell the shopper to ask the business. This is strong routing guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this store carries, spread across its categories. Use when the shopper asks for a suggestion without naming a product.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many to return (1-50, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description only says it lists products; it doesn't mention whether results are curated, random, or sorted, nor does it disclose any side effects (none expected). It also doesn't clarify pagination or that the limit parameter controls the number of results beyond the schema. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both information-dense and free of fluff. The primary purpose is stated first, followed by usage guidance. There is no redundancy or filler, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential purpose and usage trigger. It doesn't explain return format or any edge cases, but given the low complexity and the presence of sibling tools for other scenarios, this level of detail is sufficient. It could be more complete with a note about default behavior, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (limit) with a description, and coverage is 100%, so baseline is 3. The tool description adds no parameter-specific details beyond what the schema already provides. Since it doesn't need to compensate for low coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool returns what the store carries across categories, which is a clear resource and action. It also differentiates from siblings by specifying it's for suggestions without a product name, though it doesn't detail the nature of recommendations (e.g., popularity, random). This is a clear purpose, but not maximally specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'when the shopper asks for a suggestion without naming a product.' This gives a clear trigger condition, though it doesn't explicitly name alternatives or when not to use it. Still, it implies that other tools (like get_product or search_products) are for named products, so guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search this store's catalog. Returns matching products with id, title, price, availability and a direct link. Purchase happens on the store's own site: send the buyer to the link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many results to return (1-50, default 20). | |
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: the tool only returns a direct link, and the actual purchase occurs externally—preventing an agent from mistakenly trying to order through this tool. It does not state read-only semantics or error behavior, but the explicit external-purchase disclosure is substantial added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight, front-loaded sentences: what the tool does, what it returns, and the critical instruction for the agent. No filler, no repetition of schema details, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers the essential return fields (id, title, price, availability, direct link) and the external-purchase behavior, giving an agent enough to invoke and use the tool correctly. Minor gaps remain—query-matching semantics, pagination, and error handling—but they are not critical for a simple catalog search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: 'limit' has a schema description, but 'query' does not. The description merely restates 'Search this store's catalog' without explaining what a valid query is (e.g., product name, keyword, SKU) or how matching works. Since query is required and undocumented in both schema and description, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search this store's catalog.' It then states exactly what the tool returns (id, title, price, availability, direct link), which distinguishes it from siblings like browse_products (browsing vs. searching), get_product (single product retrieval), and start_order (purchase). The external-purchase note further clarifies this tool's role in the catalog-to-purchase flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context and an actionable directive: 'send the buyer to the link' because purchase happens on the store's own site. This tells the agent when and how to use the tool's output. It does not explicitly contrast with alternatives like browse_products or recommend_products, so it falls short of a full when/when-not statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an order or an enquiry with one of these businesses. Use it once the buyer has chosen — it returns the page that composes the message, the route it will leave by (WhatsApp, email or the business's own form) and the reference the order will carry, so the business can later confirm where it came from. Hand the buyer 'order_page'. Do NOT ask for their name or phone number to pass in here: they type those on that page, and nothing about them is sent to AgentFeed. A business with an online checkout returns its cart route instead, and one that published no way to be reached says so.
| Name | Required | Description | Default |
|---|---|---|---|
| what | No | What the buyer needs, in their own words — it fills the first field of the message. | |
| store | Yes | Which business, by name or part of it. | |
| product | No | Optional product id, when the order is for one item. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and meets it: it discloses the returned page, route, and reference, the cart-route variant, the no-way-to-be-reached case, and that no buyer PII is sent to AgentFeed. This goes well beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational value: purpose, trigger, output, next action, privacy constraint, and edge cases. Key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 must explain what the tool returns; it does (message page, route, reference) and tells the agent exactly what to do with the result. It also covers the important business-specific variants and failure case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameters. The description adds useful semantics by saying 'what' is the buyer's words and fills the first message field, and by explicitly excluding name/phone from the inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Start an order or an enquiry with one of these businesses.' It also names what the tool produces (message page, route, reference), which clearly distinguishes it from the browse/search product siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger: 'Use it once the buyer has chosen' plus concrete operational constraints ('Hand the buyer order_page', 'Do NOT ask for their name or phone number'). It does not explicitly contrast with sibling discovery tools, but the timing and prerequisites make the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
browse_productsget_productget_store_inforecommend_productssearch_productsstart_orderRegistry of companies selling AI agents identity, phone, email, addresses, money, legal, insurance
Verified local businesses, bookable by AI agents: services, prices, availability and appointments.
Owner-verified local business data for AI agents: profiles, hours, prices, with provenance.
AI agent product discovery via open marketplace. Search, compare and discover advertiser products.
Add one secure layer between your agents and this server.
