Skip to main content
Glama

Search Narcotics Anonymous meetings

search_meetings
Read-onlyIdempotent

Search Narcotics Anonymous meetings on a BMLT root server. Filter by location (address or lat/lng + radius), weekday, time of day, format, venue type (in-person / virtual / hybrid), and service body. Returns a trimmed summary by default; pass data_format='full' for the raw BMLT response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed). Used with page_size.
addressNoFree-form address to search near (geocoded server-side). Ignored if latitude+longitude are provided.
languageNoLanguage code for format names (e.g. "en", "es", "de", "fr").
latitudeNoLatitude in decimal degrees. Pair with longitude for an exact-coordinate search.
weekdaysNoWeekday filter. 1=Sunday, 2=Monday, ..., 7=Saturday. Example: [2,4,6] for Mon/Wed/Fri.
longitudeNoLongitude in decimal degrees. Pair with latitude for an exact-coordinate search.
page_sizeNoResults per page. Omit to return all matches.
radius_kmNoSearch radius in kilometers. Takes precedence over radius_miles when both are provided. Ignored when no coordinates are provided.
format_idsNoBMLT format IDs to require. Use list_formats to discover IDs (e.g. Open, Closed, Speaker, Beginners).
data_formatNo"summary" returns a curated subset of fields (default). "full" returns the raw BMLT response.summary
search_textNoFree-text search across meeting name, location, and notes.
venue_typesNoVenue type filter. 1=In-person, 2=Virtual, 3=Hybrid.
radius_milesNoSearch radius in miles. Defaults to 10. Ignored if radius_km is provided or no coordinates are given.
starts_afterNoEarliest start time as 24h "HH:MM" (e.g. "18:00").
starts_beforeNoLatest start time as 24h "HH:MM" (e.g. "21:30").
root_server_urlNoOverride the configured BMLT root server URL. Must be allowlisted unless BMLT_ALLOW_ANY_ROOT=true.
service_body_idsNoRestrict to specific service bodies (regions/areas). Use list_service_bodies to discover IDs.
recursive_servicesNoWhen service_body_ids is set, also include their children. Default true.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds the default 'trimmed summary' vs data_format='full' behavior, which is useful but limited. It does not mention pagination defaults, rate limits, or authentication details beyond what the schema already covers.

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?

Two sentences, front-loaded with the action and resource, followed by a concise filter overview and return format note. Every sentence earns its place; no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 18 typed parameters and no output schema, the description explains core capabilities and default output format, and mentions the raw response option. It doesn't detail 'trimmed summary' fields or pagination, but that is acceptable given the rich schema and read-only annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 18 parameters have detailed schema descriptions, so the tool description only summarizes filter categories without adding new parameter-level information. Baseline 3 applies because schema description coverage is 100%.

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?

Description begins with 'Search Narcotics Anonymous meetings' — a specific verb + resource — and then enumerates the filter dimensions (location, weekday, time, format, venue type, service body). This clearly distinguishes it from siblings like get_meeting (single meeting lookup) and list_formats (format catalog).

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?

Provides clear context: use to search/filter meetings across multiple dimensions. It does not explicitly mention alternatives or exclusions, but the search scope is unambiguous and easily differentiated from the sibling tools by name and description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching a single meeting, server info, formats, root servers, service bodies, and searching meetings. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (e.g., get_meeting, list_root_servers, search_meetings), making it easy for agents to predict and select tools.

Tool Count5/5

With 6 tools, the set is well-scoped for a meeting directory server, covering essential operations without being overly sparse or bloated.

Completeness5/5

The tools cover the full lifecycle for a read-only meeting directory: listing metadata (servers, service bodies, formats), searching meetings with filters, and fetching details. No obvious gaps.