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
Available Tools
9 toolscorporate_exception_reportCorporate Exception ReportCInspect
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?
Beyond the openWorldHint annotation, the description adds only pricing/credit cost data, not behavioral context such as side effects, permissions, rate limits, or failure modes. The pricing information is useful operationally but does not disclose what the tool does during execution or what impact it may have.
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 poorly structured: a generic heading is followed by a large pricing JSON block that dominates the text. The pricing data is not organized or explained in a way that supports tool understanding, so the description is not an efficient, front-loaded explanation.
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 tool has an output schema and the input schema is well documented, but the description still fails to explain what a corporate exception report is, what it covers, or when it should be used. The pricing block hints at chapters but does not fill the gap left by the missing operational context.
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 description itself adds no parameter meaning, but the input schema fully documents both parameters: pid is described as an internal company ID with an example source, and chapter_name has an enum and explanation. Since schema coverage is 100%, 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 is essentially a synonym for the title: 'Enterprise Change Report' restates the idea of 'Corporate Exception Report' without adding a verb, scope, or actionable meaning. The large pricing block does not clarify what the tool does, and there is no differentiation from sibling tools like due_diligence_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 no guidance on when to use this tool versus alternatives. No exclusions or comparisons to sibling tools are given, and the only usage hint appears in the input schema, not in the description itself.
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 AgentBInspect
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?
The annotations provide only openWorldHint, so the description carries most of the burden. The description discloses that the tool generates reports and includes detailed pricing per chapter, which is useful operational context. It does not mention authentication, rate limits, run duration, or any side effects beyond report generation, but 'generates' suggests a read-only analytical operation.
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 opening sentence is concise and front-loaded, but the description is dominated by a massive 43-item pricing JSON that largely duplicates the chapter_name enum in the schema. The pricing detail adds some value, but the repetition and bloat make the description much larger than necessary for an agent to understand and invoke the tool.
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 two parameters and an output schema present, the description does not need to explain return values. It gives a clear overview and a complete list of chapters via pricing, but it lacks guidance on choosing chapters based on cost/relevance, and it does not explain the relationship to prerequisite tools beyond the schema's pid example. Overall, it is minimally viable but leaves operational 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%, so the baseline is 3. The description adds meaningful value by providing per-chapter credit costs in the pricing block, which helps an agent decide between 'ALL' and specific chapter_name values. It also indirectly reinforces that chapter_name corresponds to report sections; the schema already covers pid and the enum/default for chapter_name.
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 ('Generates comprehensive supplier due diligence reports') and clearly defines the resource and purpose: benchmarking ownership, legal, and financial risk for compliance and procurement. It does not explicitly differentiate from sibling tools like corporate_exception_report or supply_chain_risk_prediction, but the 'supplier due diligence' scope is reasonably distinct.
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 phrase 'for compliance and procurement decisions' gives some context for when the tool is useful, and the pricing options imply selecting specific report chapters. However, there is no explicit guidance about when to use this tool instead of the listed sibling tools, nor any exclusions or prerequisites beyond the schema's mention of pid.
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 openWorldHint annotation is present, indicating non-exhaustive results. The description adds that the tool returns a list and consumes natural language with aliases, but does not disclose additional behavioral aspects like pagination, error behavior, or rate limits. No contradiction with annotations.
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 sentences, with the purpose front-loaded and no redundant information. The pricing detail is concise and useful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, an output schema exists, and the openWorldHint annotation covers the open-world nature. The description sufficiently conveys the tool's function and output for downstream use. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a detailed description of the 'text' parameter including examples and behavior. The description repeats the core functionality but does not add any new semantic information beyond what the schema already provides. Baseline 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 verb 'resolves' against 'SupplyGraph's internal geography registry' and specifies the output as 'standardized region names'. It distinguishes from sibling search_company_candidates by focusing on regions rather than companies.
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 context is implied through the description (for resolving natural-language region names), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. It relies on the agent to infer the appropriate context.
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?
The annotation set only contains openWorldHint: true, so the description carries most of the behavioral disclosure burden. It clearly indicates an analytical, non-mutating operation, but it does not describe output behavior, data sources, limitations, or possible variability. Pricing is included, which adds practical context, but behavioral transparency remains shallow.
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 highly concise: one focused sentence communicates the tool's analytical scope, followed by a compact pricing object. No filler or redundant repetition of the title or schema fields appears.
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 that an output schema exists, return-value details are not necessarily the description's job. However, for a complex multi-tier supply chain analysis tool, the description is only minimally sufficient: it states the core analysis but does not connect it to sibling tools or add the context needed to avoid misuse. The schema compensates for many gaps, but the description itself could still do more.
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 already documents both parameters thoroughly: pid includes an example ID and source tool; region_name includes examples and source-tool reference. Since schema description coverage is 100%, the description does not need to repeat parameter details, and it is fair that it does not add extra semantics.
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-object pair: 'Analyzes multi-tier supply chains' and goes beyond the title by naming the exact analytical goals: 'detect single-country concentration and quantify geographic dependency across regions.' This differentiates the tool from sibling tools like sg_visualization and supply_chain_risk_prediction, whose scopes are clearly different.
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 offers no guidance on when to use this tool vs its siblings, nor does it state any prerequisites or exclusions. The only extra usage signal is pricing, but cost is not a usage guideline. The parameter descriptions say pid and region_name come from search_company_candidates and search_region_candidates, but the description itself does not provide this context.
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 AgentCInspect
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?
Only annotation is openWorldHint, which is not explained in the description. The description does not disclose whether the tool is read-only, whether it has side effects, rate limits, or any specific behavioral characteristics. The phrase 'Continuously monitors' suggests a passive analysis, but this is not made explicit. Since annotations are minimal, the description carries a heavy burden that it fails to meet.
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 extremely concise, with a single core sentence plus pricing information. It is front-loaded with the main purpose, and the pricing is secondary. There is no wasted verbiage, and it is appropriately sized for a brief overview. However, it might be too brief, but that is more of a completeness issue than a conciseness issue.
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 tool is complex, with nested objects, multiple event types, and required fields depending on the event type. The description does not cover these nuances, such as the distinction between news/policy events requiring title/content/date, and commodity_price events requiring target_date, target_price, commodity_name, etc. It also does not mention the analysis modes (normal, backtest) or the need for historical price series. Given the high complexity, the description is insufficient for an agent to fully understand the tool's usage scope.
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 baseline is 3. The description itself does not add any parameter-level information beyond what the schema already provides. The schema has detailed descriptions for each field (e.g., company_id, event_type, event_info). The description adds no extra value here, but it doesn't need to due to the high coverage.
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 ('monitors' and 'evaluates') and a resource ('global supply chain risk events' affecting a target company). It clearly conveys the core purpose and distinguishes itself from sibling tools like tariff_calc or due_diligence_report, which focus on other aspects. However, it lacks specificity about the event types (news, policy, commodity_price) and the analysis modes, making it less precise than it could be.
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 no guidance on when to use this tool versus alternative tools. It does not mention any prerequisites, exclusions, or typical use cases beyond the vague mention of monitoring and evaluation. No context is given for when an agent should select this tool over the sibling tools.
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.
Discussions
No comments yet. Be the first to start the discussion!
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.
471Pay-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
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Most tools are clearly distinct (e.g., tariff_calc vs. tariff_classification, search_* vs. sg_*). However, corporate_exception_report and due_diligence_report both produce company reports with overlapping chapter lists and vague descriptions, creating potential confusion for an agent selecting the appropriate report.
Naming conventions are mixed: search_company_candidates and search_region_candidates follow verb_noun, but others use noun phrases (tariff_calc, due_diligence_report) and some use an 'sg_' prefix (sg_chokepoint, sg_visualization). This lack of a consistent pattern reduces predictability.
With 9 tools, the count is well within the ideal 3-15 range and matches the platform's scope—company search, due diligence, supply chain analysis, and tariff handling. Each tool serves a clear purpose without unnecessary bloat.
The surface covers core workflows: company identification (search), deep reporting (due diligence, exception report), supply chain analysis (chokepoint, visualization, risk prediction), and tariff handling (classification, calculation). Minor gaps exist, such as a dedicated tool for fetching a specific company profile, but due_diligence_report largely fills that need.