bsdd-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource-action combination: list vs search vs get, and each resource (dictionaries, classes, properties, relations, reference data) has a single clear purpose. The search tools are differentiated by scope (classes-only vs classes+properties), and listing tools specify whether they are scoped to a dictionary.
Naming Consistency5/5
All tools follow the bsdd_<verb>_<noun> pattern, with verbs limited to list, search, and get. The noun phrases are consistently compound structures (e.g., dictionary_classes, class_properties, property_value), making the naming predictable and uniform.
Tool Count5/5
12 tools is well-scoped for a read-only dictionary API, covering the core entities (dictionaries, classes, properties, relations, reference data) without redundancy or fragmentation. Each tool earns its place.
Completeness5/5
The tool set provides comprehensive read access to bSDD: dictionary discovery, class/property browsing and search, detailed entity retrieval, relations, property values, and reference data. No significant gaps exist for the stated purpose of reading the dictionary.
Average 4.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context about the returned data fields, which is useful since there is no output schema. It does not discuss error behavior or language fallback beyond what the parameter description already states, but the annotation coverage lowers the burden.
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 a single concise sentence that front-loads the purpose and lists the key output details. Every word earns its place with no redundancy or unnecessary filler.
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 simple get tool with only two parameters and strong annotation coverage, the description is fairly complete. It enumerates return content, which compensates for the lack of an output schema. However, it lacks usage guidance relative to siblings and does not mention potential errors or edge cases, so it is not fully comprehensive.
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?
Schema description coverage is 100%, with both parameters (uri and languageCode) already described meaningfully in the schema. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
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 clearly states the tool gets details of one property and enumerates exactly what fields are returned (data type, units, allowed values, description, related properties). This is a specific verb+resource definition and distinguishes it from sibling tools like bsdd_get_property_classes or bsdd_get_property_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need details of a single property) but provides no explicit guidance on when not to use it or which sibling tool to choose instead. No alternatives are mentioned within the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond what annotations provide, such as pagination or fallback behavior, but it does not contradict annotations.
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 a single, clear sentence that immediately communicates the tool's purpose. Every word is meaningful, and the structure is front-loaded with the verb and resource.
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 list operation with a well-described schema and annotations covering safety, the description is sufficient. It lacks detail on return format or pagination behavior, but the schema's limit/offset parameters provide some of that context. A minor gap is not explaining what 'use' means semantically, but it is not necessary for an agent to invoke correctly.
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?
Schema description coverage is 100%, with all five parameters having descriptive text. The description itself adds no extra parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
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 uses a specific verb ('List') and resource ('classes') with a clear scope ('that use a given property'). It distinguishes itself from reverse sibling tools like bsdd_get_class_properties, which lists properties for a class.
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 clearly implies when to use this tool: when you have a property and need to find which classes reference it. It does not explicitly name alternatives or exclusions, but the context is clear from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and repeatability profile. The description adds no further behavioral details (e.g., pagination behavior or response structure), but for a simple list operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-crafted sentence that front-loads the main purpose and immediately provides the key usage context. No redundancy or filler.
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 simple list tool with optional filters and no output schema, the description adequately sets expectations about discovering dictionary URIs. It could mention what the response contains, but 'discover the dictionary URIs' implies the key output, making it sufficient.
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?
Schema description coverage is 100%, with each parameter clearly documented (e.g., uri format with example, numeric ranges for limit/offset, defaults). The description adds no additional parameter context, but the schema carries the full burden effectively.
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 clearly states the tool's function: 'List the dictionaries' with specific examples (IFC, ETIM, Uniclass). It distinguishes from sibling tools by targeting the top-level 'dictionaries' resource rather than classes or properties.
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?
Explicit guidance is given with 'Start here to discover the dictionary URIs the other tools need.' This clearly indicates when to use the tool, though it doesn't explicitly mention alternative tools or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the operation is scoped to a single dictionary and supports filtering, but does not elaborate on pagination behavior or return format, which are partially covered by the schema parameters.
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 a single, well-structured sentence that directly states the tool's purpose without redundant detail. It earns its place and is easy to parse.
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 simple list tool with comprehensive annotations and fully documented parameters, the description is sufficient. It clearly communicates the scope and optional filtering. It does not describe return values, but the tool name implies a list of properties, and the schema covers pagination parameters.
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?
The schema provides descriptions for all five parameters (dictionaryUri, limit, offset, searchText, languageCode), so the description does not need to explain each. The mention of 'filtered by text' aligns with the searchText parameter but adds no new semantic information beyond 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 clearly states the tool's function: listing properties defined by a single dictionary, with optional text filtering. This differentiates it from siblings like bsdd_list_dictionary_classes (which lists classes) and bsdd_get_class_properties (which retrieves properties for a class).
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 provides clear context for use: to list properties within a specific dictionary, optionally filtered by text. It does not explicitly mention when not to use it or name alternatives, but the intended use case is unambiguous given the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description doesn't need to repeat that. It adds the scope of searching all dictionaries including IFC, but does not disclose return format or pagination behavior, which is acceptable given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences long, front-loaded with the core purpose and an illustrative example, with no redundant words.
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?
The tool is read-only, has well-documented schema parameters, and has no output schema. The description adequately conveys scope and when to use it, though it could optionally mention what the response contains (class objects).
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?
The input schema has 100% description coverage for all five parameters, so the description adds no extra parameter semantics. The example usage is helpful but does not clarify parameter details beyond 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 specifies the verb 'search' with the resource 'classes across all bSDD dictionaries, including IFC' and gives a concrete example question, which clearly distinguishes it from sibling tools like bsdd_search_text.
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?
It states a clear usage context ('best starting point') but does not explicitly list when-not-to-use or mention alternative tools for property searches, so it earns 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context that it retrieves a single, enumeration item via URI, which goes beyond the annotations. No contradiction is present, and the added scope clarity justifies a score above baseline.
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 a single, tightly worded sentence that front-loads the verb and resource. Every word contributes to the meaning, with no redundancy or 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 simple read-only tool with two well-documented parameters and rich annotations, the description covers the essential purpose and identifier. No output schema exists, but the 'details' phrasing is sufficient given the straightforward nature of the operation.
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?
Schema description coverage is 100%, with clear descriptions for both 'uri' and 'languageCode'. The description only states 'by its URI', which mirrors the schema's property description and does not add new semantic meaning. Baseline 3 is appropriate.
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 uses a specific verb 'Get' and clearly identifies the resource: 'details of a single property value (an item of an enumeration)'. It also specifies the lookup method 'by its URI', which distinguishes it from sibling tools like bsdd_get_property or bsdd_get_class_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent has a URI for a property value, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The sibling list provides context, but the description itself does not leverage it to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so safety is covered. The description adds value by stating that properties are excluded and listing what is included (definition, class type, related IFC entities), giving behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the purpose and scope with a clear verb and resource; the second sentence provides a necessary separation from a sibling tool. No waste.
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?
Although there is no output schema, the description enumerates the returned contents (definition, class type, related IFC entities, optional child classes/relations) and notes the property separation. It is sufficiently complete for a get-details tool with good annotations, though it omits details about language fallback or error behavior.
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?
Schema description coverage is 100%, so every parameter is already described in the schema. The description does not add parameter-specific details; it focuses on the output scope. The baseline of 3 applies because the schema carries the parameter semantics.
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 clearly states the tool 'Get the details of one class' and enumerates the specific content (definition, class type, related IFC entities, optionally child classes and relations). It also distinguishes itself from the sibling tool bsdd_get_class_properties by explicitly noting they are fetched separately.
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 explicitly says 'Properties are fetched separately with bsdd_get_class_properties,' providing a clear alternative and exclusion. It implies this tool should be used when class details other than properties are needed, though it does not mention the closely related bsdd_get_class_relations tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds minimal behavioral context beyond this, such as the filtering options already present in the schema. No contradictions, but also no additional behavioral insights like pagination or tree structure behavior.
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-load the core purpose and usage boundary. No wasted words; the description is compact and efficiently structured.
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 list operation with a detailed schema and safety annotations, the description is complete enough. It covers the core function and usage, though it does not describe the return format or pagination behavior—but these are not essential given the schema's parameter descriptions and the tool's straightforward nature.
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?
Input schema has 100% description coverage, so parameters are already well-documented. The description only summarizes the filter types ('text, class type or related IFC entity') without adding new semantic meaning beyond what the schema provides.
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 clearly states the tool lists classes of a single dictionary with optional filters, using a specific verb ('List') and resource ('classes of one dictionary'). It distinguishes itself from siblings by explicitly naming bsdd_search_classes for cross-dictionary searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage context: 'Use this to browse a dictionary; use bsdd_search_classes to search across dictionaries.' This clearly delineates when to use this tool versus the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the detail that units include QUDT URIs and that these are allowed field values, offering contextual behavior beyond the annotations, but doesn't disclose response format or other behavioral traits.
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 concise sentences with no superfluous information. The first sentence front-loads the action and resource, the second adds important context about usage.
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?
With one simple parameter and no output schema, the description adequately conveys that the tool returns a reference list for a given kind. However, it doesn't specify the exact response format (e.g., array of code/name pairs), which could be helpful but isn't critical for this simple, read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the 'kind' parameter with a full enum and description, so the baseline is 3. The description enhances this by naming the specific lists and noting that units include QUDT URIs, and by explaining that these are allowed values for class and property fields, adding meaning beyond 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 uses a specific verb 'List' with a clear resource 'bSDD reference lists' and enumerates the exact lists (countries, languages, units, reference documents). This distinguishes it from sibling tools that list dictionaries or classes, as 'reference lists' is a distinct category.
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 explains that these lists are 'the allowed values for the corresponding fields on classes and properties,' providing clear context for when to use this tool. While it doesn't explicitly name alternatives or exclusions, the sibling tool names (e.g., list_dictionaries, list_dictionary_classes) and the reference to 'reference lists' imply this is for reference data rather than dictionary content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the response includes data type, units, allowed values, and property set, and clarifies the deprecation context. No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and a direct alternative reference. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explains what is returned (properties, data type, units, allowed values, property set). It also notes the deprecation of an alternative. For a list tool with a well-documented schema, this is sufficient context.
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?
The input schema has 100% coverage with detailed descriptions for all 7 parameters, so the schema carries the heavy lifting. The description mentions output content (data type, units, allowed values) but adds no specific input parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 uses a specific verb 'List' and clearly identifies the resource: 'the properties assigned to a class'. It enumerates the included details (data type, units, allowed values, property set), and differentiates itself from the deprecated IncludeClassProperties option of bsdd_get_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this instead of the deprecated IncludeClassProperties option of bsdd_get_class', providing a direct alternative and when-to-use guidance. This clearly tells the agent when to select this tool over a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the low bar is met. The description adds value by explaining the semantics of reverse=true ('the classes that point at it') and giving relation type examples, which goes beyond what annotations alone convey. No contradictions found.
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 two sentences long, front-loaded with the core action, includes examples, and a use case. Every word earns its place with no redundancy.
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?
The tool has 6 params and no output schema, but the schema documents each parameter thoroughly and annotations cover safety. The description covers purpose and use case, though it does not describe the return format or potential edge cases. For a read-only list operation, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds marginal value by clarifying the reverse parameter's effect and showing example relation names, which helps an agent understand the domain. This slightly elevates it above the baseline.
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 clearly states the tool's function with a specific verb ('List') and resource ('relations of a class'), provides concrete examples (IsEqualTo, HasMaterial, IsParentOf), and explains the reverse mode. This unambiguously distinguishes it from sibling tools like bsdd_get_class (single class) and bsdd_get_class_properties (properties).
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 gives a clear use case ('Useful for mapping between dictionaries') and implies when to use it by mentioning reverse mode. However, it does not explicitly state when NOT to use it or name alternative tools for direct comparison, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses shared pagination behavior ('classes are listed first, properties after them') and the IFC preview default, which are meaningful behavioral nuances. This adds substantial context that would not be obvious from the schema alone.
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 consists of three sentences, each delivering distinct information: purpose, pagination behavior, and an alternative tool with a default note. It is front-loaded and contains no redundant or filler content.
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?
With 10 parameters and no output schema, the description covers the most important behavioral aspects: the combined result type, pagination, and IFC preview condition. It does not detail the return structure, but for a search tool the description is sufficiently complete to guide correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining that includePreview defaults to true here and that this affects IFC dictionary inclusion, and by connecting the shared pagination to the semantics of limit/offset. This goes beyond merely restating parameter descriptions.
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 'Free-text search returning both classes and properties,' which clearly states the tool's purpose with a specific verb and resource. It also distinguishes itself from the sibling bsdd_search_classes by noting 'use bsdd_search_classes for class-only searches,' making the differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: it tells users to use bsdd_search_classes for class-only searches, and it clarifies the IFC dictionary inclusion condition with includePreview. This gives clear when-to-use and when-not-to-use instructions relative to the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bsdd-mcp MCP server](https://glama.ai/mcp/servers/nhantruong96/bsdd-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nhantruong96/bsdd-mcp)

Score Badge

Copy to your README.md:

[![bsdd-mcp MCP server](https://glama.ai/mcp/servers/nhantruong96/bsdd-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nhantruong96/bsdd-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nhantruong96/bsdd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server