Search building products & manufacturers for AI agents: CAD, BIM, specs by CSI from arcat.com
Scored across 4 tools
The four tools have largely distinct roles: browse_csi_sections handles taxonomy navigation, search_manufacturers and search_products handle keyword discovery, and get_manufacturer fetches by ID. The only mild overlap is that search_manufacturers and get_manufacturer both return company info, but the ID-vs-query distinction is clear from the descriptions.
All tools follow a clean verb_noun pattern (browse_csi_sections, get_manufacturer, search_manufacturers, search_products) using snake_case throughout. The convention is predictable and instantly readable.
Four tools is slightly lean for a database spanning CSI sections, manufacturers, and products, but each tool earns its place and the scope is coherent. It is on the low end rather than excessive.
Manufacturers get a full search+get-by-ID pair, but products only get search_products with no get_product equivalent, and there is no way to list products for a given manufacturer or section. This asymmetry creates dead ends for deep product lookup.
Browse CSI MasterFormat building product categories.
No parameters: list all divisions (e.g., "07 - Thermal and Moisture Protection"). Division only: list all entries under that division. Division + level: filter by hierarchy depth: Level 1 = Groups (e.g., 07 10 00 Dampproofing and Waterproofing) Level 2 = Sections (e.g., 07 21 00 Thermal Insulation) Level 3 = Narrowscope (e.g., 07 21 13 Board Insulation) Add section to drill into a specific parent (e.g., division "07", level 2, section "072000").
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Hierarchy depth within division: 1=group, 2=section, 3=narrowscope | |
| section | No | Parent section code to filter within (e.g., "072000" to see sections under Thermal Protection) | |
| division | No | CSI division code (e.g., "07"). Omit to list all divisions. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| sections | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses the filtering semantics (that output changes shape depending on which parameters are supplied) and the meaning of each hierarchy level, which is real behavioral context. It omits any note on result size or pagination, though an output schema exists.
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?
Front-loaded one-line purpose followed by a compact, scannable enumeration of parameter combinations. Every line adds distinct information; the inline examples clarify without 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?
A read-only hierarchical browse tool with full schema coverage and an output schema needs only the parameter-combination model, which the description fully supplies. Nothing an agent requires to call it correctly is missing.
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 baseline is 3, but the description adds cross-parameter semantics the schema cannot express: how division, level, and section compose to change the result set, plus a worked example ('07', level 2, '072000'). This goes beyond the per-field descriptions.
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?
States a specific verb and resource ('Browse CSI MasterFormat building product categories') and immediately explains the hierarchical model that defines the tool. The sibling tools (search_manufacturers, get_manufacturer, search_products) are in unrelated domains, so no sibling differentiation is required here.
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 enumerates the four calling modes — no parameters (list divisions), division only, division + level, and section added to drill into a parent — which tells the agent exactly what each combination produces. It does not name alternatives or exclusions, but none of the siblings compete for this task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed profile for a specific building product manufacturer by their ARCAT ID. Returns company info, CSI sections, available content types, and product count.
| Name | Required | Description | Default |
|---|---|---|---|
| manufacturer_id | Yes | ARCAT manufacturer ID (seq/coid) |
| Name | Required | Description |
|---|---|---|
| name | No | |
| error | No | |
| website | No | |
| location | No | |
| arcat_url | No | |
| csi_sections | No | |
| product_count | No | |
| manufacturer_id | No | |
| available_content | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds the shape of the payload (company info, CSI sections, content types, product count), but since an output schema exists this is largely redundant rather than new 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?
Two tight sentences with zero filler; the purpose and lookup mechanism are front-loaded before the payload summary. Every clause 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?
With an output schema present, the return values need not be explained, and the one required parameter is fully described. Rich annotations cover safety and idempotency, so an agent has nearly everything needed; only explicit sibling routing is absent.
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 the single parameter's description ('ARCAT manufacturer ID (seq/coid)') is fully documented in the schema. The description's 'by their ARCAT ID' restates rather than extends the schema, so the baseline 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?
States a specific verb (Get) and resource (detailed profile for a building product manufacturer), with the lookup key (ARCAT ID). Clear enough to distinguish from search_manufacturers, but it doesn't explicitly name that sibling as the alternative path.
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?
Usage is only implied: 'a specific... manufacturer by their ARCAT ID' suggests this is the retrieval-by-known-ID tool, contrasted with the search_* siblings. There is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for building product manufacturers by name, keyword, or CSI MasterFormat section. Returns company details with links to their ARCAT profile.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 20) | |
| query | No | Text search (e.g., "terra cotta", "Owens Corning") | |
| offset | No | Pagination offset | |
| csi_section | No | CSI MasterFormat 04 section code (e.g., "074600") | |
| csi_division | No | CSI MasterFormat 04 division (e.g., "07") |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered externally. The description adds that results include "company details with links to their ARCAT profile," which is useful return context, but with an output schema present this is only marginal added value.
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 with zero filler: the search capability is front-loaded and the return note follows immediately. Every clause 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?
With full schema coverage, rich annotations, and an output schema handling return values, the description carries only light burden. It adequately covers what the tool does and roughly what it returns; the missing piece is routing guidance relative to the sibling search/lookup tools.
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 limit, offset, query, csi_section, and csi_division with examples. The description loosely maps its "name, keyword, or CSI MasterFormat section" phrasing onto the query and CSI parameters but adds no syntax or format detail beyond the schema; baseline 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 states a specific verb and resource ("Search for building product manufacturers") and enumerates the searchable dimensions: name, keyword, and CSI MasterFormat section. It does not differentiate itself from the sibling get_manufacturer (single lookup) or search_products, so it falls short of a 5.
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?
Search context is implied by the verb and the listed search modes, which tells an agent this is the broad discovery tool. However, there is no explicit when-to-use guidance, no mention of when to prefer get_manufacturer for a targeted lookup, and no alternatives or exclusions named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for building products by keyword, CSI MasterFormat section, or content format. Returns product details with links to specifications, CAD, BIM, and catalog downloads on arcat.com.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 20) | |
| query | No | Text search (e.g., "fiber cement rainscreen") | |
| offset | No | Pagination offset | |
| csi_section | No | CSI MasterFormat 04 section code (e.g., "074600") | |
| made_in_usa | No | Filter for Made in USA products only | |
| csi_division | No | CSI MasterFormat 04 division (e.g., "07") | |
| format_filter | No | Filter by available content format |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds that results include links to specifications, CAD, BIM, and catalog downloads, which is useful context, but says nothing about pagination limits, result ordering, or empty-result behavior beyond what the schema states.
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 filler, with the core capability front-loaded before the return-value note. Every clause carries information an agent can use.
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?
An output schema exists, so the description need not explain return payloads, and annotations cover the safety profile. With all seven parameters documented in the schema, the definition is nearly complete; only the absence of sibling routing guidance keeps it from a 5.
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 every parameter is already documented in the schema. The description reinforces three of the seven parameters (query, csi_section, format_filter) but adds no syntax or format detail beyond the schema, so the baseline 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?
States a specific verb (Search) and resource (building products), then enumerates the three search modes (keyword, CSI MasterFormat section, content format) and the catalog domain (arcat.com). The resource is distinct from siblings like search_manufacturers and browse_csi_sections, so an agent can route without opening schemas.
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 implies usage by naming the supported query modes, which hints at how to call it, but it gives no explicit when-to-use guidance, no exclusions, and never mentions the alternatives (browse_csi_sections, get_manufacturer). An agent must infer the boundary from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
browse_csi_sections1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "sections": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "arcat_url": {
+ "type": "string"
+ },
+ "code": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "division": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "number"
+ }
+ ]
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "arcat_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "sections"
+ ],
+ "type": "object"
+}get_manufacturer1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "arcat_url": {
+ "type": "string"
+ },
+ "available_content": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "csi_sections": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "manufacturer_id": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "product_count": {
+ "type": "number"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}search_manufacturers1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "arcat_url": {
+ "type": "string"
+ },
+ "available_content": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "csi_sections": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "location": {
+ "additionalProperties": false,
+ "properties": {
+ "city": {
+ "type": "string"
+ },
+ "state": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "manufacturer_id": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "website": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "location",
+ "csi_sections",
+ "available_content",
+ "arcat_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "results"
+ ],
+ "type": "object"
+}search_products1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "arcat_url": {
+ "type": "string"
+ },
+ "available_formats": {
+ "additionalProperties": false,
+ "properties": {
+ "bim": {
+ "type": "boolean"
+ },
+ "cad": {
+ "type": "boolean"
+ },
+ "catalog": {
+ "type": "boolean"
+ },
+ "spec": {
+ "type": "boolean"
+ },
+ "video": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "bim",
+ "cad",
+ "spec",
+ "catalog",
+ "video"
+ ],
+ "type": "object"
+ },
+ "csi_sections": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "description": {
+ "type": "string"
+ },
+ "is_featured": {
+ "type": "boolean"
+ },
+ "made_in_usa": {
+ "type": "boolean"
+ },
+ "manufacturer": {
+ "type": "string"
+ },
+ "manufacturer_id": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "string"
+ }
+ ]
+ },
+ "name": {
+ "type": "string"
+ },
+ "tradename": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "manufacturer",
+ "description",
+ "csi_sections",
+ "available_formats",
+ "made_in_usa",
+ "is_featured",
+ "arcat_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "results"
+ ],
+ "type": "object"
+}browse_csi_sectionsget_manufacturersearch_manufacturerssearch_productsAI-agent product catalog: search, lookup & purchase routing over verified merchant data.
Commercial glass & glazing reference for AI agents: code limits, glass data, product equivalents.
Cross-vendor B2B catalog for AI agents: search, compare, find equivalents, request a quote.
The E-commerce Marketplace For Every AI Agent. A Governed Catalog Of 600M+ US Products, Plus Four Agent Ready Capabilities Search, Price Comparison, Product-Vs-Product, And Detailed Q&A.
Add one secure layer between your agents and this server.
