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

There are no annotations, so the description must convey behavioral traits. It mentions that the result includes properties, relations, and child classes, but does not disclose defaults (e.g., includeChildren and includeRelations default to false), potential performance implications, or any read-only guarantees. This is minimal 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?

The description is one substantive sentence with a short second sentence. It is front-loaded with the verb and key details. The second sentence, 'Essential for BIM enrichment,' is somewhat promotional and adds little informational value, slightly reducing the score.

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 no output schema, the description partially addresses return content by listing what is included (properties, relations, child classes). However, it does not describe the response structure, pagination, or error cases. It is adequate for a read tool but not fully complete.

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 schema already documents all parameters. The description adds little beyond the schema, only reinforcing that properties, relations, and child classes are covered by the include flags. This is baseline for 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?

The description clearly states the tool's function: 'Get full details of a bSDD class' with concrete examples (IfcWall, IfcDoor). It also lists the included content (properties, relations, child classes), which differentiates it from more focused sibling tools like bsdd_get_class_properties and bsdd_get_class_relations.

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?

No explicit guidance is provided on when to use this tool versus alternatives. The phrase 'Essential for BIM enrichment' is vague and does not clarify when to choose this over siblings such as bsdd_get_class_properties or bsdd_search_classes.

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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses the paginated nature and the content of the returned properties, but does not mention required permissions, error behavior, default sorting, or how pagination parameters interact. This is adequate 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?

The description is two sentences, front-loaded with the core action and outcome, followed by a practical use case. Every word earns its place; there is no redundant 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?

For a list-retrieval tool with a well-described schema and no output schema, the description covers purpose, return content, pagination, and usage context. It lacks details about error cases or exact pagination behavior, but remains largely complete for a simple read operation.

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 all four parameters. The description adds little parameter-level meaning beyond noting pagination, which aligns with limit/offset. It does not elaborate on classUri or languageCode semantics, 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?

The description uses a specific verb ('Get') and resource ('paginated list of properties for a bSDD class'), making the tool's purpose immediately clear. It also names the included content (data types, units, allowed values), which distinguishes it from sibling tools like bsdd_get_class or bsdd_get_property.

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 states a use case: 'Use to know what properties a BIM element should have.' This gives clear context for when the tool is appropriate, though it does not name alternative tools or explicitly state 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.

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

No annotations are provided, so the description carries the full burden. It discloses the relationship categories and the cross-referencing purpose, implying a read-only operation. However, it does not describe the return structure, pagination details beyond the schema, or any error/edge-case behavior. This is a moderate level of transparency for a simple get tool.

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, well-structured sentence that leads with the primary action ('Get relationships'), lists concrete relationship types, and finishes with a practical use case. There is no redundancy or unnecessary detail.

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 no output schema, the description explains the core behavior and provides usage context. It tells the user what relations are returned and mentions cross-referencing, which is the primary use case. It stops short of describing the exact response format, but the low complexity and clear parameter names make it adequately complete.

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 schema already provides full coverage: classUri is described as 'Class URI', limit as 'Max relations to return (default 50)', and offset as 'Pagination offset'. The description reinforces the context (relations between classes) but does not add deeper parameter semantics beyond the schema. This meets the baseline for 100% 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?

The description clearly states the tool's function: 'Get relationships between a class and other classes' and specifies the relationship types (parent, child, has-part, similar-to). This distinguishes it from sibling tools like bsdd_get_class (which returns class details) and bsdd_get_class_properties (which returns properties). The cross-referencing use case further clarifies intent.

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 practical context with 'Useful for cross-referencing between IFC, ETIM, UniClass, etc.', which indicates when to use this tool. It does not explicitly name alternatives or exclusions, but the sibling tools (e.g., bsdd_get_class, bsdd_get_class_properties) make the differentiation implicit.

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?

With no annotations provided, the description carries the full burden for transparency. It communicates that the tool returns a hierarchy, which is useful, but it does not mention pagination behavior, response structure, or any potential performance implications. The examples add context but not behavioral detail.

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 only two sentences, with the main action front-loaded. Every word adds value: it states the function, gives concrete use cases, and avoids unnecessary detail. This is an excellent model of conciseness.

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 covers the tool's purpose and typical use cases, which is sufficient for a simple read operation given the fully documented schema. However, since there is no output schema, it could have been slightly richer in explaining what the hierarchy looks like, but the term 'class hierarchy' gives adequate indication.

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 baseline is 3. The description itself adds no additional parameter semantics beyond what the schema already provides. It does not explain how parameters interact or provide usage syntax.

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 'Get the class hierarchy of a bSDD dictionary' with a specific verb and resource. It differentiates from sibling tools like bsdd_get_class (which retrieves a single class) by focusing on the hierarchy, and provides concrete examples (IFC classes, ETIM product groups) that clarify its scope.

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 provides explicit usage context ('Use to browse IFC classes, ETIM product groups, etc.'), making it clear when this tool is appropriate. However, it does not mention alternative tools or when NOT to use it, so it lacks full 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?

With no annotations provided, the description carries the full burden. It discloses the return contents (data type, unit, allowed values, connected property sets) and 'Get' implies a read-only operation, but it does not explicitly state no side effects, authorization needs, or behavior on invalid URIs. This is acceptable 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?

Two sentences, zero waste. The main purpose is front-loaded, followed by a clear usage directive. 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?

