Skip to main content
Glama
si0nDE

mcp-bni

by si0nDE
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bni_search

Locate BNI members and their business details by country, keywords, city, or profession. Narrow results with match modes and selectable fields to avoid irrelevant listings.

Instructions

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).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityNoFilters by exact stored city — use keywords for anything less precise
fieldsNoRestrict 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.
countryYesTwo-letter country code (e.g. "DE", "FR", "US"). See bni_list_countries for every registered code.
keywordsNoSearch term: name, profession, company, or specialty (e.g. "Marketing", "Tax advisor")
matchModeNoHow 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.
maxResultsNoCaps 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.3

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools