FBA Forwarders: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not a...
The three compare_* tools are distinct views of the same comparison (criteria, option metadata, full table), and the three enquiry tools cleanly separate process explanation, schema, and submission. There is mild redundancy because compare_table could be seen as combining criteria and options, but the descriptions are explicit enough to prevent misselection.
compare_criteria, compare_options, compare_table and submit_enquiry follow a readable verb_noun style, but enquiry_describe and enquiry_fields use a noun-first pattern. This mixed convention is still readable and all names are snake_case, so it is a minor rather than severe inconsistency.
Six tools is well-scoped for the server's apparent purpose: three read-only comparison views and three enquiry-related tools (explain, schema, submit). Each tool has a clear role, and none feel like filler.
For the exposed domain, the server covers the comparison browsing path completely and supports the full two-step enquiry submission lifecycle with consent and confirmation. There are no obvious dead ends or missing operations within this scope.
The criteria and any filters of the Routes from a Chinese factory into Amazon US comparison.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It provides no operation, side effects, return values, or limitations; it is a noun phrase rather than a statement of behavior. An agent cannot infer whether this tool reads, computes, filters, or generates something.
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 the brevity is under-specification rather than efficient structure. It is an incomplete sentence fragment that does not convey an action, and there is no front-loaded usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a zero-parameter tool, the description must state what the tool does and what the agent can expect. With no annotations, no output schema, and no behavioral content, the definition is not complete enough for an agent to select or invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this, so there is no parameter meaning for the description to clarify. Baseline 4 is appropriate for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a subject—'criteria and any filters of the Routes from a Chinese factory into Amazon US comparison'—but it lacks a verb and does not state what the tool actually does. It is closer to a restatement of the title 'What is compared' than a functional definition, so it does not distinguish compare_criteria from siblings like compare_options or compare_table.
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 is given for when to use this tool versus alternatives such as compare_options, compare_table, or enquiry_describe. The domain is vaguely implied by the description, but there are no explicit conditions, exclusions, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The options in the Routes from a Chinese factory into Amazon US comparison (name, what it is best for, tags), optionally filtered by a tag value.
| Name | Required | Description | Default |
|---|---|---|---|
| filterKey | No | ||
| filterValue | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether this is a read-only operation, how the filter behaves when only one key is provided, what happens when no filter is provided, or what the response looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is structurally lean. However, it is under-specified rather than precisely concise, and the title 'The options' adds no information, making the overall packaging weaker.
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 there is no output schema, no annotations, and sibling tools that overlap in scope, the description is incomplete for a correct invocation. It does not explain the returned data shape, the filter contract, or how this tool fits among the comparison-related siblings.
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 0%, so the description must compensate. It mentions filtering 'by a tag value,' which loosely maps to filterKey and filterValue, but it never explains the meaning of filterKey, valid values, or how the two parameters interact. This leaves the only two parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('Routes from a Chinese factory into Amazon US comparison') and lists the fields returned (name, best for, tags), so it has more content than a tautology. However, the title 'The options' is generic and the phrasing 'The options in...' remains vague about what the tool actually returns, and it does not clearly distinguish compare_options from the sibling compare_table.
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 says results can be 'optionally filtered by a tag value,' which implies a basic use case, but it gives no guidance on when to use compare_options versus compare_criteria, compare_table, or the other siblings. There are no explicit exclusions or alternative-recommendation statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each option's value on every criterion of the Routes from a Chinese factory into Amazon US comparison — the full table.
| Name | Required | Description | Default |
|---|---|---|---|
| option | No | one option's name, else all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns 'the full table' but does not describe the output format, whether it includes all options or criteria by default, or any side effects. The behavior regarding the optional 'option' parameter is only implied in the schema, not in the description.
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, concise sentence that front-loads the core information (the full table of option values on criteria). It avoids unnecessary words, though it could be structured to include usage hints without much added length.
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 simplicity (one optional parameter, no output schema, no annotations), the description provides the essential purpose but lacks usage context and does not explain what the table structure looks like or how to interpret results. It is adequate for a basic call but leaves gaps for an agent trying to decide when to use it or what to expect.
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% (the single 'option' parameter has a description: 'one option's name, else all'). The tool description adds no extra meaning beyond the schema, so it does not compensate or enhance the parameter semantics. 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 identifies the tool as returning the full table of each option's value on every criterion for the specific Routes from a Chinese factory into Amazon US comparison. It distinguishes itself from siblings like compare_criteria and compare_options by indicating it provides the complete matrix, not just comparisons.
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 guidance on when to use this tool versus alternatives such as compare_criteria or compare_options. The description does not mention any conditions, filters, or exclusions that would help an agent decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read first. States plainly what submit_enquiry does on FBA Forwarders: it starts an enquiry with human providers who quote directly. Nothing is bought, ordered or paid; no quote is guaranteed; it is free. Also returns who receives the details, the consent wording, and how the person confirms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the burden of explaining behavior. It explicitly discloses that nothing is bought, ordered, or paid for, that no quote is guaranteed, and that the enquiry is free. It also describes what the tool returns: recipient details, consent wording, and how the person confirms.
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 brief and front-loaded with the most important usage signal, 'Read first.' Two sentences cover the tool's purpose, its relationship to submit_enquiry, key caveats, and the nature of its return content without any 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?
For a zero-parameter informational tool with no output schema, the description is complete: it explains what the tool does, what it returns, and what the key expectations are. An agent has enough information to decide whether to call this tool and what to do with the information it provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with an empty properties object. The baseline for zero-parameter tools is 4, and no parameter documentation is needed here because there are no inputs to document.
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 plainly that this tool explains what submit_enquiry does on FBA Forwarders, distinguishing it from actually submitting or purchasing. The title reinforces the key distinction: an enquiry with a human is not a purchase or guaranteed quote. This clearly identifies the tool's purpose and differentiates it from sibling submit_enquiry.
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 opening 'Read first' gives a clear contextual directive to consult this tool before proceeding with the enquiry flow. It does not enumerate alternatives or explicit when-not-to-use conditions, but for an informational prerequisite tool, this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field of the FBA Forwarders enquiry: key, label, type, whether required, help text and the allowed options where there are any. Pass answers to submit_enquiry keyed by field key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does disclose what the tool returns: all enquiry fields plus their metadata. It implies a read-only schema listing, though it does not explicitly state that there are no side effects or describe the exact response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, dense sentence front-loads the full content of the response and ends with an actionable cross-tool instruction. Every phrase earns its place and there is no repetition of the schema.
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 no-parameter, no-output-schema tool this is reasonably complete: it names the content, covers required/optional/options dimensions, and connects to its primary consuming sibling. A more explicit statement of the returned format would push it higher, but the core calling decision is fully supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so parameter semantics are trivially satisfied. The description adds useful context by telling the agent that the field keys produced here should be used as keys for submit_enquiry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (FBA Forwarders enquiry) and enumerates what is exposed: key, label, type, required, help text, and allowed options. It is clearly differentiated from submit_enquiry by the closing instruction, though it lacks an explicit retrieval verb like 'get' or 'list.'
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 clear usage context: consult this tool to learn field keys and then pass answers to submit_enquiry keyed by those keys. It does not explicitly contrast with enquiry_describe or the compare_* siblings, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits an enquiry to FBA Forwarders — NOT a purchase, NOT a guaranteed quote. Step 1: call with the answers (keyed by field key from enquiry_fields) and consent=true; it validates and returns a summary, the consent line and a confirmation token — show the person the summary and the consent line. Step 2: only if the person agrees, call again with the same answers, consent=true and the confirmation token; the enquiry is then submitted, and the person receives an email with a link they must click before any provider sees it. Consent means the person has read and agreed to: "Happy for my details to go to freight forwarders, who'll contact me directly."
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | the person's answers, keyed by field key | |
| consent | Yes | true only when the person has agreed to: Happy for my details to go to freight forwarders, who'll contact me directly. | |
| confirmation | No | the confirmation token from step 1, after the person has approved the summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses important behavioral traits: validation and token return in step 1, submission only after step 2, a consent message requirement, and the post-submission email link that must be clicked before providers see the enquiry. This goes well beyond a simple 'submits an enquiry' statement.
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 dense and front-loaded with the key caveat ('NOT a purchase, NOT a guaranteed quote'). It is longer than minimal because it must explain a two-step flow, but each sentence carries necessary procedural or consent information. Minor loss of conciseness from the detailed consent quote, which is nonetheless valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly explains what step 1 returns (summary, consent line, confirmation token) and what step 2 produces (submission plus email link). It also ties the optional confirmation parameter to the workflow, making the tool fully callable without additional documentation.
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%, providing a baseline of 3. The description adds meaningful semantics: answers are keyed by field key from enquiry_fields, consent has a specific required text, and confirmation is the token from step 1. This clarifies the relationship between parameters and the workflow, though the schema already documents the basic types and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Submits an enquiry to FBA Forwarders') and explicitly scopes what it is not ('NOT a purchase, NOT a guaranteed quote'). It also clearly distinguishes the two-step submit workflow from sibling tools like enquiry_fields and enquiry_describe by naming the field-key source and the confirmation step.
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?
Provides an explicit step-by-step usage protocol: Step 1 call with answers and consent=true, show the person the summary and consent line, then Step 2 call only after agreement with the same answers plus the confirmation token. This gives the agent unambiguous conditions for when to invoke the tool and how to sequence it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
compare_criteriacompare_optionscompare_tableenquiry_describeenquiry_fieldssubmit_enquiryClaiming 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 as io.github.acme/server also 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.json on 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.
No comments yet. Be the first to start the discussion!
Freight Forwarder Finder: the site's own MCP server — compare, enquiry (enquiry = a human...
Freight Insurance Cost: the site's own MCP server — enquiry (enquiry = a human handoff, not a...
Marine Insurance Cost: the site's own MCP server — enquiry (enquiry = a human handoff, not a...
Nearshore Finder: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not a...