SupplyGraph.AI
Server Details
Official MCP: continuous supply-chain risk monitoring and early warning, not a one-off report.
Register and create a key at https://supplygraph.ai/zk_chat_os/dashboard/dashboard.html — if you are not signed in you will be redirected to login; new users can register there. After login, open A2A / MCP and click Create Production Key or Create Sandbox Key. Send the header as Bearer (one Bearer prefix, then the raw key). Optional for initialize and tools/list; required for tools/call.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
Scored across 9 tools
Most tools address distinct functions, but corporate_exception_report and due_diligence_report both appear to be report generators with unclear boundaries, especially since corporate_exception_report's description is vague. The three supply-chain analysis tools (sg_chokepoint, sg_visualization, supply_chain_risk_prediction) also overlap conceptually, though their descriptions clarify their different outputs.
Naming conventions are mixed across the set: some use verb_noun (search_company_candidates, search_region_candidates), some use a prefix (sg_chokepoint, sg_visualization), and others use noun phrases (due_diligence_report, supply_chain_risk_prediction). There is no consistent pattern for an agent to reliably infer tool behavior from the name.
With nine tools, the server is well-scoped for a supply-chain intelligence platform covering company discovery, due diligence, supply-chain risk, visualization, and tariff analysis. Each tool has a reasonable place in the broader workflow, and the count is neither bloated nor thin.
The tool surface covers the main workflows: finding companies, resolving regions, generating due diligence reports, analyzing supply-chain concentration, visualizing dependencies, predicting risk, and handling tariff classification/calculation. Minor gaps exist around direct company-profile queries or more granular supply-chain graph traversal, but agents can generally complete core tasks without dead ends.
Available Tools
9 toolscorporate_exception_reportCorporate Exception ReportDInspect
Enterprise Change Report
Pricing: {"unit": "credits", "options": [{"chapter_name": "License", "per_run": 1518}, {"chapter_name": "GovRel", "per_run": 1419}, {"chapter_name": "R&D", "per_run": 1749}, {"chapter_name": "Reputation", "per_run": 8481}, {"chapter_name": "Ops", "per_run": 1749}, {"chapter_name": "GeneralRisks", "per_run": 1617}, {"chapter_name": "Profile", "per_run": 1749}, {"chapter_name": "Cost", "per_run": 1386}, {"chapter_name": "Compliance", "per_run": 1419}, {"chapter_name": "Competition", "per_run": 1452}, {"chapter_name": "Brand", "per_run": 3168}, {"chapter_name": "HR", "per_run": 1419}, {"chapter_name": "ALL", "per_run": 26400}]}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Internal company ID for the target enterprise, obtained from the search_company_candidates MCP tool (e.g. a77828f060c866441f2403384b271e63 for Tesla, Inc.). | |
| chapter_name | No | Exception domain chapter to generate. Omit or use ALL for the full corporate exception report. | ALL |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include 'openWorldHint: true', but the description adds no behavioral detail. It does not mention potential side effects, external actions, or data mutability. The description neither contradicts nor enriches the annotation; it simply ignores it. With no contribution, the description fails to carry its burden.
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?
The description is short, but it wastes the available space with a pricing JSON that is not relevant to tool usage. It lacks a clear, structured introduction. The 'Enterprise Change Report' phrase is vague and does not align with the tool's name. Conciseness is not beneficial when content is off-topic.
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?
Given the tool generates a corporate exception report with configurable chapters, the description should explain its purpose, output, and cost implications. The output schema exists but is not described. There is no discussion of the report's content, pagination, or limitations. The description is inadequate even for a simple tool.
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 includes descriptions for both 'pid' and 'chapter_name'. The description adds no extra parameter information, but per the rubric, a baseline of 3 is appropriate when schema covers parameters well. It does not harm, but it also does not enhance understanding.
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 merely says 'Enterprise Change Report' and provides pricing JSON. It does not state what the tool does, its scope, or how it differs from sibling tools. Even the title 'Corporate Exception Report' is inconsistent with the description text. No verb+resource is present.
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 gives no context on when to use this tool versus alternatives like 'due_diligence_report' or 'supply_chain_risk_prediction'. It does not mention prerequisites, such as obtaining a pid from 'search_company_candidates', even though that hint exists in the schema. No explicit or implicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
due_diligence_reportSupplier Due Diligence Report AgentAInspect
Generates comprehensive supplier due diligence reports using global enterprise data, benchmarking ownership, legal, and financial risk for compliance and procurement decisions.
Pricing: {"unit": "credits", "options": [{"chapter_name": "Company Registration Information", "per_run": 1518}, {"chapter_name": "Branch Offices", "per_run": 1650}, {"chapter_name": "Corporate Brand Initiatives", "per_run": 2079}, {"chapter_name": "Administrative Sanctions", "per_run": 1485}, {"chapter_name": "Software Copyright Details", "per_run": 1551}, {"chapter_name": "Outbound Investments", "per_run": 1650}, {"chapter_name": "Financing Activities", "per_run": 1452}, {"chapter_name": "Competitor Analysis", "per_run": 1485}, {"chapter_name": "Subsidiary Companies", "per_run": 1848}, {"chapter_name": "Trademark Portfolio", "per_run": 4059}, {"chapter_name": "Patent Holdings", "per_run": 12045}, {"chapter_name": "Website Registrations", "per_run": 1419}, {"chapter_name": "Court Judgments", "per_run": 1584}, {"chapter_name": "Shareholder Structure", "per_run": 1386}, {"chapter_name": "Senior Management Team", "per_run": 1452}, {"chapter_name": "Administrative Permits", "per_run": 1749}, {"chapter_name": "Court Hearing Notices", "per_run": 3696}, {"chapter_name": "Court Notices", "per_run": 3597}, {"chapter_name": "Equity Pledges", "per_run": 1419}, {"chapter_name": "Mobile Applications", "per_run": 1386}, {"chapter_name": "Copyrighted Works", "per_run": 1749}, {"chapter_name": "Equity Freezes", "per_run": 1419}, {"chapter_name": "Chattel Mortgages", "per_run": 1419}, {"chapter_name": "WeChat Official Accounts", "per_run": 1386}, {"chapter_name": "Tendering and Bidding Activities", "per_run": 2145}, {"chapter_name": "Qualification Certificates", "per_run": 2310}, {"chapter_name": "Engineering Irregularities", "per_run": 1419}, {"chapter_name": "Major Regulatory Violations", "per_run": 1452}, {"chapter_name": "Compensation and Benefits", "per_run": 1386}, {"chapter_name": "Enforcement Targets", "per_run": 1452}, {"chapter_name": "Supplier Network", "per_run": 1584}, {"chapter_name": "Credit Ratings", "per_run": 1419}, {"chapter_name": "Tax Offenses", "per_run": 1419}, {"chapter_name": "Regulatory Spot Checks", "per_run": 1485}, {"chapter_name": "Import-Export Credit Records", "per_run": 1386}, {"chapter_name": "Regulatory Actions", "per_run": 1617}, {"chapter_name": "Granted Government Subsidies", "per_run": 1551}, {"chapter_name": "Eligible Government Subsidies", "per_run": 1584}, {"chapter_name": "Consolidated Statements of Operations", "per_run": 1749}, {"chapter_name": "Income Statement", "per_run": 1947}, {"chapter_name": "Statement of Cash Flows", "per_run": 2442}, {"chapter_name": "Consolidated Balance Sheets", "per_run": 2145}, {"chapter_name": "ALL", "per_run": 26400}]}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Internal company ID for the target enterprise, obtained from the search_company_candidates MCP tool (e.g. a77828f060c866441f2403384b271e63 for Tesla, Inc.). | |
| chapter_name | No | Report chapter to generate. Omit or use ALL for the full due diligence report. | ALL |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations limited to openWorldHint: true, the description adds a detailed pricing block showing per-chapter credit costs, which is useful behavioral context. However, it does not explicitly describe side effects, report generation behavior, or any prerequisites beyond the schema.
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?
The first sentence is concise and front-loaded, but the rest is a massive pricing JSON blob that duplicates the chapter_name enum and adds significant bloat. The description is far larger than necessary for the operational information it conveys.
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 and full parameter descriptions, the definition is mostly complete for invocation. However, it lacks explicit usage guidance, doesn't clarify the openWorldHint annotation, and the pricing dump is noisy. Overall adequate but with clear gaps.
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% with clear descriptions for both pid and chapter_name. The description's pricing block adds cost-per-chapter information not in the schema, helping agents make cost-aware parameter choices, and the schema pid description already explains where to obtain the ID.
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 clearly states 'Generates comprehensive supplier due diligence reports' with a specific verb and resource, and details what it benchmarks (ownership, legal, financial risk). This distinguishes it from sibling tools like search_company_candidates (search) and corporate_exception_report.
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 provides context ('for compliance and procurement decisions') and the schema references search_company_candidates for pid, but there is no explicit 'use when' statement or comparison to alternative tools. The guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_company_candidatesSearch Company CandidatesAInspect
Search company candidates by company name, optionally filtered by country or region, and return possible matching records with mapped company IDs for caller-side selection.
Pricing: {"unit": "credits", "billing_model": "per_run", "per_run": 1}
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Company name with optional country or region. The input should contain a company name, and may optionally include its country or region (e.g. 'Tesla United States', 'Samsung South Korea', 'Huawei China'). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint as an annotation, the description discloses important behavior: results are 'possible matching records', they include 'mapped company IDs', and selection is deferred to the caller. It also includes pricing/cost context, which adds transparency beyond the structured fields.
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?
The description is two short sentences: the first states the core behavior and the second provides pricing. There is no filler, repetition, or unnecessary detail, and the most important information is front-loaded.
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 search tool with an output schema, the description covers the essential usage context: input, optional region scoping, return type, and caller-side selection. The presence of an output schema reduces the need to document return shape further.
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 schema already describes the text parameter, including the option to include country or region and relevant examples. The description repeats this information without adding further syntax or semantic detail, so it meets the baseline but does not exceed it.
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 uses a specific verb+resource: 'Search company candidates by company name', and adds scope with 'optionally filtered by country or region'. It also names the key output—'possible matching records with mapped company IDs'—which helps differentiate it from sibling tools like search_region_candidates.
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?
It clearly conveys when to use this tool: when looking up company candidates and letting the caller select from possible matches. It does not explicitly name alternatives like search_region_candidates or state when not to use it, but the context is clear enough for an informed agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_region_candidatesSearch Region CandidatesAInspect
Resolves natural-language country or region names (including aliases and abbreviations) against SupplyGraph’s internal geography registry and returns a list of standardized region names for downstream agent and MCP tool consumption.
Pricing: {"unit": "credits", "billing_model": "per_run", "per_run": 1}
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Country or region name in natural language, including aliases and abbreviations (e.g. 'China', 'USA', 'South Korea', 'Hong Kong', '中国', '美国'). The tool searches the internal geography registry and returns standardized matching region names for caller-side selection. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions handling aliases and abbreviations and returning a list, which adds some behavioral context. However, it does not disclose what happens on no match, whether multiple matches are returned, or any edge-case behaviors. The openWorldHint annotation is the only structured signal, and the description does not contradict it but also does not enrich it significantly.
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?
The description is a single front-loaded sentence that captures the essence, followed by a compact pricing metadata block. No wasted words; efficient and structured.
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 simple single-parameter search tool with high schema coverage and an output schema, the description provides sufficient context. It covers the tool's function, input scope, and intended consumption. It lacks explicit disambiguation from the sibling search_company_candidates, but the name and description make the purpose clear.
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 schema fully documents the 'text' parameter, including examples and purpose. The description adds no new parameter-level details beyond restating the function. Since schema coverage is 100%, the baseline of 3 applies; no compensation needed.
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 clearly states the tool's purpose: it 'resolves natural-language country or region names' against a 'geography registry' and returns 'standardized region names'. This is a specific verb-resource combination that distinguishes it from siblings like search_company_candidates and the report/visualization tools.
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 for resolving region names but does not explicitly mention when to use this tool over alternatives. It provides a usage context ('for downstream agent and MCP tool consumption') but lacks exclusions or direct comparisons to sibling tools. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sg_chokepointGeographic Concentration Analysis AgentAInspect
Analyzes multi-tier supply chains to detect single-country concentration and quantify geographic dependency across regions.
Pricing: {"unit": "credits", "per_run": 264590}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Internal company ID for the target enterprise, obtained from the search_company_candidates MCP tool (e.g. a77828f060c866441f2403384b271e63 for Tesla, Inc.). | |
| region_name | Yes | Standardized country or region name for geographic concentration analysis, obtained from the search_region_candidates MCP tool (e.g. China, United States, Hong Kong). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are limited to openWorldHint, so the description carries only a modest behavioral burden. It does not mention whether the tool is read-only, whether results are deterministic, or how the open-world nature should affect repeated runs. The pricing line adds operational context about credits, but not behavior like side effects or data destruction.
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?
The descriptive sentence is dense and specific, covering the scope and purpose in one well-structured sentence. The pricing line adds concise operational information without padding. There is no unnecessary repetition or generic filler.
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?
Given it has 2 clearly described, an output schema, and a global annotation, the description supplies sufficient context to recommend and invoke the tool for a geographic concentration check. It spends a sentence on the core capability requiring no additional caveat; the only missing element is permit selection context already covered in the usage_guidelines dimension.
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 input schema provides 100% coverage with rich descriptions for both pid and region_name, including examples and provenance mention of the related candidate search tools. The description itself contributes no additional parameter-level meaning, so basелинев 3 is appropriate.
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 clearly states the tool's function: 'Analyzes multi-tier supply chains to detect single-country concentration and quantify geographic dependency across regions.' A specific verb 'Analyzes' is paired with a specific resource ('multi-tier supply chains') and a more defined output ('detect single-country concentration, quantify ... dependency'), setting it apart from sibling tools such as supply_chain_risk_prediction and sg_visualization.
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 situational guidance such as when to use this tool instead of a sibling, when not to use it, or how it relates to the other supply-chain analysis tools. All descriptive content is focused on own action and inputs, leaving the agent to infer appropriate use from the tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sg_visualizationEnterprise Supply Graph Visualization AgentAInspect
Generates global multi-tier supply-chain graphs providing full visibility into enterprise and product dependencies.
Pricing: {"unit": "credits", "per_run": 264590}
| Name | Required | Description | Default |
|---|---|---|---|
| pid | Yes | Internal company ID for the target enterprise, obtained from the search_company_candidates MCP tool (e.g. a77828f060c866441f2403384b271e63 for Tesla, Inc.). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention side effects, required permissions, or whether the graph generation modifies any state. It is not contradictory, but without annotation support, it leaves uncertainty about the underlying behavior.
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?
The description is a single, focused sentence followed by pricing information. No unnecessary words or repetition, making it highly concise and well-structured.
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?
The description gives a good high-level understanding of what the tool does, and since an output schema exists (though not provided), it does not need to detail return values. It is sufficiently complete for an agent to decide when to use it.
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 only parameter (pid) is fully described in the schema, and the description does not add extra parameter context. With 100% schema coverage, the baseline of 3 is appropriate.
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 clearly defines the tool's function: generating global multi-tier supply-chain graphs for visibility into enterprise and product dependencies. This is specific and distinct from sibling tools like search_company_candidates or supply_chain_risk_prediction.
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 when visualization of supply-chain dependencies is needed, but it does not explicitly mention alternatives or provide strong when-to-use/not-use guidance. It is clear enough for most situations, given the tool's unique purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
supply_chain_risk_predictionSupply Chain Risk Prediction AgentAInspect
Continuously monitors global supply chain risk events and evaluates whether, how, and to what extent those events may affect a target company.
Pricing: {"unit": "credits", "per_run": 264590}
| Name | Required | Description | Default |
|---|---|---|---|
| event_info | Yes | Evaluates how a supply chain risk event may affect a target company through multi-tier supply chain propagation analysis. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks transparency about operational aspects such as side effects, return value, or whether 'continuously monitors' implies an ongoing process or a single analysis. The only annotation (openWorldHint) does not compensate for this lack of behavioral detail.
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?
The description is succinct and to the point, consisting of a single clear sentence. It avoids redundancy with the schema details and is well-structured.
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?
While the schema is detailed, the description lacks information about the expected output or how to interpret results. It also does not explain the practical context for the different event types or analysis modes, which are crucial for a complete understanding of the tool's usage.
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 schema itself provides comprehensive descriptions for all nested properties, and the description of the top-level 'event_info' adds meaningful context about multi-tier supply chain propagation analysis. This fully clarifies the purpose of each parameter.
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 clearly states the tool's function: continuously monitors global supply chain risk events and evaluates their impact on a target company. This is specific and distinct from sibling tools like due_diligence_report or tariff_calc.
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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'continuously monitors' but does not specify under what conditions this tool should be invoked or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tariff_calcU.S. Tariff Calculation AgentAInspect
Calculates U.S. customs duties by combining HTS base rates with applicable Chapter 99 measures, providing transparent, rule-based tariff outcomes.
Pricing: {"unit": "credits", "per_run": 10}
| Name | Required | Description | Default |
|---|---|---|---|
| country_or_region | Yes | Country or region of origin for the imported product, e.g. China, Mexico, European Union. | |
| product_description | Yes | Description of the product to import into the United States, e.g. HS code, product name, material, or specifications. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the core calculation logic (HTS base rate + Chapter 99) and per-run credit cost, which goes beyond the openWorldHint annotation. However, it omits limitations, assumptions, data freshness, or whether the result should be treated as authoritative vs. indicative.
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?
One compact sentence plus a pricing line; no filler, no restating the title, and key information is front-loaded with the verb 'Calculates'.
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 2-param tool with a full output schema, the description is appropriately complete: scope, method, and pricing are all included. It only lacks a brief statement about when tariff_classification would be a better alternative, which is a modest gap.
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 parameters are already well documented. The description implies that country_or_region matters for Chapter 99 applicability, but it does not add meaningful parameter-level guidance beyond what the schema already provides.
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?
Using 'Calculates U.S. customs duties' plus the explicit method ('combining HTS base rates with applicable Chapter 99 measures') gives a clear action and resource. It also distinguishes itself from tariff classification, although it does not explicitly name sibling alternatives.
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 context clearly implies the tool is for calculating U.S. duties on imported products, but it does not state when not to use it or point to a sibling tool like tariff_classification for classification-related needs. The usage guidance is present but largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tariff_classificationCustoms Classification AgentBInspect
Classifies products into correct HTS codes from text or documents, automating tariff lookup and ensuring customs compliance in real time.
Pricing: {"unit": "credits", "per_run": 2}
| Name | Required | Description | Default |
|---|---|---|---|
| product_description | Yes | Description of the product used to identify HS/HTS codes. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true, indicating flexible inputs. Description adds 'real time' and 'from text or documents' but doesn't disclose limitations, output format, or side effects. The bar is lower due to annotations, but the description still lacks depth on behavior.
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?
Description is short and front-loaded with the action. Includes pricing info which is extra but not harmful. One sentence, no fluff.
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 only one parameter and an output schema present, the description is fairly complete for a straightforward classification tool. However, it doesn't specify output format or edge cases, and the pricing info is extraneous. For a simple tool, it's adequate but could mention return format or use cases.
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 covers product_description fullycarsWalkthrough. Description adds minor context ('from text or documents') but doesn't elaborate on input formats or constraints beyond schema.
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 clearly states the tool classifies products into correct HTS codes from text or documents, which is a specific verb+resource. It does not explicitly differentiate from sibling tariff_calc, but the purpose is unambiguous.
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?
No guidance on when to use this tool versus alternatives like tariff_calc. It mentions 'automating tariff lookup' but doesn't specify use cases, exclusions, or situations where other tools are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
- Changed
corporate_exception_report2 fields changed- added
Output schema / definitionsAdded value: +{ + "sub_section": { + "properties": { + "section_texts": { + "description": "Array of sub-section text paragraphs, formatted in Markdown for detailed and structured content including headings, bullet points, tables, and hyperlinks to ensure professional and informative corporate exception subsections.", + "items": { + "type": "string" + }, + "type": "array" + }, + "section_title": { + "description": "Sub-section title.", + "type": "string" + }, + "sub_sections": { + "description": "Nested array of sub-sections.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "section_title", + "sub_sections", + "section_texts" + ], + "type": "object" + } +} - changed
Output schema / oneOfPrevious value: -[ - { - "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", - "properties": { - "text": { - "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", - "type": "string" - } - }, - "required": [ - "text" - ], - "type": "object" - }, - { - "definitions": { - "sub_section": { - "properties": { - "section_texts": { - "description": "Array of sub-section text paragraphs, formatted in Markdown for detailed and structured content including headings, bullet points, tables, and hyperlinks to ensure professional and informative corporate exception subsections.", - "items": { - "type": "string" - }, - "type": "array" - }, - "section_title": { - "description": "Sub-section title.", - "type": "string" - }, - "sub_sections": { - "description": "Nested array of sub-sections.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "section_title", - "sub_sections", - "section_texts" - ], - "type": "object" - } - }, - "description": "Structured corporate exception report output for enterprise analysis.", - "properties": { - "data": { - "properties": { - "chapter_infos": { - "description": "Array of chapter information in the corporate exception report.", - "items": { - "properties": { - "en": { - "properties": { - "chapter_name": { - "description": "Chapter name in English.", - "type": "string" - }, - "chapter_texts": { - "description": "Array of chapter text paragraphs in English, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional corporate exception content.", - "items": { - "type": "string" - }, - "type": "array" - }, - "sub_sections": { - "description": "Array of sub-sections in English.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "chapter_name", - "sub_sections", - "chapter_texts" - ], - "type": "object" - }, - "zh": { - "properties": { - "chapter_name": { - "description": "Chapter name in Chinese.", - "type": "string" - }, - "chapter_texts": { - "description": "Array of chapter text paragraphs in Chinese, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional corporate exception content.", - "items": { - "type": "string" - }, - "type": "array" - }, - "sub_sections": { - "description": "Array of sub-sections in Chinese.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "chapter_name", - "sub_sections", - "chapter_texts" - ], - "type": "object" - } - }, - "required": [ - "en" - ], - "type": "object" - }, - "type": "array" - }, - "languages": { - "description": "Array of language codes indicating the languages included in the response, where 'zk' represents Chinese and 'en' represents English.", - "items": { - "type": "string" - }, - "type": "array" - }, - "report_infos": { - "description": "Dictionary containing report metadata in English and Chinese.", - "properties": { - "en": { - "properties": { - "report_date": { - "description": "Report generation date in English.", - "type": "string" - }, - "report_name": { - "description": "Full report name in English.", - "type": "string" - }, - "report_type": { - "description": "Type of the report in English.", - "type": "string" - } - }, - "required": [ - "report_date", - "report_name", - "report_type" - ], - "type": "object" - }, - "zh": { - "properties": { - "report_date": { - "description": "Report generation date in Chinese.", - "type": "string" - }, - "report_name": { - "description": "Full report name in Chinese.", - "type": "string" - }, - "report_type": { - "description": "Type of the report in Chinese.", - "type": "string" - } - }, - "required": [ - "report_date", - "report_name", - "report_type" - ], - "type": "object" - } - }, - "required": [ - "en" - ], - "type": "object" - } - }, - "required": [ - "languages", - "report_infos", - "chapter_infos" - ], - "type": "object" - }, - "type": { - "description": "Indicates structured corporate exception report output.", - "enum": [ - "results" - ] - } - }, - "required": [ - "type", - "data" - ], - "type": "object" - } -]New value: +[ + { + "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", + "properties": { + "text": { + "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + { + "description": "Structured corporate exception report output for enterprise analysis.", + "properties": { + "data": { + "properties": { + "chapter_infos": { + "description": "Array of chapter information in the corporate exception report.", + "items": { + "properties": { + "en": { + "properties": { + "chapter_name": { + "description": "Chapter name in English.", + "type": "string" + }, + "chapter_texts": { + "description": "Array of chapter text paragraphs in English, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional corporate exception content.", + "items": { + "type": "string" + }, + "type": "array" + }, + "sub_sections": { + "description": "Array of sub-sections in English.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "chapter_name", + "sub_sections", + "chapter_texts" + ], + "type": "object" + }, + "zh": { + "properties": { + "chapter_name": { + "description": "Chapter name in Chinese.", + "type": "string" + }, + "chapter_texts": { + "description": "Array of chapter text paragraphs in Chinese, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional corporate exception content.", + "items": { + "type": "string" + }, + "type": "array" + }, + "sub_sections": { + "description": "Array of sub-sections in Chinese.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "chapter_name", + "sub_sections", + "chapter_texts" + ], + "type": "object" + } + }, + "required": [ + "en" + ], + "type": "object" + }, + "type": "array" + }, + "languages": { + "description": "Array of language codes indicating the languages included in the response, where 'zk' represents Chinese and 'en' represents English.", + "items": { + "type": "string" + }, + "type": "array" + }, + "report_infos": { + "description": "Dictionary containing report metadata in English and Chinese.", + "properties": { + "en": { + "properties": { + "report_date": { + "description": "Report generation date in English.", + "type": "string" + }, + "report_name": { + "description": "Full report name in English.", + "type": "string" + }, + "report_type": { + "description": "Type of the report in English.", + "type": "string" + } + }, + "required": [ + "report_date", + "report_name", + "report_type" + ], + "type": "object" + }, + "zh": { + "properties": { + "report_date": { + "description": "Report generation date in Chinese.", + "type": "string" + }, + "report_name": { + "description": "Full report name in Chinese.", + "type": "string" + }, + "report_type": { + "description": "Type of the report in Chinese.", + "type": "string" + } + }, + "required": [ + "report_date", + "report_name", + "report_type" + ], + "type": "object" + } + }, + "required": [ + "en" + ], + "type": "object" + } + }, + "required": [ + "languages", + "report_infos", + "chapter_infos" + ], + "type": "object" + }, + "type": { + "description": "Indicates structured corporate exception report output.", + "enum": [ + "results" + ] + } + }, + "required": [ + "type", + "data" + ], + "type": "object" + } +]
- Changed
due_diligence_report2 fields changed- added
Output schema / definitionsAdded value: +{ + "sub_section": { + "properties": { + "section_texts": { + "description": "Array of sub-section text paragraphs, formatted in Markdown for detailed and structured content including headings, bullet points, tables, and hyperlinks to ensure professional and informative due diligence subsections.", + "items": { + "type": "string" + }, + "type": "array" + }, + "section_title": { + "description": "Sub-section title.", + "type": "string" + }, + "sub_sections": { + "description": "Nested array of sub-sections.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "section_title", + "sub_sections", + "section_texts" + ], + "type": "object" + } +} - changed
Output schema / oneOfPrevious value: -[ - { - "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", - "properties": { - "text": { - "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", - "type": "string" - } - }, - "required": [ - "text" - ], - "type": "object" - }, - { - "definitions": { - "sub_section": { - "properties": { - "section_texts": { - "description": "Array of sub-section text paragraphs, formatted in Markdown for detailed and structured content including headings, bullet points, tables, and hyperlinks to ensure professional and informative due diligence subsections.", - "items": { - "type": "string" - }, - "type": "array" - }, - "section_title": { - "description": "Sub-section title.", - "type": "string" - }, - "sub_sections": { - "description": "Nested array of sub-sections.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "section_title", - "sub_sections", - "section_texts" - ], - "type": "object" - } - }, - "description": "Structured due diligence report output for enterprise analysis.", - "properties": { - "data": { - "properties": { - "chapter_infos": { - "description": "Array of chapter information in the due diligence report.", - "items": { - "properties": { - "en": { - "properties": { - "chapter_name": { - "description": "Chapter name in English.", - "type": "string" - }, - "chapter_texts": { - "description": "Array of chapter text paragraphs in English, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional due diligence content.", - "items": { - "type": "string" - }, - "type": "array" - }, - "sub_sections": { - "description": "Array of sub-sections in English.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "chapter_name", - "sub_sections", - "chapter_texts" - ], - "type": "object" - }, - "zh": { - "properties": { - "chapter_name": { - "description": "Chapter name in Chinese.", - "type": "string" - }, - "chapter_texts": { - "description": "Array of chapter text paragraphs in Chinese, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional due diligence content.", - "items": { - "type": "string" - }, - "type": "array" - }, - "sub_sections": { - "description": "Array of sub-sections in Chinese.", - "items": { - "$ref": "#/definitions/sub_section" - }, - "type": "array" - } - }, - "required": [ - "chapter_name", - "sub_sections", - "chapter_texts" - ], - "type": "object" - } - }, - "required": [ - "en" - ], - "type": "object" - }, - "type": "array" - }, - "languages": { - "description": "Array of language codes indicating the languages included in the response, where 'zk' represents Chinese and 'en' represents English.", - "items": { - "type": "string" - }, - "type": "array" - }, - "report_infos": { - "description": "Dictionary containing report metadata in English and Chinese.", - "properties": { - "en": { - "properties": { - "report_date": { - "description": "Report generation date in English.", - "type": "string" - }, - "report_name": { - "description": "Full report name in English.", - "type": "string" - }, - "report_type": { - "description": "Type of the report in English.", - "type": "string" - } - }, - "required": [ - "report_date", - "report_name", - "report_type" - ], - "type": "object" - }, - "zh": { - "properties": { - "report_date": { - "description": "Report generation date in Chinese.", - "type": "string" - }, - "report_name": { - "description": "Full report name in Chinese.", - "type": "string" - }, - "report_type": { - "description": "Type of the report in Chinese.", - "type": "string" - } - }, - "required": [ - "report_date", - "report_name", - "report_type" - ], - "type": "object" - } - }, - "required": [ - "en" - ], - "type": "object" - } - }, - "required": [ - "languages", - "report_infos", - "chapter_infos" - ], - "type": "object" - }, - "type": { - "description": "Indicates structured due diligence report output.", - "enum": [ - "results" - ] - } - }, - "required": [ - "type", - "data" - ], - "type": "object" - } -]New value: +[ + { + "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", + "properties": { + "text": { + "description": "Text or Markdown response generated by the agent. Returned when the task is not yet completed, failed, cancelled, or requires user input (e.g. validation prompts, error messages, or clarification requests).", + "type": "string" + } + }, + "required": [ + "text" + ], + "type": "object" + }, + { + "description": "Structured due diligence report output for enterprise analysis.", + "properties": { + "data": { + "properties": { + "chapter_infos": { + "description": "Array of chapter information in the due diligence report.", + "items": { + "properties": { + "en": { + "properties": { + "chapter_name": { + "description": "Chapter name in English.", + "type": "string" + }, + "chapter_texts": { + "description": "Array of chapter text paragraphs in English, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional due diligence content.", + "items": { + "type": "string" + }, + "type": "array" + }, + "sub_sections": { + "description": "Array of sub-sections in English.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "chapter_name", + "sub_sections", + "chapter_texts" + ], + "type": "object" + }, + "zh": { + "properties": { + "chapter_name": { + "description": "Chapter name in Chinese.", + "type": "string" + }, + "chapter_texts": { + "description": "Array of chapter text paragraphs in Chinese, formatted in Markdown for structured presentation including headings, lists, tables, and links to provide comprehensive and professional due diligence content.", + "items": { + "type": "string" + }, + "type": "array" + }, + "sub_sections": { + "description": "Array of sub-sections in Chinese.", + "items": { + "$ref": "#/definitions/sub_section" + }, + "type": "array" + } + }, + "required": [ + "chapter_name", + "sub_sections", + "chapter_texts" + ], + "type": "object" + } + }, + "required": [ + "en" + ], + "type": "object" + }, + "type": "array" + }, + "languages": { + "description": "Array of language codes indicating the languages included in the response, where 'zk' represents Chinese and 'en' represents English.", + "items": { + "type": "string" + }, + "type": "array" + }, + "report_infos": { + "description": "Dictionary containing report metadata in English and Chinese.", + "properties": { + "en": { + "properties": { + "report_date": { + "description": "Report generation date in English.", + "type": "string" + }, + "report_name": { + "description": "Full report name in English.", + "type": "string" + }, + "report_type": { + "description": "Type of the report in English.", + "type": "string" + } + }, + "required": [ + "report_date", + "report_name", + "report_type" + ], + "type": "object" + }, + "zh": { + "properties": { + "report_date": { + "description": "Report generation date in Chinese.", + "type": "string" + }, + "report_name": { + "description": "Full report name in Chinese.", + "type": "string" + }, + "report_type": { + "description": "Type of the report in Chinese.", + "type": "string" + } + }, + "required": [ + "report_date", + "report_name", + "report_type" + ], + "type": "object" + } + }, + "required": [ + "en" + ], + "type": "object" + } + }, + "required": [ + "languages", + "report_infos", + "chapter_infos" + ], + "type": "object" + }, + "type": { + "description": "Indicates structured due diligence report output.", + "enum": [ + "results" + ] + } + }, + "required": [ + "type", + "data" + ], + "type": "object" + } +]
47 tool updates
- Removed
enterprise_change_branch_setup - Removed
enterprise_change_business_strategy - Removed
enterprise_change_capital_brand_innovation - Removed
enterprise_change_capital_brand_recognition - Removed
enterprise_change_capital_brand_transparency - Removed
enterprise_change_certification - Removed
enterprise_change_charity_responsibility - Removed
enterprise_change_company_profile - Removed
enterprise_change_competitor_moves - Removed
enterprise_change_credit_debt_risk - Removed
enterprise_change_domestic_policy_compliance - Removed
enterprise_change_employee_benefits - Removed
enterprise_change_employee_development - Removed
enterprise_change_employee_evaluation - Removed
enterprise_change_employee_image - Removed
enterprise_change_employee_protection - Removed
enterprise_change_entrepreneur_image - Removed
enterprise_change_env_responsibility - Removed
enterprise_change_executive_change - Removed
enterprise_change_executive_sentiment - Removed
enterprise_change_external_policy - Removed
enterprise_change_financial_indicators - Removed
enterprise_change_gov_visit_exchange - Removed
enterprise_change_human_resources - Removed
enterprise_change_industry_academia - Removed
enterprise_change_innovation - Removed
enterprise_change_international_coop - Removed
enterprise_change_international_influence - Removed
enterprise_change_international_policy_compliance - Removed
enterprise_change_investment_financing - Removed
enterprise_change_key_roles - Removed
enterprise_change_legal_compliance_risk - Removed
enterprise_change_legal_responsibility - Removed
enterprise_change_license - Removed
enterprise_change_org_attributes - Removed
enterprise_change_policy_fiscal_support - Removed
enterprise_change_process_evaluation - Removed
enterprise_change_product - Removed
enterprise_change_project_coop - Removed
enterprise_change_public_responsibility - Removed
enterprise_change_reputation_awareness - Removed
enterprise_change_reputation_favorability - Removed
enterprise_change_result_evaluation - Removed
enterprise_change_strength_evaluation - Removed
enterprise_change_user_brand_awareness - Removed
enterprise_change_user_brand_satisfaction - Removed
enterprise_change_violation_illegal
56 tool updates
- First observed
corporate_exception_report - First observed
due_diligence_report - First observed
enterprise_change_branch_setup - First observed
enterprise_change_business_strategy - First observed
enterprise_change_capital_brand_innovation - First observed
enterprise_change_capital_brand_recognition - First observed
enterprise_change_capital_brand_transparency - First observed
enterprise_change_certification - First observed
enterprise_change_charity_responsibility - First observed
enterprise_change_company_profile - First observed
enterprise_change_competitor_moves - First observed
enterprise_change_credit_debt_risk - First observed
enterprise_change_domestic_policy_compliance - First observed
enterprise_change_employee_benefits - First observed
enterprise_change_employee_development - First observed
enterprise_change_employee_evaluation - First observed
enterprise_change_employee_image - First observed
enterprise_change_employee_protection - First observed
enterprise_change_entrepreneur_image - First observed
enterprise_change_env_responsibility - First observed
enterprise_change_executive_change - First observed
enterprise_change_executive_sentiment - First observed
enterprise_change_external_policy - First observed
enterprise_change_financial_indicators - First observed
enterprise_change_gov_visit_exchange - First observed
enterprise_change_human_resources - First observed
enterprise_change_industry_academia - First observed
enterprise_change_innovation - First observed
enterprise_change_international_coop - First observed
enterprise_change_international_influence - First observed
enterprise_change_international_policy_compliance - First observed
enterprise_change_investment_financing - First observed
enterprise_change_key_roles - First observed
enterprise_change_legal_compliance_risk - First observed
enterprise_change_legal_responsibility - First observed
enterprise_change_license - First observed
enterprise_change_org_attributes - First observed
enterprise_change_policy_fiscal_support - First observed
enterprise_change_process_evaluation - First observed
enterprise_change_product - First observed
enterprise_change_project_coop - First observed
enterprise_change_public_responsibility - First observed
enterprise_change_reputation_awareness - First observed
enterprise_change_reputation_favorability - First observed
enterprise_change_result_evaluation - First observed
enterprise_change_strength_evaluation - First observed
enterprise_change_user_brand_awareness - First observed
enterprise_change_user_brand_satisfaction - First observed
enterprise_change_violation_illegal - First observed
search_company_candidates - First observed
search_region_candidates - First observed
sg_chokepoint - First observed
sg_visualization - First observed
supply_chain_risk_prediction - First observed
tariff_calc - First observed
tariff_classification
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity – fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge – works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge – works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Related MCP Connectors
Official SupplyGraph.AI data MCP: POIs, parks, regions, industry chains, and companies.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Related MCP Servers
FlicenseNot gradedqualityDmaintenanceNooxus-MCP is the official Model Context Protocol (MCP) gateway connecting AI models to real-time, verified global supply chain data.-- FlicenseAqualityBmaintenanceMCP server that exposes tools for monitoring supply chain disruptions, including vessel positions, port weather, congestion, and news. Includes an AI agent that synthesizes these sources to assess route risks.5-
- AlicenseNot gradedqualityDmaintenanceAgent-native company intelligence. AI agents search and retrieve structured, verified company context (certifications, capabilities, capacity, lead times) for manufacturing & supply chain via 5 MCP tools.MIT
- AlicenseNot gradedqualityAmaintenance62 real-time data tools for AI agents via MCP. Finance, crypto, FMCSA, sanctions, courts, weather, vehicles, cybersecurity. One bearer token, one bill. Free tier available.MIT