Contact Improvisation events, teachers, venues and communities worldwide. Read-only.
Scored across 8 tools
Each tool has a clearly distinct resource and action: search_* for discovery and get_* for detail across communities, events, teachers, and venues. The potential overlap between search_communities and search_venues is well handled by describing communities as groups and venues as physical spaces. Agents can confidently select the right tool for location, event, teacher, or venue queries.
All tool names follow a strict verb_noun pattern: search_communities, get_community, search_events, get_event, and so on. Plural nouns are used consistently for search tools and singular nouns for detail tools. There are no mixed conventions or vague names.
Eight tools form a clean, well-scoped surface: four entity types each with a search and a get operation. This is neither too thin nor bloated for a public directory of communities, events, teachers, and venues.
The search/get pairs provide solid read-only coverage for all four main entities, with filters and detail lookups covering core discovery workflows. Minor gaps exist, such as search_events returning at most 20 results without an explicit pagination tool, and get_community not returning contact or chat invite details. These are workable limitations rather than dead ends.
Get one local community's public details: what it runs, where, in which languages, the people and venues involved, and events it organizes. Use with a slug from search_communities. Group chat invite links and contacts are only on the community's page, not returned here.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Community slug from search_communities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by disclosing the content scope of the response and, importantly, what is deliberately omitted (group chat invite links and contacts), which prevents an agent from assuming a complete record.
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, no filler, with the capability statement front-loaded and the usage caveat second. Every clause carries either content scope or routing 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?
No output schema exists, so the description must convey return content — it does, listing the facets returned and explicitly noting what is absent. Combined with annotations covering safety and one fully documented parameter, nothing needed to invoke this 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?
Single parameter with 100% schema description coverage, so the schema already defines the slug and its origin. The description restates the slug provenance ('from search_communities') without adding format, validation, or resolution behavior beyond the schema, matching the baseline of 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?
Specific verb+resource with an explicit enumeration of the returned facets ('what it runs, where, in which languages, the people and venues involved, and events it organizes'). This clearly separates it from siblings like get_event or get_venue, which return a single entity 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?
Explicitly states the required input provenance ('Use with a slug from search_communities'), routing the agent through the sibling search tool first. It also flags an exclusion — invite links and contacts are only on the community's page — which is useful scope guidance, though it stops short of naming a dedicated alternative tool for those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full listing of one event: dates and times, venue and address, description, prices, teachers, organizers, level, languages, features and where people sleep. Use after search_events, or when the user gives a citreasurehunt.com event link. Accepts the event id (e.g. 'W27r') or the URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Event id (e.g. 'W27r'), its slug, or its citreasurehunt.com URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and non-destructive semantics, so the description need only add what they can't. It does that by disclosing the scope of the payload (venue/address, prices, teachers, organizers, level, languages, features, sleeping arrangements), which is meaningful since no output schema exists. It stops short of return shape or error behavior, so a 4 rather than 5.
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, front-loaded with the action and payload, then the when-to-use routing. No filler and nothing redundant to the structured fields beyond the useful payload enumeration.
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 one-parameter read tool with rich annotations, the description supplies both the invocation trigger and a summary of returned content in lieu of an output schema. Nothing an agent needs in order 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 coverage is 100% and the single parameter already documents id, slug and URL forms with the 'W27r' example. The description's 'accepts the event id (e.g. W27r) or the URL' merely restates the schema, adding no new syntax or constraint. Baseline 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?
States a specific verb and resource ('Get the full listing of one event') and immediately enumerates the fields returned. Against siblings like search_events, it is clear this is the single-record detail fetch rather than a list/search operation, so no schema inspection is needed to tell them apart.
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 names the predecessor ('Use after search_events') and the alternate entry condition ('when the user gives a citreasurehunt.com event link'). It does not state exclusions or when to prefer get_venue/get_teacher, but those serve different resources so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one person's public profile: bio, where they are based, practices, years of experience and their upcoming events. Use with a slug from search_teachers or from a get_event teacher link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Profile slug from search_teachers, e.g. 'mona-ring'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld=false, so the safety profile is covered structurally. The description still adds value by disclosing the content scope of the response, including a derived set (upcoming events) that the agent would not otherwise anticipate.
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, no waste, and the returned-content summary is front-loaded ahead of the input-provenance tip. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return shape, and it does so by listing the profile fields. It is essentially complete for a single-parameter read tool, with only error or not-found behavior 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 100% and the schema already documents the slug with an example, so the baseline would be 3. The description adds a second provenance path ('from a get_event teacher link') that the schema does not mention, giving meaningful extra context on valid input sources.
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 ('Get') plus a precise resource ('one person's public profile') and enumerates the content returned: bio, location, practices, years of experience, and upcoming events. This makes it clearly distinguishable from the sibling get_event and get_venue tools without opening any 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?
It explicitly states where the required input comes from — 'a slug from search_teachers or from a get_event teacher link' — which routes the agent correctly after a search. It stops short of any when-not-to-use condition or explicit alternative tool, so it is clear context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one venue's public details: address, description, website and the upcoming events it hosts. Use with a slug from search_venues or from a get_event venue link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Venue slug from search_venues. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only that the exposed data is 'public' and what fields come back, with no note on pagination for the upcoming events list or failure behavior for an unknown slug.
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, both earning their place: the first front-loads what is returned, the second front-loads the required input source. No filler or repetition of the title.
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 usefully names the returned fields (address, description, website, upcoming events), which is what an agent needs to decide whether to call it. It is slightly thin on the shape of the nested upcoming-events payload and any pagination or not-found behavior, but is otherwise adequate for a single-parameter read 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?
Schema coverage is 100% and the schema already documents the slug as coming from search_venues, so the baseline is 3. The description goes one step further by naming a second legitimate source ('a get_event venue link'), which is meaning the schema does not carry.
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 (get) and resource (one venue's public details) and enumerates what is returned: address, description, website and upcoming events. This clearly separates it from the sibling search_venues, which returns multiple venues to choose from.
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 tells the agent where the required slug comes from (search_venues or a get_event venue link), which is the key precondition for calling it. It does not say when not to use it or contrast it directly against the other get_* siblings, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find local Contact Improvisation communities, the groups that run regular weekly jams and classes, by country, city or name. The primary tool for 'where can I dance CI in ' or 'is there a CI jam in '. Returns communities with slug and URL; call get_community for details.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | Maximum results, 1 to 20. Default 10. | |
| query | No | Community name or words from its description. | |
| country | No | ISO code or English name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds useful behavior the schema cannot: it returns communities with slug and URL, and points to get_community for full details. It does not state pagination/limit behavior, but that 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?
Three sentences, front-loaded with the core purpose, followed by a concrete query example and the return/hand-off note. Every sentence earns its place with no 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?
With no output schema, the description steps in to describe the return shape (slug and URL) and the natural next call (get_community). Annotations cover the safety profile, so the only residual gap is the undocumented city parameter and limit/pagination nuance, which the schema mostly handles.
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 75% (city is undocumented in the schema). The description compensates by naming the filter dimensions — 'by country, city or name' — which maps country/city/query, and its examples clarify that query covers name-or-description matching. Adds meaning beyond the schema for the loosely documented 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?
Specific verb (find/search) plus a precisely scoped resource ('local Contact Improvisation communities, the groups that run regular weekly jams and classes') with the filter dimensions named. It distinguishes itself from the get_* siblings by stating it returns the list and routing detail lookups to get_community.
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 frames itself as 'the primary tool' for 'where can I dance CI in <city>' and 'is there a CI jam in <city>', and names get_community as the follow-up for details. No exclusions against search_events/search_venues, but the core when-to-use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Contact Improvisation events worldwide: festivals, workshops, intensives, retreats, long jams, residencies, jams and classes. Upcoming by default; a past 'from' date also searches ended events. Use for questions like 'CI festivals in Germany this summer', 'workshops with ' or 'when was X last year'. Filter by country, city, dates, type, practice or free text. Returns up to 20 events sorted by start date, each with id and citreasurehunt.com URL, plus the total match count. Call get_event for prices, teachers and the full description.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Window end: the latest start date, YYYY-MM-DD. | |
| city | No | City name, e.g. Berlin. | |
| from | No | Window start, YYYY-MM-DD. Default today. Includes events still running on or after this date; a past date also returns ended events. | |
| type | No | Event type. | |
| limit | No | Maximum results, 1 to 20. Default 10. | |
| query | No | Free text matched against title, description and place, e.g. a teacher's name or 'silent'. | |
| country | No | Country as ISO code ("PT") or English name ("Portugal"). | |
| features | No | Only events offering all of these, e.g. ["residential", "meals"] or ["sliding_scale"]. | |
| practice | No | Practice tag, e.g. "contact_improvisation" (default), "conscious_dance", "axis_syllabus", or "any" for all practices. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is carried. The description adds genuinely new behavior: capped at 20 results, sorted by start date, each row containing id and a citreasurehunt.com URL, plus a total match count. It does not discuss empty-result behavior or ranking, which keeps it short of a 5.
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 purpose, then usage examples, then filters, then return shape and the sibling routing — a sensible order with no throwaway sentences. The domain noun list in sentence one is long but earns its place for term matching.
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 stating the result shape (id, URL, start-date sort, total count, 20 cap). With zero required parameters and full schema coverage, the description plus schema is close to complete; only failure/empty-result handling is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all nine parameters, including the past-date semantics of 'from' and the all-of semantics of 'features', are already documented. The description only restates the filter axes (country, city, dates, type, practice, free text) at a higher level, adding little 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?
Specific verb + resource ("Find Contact Improvisation events worldwide") with the domain's event taxonomy enumerated (festivals, workshops, jams, classes), so the agent knows exactly what corpus this searches. It also distinguishes itself from the sibling that shares the same resource by routing detail lookups to get_event.
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?
Gives concrete when-to-use examples ("CI festivals in Germany this summer", "workshops with <teacher>", "when was X last year") and an explicit boundary: this tool returns summary rows, while get_event is the call for prices, teachers and full descriptions. Default behavior (upcoming unless a past 'from' is supplied) is stated up front.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Contact Improvisation teachers, organizers and musicians by name, or by where they are based. Use for 'who teaches CI in ' or to look up a person mentioned in an event. Returns short profiles with slug and URL; call get_teacher for the full bio and their upcoming events.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City they are based in. | |
| role | No | ||
| limit | No | Maximum results, 1 to 20. Default 10. | |
| query | No | Name or words from their bio. | |
| country | No | Where they are based, ISO code or English name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and determinism are covered. The description adds genuinely useful context beyond them: results are short profiles containing slug and URL, and the full bio plus upcoming events require a separate get_teacher call. It does not mention result caps or ordering, which is a minor gap.
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, zero filler, front-loaded with purpose before the routing advice. Every clause carries information an agent needs.
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 usefully describes the return shape (short profiles with slug and URL) and the follow-up path. It leaves pagination/result-cap behavior to the schema and doesn't say how query and city interact when both are supplied, but 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 80%, so the schema already documents city, role, limit and query. The description restates the name/location/role dimensions but adds no syntax, matching rules, or city-vs-country interaction detail beyond what the schema provides. Baseline 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?
States a specific verb (Find) and resource (CI teachers, organizers, musicians) with the two axes of retrieval: by name or by location. It also names the sibling it is not — get_teacher for the full bio — so an agent can distinguish it without opening either 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?
Gives concrete triggering phrasings ('who teaches CI in <city>') and a second scenario (looking up a person mentioned in an event). It explicitly routes deeper lookups to get_teacher, so the alternative tool and the condition that selects it are both stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find dance studios and retreat centers that host Contact Improvisation classes, jams and events, by name, country or city. Use for 'where is CI taught in ' alongside search_communities. Returns venues with slug and URL; call get_venue for the address and upcoming events.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | Maximum results, 1 to 20. Default 10. | |
| query | No | Venue name or words from its description. | |
| country | No | ISO code or English name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the description is not burdened with the safety profile. It does add genuinely new behavioral facts: the result shape is slug and URL only, and address/events are deliberately absent and require a follow-up get_venue call. It stops short of describing pagination or the 1-20 limit's effect on response size.
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, front-loaded with what the tool finds before the usage trigger and the follow-up routing. Every clause carries information an agent needs to pick and sequence the call.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by stating what is returned (slug and URL) and where the rest lives (get_venue). Working alongside annotations that cover the safety profile, it leaves no gap an agent needs filled to invoke 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?
The schema describes three of four parameters (country, query, limit) but leaves city bare at 75% coverage; the description supplies the search axes 'by name, country or city', which maps query/country/city to intent. It adds meaning beyond the schema but does not clarify matching behavior (exact vs fuzzy) for city.
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 domain ('Find dance studios and retreat centers that host Contact Improvisation classes, jams and events') and names the lookup axes (name, country, city). It is clearly separable from search_communities, search_events and get_venue without opening any 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?
Gives an explicit situational trigger ('where is CI taught in <city>'), names the complementary sibling to run alongside it (search_communities), and routes the agent to get_venue when address/upcoming-event detail is needed. That is when-to-use plus alternatives, not just implied context.
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.
search_events1 field changedInput schema / properties / featuresAdded value: +{
+ "description": "Only events offering all of these, e.g. [\"residential\", \"meals\"] or [\"sliding_scale\"].",
+ "items": {
+ "enum": [
+ "residential",
+ "meals",
+ "sauna",
+ "swimming_pool",
+ "nature",
+ "by_the_sea",
+ "mountains",
+ "jams",
+ "silent_jam",
+ "live_music",
+ "self_organized",
+ "outdoor_dancing",
+ "hiking",
+ "site_specific",
+ "labs",
+ "underscore",
+ "contemplative_dance",
+ "ensemble_thinking",
+ "performance",
+ "talks",
+ "film_screenings",
+ "meditation",
+ "water_practice",
+ "silence",
+ "teacher_training",
+ "sliding_scale",
+ "work_exchange",
+ "scholarships",
+ "family_friendly",
+ "childcare",
+ "flinta",
+ "mixed_abilities"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}search_events2 fields changedInput schema / properties / from / descriptionPrevious value: -"Earliest date, YYYY-MM-DD. Default today."New value: +"Window start, YYYY-MM-DD. Default today. Includes events still running on or after this date; a past date also returns ended events."Input schema / properties / to / descriptionPrevious value: -"Latest start date, YYYY-MM-DD."New value: +"Window end: the latest start date, YYYY-MM-DD."get_communityget_eventget_teacherget_venuesearch_communitiessearch_eventssearch_teacherssearch_venuesBJJ and grappling gyms worldwide, plus upcoming competitions. Free, read-only.
Live events in 50 cities: AI/tech meetups, hackathons, conferences, concerts. Free, read-only.
Find aviation events: airshows, fly-ins, workshops and club meets. Public and read-only.
Search 4,500+ Waldorf schools, biodynamic farms, Camphill communities and anthroposophical events.
Add one secure layer between your agents and this server.