Find liquid-cooling vendors for 30-150 kW AI data centers.
Scored across 6 tools
Each tool targets a distinct resource or operation: single vendor retrieval, text/place/category search, category listing, place listing, source listing, and aggregate statistics. There is little plausible confusion between search_listings and get_listing because one searches and the other retrieves by slug.
All names follow a consistent snake_case verb_noun pattern: get_listing, get_stats, list_categories, list_places, list_sources, search_listings. The convention is predictable throughout the set.
Six tools is well-scoped for a read-only vendor directory. Each tool serves a clear query or discovery need without obvious redundancy.
The surface covers vendor lookup, search, taxonomy browsing, source attribution, and stats, which is appropriate for a published-data directory. Minor gaps remain, such as no explicit list-all-vendors operation independent of search and no visible pagination controls.
Get one published vendor by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The word "published" adds genuine behavioral context — unpublished or draft vendors are not returned — but the description says nothing about not-found behavior or what a miss looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single eight-word sentence with no filler, and the distinguishing constraint ("published") plus the lookup key are front-loaded. Nothing could be removed without losing signal.
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 one-parameter read tool with full annotation coverage, the definition is nearly sufficient. The one real gap is that no output schema exists and the description gives no hint of what a returned vendor contains, though this is minor at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema description coverage, including pattern and length constraints, so the schema does the heavy lifting; baseline is 3. The description's "by its slug" only restates the schema's lookup key without adding format or resolution detail.
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), resource (one published vendor), and lookup key (slug), so an agent can tell it apart from search_listings and the list_* siblings. It stops short of explicitly naming those alternatives, which keeps it out of 5 territory.
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?
"By its slug" implies the precondition that the caller already has a known slug rather than search criteria, which is useful implied routing away from search_listings. However, no when-to-use or when-not-to-use guidance is stated explicitly, and no alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published vendors, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that the counts are limited to 'published' entities and that a freshness timestamp is returned, which is genuinely useful behavior beyond annotations, but nothing is said about scope (workspace-wide vs filtered) or recency semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the returned quantities and ends with the freshness signal, with no redundant restatement of the name or title. Nothing could be trimmed without losing 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 zero-parameter, non-destructive read tool with no output schema, the description carries the full burden of describing return values, and it does so by enumerating vendor/place/category counts plus a last-changed timestamp. An agent has everything needed to call it correctly and interpret the response.
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 tool takes zero parameters, so there is no parameter meaning to explain; the baseline of 4 applies. The description correctly introduces no phantom inputs, reinforcing that this is a parameterless aggregate call.
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 names a specific verb ('Get the number of') and enumerates the exact resources counted (published vendors, places, categories) plus a last-changed timestamp. This clearly distinguishes it from the sibling list_categories/list_places/search_listings tools, which return records rather than aggregate counts, though no sibling is named explicitly.
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: an agent can infer this is the summary/count tool to call instead of listing and counting records itself. There is no explicit statement of when to prefer it, and no exclusions or prerequisites are given, which matters little here since the tool takes no parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their vendor counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and determinism profile is fully covered. The description adds one useful behavioral fact beyond that: each category comes with a vendor count, i.e. an aggregation is performed. It says nothing about ordering, truncation, or whether empty categories appear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the resource and its payload front-loaded. There is no redundant restatement of the tool name or filler of any kind.
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 parameters, no output schema, and rich annotations, the definition needs only to say what is listed and what comes back, which it does. The remaining gap is minor: without an output schema, a hint about the shape of the 'vendor count' (or ordering) would make it fully self-contained.
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 tool takes zero parameters, so the baseline is 4. There is nothing the description could add about inputs, and it correctly spends its words on output content instead.
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 ('List categories') and adds what each entry carries ('their vendor counts'), which distinguishes it from the sibling list_places/list_sources and from get_stats. It stops short of explicitly naming which sibling to use for aggregate statistics, so it is clear but not fully differentiated.
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?
There is no explicit when-to-use or when-not-to-use statement and no mention of alternatives. For a zero-parameter enumeration tool the usage is strongly implied by the name and the mention of vendor counts, but the agent gets no routing help toward get_stats or search_listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have vendors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description's only added behavioral content is that results are limited to places with vendors, which is genuinely useful scoping information. It does not say whether results are hierarchical or flat, or whether they can change over time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler; the qualifier 'that have vendors' is placed where it matters and nothing is repeated from the name.
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 zero-parameter list tool with no output schema, the description should hint at the return structure (e.g., whether countries, regions and cities come back nested or as a flat list) and roughly how large the result is. It identifies what is listed but leaves the response shape entirely to inference.
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 tool takes zero parameters, so by baseline this dimension scores 4. The schema already excludes any input, and the description correctly doesn't invent any parameter discussion.
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 gives a specific verb ('List') and a specific resource (countries, regions and cities), plus a meaningful qualifier ('that have vendors') that scopes results to populated geographies. It's clear against siblings like list_categories and list_sources by resource, though it doesn't explicitly contrast with them.
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: an agent can infer this is the reference lookup for valid geography values (e.g., for filtering search_listings), but there is no explicit when-to-use, when-not-to-use, or named alternative. There are no prerequisites or call-ordering guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the vendor data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the description need not restate safety. It adds useful return-content context (license and refresh per source) but omits ordering, pagination, and the full response shape; with no output schema, that is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states what is listed and what metadata is included. There is no redundant wording or repetition of annotations.
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 zero-parameter list tool, the description supplies enough context to invoke it and says what the results contain (license and refresh). It could be richer about response ordering or fields, but annotations cover the safety profile and no parameters need explanation.
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?
There are no input parameters, so the baseline is 4. The description correctly adds no parameter details because none exist.
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: listing vendor data sources together with each source's license and refresh. The purpose is distinct from sibling listing tools, but the description does not explicitly name or contrast those siblings.
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?
Implies usage for inspecting data provenance, but gives no explicit when-to-use guidance or alternatives. An agent can infer the context from 'vendor data comes from,' yet no exclusions or routing to sibling list tools are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published vendors by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's one genuine addition is the word "published", which tells the agent that unpublished/draft vendors are excluded from results — useful scope context beyond the annotations. It says nothing about result ordering, pagination behavior, or empty-query behavior, all of which the agent must infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler — the core purpose arrives immediately. It is, however, so compressed that no structural scaffolding (usage, result shape) accompanies it, which is a terseness tradeoff rather than wasted wording.
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 8 optional parameters, rich schema descriptions and read-only annotations, the description is minimally adequate: an agent can call it correctly by leaning on the schema. What is missing is the payoff side — whether results are paginated, what a no-filter query returns, and how to resolve the place/category slugs the schema references.
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%, including enum semantics for sort, cursor usage, and the country 400 case, so the schema carries the parameter burden. The description only loosely maps its "text, place and category" phrasing onto q, city/region/country and category, adding little beyond the structured fields. 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 gives a specific verb and resource ("Search published vendors") plus the three searchable dimensions (text, place, category), which lets an agent distinguish it from get_listing (single fetch) and the list_* facet tools. It stops short of naming any sibling explicitly, so the differentiation is inferential rather than stated.
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?
There is no when-to-use guidance, no exclusion, and no mention of alternatives such as get_listing for a known vendor or list_places/list_categories for resolving slugs. The only routing hint lives in the schema ("from /places", "from /categories"), not in the description.
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.
get_listingget_statslist_categorieslist_placeslist_sourcessearch_listingsSearch 400G/800G DCI, DWDM and optical switching gear for AI data centers and request quotes.
AI infrastructure tracker: data center campuses, power projects, MW and the companies behind them
AI data-center design engine: size, validate & lay out Rubin-era data centers. Korea live.
Cloud GPU prices with live stock from 22 providers. Find where to rent an H100 or B300 now.
Add one secure layer between your agents and this server.
