BMLT Meetings

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds 'full record' to hint at the return payload. However, it does not disclose error behavior (e.g., not found) or any operational details 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: 'Fetch the full record for a single meeting by its BMLT id_bigint.' Every word earns its place, no wasted text.

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?

This is a simple get-by-ID tool with annotations covering safety. The description indicates it returns the 'full record', which partially compensates for the lack of an output schema. It does not describe error handling but is sufficient for this simple case.

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. The description only restates the id parameter as 'BMLT id_bigint', adding no new meaning beyond the schema. Baseline of 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 uses the specific verb 'Fetch' and identifies the resource as 'a single meeting by its BMLT id_bigint', which clearly distinguishes it from sibling search_meetings and list 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?

It clearly indicates this is for retrieving a single meeting when you have its id_bigint, but it does not explicitly state when to use search_meetings instead. This provides clear context without exclusions.

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

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

Annotations already declare readOnlyHint and idempotentHint, establishing a safe, non-mutating operation. The description adds value by specifying exactly what information is returned (capabilities, version, languages, coordinates), which goes beyond the annotation stubs. No contradiction with 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?

The description is a single, strategically worded sentence that directly states the tool's output without waste. It front-loads the action and enumerates the key data categories, earning every word.

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 read-only tool with one optional parameter and rich annotations, the description fully covers the necessary context. It specifies the return data categories, and there is no output schema requiring elaboration. The agent has enough to select and invoke 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 input schema fully describes the only parameter, root_server_url, with its 'Override...' purpose. The tool description merely mentions 'for a BMLT root server' but does not add syntax or default behavior details; given 100% schema coverage, 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 identifies the tool's action ('Return') and specific data ('capabilities, version, languages, and default coordinates') for a BMLT root server. This sharply distinguishes it from sibling tools that list formats, meetings, service bodies, or search meetings.

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 it clear when to use this tool: when you need root server metadata. It does not explicitly name alternatives or exclusions, but the context of 'for a BMLT root server' implies the appropriate use case, and no misleading guidance is present.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description need not repeat safety. It adds useful context about what formats are (e.g., language tags) and the mapping purpose, but does not disclose behaviors like default language handling, whether unused formats are excluded by default, or return structure. This is moderate but not rich.

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, well-structured sentence. It starts with the action and resource, includes concrete examples for clarity, and ends with a purpose clause. Every word earns its place with no redundancy or padding.

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 list tool with no output schema and only optional parameters, the description is adequate: it clarifies the purpose and gives examples. It could mention that the response contains format objects with IDs, but the purpose clause implies this. It is complete enough for the tool's complexity.

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 explains each parameter clearly. The description adds little beyond tying 'language tags' to the language parameter and 'human-friendly format names' to key_strings, but it does not meaningfully extend parameter understanding 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?

The description clearly states the verb ('List') and resource ('available meeting formats'), with concrete examples (Open, Closed, Speaker, Beginners, language tags) and a clear purpose: mapping human-friendly format names to BMLT format IDs. This distinguishes it from sibling list tools that focus on meetings, server info, etc.

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 provides a clear use case: 'so the caller can map human-friendly format names to BMLT format IDs.' While no alternative tools for formats exist among siblings, the context is sufficient. It does not explicitly state when not to use, but the purpose statement makes the primary usage obvious.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds that the tool returns public servers known to the aggregator and that returned values are usable in later calls, which is useful behavioral context beyond the structured hints.

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 fluff. The first sentence states the core function; the second provides actionable guidance on using the result. Every word 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 one optional parameter and no output schema, the description provides enough context: it defines the scope (public/known aggregator), indicates the return value contains root_server_url, and explains how to use it. This is complete for the given complexity.

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% for the single optional parameter, with the schema describing it as a case-insensitive substring filter. The description adds no additional meaning about the parameter, so the baseline of 3 applies—the schema handles the semantics adequately.

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 ('List') and resource ('public BMLT root servers known to the BMLT aggregator'), clearly distinguishing this from sibling tools that operate on meetings, formats, and service bodies. It also notes the output values are meant for use with other tools, which reinforces its unique role.

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 tells the agent to 'Use the returned root_server_url values with other tools to query a specific server,' providing clear downstream context. It does not compare against alternatives by name, but the guidance is sufficient for when this tool should be invoked (as a discovery step).

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds a behavioral hint about translating names to IDs, implying the output includes names and IDs. However, it does not disclose details like default behavior with no parameters, ordering, or pagination. With annotations present, a score of 3 is appropriate as it adds limited extra behavior context.

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 two sentences and front-loaded with the core action. The first sentence states what it does; the second adds a concrete use case. No redundant information or fluff. Every word 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?

Given the tool's simplicity (4 optional parameters, no output schema), the description is nearly complete. It explains the resource types and the primary use case (translating names to IDs). However, it doesn't explicitly state that calling with no parameters returns all service bodies, which could be inferred from the schema but is not directly stated. Slight gap, but overall adequate.

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%, with each parameter (include_parents, include_children, service_body_ids, root_server_url) having its own description. The tool description does not add additional parameter meaning beyond the schema, so the baseline of 3 applies. It doesn't compensate for any gaps because none exist 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 uses a specific verb 'List' with a clear resource 'BMLT service bodies,' and clarifies the domain with synonyms (zones, regions, areas, groups). It distinguishes itself from sibling list tools (list_formats, list_root_servers) by focusing on a different resource, and even connects to search_meetings by explaining the ID translation use case.

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 provides explicit context: it is useful for translating human-readable names like 'Northern California Region' into service body IDs for search_meetings. This implies when to use it, though it doesn't explicitly state when not to use alternatives. The mention of search_meetings gives a clear connection to a sibling tool, but no direct exclusions are stated.

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

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.

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.

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.

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.

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.

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.