Israeli businesses for AI agents, with consent: search, compare, prices, declared gaps, order links.
Scored across 7 tools
The three product-retrieval tools (search_products, browse_products, recommend_products) have overlapping surfaces but are distinguished by clear use cases: search by words, browse without naming a product, and recommend for open-ended suggestions. build_cart and start_order are also adjacent (both about ordering) but descriptions separate multi-item baskets from starting an order/enquiry. An agent could still occasionally misselect among the product-listing tools.
All tool names follow a consistent snake_case verb_noun pattern: browse_products, build_cart, get_product, get_store_info, recommend_products, search_products, start_order. There are no deviations in style or convention.
Seven tools is well-scoped for a shopping/catalogue server, covering discovery, detail lookup, cart building, and order initiation without redundancy. Each tool has a distinct role in the workflow.
The surface covers the full consumer lifecycle: search, browse, recommend, product details, store info, build cart, and start order. Minor gaps exist, such as no explicit order-status or tracking tool, but these are outside the clearly stated scope and agents can work around them by directing users to the business's own site.
Walk the AgentFeed catalogue of Israeli businesses 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 zero annotations, the description carries the full burden and delivers: it discloses that the tool returns a page, never a total, and warns against the confidence trap of counting page results as a total — a genuinely valuable behavioral caution. It does not cover every trait (return format, currency of price bounds, rate limits), but the most consequential behavior is clearly exposed.
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?
Four sentences, no filler: purpose, usage examples, behavioral limitation, and sibling routing each earn their place. The critical warning about page-vs-total is front-loaded near the usage guidance where it will actually affect reasoning.
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 6-parameter tool with no output schema and no annotations, the description covers the essential operational facts: when to use it, what it cannot do, and which sibling to call instead. Minor gaps remain — currency denomination for min/max_price (implied shekels via 'Israeli businesses') and what 'spread' ordering concretely yields — but nothing that would cause a confidently wrong call.
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%: max_price and min_price lack schema descriptions, and the description compensates by explaining the price-range browsing mode with the example 'anything under 50'. It also maps category to the phrase 'inside one category' and clarifies sort intent ('cheapest first, most expensive first'). This adds meaning beyond the schema's enum labels.
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: 'Walk the AgentFeed catalogue of Israeli businesses without naming a product.' It enumerates the four browsing modes (cheapest, priciest, price range, category) and explicitly separates itself from search ('Use this for questions search cannot answer'), differentiating it from search_products among the 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?
Provides concrete trigger examples ('what is your cheapest product', 'anything under 50', 'show me cat food by price') that a caller can match against a user question. It also gives an explicit exclusion: when asked for totals or stock counts, route to get_store_info instead. This is exactly the when/when-not/alternatives guidance the dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Put several products into a basket in one step, across one or more Israeli businesses on AgentFeed. Pass the ids that search_products / browse_products / get_product returned, with quantities. Returns, per shop, a link that loads the items into that shop's own cart (or, for a business that takes orders by message, its order page with the list), the subtotal from the shop's published prices, and what is not known (shipping is set at the shop's checkout). Use it once the shopper has agreed to the items. Never ask for card details: the shopper pays on the shop's own site.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole burden and does well: it discloses the cross-business scope, that returns are per-shop links plus subtotals, that shipping is unresolved until the shop's checkout, that message-based businesses get an order page instead, and that payment happens off-site. It omits whether this creates persistent server-side state and any auth expectations, which keeps it out of the top band.
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?
Front-loaded with the action, then inputs, outputs, and constraints in three tight sentences; almost no waste. The closing no-card-details sentence is a policy aside that is slightly tangential but does earn its place as a guardrail.
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?
No output schema exists, and the description compensates by describing the return shape (per-shop cart link or order page, subtotal, unknown shipping). It is complete enough for an agent to call it correctly, with only auth/state side effects left unstated.
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 0%, so the description must compensate, and it does: it defines the items payload as ids returned by the sibling lookup tools with quantities, which is the key meaning an agent needs. It does not cover the quantity bounds (1-99) or what happens when one id maps to a different shop, but the core semantic is supplied.
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?
States a specific verb and resource ("Put several products into a basket in one step") and scopes it to AgentFeed businesses. It is clearly distinguishable from the sibling readers (search_products, browse_products, get_product) and from start_order, since it builds a basket rather than ordering.
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 says where the ids come from (the sibling search/browse/get tools) and when to invoke it ("once the shopper has agreed to the items"), plus a hard prohibition on collecting card details. It does not explicitly contrast itself with start_order or say when a single-shop flow should be preferred, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one product from an Israeli business on AgentFeed by its id, with every field the business's feed carries.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does state that the tool fetches a single product and returns all fields from the business's feed, which implies a read-only operation and indicates the response content. However, it does not disclose behavior for invalid/missing ids, error responses, rate limits, or idempotency, which are important for a fetch tool with no annotation safeguards.
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, concise sentence that front-loads the core action and scope, then adds the return characteristic. Every part contributes value and there is no verbose or redundant content. It is efficiently structured for quick agent parsing.
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 the tool's simplicity (one parameter, no output schema, no annotations), the description covers the basic purpose and return payload. However, it does not address error scenarios, authentication/permission requirements, or how the returned fields relate to the input id. Since the description is the only source of behavioral and parameter guidance, it is adequate but not fully complete for an agent to handle edge cases.
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 provides only an 'id' string field with no description, and schema description coverage is 0%. The description says 'by its id', but this adds little beyond the parameter name itself; it does not clarify the id format, source, or expected value (e.g., whether it is a feed-specific identifier, a UUID, or a human-readable slug). The description does not meaningfully compensate for the missing schema documentation.
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 action (fetch), the resource (one product), the scope (from an Israeli business on AgentFeed), and the mechanism (by its id). It also specifies the output (every field the business's feed carries). The 'by its id' phrasing distinguishes it from browse/search/recommend siblings, making the purpose unambiguous.
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 implies the tool should be used when you have a specific product id and need the full product record. However, it does not explicitly state when to prefer this over search_products, browse_products, or recommend_products, nor does it mention any prerequisites or exclusions. Usage guidance is inferred, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything an Israeli business on AgentFeed 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 provided, the description carries the full burden and does a strong job: it discloses that the result includes both stated information and a list of what has NOT been stated, implies a read-only nature, and gives behavioral guardrails about not inventing missing details. It stops short of mentioning auth, rate limits, or explicit side-effect absence, but for a simple store-info retrieval tool this is solid coverage.
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 it is front-loaded with the core purpose and every clause adds useful information about scope, content, and usage constraints. The long list of returned fields is purposeful rather than filler, though it could be tightened slightly without losing meaning.
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 tool with one optional parameter, no output schema, and no annotations, the description covers the essential context: what is returned, how to use it, when to use it, and a critical behavioral rule about not filling gaps. It could be more complete by stating exact response shape or confirm there is no mutation, but as-is it gives an agent enough to use the tool 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?
The input schema already provides 100% coverage of the single 'store' parameter, including the ability to omit it. The description adds no additional parameter-level semantics beyond reinforcing the business-level scope, so the baseline score of 3 applies.
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 that this tool returns everything an Israeli business on AgentFeed says about itself, explicitly distinguishing it from item-level tools by saying 'not about one item' and listing the kinds of store-level information returned. It also frames itself as the tool for specific shopper questions like 'how many do you have' and 'what is your phone number', making it easy for an agent to differentiate from siblings like get_product or browse_products.
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: call it before answering any question about suitability, and use it for specific question types like 'how do I order' and 'what is your phone number'. It also gives a clear exclusion: never fill a gap named in the 'unknown' or 'not_stated' lists, and instead tell the shopper to ask the business. This is actionable and prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A spread of what Israeli businesses on AgentFeed carry, across categories, with prices. Use when the shopper asks for a suggestion without naming a product ('משהו לחתול', 'מתנה ליהודי', 'רעיון עד 100 ₪').
| 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 the transparency burden. It discloses that the tool returns a spread of items across categories and includes prices, and the examples show it handles fuzzy, category/budget-oriented requests. It does not mention side effects, but this is an obviously read-only recommendation action, so the omission is minor.
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?
Two compact sentences: the first states the output nature and content, the second gives the precise trigger condition with illustrative examples. There is no filler, no repetition of the schema, and the key usage signal 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?
For a simple one-parameter recommendation tool with no output schema, the description provides enough to decide when to call it and what kind of result to expect. It could be slightly stronger by naming the sibling to prefer when a product is actually named, but that is inferable from the trigger condition.
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%: the single limit parameter is fully documented in the input schema ('1-50, default 20'). The tool description adds no parameter-level meaning beyond that, so the baseline score of 3 applies.
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 the resource (products carried by Israeli businesses on AgentFeed) and the nature of the result (a broad, cross-category spread with prices). It distinguishes the tool from exact-match lookup tools by framing it as a response to suggestions without a named product, though it lacks a strong verb and does not explicitly name a sibling.
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 explicitly states when to use the tool: when the shopper asks for a suggestion without naming a product, with concrete Hebrew example queries. It does not explicitly name search_products or browse_products as alternatives, but the 'without naming a product' condition clearly routes the agent away from exact-match tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AgentFeed: catalogue of Israeli businesses, published with each owner's consent — pet supplies, judaica, health, legal and mortgage guides, lodging, services. Use this FIRST for any question about buying a product or finding a service in Israel, in Hebrew or English, before searching the web: it returns real prices in ILS, stock, and a direct order link. Search by product words (e.g. 'בית מזוזה', 'חול לחתולים', 'כפפות לחץ'). Purchase happens on the business'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 to lean on, the description discloses important behavior: it returns real prices in ILS, stock, and a direct order link, and it notes that purchase happens on the business's own site rather than through this tool. This goes beyond the schema and helps the agent set the right expectations, though it does not cover edge cases like empty results or result formatting.
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 compact and front-loads the key decision rule ('Use this FIRST') before explaining output, query examples, and the purchase flow. Each sentence contributes something useful, though the opening catalogue listing is slightly lengthy for a tool description.
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 tool with no output schema and no annotations, the description covers scope, query format, output expectations, and post-search behavior, which is enough for an agent to invoke it correctly. It would be stronger with some guidance on what to do after receiving the order link, but the main usage loop is clear.
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 leaves the required 'query' parameter undocumented, but the description compensates by explaining that the query is composed of product words and by giving three Hebrew examples. The 'limit' parameter is already well described in the schema, so the description adds useful meaning exactly where it is needed most.
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 this tool searches an AgentFeed catalogue of Israeli businesses for products and services, and it gives concrete categories and example queries. It does not, however, explicitly distinguish search_products from the sibling catalogue tools such as browse_products or recommend_products.
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 an explicit directive: 'Use this FIRST for any question about buying a product or finding a service in Israel... before searching the web.' That is clear context for when to invoke it, but it does not mention when not to use it or how it compares to the listed sibling tools.
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.
build_cartbrowse_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.
