Search and discover local community listings, classifieds, services and events.
Scored across 5 tools
Each tool has a distinct primary job, but search_listings and search_nearby overlap because search_listings can also calculate distance when latitude, longitude, and radius_km are supplied. Descriptions give enough guidance to usually choose correctly, but the boundary is not perfectly sharp.
All names use snake_case and most follow a verb_noun pattern (get_listing, list_categories, search_listings). Minor deviations exist: community_board_help is prefixed with the server name and search_nearby uses an adverb rather than a noun.
Five tools are well-scoped for a search-centric community board: help, category listing, listing detail, general search, and nearby search. No tool feels redundant or missing from the count itself.
The surface covers discovery/search and retrieval but lacks listing creation, update, deletion, or contact/messaging operations. Since descriptions reference 'listing creation' as part of the broader app, the missing write lifecycle is a notable gap, though search workflows are covered.
Use this when the user just says 'Community Board' or 'community-board', asks what this app can do, or asks for help or examples ('מה אפשר לעשות כאן?', 'עזרה'). Returns a summary, supported capabilities, the live category list, example requests in Hebrew and English, current limitations and search tips.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tips | Yes | |
| summary | Yes | |
| examples | Yes | |
| categories | Yes | |
| limitations | Yes | |
| capabilities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by enumerating what the call actually returns (live category list, Hebrew/English examples, limitations, search tips), which goes beyond the annotations.
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?
A single front-loaded sentence that leads with the trigger conditions and follows with the return contents. It is somewhat run-on because the return list is long, and that enumeration is partly redundant given an output schema exists, but no sentence is wasted.
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 help tool with an output schema and full annotation coverage, the description does everything needed: it tells the agent when to invoke it and what the response contains. Nothing required 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?
The tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify about arguments, and it correctly makes no attempt to invent any.
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 purpose: a help/discovery tool that returns a summary, capabilities, category list, examples, limitations and search tips. This is clearly distinct from the sibling listing/search tools, which all perform data retrieval rather than app orientation.
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 explicit triggering conditions: the user says 'Community Board'/'community-board', asks what the app can do, or asks for help/examples, with concrete Hebrew phrasing. An agent knows exactly when to route here instead of to search_listings or list_categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants more details about a listing returned by a search. Retrieves one listing by its UUID. Active listings are visible to everyone. Draft, sold, closed, or expired listings are returned only to their owner when the local development identity is configured; otherwise they are reported as not found.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes | UUID of the listing to retrieve. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| price | Yes | |
| title | Yes | |
| status | Yes | |
| address | Yes | |
| category | Yes | |
| currency | Yes | |
| latitude | Yes | |
| longitude | Yes | |
| created_at | Yes | |
| description | Yes | |
| distance_km | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description adds substantial behavior beyond them: visibility rules for active vs draft/sold/closed/expired listings, the owner-identity requirement, and the not-found outcome for non-owners. This is exactly the access-control detail an agent needs.
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 tight sentences, front-loaded with the usage trigger before the retrieval mechanics and visibility behavior. 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?
With an output schema present, return-value explanation is unnecessary, and the description covers the remaining gaps (access semantics, identity requirements, not-found behavior). Nothing an agent needs to call 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?
Schema coverage is 100% and the single listing_id parameter is fully documented as a UUID there. The description's 'by its UUID' phrase merely restates the schema, adding no new semantics, so 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 (retrieves one listing by its UUID) and ties it to the search flow. It is clearly distinguishable from the sibling search_* tools, which return result sets rather than a single record.
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?
'Use this when the user wants more details about a listing returned by a search' names the exact trigger and implicitly routes the agent away from the search tools toward this detail fetch. The context that selects this tool over its siblings is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to map what the user wants (e.g. car, apartment, plumber, job, dog, event) to a category slug before searching. Returns the category slugs and display names accepted by listing creation and search. Use a returned slug as the category parameter. An empty categories array means no categories are currently configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world semantics, so the safety profile is covered. The description adds genuinely new context: that returned slugs are the exact values accepted by listing creation and search, and that an empty array signals no configured categories.
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 tight sentences, front-loaded with purpose, then the integration contract, then the empty-state edge case. No filler and every sentence carries actionable 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?
With an output schema present, the description is not obligated to enumerate return fields, yet it still clarifies the semantic meaning of the returned slugs and the empty-array case. An agent has everything needed to call and interpret this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4 and there is no schema semantics for the description to duplicate or compensate for. No parameter guidance is needed 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?
States a specific verb and resource ('list categories') and immediately defines its functional role: mapping user intent (car, apartment, plumber) to an accepted category slug. It also distinguishes itself from search siblings by framing itself as a prerequisite step rather than a search itself.
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 clear when-to-use guidance ('use this to map what the user wants ... before searching') and a concrete follow-up action ('use a returned slug as the category parameter'). It does not name specific sibling alternatives or exclusions, which keeps it just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this first whenever the user asks to find, search for, buy or rent something locally (e.g. 'תחפש לי', 'תמצא לי', 'אני מחפש לקנות'): second-hand items, vehicles, apartments, jobs, professionals, pets or events. Searches active Community Board listings. Filter by words in the title or description, category slug, and inclusive minimum or maximum price. Supply both latitude and longitude to calculate distance; also supply radius_km to limit results to that distance. Use distance sorting only with an origin, relevance to put title matches first for a query, or newest for recent listings. An empty results array means no active listings matched the filters.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering: relevance, distance (requires origin), or newest. | newest |
| query | No | Optional words to match in title or description. | |
| category | No | Optional category slug, such as vehicles or real_estate. | |
| latitude | No | Latitude of the search origin; provide together with longitude. | |
| longitude | No | Longitude of the search origin; provide together with latitude. | |
| max_price | No | Optional inclusive maximum price; use the listing currency. | |
| min_price | No | Optional inclusive minimum price; use the listing currency. | |
| radius_km | No | Optional maximum distance in kilometers; requires latitude and longitude. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context: distance sorting requires an origin, radius_km bounds results around it, and an empty results array means no active listings matched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the imperative 'use this first' and the trigger phrases, then the filters and sorting rules. Slightly dense as one paragraph and the parenthetical Hebrew examples add length, but 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?
An output schema exists, so return-value explanation is unnecessary. The description covers filters, sorting preconditions, and the empty-result case; the only gap is routing relative to search_nearby for geo queries.
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 3. The description adds meaning beyond the schema by calling out inclusive min/max price bounds, the title/description scope of query, and what relevance sorting actually does ('put title matches first').
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 a precise verb and resource ('Searches active Community Board listings') and enumerates the domains it covers (second-hand items, vehicles, apartments, jobs, professionals, pets, events). It clearly separates itself from get_listing and list_categories, but does not distinguish itself from search_nearby despite overlapping geography/radius behavior.
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?
Strong routing guidance: 'Use this first whenever the user asks to find, search for, buy or rent something locally,' backed by multilingual trigger examples. It gives no explicit exclusions or named alternatives (e.g. when to prefer search_nearby over distance sorting here).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what is available, sold or happening near a place or near them (e.g. 'מה מוכרים לידי', 'מה קורה לידי', 'איש מקצוע באזור'). If their location is unknown, ask for a city or area first instead of guessing. Finds active listings near a geographic point using PostGIS distance search. Latitude and longitude are separate decimal-degree values; radius_km is required and measured in kilometers. You may narrow by category. Distance ordering is the default. An empty results array means nothing active matched within the radius.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Result ordering; distance requires the supplied origin. | distance |
| category | No | Optional category slug. | |
| latitude | Yes | Search origin latitude in decimal degrees. | |
| longitude | Yes | Search origin longitude in decimal degrees. | |
| radius_km | Yes | Maximum distance from the origin, in kilometers. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| results | Yes |
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 real behavioral context beyond that: the PostGIS distance mechanism, that distance ordering is the default, and that an empty array means nothing active matched within the radius — a useful signal for interpreting results.
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 trigger condition before the mechanics, which is the right ordering, and every sentence is informative. The 'using PostGIS distance search' clause is mild implementation detail that an agent doesn't need to select the tool, but it is not wasteful enough to hurt.
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-value documentation is unnecessary, and the description still covers the one interpretive case that matters (empty array). With annotations and a complete schema, the definition leaves no functional gap for a geospatial search call; only an explicit sibling pointer is absent.
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 every parameter including bounds, defaults and enum values is already documented. The description reinforces a few points (radius_km required, kilometers, lat/long as separate decimal degrees, category narrowing) but adds no syntax or semantics the schema lacks. Baseline 3 applies when the schema does the heavy lifting.
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 ('Finds active listings near a geographic point using PostGIS distance search') and the geospatial scoping implicitly separates it from the general search_listings sibling. However, it never names an alternative sibling, so the differentiation is inferential rather than explicit.
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 invocation triggers with multilingual user phrasings ('מה מוכרים לידי', 'איש מקצוע באזור') and a clear when-not to act: if location is unknown, ask for a city or area instead of guessing. No alternative tool is named for the case where the user wants a non-geographic search, which keeps it short of a 5.
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.
community_board_helpget_listinglist_categoriessearch_listingssearch_nearbySearch and discover local businesses. 30+ categories with verified contact info, hours, and reviews.
Directory and marketplace of local businesses and independent professionals near you.
Find and book local services, classes and rentals; businesses set up and manage their pages.
Search and browse global classifieds across 80 markets. No auth required for read-only access.
Add one secure layer between your agents and this server.