The description sufficiently conveys the tool's return value (property details) and use case, which is adequate given the simple schema and absence of an output schema. It could mention languageCode behavior, but the schema covers that parameter.

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%, and the parameters are straightforward (uri, languageCode). The description does not add parameter-specific semantics beyond what the schema already provides, so the baseline score of 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?

The description uses a specific verb ('Get') and resource ('bSDD property'), and clearly differentiates from siblings by enumerating the details returned (data type, unit, allowed values, connected property sets). This distinguishes it from related tools like bsdd_get_class_properties and bsdd_get_property_classes.

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 to understand what a BIM property means and what values it accepts' provides clear guidance on when to invoke the tool. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a full 5.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, nor does it describe the result shape (e.g., list of class URIs or full class objects). Although the verb 'find' suggests a query, the lack of any detail about pagination (despite limit/offset params) or output format leaves gaps.

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 long, front-loads the core action, and uses the second sentence to provide a practical use case. Every word earns its place; no fluff 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?

The tool is relatively simple, but without an output schema or annotations, the description should at least indicate what the response contains. It states it finds classes, implying a list of classes, but does not specify whether these are names, URIs, or full objects. The lack of this information makes it less complete than an ideal tool description.

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 'propertyUri' described as 'Property URI'. The description adds examples like 'FireRating' and 'AcousticRating', which suggest that short names may be acceptable, adding some semantic value. However, this could be ambiguous if a full URI is required, and the description does not elaborate on the format for limit/offset 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 tool's purpose: 'Find which bSDD classes use a given property.' This is a specific verb+resource combination and differentiates it from sibling tools like bsdd_get_class_properties by being the inverse lookup. The example properties ('FireRating', 'AcousticRating') further clarify intent.

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 clear context for when to use it: 'Useful to understand where a property... applies.' It implies a scenario where the user has a property and wants to find applicable classes. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to distinguish it from sibling tools.

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?

With no annotations provided, the description carries full burden for behavioral disclosure. It does explain that this is a discovery operation returning URIs, but it omits details like pagination behavior (though limit/offset are in schema) and response format. This is acceptable for a simple list endpoint 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 exceptionally concise: two sentences, no wasted words. It front-loads the action and resource, then adds a brief purpose. 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 two optional parameters and no output schema, the description covers the essential purpose and value. It doesn't explain the output structure, but that's likely straightforward given the listing nature. Given the low complexity, this is adequately complete.

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 both `limit` and `offset` are well-described in the schema itself. The description does not add any additional parameter context, which is fine since the schema already conveys meaning; thus the baseline score of 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?

The description clearly states the action ('List') and the resource ('available bSDD dictionaries'), with concrete examples (IFC, ETIM, UniClass) that make the scope obvious. It also distinguishes itself from sibling tools by focusing on dictionary discovery rather than class/property lookup.

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 phrase 'Use to discover classification systems and their URIs' provides a clear use case. While it doesn't explicitly exclude alternatives, the sibling tools are focused on searching/getting specific entities, so the intent is unambiguous and contextual.

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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the purpose without mentioning pagination, sorting, result structure, language handling, or any limitations. The schema parameters cover search options, but the tool's runtime behavior is opaque.

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 concise sentences, front-loaded with the main action and scope. Every word adds value, with no redundancy or 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 search tool with 6 parameters, no annotations, and no output schema, the description provides only the minimal purpose. It does not explain what the response looks like, how to refine the search effectively, or when to choose sibling tools like bsdd_text_search. This leaves the agent without enough context to fully understand the tool's behavior.

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 baseline is 3. The description adds marginal value by hinting at the types of content to search (IFC classes, ETIM groups), but the schema already documents searchText with examples. No additional semantic enrichment beyond that.

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 it searches for classes across bSDD dictionaries by keyword, which distinguishes it from sibling tools like bsdd_get_dictionary_classes or bsdd_get_class. It also provides concrete use cases (IFC classes, ETIM groups). However, it does not explicitly contrast with bsdd_text_search, which could be a close alternative.

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 gives a clear use case: 'Use to find IFC classes, ETIM groups, or any classification.' This provides context for when to use the tool. It does not mention exclusions or alternatives, so it stops short of a 5, but it is more than merely implied.

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?

No annotations are provided, so the description carries the full burden. It discloses the search scope and optional dictionary URI filtering, but does not explicitly state that the operation is read-only, nor does it mention pagination behavior or result format. For a search tool, this is minimally adequate but lacks richer behavioral 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 compact at two sentences, with the core action and scope in the first sentence and usage guidance in the second. No unnecessary words, and the examples are efficiently integrated.

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 5 parameters, no output schema, and no annotations, the description covers the essential aspects: what is searched, optional filtering, and example queries. It omits explicit mention of pagination (limit/offset) or result format, but these are partially addressed in the schema. Overall, it provides sufficient context for a search 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a couple of example search texts and reinforces the dictionary URI filter, but it does not provide any new semantics beyond what the schema already documents. The examples are helpful but not essential.

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 uses the specific verb 'search' with a clear resource scope: 'across all bSDD content (classes, properties, dictionaries)'. This differentiates it from sibling tools like bsdd_search_classes, which likely targets a more limited scope. The examples ('fire resistance', 'thermal conductivity') help clarify the intended query 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?

Explicitly states when to use: 'Use for broad discovery queries' and provides example search terms. It does not explicitly name alternative tools or when not to use, but the sibling list is present and the instruction makes the primary use case clear.

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