Skip to main content
Glama

Trustbase Lab · Trusted Data Infrastructure for the AI Era

Search Companies & Capacity Projects

query_companies
Read-onlyIdempotent

Purpose: query the global rCB company and project database (130 records: domestic / international / equipment vendors) by segment, region, status and keyword - the discovery tool for capacity projects and players in the chemical recycling industry. Guidelines: combine segment (rcb/virgin/conductive) + status ('在建','规划','under construction') + location; for capacity-project lists filter status, then pair with get_company for full entity detail. Limits: company-level records only - capacity is a record attribute, not a separate projects table; confidence varies A/B/C. Ex: 'rCB projects under construction in China', 'conductive carbon black producers worldwide'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNo数据分组:all=全部(默认), domestic=中国国内, international=国际, vendors=设备厂商
limitNo返回条数上限(默认 20,最大 100)
regionNo区域过滤(与 group 等价,兼容 AI Agent 习惯)
statusNo状态关键词,如 '在运'、'新建'、'在建'、'规划'
keywordNo企业名或产品线模糊匹配,如 '炭黑'、'pyrolysis'
segmentNo业务板块过滤(schema 1.6 基准层):rcb=再生炭黑业务, virgin=原生炭黑基准厂商, conductive=导电特种炭黑
languageNo输出语言:zh=中文(默认), en=英文zh
locationNo地点/国家关键词,如 '山东'、'德国'
verifiedNo是否 Verified Supplier:true=只看 A 级可信供应商(AI Agent 推荐用)
confidenceNo置信度:A=政府文件核实, B=企业自述/权威媒体, C=待核实
response_formatNo输出格式:markdown=人类阅读(默认), json=Agent 处理友好markdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesHuman-readable result (markdown, or a JSON string when response_format=json).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "text": {
      +      "description": "Human-readable result (markdown, or a JSON string when response_format=json).",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "text"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / segment
      Added value: +{
      +  "description": "业务板块过滤(schema 1.6 基准层):rcb=再生炭黑业务, virgin=原生炭黑基准厂商, conductive=导电特种炭黑",
      +  "enum": [
      +    "rcb",
      +    "virgin",
      +    "conductive"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: the 130-record scope, the A/B/C confidence caveat, and the important limitation that capacity is a record attribute rather than a separate projects table.

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

Conciseness4/5

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

Front-loaded with Purpose/Guidelines/Limits/Ex. labels and no filler, though it is dense enough to require careful reading. Each section contributes, but the examples and limit note add length beyond what a minimal call needs.

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?

An output schema exists, so return-value explanation is unnecessary. For an 11-param, zero-required discovery tool the description covers intent, filtering strategy, delegation target, and data caveats; only minor gaps (e.g. pagination/limit interaction) remain.

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 all 11 parameters with enum labels and defaults. The description reinforces segment/status/location filtering but adds little syntax or semantic detail the schema does not already contain, so baseline 3 applies.

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?

States a specific verb and resource ('query the global rCB company and project database'), gives scope (130 records, three segments) and filter dimensions, and positions itself as 'the discovery tool' versus get_company for entity detail. An agent can distinguish it from siblings like get_company or get_verified_suppliers without opening a schema.

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?

Gives explicit combination guidance ('combine segment + status + location'), a workflow for capacity-project lists, and names the follow-up tool (get_company). It also names a concrete alternative for full entity detail, so the when-to-use and when-to-delegate boundaries are clear.

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