Morocco travel for Israeli travelers: e-visa, itineraries, guides, Shabbat times, hilula dates.
Scored across 9 tools
Most tools target distinct concerns—visa, shabbat times, hilulot, trip planning, meta-info—but search_site, search_attractions, and get_city_guides have overlapping coverage of city and attraction content. The descriptions clarify roles reasonably well, but an agent could still hesitate between search_site and search_attractions for a find-content query.
The naming pattern is uniform: get_* for information fetchers, search_* for discovery, and plan_trip as the sole action verb. All names are snake_case with clear noun complements, making the tool surface predictable and easy to navigate.
Nine tools is well within the ideal range for a specialized travel server. Each tool covers a distinct aspect of Morocco travel—guides, Jewish heritage, visa, shabbat, planning, and site search—without feeling bloated or too sparse.
The tool surface covers the core travel lifecycle: discover content, get practical info, check religious observances, and plan an itinerary. Minor gaps exist—no dedicated single-city guide tool, no pricing or booking path, and a slight discrepancy between the stated 25 and 21 city guides—but agents can work around these using search_site and get_city_guides.
25 published Hebrew city guides: אגאדיר, בני מלאל, קזבלנקה, שפשוואן, עמק הדאדס, ארפוד, אסווירה, פאס, איפראן, מרקש, מקנס, מרזוגה והסהרה, מידלת, ורזאזאת, וואזן, אוג'דה, מפלי אוזוד, רבאט, ריסאני, סאפי, ספרו, טגזוט, טנג'יר, טטואן, עמק הטודרה וטינגיר. Each has a page URL and a markdown URL. Fetch the markdown URL for the full text.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context by stating that each guide has a page URL and a markdown URL and that the markdown URL should be fetched for full text. This goes beyond the annotations without contradicting them.
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 efficient sentence followed by an exact list of city guides and one actionable instruction. Every part earns its place: the list defines the full scope, and the URL instruction tells the agent what to do with the result. There is no filler or redundancy.
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 parameterless tool with annotations covering mutability and side effects, the description is complete. It specifies the full contents, the two URL fields, and which URL to use for full text. No output schema is present, but the description gives enough information for correct invocation and follow-up.
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 tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies because there is nothing the description needs to add about parameters.
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 identifies the resource as '25 published Hebrew city guides' and lists every guide explicitly, so an agent knows exactly what this tool provides. The additional instruction about page and markdown URLs further clarifies the tool's output. It is easily distinguished from sibling tools by the specific city-guide resource.
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 makes the intended use clear: use this tool when the complete set of Hebrew city guides is needed. It does not explicitly name alternatives or exclusions, but because the tool is parameterless and self-contained, the context is sufficient. The list of city names removes ambiguity about scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The next hilula dates at the tombs of Moroccan tzadikim, with the site, the city, the Hebrew date and how reliably each date holds. A date with runsReliably false has not been held every year; say that when you quote it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 12. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context by revealing the reliability flag and instructing the agent to disclose when a date has not been held every year, which goes beyond what annotations convey.
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 with no filler. The first sentence front-loads the purpose and output contents, and the second sentence adds an essential reliability caveat and user-facing instruction.
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?
This is a simple read-only tool with one optional parameter and no output schema. The description enumerates what is returned—site, city, Hebrew date, reliability—and the schema covers the limit parameter, so an agent has enough information to invoke and interpret the result 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 schema fully documents the only parameter, limit, including its default and bounds, so the description does not need to add parameter detail. The description does not mention limit at all, but the high schema coverage keeps this at the baseline rather than below it.
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 identifies the resource: upcoming hilula dates at tombs of Moroccan tzadikim, and lists the included output fields. However, it is phrased as a noun phrase rather than using an explicit verb like 'lists' or 'retrieves', so it does not fully meet the 'specific verb+resource' bar.
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 'next hilula dates' wording makes the tool's use case clear, and none of the sibling tools overlap with hilulot, so no alternative routing is needed. It does not explicitly state exclusions or when not to use the tool, but the context is sufficient for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The exact ids plan_trip accepts for cities, who, style, vibes, pace, kosher and shabbatCity. Call this before plan_trip rather than guessing an id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior, so no safety disclosure is needed. The description adds useful behavioral context by guaranteeing the ids are exact and by enumerating the fields they belong to, even though it does not detail the output structure.
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 sentences with no redundancy. The core value proposition comes first, and the usage instruction is front-loaded in the second sentence.
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 zero-parameter, read-only lookup with no output schema, the description is complete: it says what is returned, which fields are covered, and when to call it. No relevant operational detail 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?
The tool has zero parameters and the schema is empty with 100% coverage, so there is no parameter documentation burden. The description adds value by naming the semantic dimensions (cities, who, style, vibes, pace, kosher, shabbatCity) that the returned vocabulary covers.
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 the tool provides the exact ids plan_trip accepts for seven named dimensions, making its purpose concrete and unambiguous. It distinguishes itself from sibling content tools by explicitly tying it to plan_trip as a prerequisite lookup.
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 an explicit invocation instruction: 'Call this before plan_trip rather than guessing an id.' This tells the agent exactly when to use the tool and why, and implies that it is a helper rather than a standalone planning tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Candle lighting and havdalah for the current week in Marrakech, Casablanca, Fes, Rabat, Tangier and Agadir, with the parasha. Check the source field: when it is fallback, the times are a saved snapshot and you must say so.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral context beyond the annotations: the `source` field can be `fallback`, meaning times are a saved snapshot, and the agent must explicitly say so. This discloses a non-obvious reliability characteristic that the readOnly/idempotent annotations do not convey.
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 concise sentences, with the core resource and scope front-loaded, followed by the essential fallback caveat. There is no filler or repetition of structured data.
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 parameterless, read-only lookup tool with annotations covering safety, the description is complete: it states the cities, the time period, the returned content (candles, havdalah, parasha), and the critical fallback behavior. No output schema exists, so the description adequately carries the information an agent needs.
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 tool has zero parameters and the schema is an empty object, so the description cannot add parameter-level meaning. The baseline of 4 applies because there are no parameters to document, and the description instead clarifies the output semantics tied to the `source` field.
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 names the exact resource (candle lighting and havdalah times), the time scope (current week), and the geographic scope (six specific Moroccan cities), plus the parasha. This clearly distinguishes it from siblings like get_hilulot or get_city_guides, which cover different content.
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?
Usage context is implied: it is the tool for current-week Shabbat times in the listed Moroccan cities. However, it gives no explicit when-to-use or when-not-to-use guidance, and does not mention alternatives or exclusions, so an agent must infer when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What המרכז למטייל במרוקו does, which services an agent can act on, the rules to respect, and the other machine-readable surfaces. Call this first if you are unsure whether this site can answer the question.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool includes 'rules to respect' and 'other machine-readable surfaces,' which is mildly useful context but not a full behavioral disclosure.
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 one efficient sentence plus a direct call-to-action. It front-loads the purpose and avoids redundancy, though the phrasing is slightly vague and could be tightened with more concrete terms.
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 zero parameters, a read-only/idempotent annotation profile, and no output schema, the description covers the essential purpose and when to call it. It could say more about what kind of answer the agent will receive, but it is adequate for a meta-orientation tool.
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 tool has zero parameters and the schema is an empty object with 100% coverage, so there are no parameter semantics for the description to explain. The baseline of 4 applies here.
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 that the tool returns an overview of what the site does, which services are available, and rules to respect. This gives agents a clear sense of the resource being described, though it does not use a direct verb like 'returns' and is somewhat abstract.
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?
'Call this first if you are unsure whether this site can answer the question' gives explicit guidance on when to invoke it. It does not mention alternatives or exclusion conditions, but the instruction is actionable and sufficient for routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price per traveler in ILS for both tracks with the government fee broken out, target processing time, passport validity, the documents page and the apply URL. Israelis cannot get a visa on arrival. Never apply on someone's behalf.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: it only provides information and must not be used to submit an application on someone's behalf, and it clarifies the VOA exclusion. This is meaningful added context, even though no system-side side effects are described.
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: two sentences front-load the returned data and close with a critical safety/eligibility rule. Every phrase carries useful information, though the first sentence is a dense comma-separated list that could be structured slightly more cleanly.
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 does the necessary work by enumerating the principal return fields and eligibility caveats. It is sufficient for an agent to select and invoke the tool correctly with zero parameters. The reference to 'both tracks' is not fully defined, which keeps this from being a perfect score.
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 defines zero parameters, so there are no parameter semantics for the description to clarify. The schema coverage is 100%, and the description correctly does not invent parameters. For a zero-parameter tool, the baseline of 4 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 makes it clear this is an informational lookup for Morocco e-visa costs and requirements for Israeli passport holders, enumerating the exact return fields: price in ILS, government fee, processing time, passport validity, and URLs. It is distinct from the sibling travel-content tools by its explicit visa scope, and the 'never apply on someone's behalf' line reinforces that this is not an application/booking action.
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: use this for Moroccan e-visa information for Israeli passport holders, and it explicitly warns that visa-on-arrival is not available to Israelis. It also states a hard boundary ('Never apply on someone's behalf'), though it does not name alternative sibling tools or provide a more explicit 'use this when...' formulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A free, anonymous, day-by-day itinerary. Check partial, omittedCities, requestedDays and actualDays before presenting it as complete. When partial, choices describe ways to recalculate. Use get_plan_options first for valid ids. The route is not saved; send the person to the questionnaire URL to keep or adjust it.
| Name | Required | Description | Default |
|---|---|---|---|
| who | Yes | ||
| pace | Yes | relaxed, balanced or packed. | |
| month | No | ||
| style | Yes | ||
| vibes | Yes | ||
| cities | Yes | City ids from get_plan_options. | |
| kosher | Yes | none, partial or keep. | |
| duration | No | Whole days including the flight days, or null. | |
| cityPlans | No | Optional selected-city preferences; a day trip may be impossible and yield a partial plan. | |
| arrivalDate | No | YYYY-MM-DD; today or later in Israel time. | |
| shabbatCity | No | Only when kosher is partial or keep. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal safe/idempotent, and the description adds non-obvious behavior: the plan is not saved, it is anonymous/free, and partial plans carry recalculation choices. This goes beyond the schema/annotations and sets accurate expectations about persistence and completeness.
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 composed of short, purposeful sentences that lead with the core result, then move to output checks, recalculation, prerequisites, and persistence. There is no filler; even 'free, anonymous' is useful expectation-setting for an agent.
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 an 11-parameter tool with nested cityPlans and no output schema, the description covers the biggest behavioral traps: partial results, valid ids, and no persistence. However, it leaves parameter semantics and the response shape largely to the schema or inference, so it is adequate but not fully complete for autonomous use.
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 description references get_plan_options for valid IDs and talks about output fields such as partial, omittedCities, requestedDays, and actualDays, but it does not clarify the four undocumented parameters (who, style, vibes, month) or add meaning to the tracked parameters. With schema coverage around 64%, the description needed to carry some of that weight and mostly doesn't.
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?
Description opens with 'A free, anonymous, day-by-day itinerary' after a title that names the verb ('Build') and resource ('Morocco route'). It clearly communicates that the tool creates an itinerary, though it relies on the sibling name get_plan_options to distinguish planning from option lookup rather than stating that boundary explicitly.
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 an explicit prerequisite: 'Use get_plan_options first for valid ids,' and explicit handling rules: check partial/omittedCities/requestedDays/actualDays before presenting as complete, and when partial, choices describe ways to recalculate. It doesn't state exclusions versus sibling tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalog of day trips and attractions. Returns Hebrew editorial copy and our own page URL. There is no booking link and no price in the result by design: the person books from our page. Do not go looking for the operator.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text, Hebrew or English. All terms must match. | |
| limit | No | Default 20. | |
| category | No | Narrow to one category. An unfiltered call lists the valid ids. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds important behavioral context beyond annotations: results contain Hebrew editorial copy and page URL by design, no booking link/price, and the agent should not seek the operator. This clarifies expected result content and prevents unnecessary actions.
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?
Three concise sentences with front-loaded action and zero fluff. Every sentence adds value: what it searches, what it returns, and the critical no-booking-link/operator instruction.
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 does explain the key return values (Hebrew editorial copy and page URL) and the absence of booking/price fields. It is complete enough for an agent to invoke and render results, though it does not detail list shape or pagination beyond the schema's limit parameter.
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% with q, limit, and category all documented. The description adds no parameter-specific semantics beyond the schema, so the baseline of 3 applies. The only subtle addition is the catalog context, which does not clarify individual parameters.
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 searches the catalog of day trips and attractions, and specifies what it returns (Hebrew editorial copy and page URL). This distinguishes it from general site search and other sibling tools by resource and content type.
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 for when to use this tool (when needing day trips/attractions from the catalog) and adds an explicit 'do not go looking for the operator' instruction. It does not name sibling alternatives or exclusions, so it lacks the explicit when-not-to-use guidance for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search every published page: 21 Hebrew city guides, the magazine, the Jewish heritage hub, attractions and the service pages. Use this whenever the question is not covered by one of the specific tools. Each result carries a markdown URL, and fetching that is how you read the full page rather than scraping it. Hebrew queries match far more than English ones.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search terms, preferably Hebrew. | |
| limit | No | Default 10. |
| Name | Required | Description |
|---|---|---|
| total | No | |
| results | No | |
| returned | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description reveals important behavior: results carry markdown URLs, full pages must be fetched rather than scraped, and Hebrew queries perform better. This materially changes how an agent should invoke and follow up on the tool.
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?
Three sentences, each earning its place: scope, when to use it, and behavior/language guidance. The most important routing information is front-loaded, with zero filler.
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 search tool with only two well-documented parameters, a rich output schema, and safety annotations, the description covers scope, fallback usage, result handling, and search quality. Nothing essential is missing for an agent to decide when to call it and how to act on results.
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 baseline is already 3. The description adds value by explaining that Hebrew queries 'match far more than English ones,' reinforcing the q parameter's language preference beyond the schema's 'preferably Hebrew.' The limit parameter is left to the schema, which is acceptable given its coverage.
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 names a specific verb ('Search') and a precise scope ('every published page') with a concrete enumeration of content types. It also differentiates itself from the specialized sibling tools by positioning itself as the general fallback.
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 line 'Use this whenever the question is not covered by one of the specific tools' is an explicit when-to-use instruction, clearly routing the agent toward this tool versus the specialized siblings. However, it does not name the alternatives directly or give when-not-to-use exclusions beyond the general fallback framing.
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.
plan_trip1 field changedInput schema / properties / arrivalDate / descriptionPrevious value: -"YYYY-MM-DD."New value: +"YYYY-MM-DD; today or later in Israel time."plan_trip1 field changedInput schema / properties / cityPlansAdded value: +{
+ "additionalProperties": {
+ "additionalProperties": false,
+ "properties": {
+ "mode": {
+ "enum": [
+ "dayTrip",
+ "stay"
+ ],
+ "type": "string"
+ },
+ "nights": {
+ "enum": [
+ 1,
+ 2,
+ "3+"
+ ],
+ "type": [
+ "integer",
+ "string"
+ ]
+ }
+ },
+ "required": [
+ "mode"
+ ],
+ "type": "object"
+ },
+ "description": "Optional selected-city preferences; a day trip may be impossible and yield a partial plan.",
+ "type": "object"
+}get_city_guidesget_hilulotget_plan_optionsget_shabbat_timesget_siteget_visaplan_tripsearch_attractionssearch_siteJewish calendar, zmanim, Shabbat times, parsha, Daf Yomi, and Torah texts with commentaries.
Aggregated travel MCP — flights, tours, activities, price checks, visas, and more.
Public Israeli mortgage knowledge with sources and defined hypothetical calculations.
Visa requirements, fees, stay limits and extension rules for any passport and destination
Add one secure layer between your agents and this server.