Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-bni Find BNI members in Australia who are accountants"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for searching BNI (Business Network International) members and chapters worldwide, built against BNI's own public "find a member" pages — no login required, no data stored.
Tool | Purpose |
| Search members in a country (fans out across every registered site for that country) |
| Full public profile: phone, email, website, chapter, chapter meeting info, and bio split into BNI's standard sections (My Business, Ideal Referral, Ideal Referral Partner, Top Problem Solved, Top Product, Favorite BNI Story) where the profile has them |
| Whitespace analysis for a chapter against the official BNI profession taxonomy — resolves the chapter's exact name via |
| Named roster for a chapter (name, company, profession, city per member) — same exact chapter resolution as |
| Every registered country code and its known site(s) |
| Exact chapter names (and internal ids) for a country, where the site exposes them |
| Public events (trainings, webinars, regional visitor days) |
| Full event details: contact, cost, location, registration count |
| Official BNI regions for a country |
| Official event-type names — good search terms for |
| The official worldwide BNI profession catalog |
| LinkedIn search URL + suggested web searches (no external requests) |
Related MCP server: B2Bhint MCP Server
A "country" can have more than one registered site — most countries have exactly one national member database, but some (large markets where BNI never built a single national entry point) are split into regional sites instead. bni_search, bni_upcoming_events, bni_list_regions, and bni_list_event_types automatically query every registered site for the country you ask about (capped at 5 per call; the response says so explicitly if more exist). bni_list_countries shows exactly what's registered.
New sites are added by finding their public "find a member" page URL — no reverse engineering needed; the technical IDs are discovered automatically and cached (see src/registry/discovery.ts).
The reverse can also be true: one physical site can serve more than one registered country from a shared database (Germany and Austria, on bni.de). Every tool still returns only the country you asked for — discovery resolves each registered country to its own distinct id live (via BNI's own country-name lookup, not a hardcoded mapping), so a country: "DE" query never leaks Austrian chapters/regions/events and vice versa.
BNI's own member-search "keywords" field does broad, OR-style full-text matching across name, profession, and company rather than an exact/AND filter — a common word matches every member containing it, up to the ~250-per-site result cap. bni_search narrows this client-side by default: a multi-word keywords is matched as an exact phrase (matchMode: "phrase") against the already-fetched results before they're returned, so e.g. a two-word name search comes back with just the real match instead of hundreds of unrelated members. This narrowing only ever removes noise from what BNI already returned — it can't hide a real match. Pass matchMode: "any" to see BNI's raw unfiltered match, or "all" to require every word present in any order/field. bni_search also detects when a site's raw result count looks suspiciously high and flags it explicitly, since a swamped raw set can mean the real match never made it into the ~250-per-site cap in the first place. Responses default to the first 20 matched members (maxResults, capped at 250) — a compact fields projection is available for large result sets.
For chapters specifically, this is partly avoidable: bni_list_chapters resolves each site's real, exact chapter names (from a static dropdown where the page renders one, or by fanning out over every region otherwise — see "Known limitation" below), and bni_chapter_gaps/bni_chapter_members use a matched exact name as the search keyword instead of a guessed word. This still goes through the same keyword search and its ~250-per-site cap (a chapter's own numeric id turned out not to reliably scope a search to just that chapter when tested live — see below), but a full exact chapter name is a much lower-collision-risk keyword than a single guessed word, and the response is still narrowed further by matching each result's own chapter/region field. If a chapter name matches more than one entry (e.g. a city shared by several chapters), the response names every matching candidate instead of guessing one.
searchMembers accepts a chapter's own id as an alternative to a keyword — this was expected to return that chapter's exact, complete roster with no cap involved. Live-tested against bni.de and found not to work reliably: passing a real chapter id (independently confirmed correct via bni_member_detail's own chapterId, and via the region-based chapter listing) returned either zero results, or every member of that chapter's whole region unfiltered, depending on which other form fields were present in the request — never just that one chapter. Root cause unconfirmed; bni_chapter_gaps/bni_chapter_members no longer rely on this and instead search by the chapter's exact name (see above). The parameter itself is left in place in case a future investigation finds the correct usage, but nothing in this package currently uses it.
The official BNI profession catalog (bni_list_professions, and the taxonomy bni_chapter_gaps matches against) is sourced live from a German-only reference endpoint — there's no English or other-language variant to request. A member's own free-text profession, chapter names, and site registry labels can each be in a different language depending on the source site, so a single response can mix languages (e.g. a German category name next to an English member-entered profession). This server doesn't translate anything itself; presenting a consistent language to an end user is left to the calling model.
This package ships two Claude Skills under skills/, installable alongside the MCP tools:
Skill | Purpose |
| Find matching BNI members for a product/service and prepare personalized 1:1 outreach |
| Prepare a briefing before visiting a BNI chapter as a guest or member |
npx -y mcp-bni@latestClaude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"bni": {
"command": "npx",
"args": ["-y", "mcp-bni@latest"]
}
}
}Claude Code:
claude mcp add bni -- npx -y mcp-bni@latestBNI Connect's Terms of Service contain a "No Automated Querying" clause: "You may not send automated queries of any sort to the BNI Sites or its systems without express written permission in advance from BNI." This term is written broadly enough that it plausibly covers the public country "find a member" sites this tool queries, not only the login-gated BNI Connect app — they run on the same backend platform.
This is not resolved by personal, low-volume, or rate-limited use — those reduce practical/enforcement risk, they do not change whether an automated request is textually "automated" under the clause. This tool is provided for personal/informational use, at your own risk. If your use case has higher stakes (commercial use, wide redistribution, high volume), seek BNI's written permission or independent legal advice before relying on it.
Every request to a BNI host is spaced by a minimum delay and multi-site queries run sequentially, never in parallel (see src/rate-limit.ts). This is partly courtesy and partly self-preservation — BNI's own infrastructure temporarily IP-bans clients that exceed its own request rate, so staying well under that threshold is also just practical.
MIT — see LICENSE.
Analyzes a chapter: lists existing professions with counts, and identifies whitespace using the official BNI profession taxonomy (empty categories + specific open professions in thinly-covered categories). Resolves the chapter's exact name via bni_list_chapters where possible and uses that as the search keyword (still subject to the ~250-result-per-site cap, but with a low-collision-risk exact name rather than a guessed word). The taxonomy itself is German-only; a member's own free-text profession can be in a different language, which is the usual cause when it shows up as "unmatched" rather than being a data error — translate as needed for the person you're presenting results to.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. | |
| chapterName | Yes | Chapter name (as it appears in search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's actions: lists counts, identifies gaps, resolves names, applies a ~250-result cap, and highlights the German-only taxonomy and language mismatch issue. It also clarifies that unmatched professions are often not data errors. This is exceptional transparency for a read/analysis tool, covering all significant behaviors and edge cases.
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 somewhat lengthy but every sentence contributes critical information. The main purpose is front-loaded in the first sentence, followed by operational details (name resolution, cap, language caveat). It avoids fluff and is well-structured, though it could be slightly tightened without losing value. It is appropriately sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema or annotations, the description is quite complete. It explains the analysis approach, the resolution process, the cap, and the language handling. It does not explicitly describe the return format, but the description implies it lists professions and counts and identifies gaps, which is sufficient for an agent to understand what to expect. Minor omissions like pagination details are acceptable given the level of context provided.
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 both parameters described in the schema, so the baseline is 3. The description adds meaningful value beyond the schema: it explains that chapterName is used as a search keyword after resolution via bni_list_chapters, and that the exact name reduces collision risk. It also adds context about country being a two-letter code without repeating the schema. This exceeds the baseline by providing practical usage nuance.
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 a specific verb ('analyzes') and resource ('a chapter'), and specifies what it produces: existing professions with counts and identified whitespace based on the BNI taxonomy. It distinguishes itself from siblings like bni_chapter_members or bni_search by focusing on profession gap analysis rather than membership lists or general search. The purpose is immediately understandable and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining it resolves the chapter name via bni_list_chapters and notes the search cap, but it does not explicitly state when to choose this tool over alternatives (e.g., 'use this when you need to find profession gaps' or 'not for member counts'). It gives process hints but not explicit when/when-not guidance, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every member of a chapter by name, with company/profession/city — a compact roster. Complements bni_chapter_gaps (which analyzes professions/whitespace but omits names) without needing a bni_search keyword workaround. Resolves the chapter's exact name via bni_list_chapters where possible and uses that as the search keyword (still subject to the ~250-result-per-site cap, but with a low-collision-risk exact name rather than a guessed word).
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. | |
| chapterName | Yes | Chapter name (as it appears in search results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses the output fields, the resolution process through bni_list_chapters, and the ~250-result cap plus low-collision-risk reasoning. It does not mention error/fallback behavior or explicitly state read-only, so it stops 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?
The description is three dense, purposeful sentences: core purpose, sibling differentiation, and important operational caveat. Every sentence earns its place and the most essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description supplies the essential return fields, the main limitation, and how it relates to sibling tools. The phrase 'where possible' leaves some ambiguity about fallback behavior, and a read-only statement would strengthen completeness, so a 4 is appropriate.
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 meaningful semantics beyond the schema by explaining that chapterName is resolved via bni_list_chapters and then used as the search keyword, and by flagging the result cap. Country is not elaborated, but the schema already covers it well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lists every member of a chapter by name, with company/profession/city — a compact roster.' It clearly differentiates itself from bni_chapter_gaps and bni_search, so an agent knows exactly what this tool returns and how it differs from close siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names alternatives and their roles: bni_chapter_gaps analyzes professions/whitespace but omits names, and bni_search is not needed as a workaround. It also explains that the tool resolves the exact chapter name via bni_list_chapters where possible, giving clear routing and execution context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates LinkedIn search URLs and suggested web searches to find more information about a BNI member (no external requests).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| name | Yes | Member's full name | |
| company | No | ||
| profession | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses that no external requests are made, meaning the tool only generates URLs and search suggestions rather than performing network calls. This is a critical behavioral trait for an agent to know, and it is stated upfront. However, it does not describe any other behaviors such as output format or rate limits, but the main non-obvious behavior is covered.
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 that front-loads the primary action ('Generates LinkedIn search URLs and suggested web searches') and immediately follows with the key caveat ('no external requests'). Every word earns its place, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is minimal. It states the core function and the no-request caveat, but it does not describe the structure of the output (e.g., whether it returns a list of URLs, a formatted string, or a report) or how the optional parameters refine the search. An agent might need to guess at output formatting. However, the tool's simplicity (generating URLs) and the clear purpose reduce the need for extensive detail, so a 3 is appropriate.
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 has only 25% description coverage (only 'name' is described). The description does not elaborate on how 'city', 'company', or 'profession' influence the generated URLs or search suggestions. It only vaguely ties them to 'find more information about a BNI member'. This is insufficient given the low schema coverage; the description should compensate by explaining each parameter's role, but it does not.
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 specific verb ('generates') and a specific resource ('LinkedIn search URLs and suggested web searches'), and it clarifies the scope ('to find more information about a BNI member'). It also notes a key distinction ('no external requests'), which differentiates it from tools that actually fetch data, like bni_member_detail or bni_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for enrichment (finding more info) but does not explicitly state when to use this tool versus alternatives like bni_member_detail (which likely retrieves internal details) or bni_search (which might be a general search). No exclusions or conditions are provided, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches an event's full details: contact, member/non-member cost, location or online link, registration count.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | The site id this event was found on | |
| eventId | Yes | Event id or full eventdetails URL from bni_upcoming_events |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of explaining behavior. It clearly conveys a read-only fetch and discloses what the returned details include: contact, cost, location/online link, and registration count. It does not describe failure modes or response format, but for a simple fetch tool this is acceptable.
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 sentence that front-loads the core purpose and then lists the key return fields. Every phrase adds information, with 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?
Given the tool's simplicity, the two parameters are fully documented, and the description covers the main return fields even though no output schema exists. The only minor gap is the lack of explicit guidance about how this tool fits relative to bni_upcoming_events, but the schema reference helps bridge that.
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 the input schema already documents both site and eventId. The description adds no parameter-specific meaning beyond the schema's own explanations, leaving it at the baseline score.
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: 'Fetches an event's full details' and enumerates specific content (contact, cost, location/link, registration count). This clearly separates it from the list-oriented sibling bni_upcoming_events, which only returns event summaries.
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 is implied rather than explicit. The parameter schema notes that eventId comes from bni_upcoming_events, suggesting a workflow of first listing events then fetching details, but the description itself never states when to prefer this tool over its siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the exact, complete chapter names for a country, where available. Chapters found this way are used by bni_chapter_gaps/bni_chapter_members as a precise search keyword instead of a guessed word (still subject to the ~250-result-per-site cap); sites that don't expose this list are noted as such. First call for a country whose site builds this list region-by-region (rather than serving it directly) can take significantly longer (dozens of seconds) as a result; cached in-process afterward.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the 'where available' caveat, the ~250-result cap, the potentially long first-call latency for region-by-region sites, and in-process caching—useful behavioral context beyond a simple 'list' statement.
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 pack purpose, usage context, limitations, and performance into a compact description; no filler. It is dense but each clause adds value.
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 single-parameter read tool with no output schema or annotations, the description covers purpose, usage, edge cases, performance, and caching. It could specify the exact return shape, but the core information an agent needs is present.
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 only parameter, country, is fully documented in the schema (two-letter code, example, reference to bni_list_countries). The description adds no additional parameter-level detail, so baseline 3 is appropriate.
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 action ('Lists') and resource ('exact, complete chapter names for a country'), and clarifies its role as a precise keyword source for bni_chapter_gaps/bni_chapter_members, distinguishing it from sibling tools.
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?
Explains that the result is intended as a search keyword for chapter-related siblings, which tells an agent when this tool is relevant. It does not explicitly list when not to use it or name alternatives, but the use context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists every registered country code and the sites known for it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It implies a read-only operation through the verb 'Lists' but does not explicitly state safety, output structure, pagination, or any caveats. It adds some context but leaves room for ambiguity.
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 sentence with no filler. The action and object are front-loaded, making it highly scannable and economical.
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 no annotations or output schema, the description adequately conveys its purpose and scope. It tells the agent what will be returned (country codes and their known sites). Minor details like response format or error behavior are not addressed but are not critical for this simple list 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?
With zero parameters and an empty schema (100% coverage), the baseline for this dimension is 4. The description does not need to explain parameters and correctly omits them.
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 the specific verb 'Lists' and clearly identifies the resource: every registered country code and its associated sites. This distinguishes it from sibling list tools like bni_list_regions and bni_list_chapters, which target different resources.
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 clearly states the context: use this tool to obtain all registered country codes and their sites. While it doesn't name alternative tools or exclusions, the specificity of the resource makes the usage obvious for agents needing country-level data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the official BNI event-type names for a country — useful search terms for bni_upcoming_events.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool lists event-type names, which is a read operation, but doesn't disclose any other behavioral traits like whether the country code must be valid, what happens for invalid codes, or the format of the output. It adds some context by noting the output is useful for bni_upcoming_events, but lacks depth.
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 sentence that is concise and front-loaded with the main purpose. It also adds a practical hint about usage without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is mostly complete. However, it doesn't mention what the output looks like (e.g., array of strings) or any error behavior, which could be useful for an agent. The hint about bni_upcoming_events adds context, but the lack of output format details is a minor gap.
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 the schema already documents the country parameter. The description doesn't add much beyond the schema, but it does imply the country code is used to filter event types. Baseline 3 is appropriate.
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 lists official BNI event-type names for a country, with a specific verb and resource. It doesn't explicitly distinguish it from siblings like bni_list_regions or bni_list_countries, but the resource (event types) is distinct enough.
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 says the output is useful as search terms for bni_upcoming_events, which gives clear context for when to use it. It doesn't explicitly state when not to use it or name alternatives, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the official BNI worldwide profession catalog (professions + categories), searchable and filterable. Names are German-only (the taxonomy source has no other-language variant) — translate for the person you're presenting results to if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filters professions by keyword (e.g. "advisor", "IT") | |
| category | No | Filters by category name (e.g. "Legal & Tax", "Computers & Technology") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that names are German-only and advises translation, a key behavioral trait. The verb 'Lists' implies a read-only operation, which is appropriate. It adds value beyond the schema by flagging the language limitation.
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 primary purpose and followed by a crucial caveat. No wasted words; 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?
For a simple list tool with no output schema, the description covers the essential purpose, parameters, and an important behavioral quirk (German-only names). It does not mention pagination or result limits, but these are minor for a list operation and not necessary for correct invocation.
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 both parameters are already well-documented. The description's mention of 'searchable and filterable' aligns with the parameters but adds no extra meaning about formats or defaults. Baseline of 3 is appropriate given full schema 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?
States a specific verb ('Lists'), a specific resource ('official BNI worldwide profession catalog'), and notes it includes professions and categories. It also mentions search/filter capabilities, clearly distinguishing it from sibling tools that handle events, regions, or chapters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for profession data, but does not explicitly state when to use it versus alternatives like bni_list_regions or bni_list_chapters. There is no 'when not to use' guidance, though the resource name is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the official BNI regions for a country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Lists' signals a read-only operation, but the description does not disclose response format, whether region identifiers are returned, or any other behavior the agent should expect. It is adequate for a simple list tool but not richly transparent.
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 sentence with no wasted words. It states the action, resource, and scope immediately, making it easy to scan and process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is close to sufficient. However, it does not clarify what a 'region' looks like in the response or how the output can be used with other tools, leaving a notable gap for an agent that must chain calls.
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 the country parameter is already fully documented, including examples and a pointer to bni_list_countries. The tool description adds only the phrase 'for a country,' which reinforces the parameter but does not add meaning beyond the structured 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?
The description uses a specific verb ('Lists') with a clear resource ('official BNI regions') and a scope ('for a country'). It is easy to distinguish from siblings like bni_list_countries and bni_list_chapters because the resource type is 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?
The description implies when to use the tool: when you need BNI regions for a country. However, it does not explicitly mention alternatives, exclusions, or how this tool fits into the broader country/region/chapter hierarchy, leaving some usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches a member's full public profile: phone, email, website, title, chapter, chapter meeting info if resolvable, and their bio broken into BNI's standard sections where available (My Business, Top Product, Ideal Referral, Ideal Referral Partner, Top Problem Solved, Favorite BNI Story) — the Ideal Referral Partner section is the most direct signal for who to introduce this member to.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Member's name (required to build the profile URL) | |
| site | Yes | The site id this member was found on (from bni_search results) | |
| encryptedMemberId | Yes | From bni_search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read-only fetch of public data, lists what is returned, and flags conditional availability ('if resolvable', 'where available'). It does not mention error cases or rate limits, but those are less critical for a public profile fetch.
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 dense sentence with no filler; every clause adds value, including the note about the Ideal Referral Partner section. It is slightly long but appropriately detailed for the complexity of the returned 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?
Given there is no output schema, the description effectively documents the return payload by listing the profile fields and bio sections. It also provides practical guidance on using the Ideal Referral Partner section. The required parameters and their origins are covered, making the tool invocable without missing information.
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 the parameters are already well-documented in the schema. The description itself adds no additional parameter-level meaning beyond what the schema already states.
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 ('Fetches') and resource ('member's full public profile') and enumerates the exact fields returned. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like bni_enrich_member or bni_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving detailed profile data after a search, especially because the schema notes that site and encryptedMemberId come from bni_search results. However, it does not explicitly state when to prefer this over bni_enrich_member or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches the public BNI member directory for a country. Fans out across every registered site for that country (capped; see bni_list_countries). BNI's own search matches each word in "keywords" independently (OR-style) up to 250 raw results per site; for a multi-word keywords this tool then narrows the raw matches down by matchMode before returning (default 20 results — raise maxResults for more).
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filters by exact stored city — use keywords for anything less precise | |
| fields | No | Restrict each result to just these fields, e.g. ["name","company","profession","city"], for a compact one-line-per-member response. Omit for the full default format. | |
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. | |
| keywords | No | Search term: name, profession, company, or specialty (e.g. "Marketing", "Tax advisor") | |
| matchMode | No | How a multi-word "keywords" is narrowed against BNI's raw (broad, OR-style) match: "phrase" (default) requires the exact phrase; "all" requires every word present in any order; "any" disables narrowing and returns BNI's raw unfiltered match. No effect on a single word. | |
| maxResults | No | Caps how many matched members are returned (default 20, max 250). The full raw result set is still fetched and matched first; this only truncates the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does exceptionally well: it reveals BNI's raw OR-style matching, the 250-result cap per site, fan-out across sites, matchMode narrowing behavior, and that maxResults only truncates the response after the full raw set is fetched. These are non-obvious behavioral details an agent needs to set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it front-loads the core action, then layers in the fan-out cap, raw matching semantics, and result-count behavior. Every sentence contributes a distinct, useful fact 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?
For a six-parameter tool with no output schema and no annotations, the description covers the essential operational context: country scope, fan-out behavior, result caps, matchMode semantics, and how maxResults affects output. The sibling list and schema fill remaining details.
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%, but the description adds meaningful behavior beyond the schema: it explains how multi-word keywords interact with matchMode, what 'any' means relative to BNI's raw OR-style match, and that maxResults doesn't reduce upstream fetching. This goes well beyond the parameter descriptions in 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?
The description opens with a specific verb and resource: "Searches the public BNI member directory for a country." It clarifies scope by noting it fans out across every registered site for that country, which clearly differentiates it from sibling tools like bni_member_detail or bni_chapter_members.
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 clear this is the country-wide directory search tool, referencing bni_list_countries for valid codes. It doesn't explicitly name alternatives or exclusions, but the context is strong enough for an agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists upcoming public BNI events for a country (trainings, webinars, regional visitor days). See bni_list_event_types for good search terms.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filters title/description by keyword (e.g. "Visitor Day") | |
| country | Yes | Two-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code. | |
| daysAhead | No | Days ahead from today (default 60) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by stating events are public and upfront, but it does not describe the return format, ordering, date window semantics, or behavior when no events match. This is adequate but leaves room for more transparency.
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?
One dense, front-loaded sentence captures the tool's purpose and scope, followed by a useful cross-reference. Every word earns its place; there is no filler or redundant restating of the tool name.
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?
The description, combined with the fully documented schema, gives an agent enough to call the tool correctly for an initial list request. The main gap is that, with no output schema, it does not mention what event fields are returned or point to bni_event_detail for follow-up details.
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 value beyond the schema by suggesting bni_list_event_types as a source for search terms, which directly helps an agent populate the optional 'search' parameter meaningfully.
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: 'Lists upcoming public BNI events for a country'. It also names the event categories (trainings, webinars, regional visitor days), which clarifies scope and distinguishes it from detail/listing siblings like bni_event_detail and bni_list_event_types.
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 clearly states the use case: listing future public events by country. The pointer to bni_list_event_types for good search terms gives practical guidance on how to refine the search, though it does not explicitly state when not to use this tool or contrast it with bni_event_detail.
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.
v1.1.3bni_chapter_gapsbni_chapter_membersbni_enrich_memberbni_event_detailbni_list_chaptersbni_list_countriesbni_list_event_typesbni_list_professionsbni_list_regionsbni_member_detailbni_searchbni_upcoming_eventsScored across 12 tools
Every tool targets a distinct resource or action: countries, regions, chapters, event types, professions, events, members, and chapter analysis. The complementary pairs like bni_chapter_members vs bni_chapter_gaps and bni_search vs bni_member_detail are clearly differentiated by their descriptions.
All tools share the bni_ prefix and snake_case style, and list/detail/search verbs are used predictably for their roles. Minor deviations exist: bni_event_detail, bni_chapter_gaps, and bni_chapter_members are noun-phrase names rather than verb_noun, and bni_search lacks a noun object, but the pattern remains readable and predictable.
Twelve tools is well within the ideal range for a read-only domain-specific server. Each tool covers a distinct data need, and none feels redundant or superfluous for the BNI public directory use case.
The server covers the full public read-only BNI data surface: countries, regions, chapters, professions, events, event details, member search, member profiles, chapter rosters, and chapter profession-gap analysis. No obvious missing operations or dead ends are apparent for the stated purpose.
One API for public web data across social, directories and real estate, as clean JSON.
Search B2B contacts, enrich verified emails and phone numbers, and export results.
Find verified B2B emails and phone numbers; search and enrich people and companies for prospecting.
Find decision makers at any company: name, job title and LinkedIn profile URL. No login needed.
