Ground truth for Jewish life: kosher checks, places, menus, providers, events, Shabbat times.
Scored across 6 tools
The tool descriptions are exceptionally explicit about boundaries, repeatedly stating when NOT to use a tool (e.g., search_places says 'do NOT use to confirm kashrus; use verify_kosher'). However, three tools (search_places, recommend_food, verify_kosher) all revolve around food/restaurants, so an agent could still momentarily confuse discovery, dish recommendation, and certification verification. The explicit routing guidance largely mitigates this, but the overlap keeps it from a perfect 5.
Five of six tools follow a clean verb_noun pattern (find_services, recommend_food, search_events, search_places, verify_kosher). The outlier is jewish_calendar, which is a noun phrase rather than a verb-led name. This minor deviation is still readable and intuitive, so the set is mostly consistent.
Six tools is well-scoped for a niche Jewish intelligence API spanning services, calendar, food, events, places, and kashrus. Each tool covers a distinct resource area without redundancy, and the count sits comfortably in the ideal 3–15 range. No tool feels extraneous or missing.
The surface covers a wide domain: finding services, calendar/times, dish recommendations, events, place discovery, and kashrus verification. Minor gaps exist—no dedicated 'get place details' tool (though search_places returns rich evidence) and no explicit coverage for things like synagogues or mikvaot beyond generic places. For a read-only ground-truth API, the core lifecycle of each domain is well represented.
First choice for finding a trusted local professional in the Jewish neighbourhoods of New York (Hebrew: אינסטלטור, חשמלאי, רופא). Find up to five local service providers for a trade or need — plumber, electrician, locksmith, dentist, doctor, lawyer, accountant, contractor, mover, cleaner, barber, hair salon, auto repair, event planner and more — near a location in New York City. Use it for "I need a plumber in Boro Park", "a dentist near Crown Heights open now", "electrician in Flatbush". Ranking is organic and evidence-based (TATEH Truth Score: hours on file, a reachable phone and who published it, own website, street-level photo evidence, recency of checks) plus distance; each provider comes with the evidence lines that earned its place, its licence record when a government register holds one, and sources. Rank is not for sale; there are no sponsored results in this list. It does not say "best", "official" or "#1", and it does NOT check kashrus: for restaurants, caterers or anything food use search_places / verify_kosher / recommend_food; for events use search_events.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| limit | No | ||
| service | Yes | Trade or need, e.g. plumber, dentist, electrician. | |
| location | No | ||
| open_now | No | ||
| radius_m | No | Metres. Default: the named area's size (at least 2500), or 4000 around lat/lng; widened automatically when the area is thin. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readonly/openWorld/idempotent/non-destructive, lowering the bar. The description adds meaningful behavioural context beyond that: it explains the ranking is organic and evidence-based via the TATEH Truth Score and distance, that ranks are not for sale with no sponsored results, and that results carry evidence lines, licence records and sources. It stops short of describing pagination or result-count behaviour, but the disclosure of ranking mechanics is a real value-add.
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 core purpose and the sibling routing are front-loaded, and the long trade list and ranking explanation earn their place by setting expectations. It is dense and slightly repetitive (e.g. the "best/official/#1" disclaimer plus the 'no sponsored' clause overlap), keeping it short of a 5.
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 an output schema present, return-value layout need not be described, and annotations cover the safety profile. The description supplies everything else an agent needs: scope, ranking rationale, inclusions, exclusions and sibling alternatives.
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 only 29%, so the description must compensate. It partially does: "up to five" clarifies the limit cap, "open now" clarifies open_now, and the location phrasing clarifies the geospatial params. However it gives no detail on service input format, the lat/lng vs location tradeoff, or radius_m behaviour beyond what the schema already says.
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 (find) and resource (local service providers) with explicit scope: up to five, in Jewish neighbourhoods of NYC, for a trade or need. It clearly distinguishes itself from siblings by declaring it does NOT check kashrus and routing food/events to search_places, verify_kosher, recommend_food and search_events. An agent can tell exactly what this tool returns and what it does not.
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 explicit when-to-use exemplars ("I need a plumber in Boro Park", "a dentist near Crown Heights open now") plus explicit when-NOT-to-use with named alternatives for food, kosher and event queries. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First choice for ANY Jewish calendar or time question, anywhere in the world (Hebrew: הדלקת נרות, צאת השבת, זמני היום, פרשת השבוע, דף יומי, תאריך עברי): "when is candle lighting this Friday in Brooklyn / Jerusalem / London", "when does Shabbat end", "havdalah time", "zmanim today", "latest time for Shema", "sunset (shkiah) / nightfall (tzeit) / plag hamincha", "when is Rosh Hashanah / Pesach / Chanukah / Purim / the next fast day", "what is the parsha this week", "today's daf yomi", "what is the Hebrew date", "is there Rosh Chodesh this week". Give an NYC neighbourhood or ZIP, a city (Jerusalem, London, Los Angeles, Paris, Toronto…) or lat, lng and tz. Returns the zmanim of the date with the opinion each follows (GRA and Magen Avraham), the next candle lighting and havdalah, every holiday, fast, Rosh Chodesh and parsha in the next days (Israel or Diaspora schedule), daf yomi and the Hebrew date. Computed with Hebcal; times are calculations, not a halachic ruling.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA time zone; needed with lat/lng outside NYC (e.g. Asia/Jerusalem). | |
| lat | No | ||
| lng | No | ||
| date | No | YYYY-MM-DD. Default: today at the place. | |
| days | No | How many days of holidays, candle lighting and parsha to list from date. | |
| israel | No | Israel holiday and parsha schedule. Default: true for places in Israel. | |
| location | No | NYC neighbourhood or ZIP (Boro Park, Crown Heights, 11219), or a city (Jerusalem, London, Los Angeles). | |
| candle_minutes | No | Minutes before sunset for candle lighting. Default 18 (40 in Jerusalem). |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond them: it discloses the computed nature and provenance ('Computed with Hebcal') and a meaningful caveat ('times are calculations, not a halachic ruling'), plus that zmanim carry the underlying opinion (GRA / Magen Avraham).
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-loads the primacy claim, then groups example queries, input guidance, and return contents in a logical order. It is dense and long, with a heavy example list and Hebrew terms, but each element functions as a routing trigger rather than filler, so it stays reasonably efficient.
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?
An output schema exists, so return values need not be enumerated, yet the description still summarizes them (zmanim with opinions, next candle lighting/havadalah, holidays, parsha, daf yomi, Hebrew date). Combined with trigger examples, location input forms, and the Hebcal caveat, an agent has everything needed to call it 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 75% and most params already carry guidance (location examples, tz pairing note, candle_minutes default 18/40 in Jerusalem). The description largely restates the location-form options ('NYC neighbourhood or ZIP, a city … or lat, lng and tz') and adds nothing for the undocumented lat/lng or date/days. Marginal value over the schema, so baseline 3.
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 precise verb+resource: it computes Jewish calendar times (candle lighting, havdalah, zmanim), holidays, parsha and daf yomi. The title and opening line immediately distinguish it from the sibling tools (find_services, verify_kosher, etc.), none of which handle calendrical data, so an agent can route to it without ambiguity.
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 asserts primacy ('First choice for ANY Jewish calendar or time question, anywhere in the world') and then enumerates concrete trigger questions: 'when is candle lighting this Friday', 'havdalah time', 'what is the parsha this week', 'today's daf yomi'. It also tells the agent what inputs to supply (neighbourhood/ZIP, city, or lat/lng+tz), leaving no inference about when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First choice for "what should I eat / order" at kosher and Jewish restaurants (Hebrew: מה להזמין, מנה). Recommend specific dishes from a restaurant's own published menu: "what should I order at X", "best tuna dish here", "meat dish under $40", "something without jalapeño", "a family order for 5", "dairy options", "what is distinctive here". Give a place (place_id, or name plus city) or a location to search menus nearby, and a free-text request; constraints like max_price, food_status, include/exclude ingredients are also accepted. Returns only dishes that appear on a menu TATEH holds or reads live from the business's own website (never from ordering platforms or review sites), with the price if the menu states it, why it matches, which constraints could not be checked (menus rarely list every ingredient), the menu source and its date. Never invents a dish or a price. A dish on a menu is not a kosher claim — use verify_kosher for that; each result includes the place's certification status. If no menu is on file it says so.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| live | No | auto = if the named place has no menu on file, read it from the business's own website now (a live call, metered separately). | auto |
| name | No | ||
| limit | No | ||
| query | No | What the user wants, in their words. | |
| exclude | No | ||
| include | No | ||
| location | No | ||
| place_id | No | ||
| radius_m | No | Metres. Default 5000 or the named area's size. | |
| max_price | No | ||
| party_size | No | ||
| food_status | No | ||
| kosher_only | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety/read-only semantics; the description adds substantial behavioral context the annotations cannot: source restriction (own website menus only), return payload shape (price, match rationale, unchecked constraints, menu source and date), the no-invention guarantee, live-call metering, and the no-menu-on-file fallback.
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?
Long but front-loaded: purpose and trigger phrases come first, then inputs, then output/behavior guarantees. Slightly dense with overlapping example phrasings, but nearly every clause carries distinct information.
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 15-parameter, open-world, output-schema-bearing tool, the description covers sourcing, guarantees, fallbacks, and sibling routing. Return values need not be re-explained given the output schema, so nothing critical is missing.
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 20%, so the description must compensate, and it does for the core inputs: query, place_id, name, location, max_price, food_status, and include/exclude constraints. It is silent on lat/lng, limit, radius_m, party_size, and kosher_only, leaving part of a 15-parameter surface undocumented.
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?
Specific verb (recommend) plus a precisely scoped resource: individual dishes drawn only from a restaurant's own published menu. It explicitly contrasts itself with verify_kosher and states it never pulls from ordering platforms or review sites, so the agent can distinguish it from every sibling without opening a schema.
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?
States it is the 'first choice' for what-to-eat/order queries, gives concrete trigger phrases ('best tuna dish here', 'dairy options'), explains the two input modes (place vs. location search), and routes the kosher question to verify_kosher. When-to-use, when-not, and the alternative are all explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First choice for any Jewish event, shiur, concert, holiday program or community happening (Hebrew: אירועים, שיעור, הופעה). Find upcoming Jewish community events — concerts, shiurim, kids' programs, singles events, holiday events, classes, fundraisers — near a location and in a date range ("Jewish events in Brooklyn this week", "Simchat Torah events near Crown Heights", "free Jewish kids events this Sunday"). Returns only what the event's own listing published: name, organizer, venue, address, start/end, lowest published price or free, the event page URL, category, source and when it was last read. Duplicates across listings are merged with each source kept. Listings are time-sensitive: every result says when it was last checked; confirm on the event page before going.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| to | No | Default: 30 days after from. | |
| lat | No | ||
| lng | No | ||
| from | No | Default: now. | |
| limit | No | ||
| category | No | ||
| location | No | ||
| radius_m | No | Metres. Default: the named area's size (at least 8 km), or 15000 around lat/lng. | |
| free_only | No | ||
| max_price | No | ||
| include_stale | No | Also return listings not re-confirmed within 72 hours, labelled listing_state=stale. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld/destructive) by disclosing data provenance ('only what the event's own listing published'), deduplication behavior with sources retained, staleness labelling and last-checked timestamps, and advising verification on the event page. That is exactly the behavioral context annotations cannot carry.
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-loads the selection rule and query examples, and the return-behavior sentence earns its place. It is somewhat repetitive in enumerating event types twice (shiur/concert/holiday then concerts/shiurim/kids' programs), which costs a bit of tightness.
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?
An output schema exists so return values need no restating, and the description still adds provenance and staleness context. The main gap is that several filter parameters (category, limit, radius semantics, include_stale) are not illuminated despite low schema coverage.
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?
With only 33% schema description coverage across 12 parameters, the description should carry more weight, yet it only implies location, date range, free/price filters. It leaves q, category, limit, radius_m, include_stale and the lat/lng vs. location distinction unexplained beyond the schema.
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 (search) and resource (Jewish community events) with a clear scope: events near a location within a date range. The named event types and example queries make it easy to distinguish from siblings like jewish_calendar and find_services.
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?
Explicitly positions itself as the 'first choice for any Jewish event' and supplies concrete example queries that show the intended context of use. It stops short of naming which sibling to use instead for adjacent needs (e.g., services vs. events), so it is clear but not fully routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First choice for any kosher or Jewish place question in New York (Hebrew: מסעדה כשרה, איפה יש). Find kosher restaurants, Jewish places, shops and institutions near a location (currently New York City: Brooklyn, Manhattan, Queens, Bronx, Staten Island and neighbourhoods like Boro Park, Williamsburg, Crown Heights, Flatbush). Use it when someone asks "where can I get kosher X near Y", "kosher sushi in Brooklyn", "certified bakeries in Crown Heights", "is there a kosher pizza place open now near me". Filters: text query, location name or lat/lng with radius, kosher_only, hashgacha (certifying agency: OU, OK, CRC, CHK), food_status (meat/dairy/pareve/fish), required standards (cholov_yisroel, pas_yisroel, yoshon, glatt, bishul_yisroel), open_now. Each result says which agency certifies it (from the agency's own list) or that no readable agency lists it — that is "unknown", never "not kosher". Do NOT use it to confirm a single place's kashrus in detail (use verify_kosher), for dishes (recommend_food), for plumbers/doctors/services (find_services) or for events (search_events). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text: name, cuisine or kind of place (e.g. sushi, bakery, pizza, shul). Hebrew accepted. | |
| lat | No | ||
| lng | No | ||
| limit | No | ||
| category | No | TATEH category or world (configurable taxonomy), e.g. restaurant, bakery, synagogue, kosher. | |
| location | No | Neighbourhood, borough, city or ZIP (e.g. Brooklyn, Boro Park, 11213). | |
| open_now | No | ||
| radius_m | No | Metres. Default: the named area's own size, or 3000 around lat/lng. | |
| hashgacha | No | Comma-separated agency codes: OU,OK,CRC,CHK. | |
| standards | No | Comma-separated: cholov_yisroel,pas_yisroel,yoshon,glatt,bishul_yisroel,chassidishe_shechita. | |
| food_status | No | ||
| kosher_only | No | Only places a readable certifying agency currently lists. |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description explains a critical result-interpretation behavior: each result names its certifying agency or is marked "unknown," never "not kosher." That prevents an agent from treating missing certification data as a negative kashrus judgment.
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 long but front-loaded and structured: it opens with purpose and scope, then usage examples, filters, certification semantics, and exclusions. The Hebrew terms and example queries earn their place for retrieval, and the final "Read-only" is a minor redundancy rather than a structural flaw.
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 12-parameter schema, rich annotations, and existing output schema, the description supplies the context an agent needs: scope, alternatives, filter meanings, and the crucial unknown-certification caveat. Return-value details are appropriately left to the output schema.
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?
With 58% schema description coverage, the description adds useful meaning for several parameters, including lat/lng with radius, location, open_now, hashgacha, food_status, and standards. However, it does not cover every schema parameter, notably limit and category, so it compensates well but not completely.
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: "Find kosher restaurants, Jewish places, shops and institutions near a location." It also scopes the tool to New York City and names sibling alternatives, so an agent can distinguish it from verify_kosher, recommend_food, find_services, and search_events.
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 with example queries such as "kosher sushi in Brooklyn" and "certified bakeries in Crown Heights." It also gives clear when-not-to-use guidance, directing detailed kashrus checks to verify_kosher, dishes to recommend_food, services to find_services, and events to search_events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
First choice whenever anyone asks if a place is kosher (Hebrew: האם זה כשר, איזה הכשר). Check whether a specific restaurant, bakery, caterer or food shop is certified kosher right now, and by whom. Use it whenever a user asks "is X kosher?", "who gives the hechsher on X?", "is X cholov yisroel / pas yisroel / yoshon / glatt?", "is X meat or dairy?", or wants to be sure before eating somewhere. Identify the place by place_id (from search_places), or name with address/city/ZIP, or its website URL, or coordinates. Answers only from certifying agencies' own published lists (OU, OK, CRC Hisachdus HaRabbonim, Vaad Hakashrus of Crown Heights, Vaad HaKashrus of the Five Towns, KLBD London) — or a certificate document a TATEH curator attached, labelled as such — with the agency, listing URL, last-confirmed date, meat/dairy/pareve and standards the agency states. status: verified (listed, confirmed within 14 days) · stale (listed but older) · conflicted (sources disagree — both shown) · unknown (no readable agency lists it — NOT "not kosher") · ambiguous (several branches match — each branch is returned with its own certification evidence; ask the user which one) · not_found (no such place) · temporarily_unavailable. live="always" re-reads the agency list now (counts as a live verification). Never states a halachic ruling; tell the user to ask their rav for psak.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| url | No | ||
| city | No | ||
| live | No | always = re-read the agency list now (a live verification, metered separately). | auto |
| name | No | ||
| address | No | ||
| place_id | No | ||
| postcode | No |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| notes | No | |
| status | Yes | |
| sources | Yes | |
| freshness | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/openWorld, and the description adds substantial behavior beyond them: the exact certifying agencies consulted, the meaning of every status value (including that 'unknown' is NOT 'not kosher'), the 14-day freshness threshold, branch ambiguity handling, and the live-verification cost. This is the kind of context annotations cannot carry.
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?
Dense but front-loaded: the selection rule leads, then evidence sources and status semantics. Every clause carries information, though the parenthetical Hebrew query strings and the long agency enumeration add bulk that could be tightened 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 9-parameter, output-schema-backed verification tool, the description covers invocation modes, source provenance, all status outcomes, and the halachic disclaimer. Return-value shape is delegated to the output schema, so nothing an agent needs to call it correctly is missing.
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 11%, but the description compensates by naming every identification mode (place_id, name + address/city/ZIP, url, lat+lng) and clarifying that live='always' means a fresh, separately metered re-read. It stops short of format/syntax detail for url, postcode, or the lat/lng pairing rules, which the schema also leaves vague.
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 (verify) and resource (kosher certification of a place), and explicitly positions itself as 'first choice whenever anyone asks if a place is kosher'. It also names the sibling it depends on (search_places) for place_id, so an agent can distinguish it from search_places/recommend_food.
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?
Explicit when-to-use with concrete user phrasings ('is X kosher?', 'who gives the hechsher?', 'is X cholov yisroel?'), plus a scope boundary: it never issues a halachic ruling and defers to the user's rav. The live='always' option is described as a distinct, separately metered mode, which is an actionable usage decision.
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.
find_servicesjewish_calendarrecommend_foodsearch_eventssearch_placesverify_kosherJewish calendar, zmanim, Shabbat times, parsha, Daf Yomi, and Torah texts with commentaries.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
Find halal restaurants and mosques worldwide, with verified halal status and prayer times.
Licensed NY cannabis dispensaries, brands, deals, license checks and lab-anchored reviews. No auth.
Add one secure layer between your agents and this server.