Skip to main content
Glama

NCARB-certified architects from NCARB's official

b2b_ncarb_architects_directory
Read-only

NCARB-certified architects (US national certificate holders, all licensed in at least one US jurisdiction) from NCARB's official Certificate Lookup: name, city, state/province and country, filtered by last name, first name, city, US state/Canadian province or country, with the total match count. To confirm a specific license number use the state board roster. Related tools on this server, for a different need: b2b_apis_guru_openapi_directory when you need APIs.guru open directory of public API descriptions: finds; b2b_clio_app_directory when you need Clio App Directory, one page of 9: app slug, name, one-line. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "b2b_ncarb_architects_directory"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoCity of residence
limitNoResults, 1 to 100 (default 20)
stateNoUS state / territory or Canadian province code, e.g. TX, NY, ON
offsetNoSkip this many results (paging)
countryNoISO3 country code for non-US architects, e.g. GBR, CAN
lastNameNoLast name (or its start)
firstNameNoFirst name or its first letters

Output Schema

NameRequiredDescriptionDefault
totalNo
offsetNo
sourceNo
hasMoreNo
checkedAtNo
architectsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds genuinely new behavioral facts: the response includes a total match count, and the call is billed $0.002 USDC via x402 with failed calls not charged. That cost/charging disclosure is exactly the kind of context an agent needs before invoking a paid endpoint. It stops short of describing paging behavior beyond what the schema implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core sentence is front-loaded and dense with useful detail, and the pricing sentence earns its place. However, the two sentences describing b2b_apis_guru_openapi_directory and b2b_clio_app_directory spend substantial length on tools unrelated to architect lookup, diluting the definition.

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 an output schema present and full annotation coverage, the description needn't explain return values, and it nonetheless notes the total match count. Combined with the licensing-scope caveat and payment terms, an agent has enough to call this correctly; only paging/limit interaction is left implicit.

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 the schema already documents every filter (city, state, country, firstName, lastName, limit, offset). The description restates the filter set but adds no format hints such as prefix-matching nuances or the country/state interaction. Baseline 3 is appropriate when the schema carries the 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 names a specific resource (NCARB-certified architects from the official Certificate Lookup), defines its scope (US national certificate holders licensed in at least one jurisdiction), and enumerates the returned fields (name, city, state/province, country, total match count). An agent can distinguish this from the state-board-license siblings without opening the schema.

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 the supported filter axes and explicitly routes a different need elsewhere: 'To confirm a specific license number use the state board roster.' That is a real when-not/alternative rule. The two other sibling callouts (apis_guru, clio) reference unrelated directories rather than competing alternatives for the same task, so the guidance is clear but partly misdirected.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources