Freight Forwarder Finder: the site's own MCP server — compare, enquiry (enquiry = a human...
Each tool has a clearly distinct purpose: comparison tools focus on criteria, options, and full table views, while enquiry tools cover description, fields, and submission. No overlap or ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (compare_*, enquiry_*, submit_enquiry). No deviations or mixed conventions.
6 tools is well-scoped for a site that compares freight intermediary types and allows enquiries. Each tool serves a distinct function without redundancy.
The surface covers comparison (criteria, options, table) and enquiry (description, fields, submission). No obvious dead ends, though there might be minor gaps like no ability to retrieve previous enquiries.
The criteria and any filters of the Types of freight intermediary, and what each does comparison.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 mention what the tool returns, side effects, limitations, or any other behavioral traits. The vague statement offers no insight into how the tool behaves.
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 but is poorly structured and confusing. It is not concise in the sense of being clear and efficient; rather, it is underspecified and awkward, failing to convey its message effectively.
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 tool with no parameters and no output schema, the description should at least clearly state its purpose. It fails to do so, leaving the tool's functionality ambiguous. The description is inadequate even for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description does not add or contradict any parameter information, which is acceptable since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'comparison' and 'criteria and filters of the Types of freight intermediary,' but the phrasing is grammatically broken and unclear. It lacks a clear verb and resource, making it hard for an agent to discern the exact action and object. It is not a tautology but is too vague to differentiate from sibling comparison tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like compare_options or compare_table. The description does not provide any context, exclusions, or alternative routing, leaving the agent without direction.
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 Types of freight intermediary, and what each does 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?
With no annotations, the description must carry the burden of behavioral disclosure. It only mentions optional filtering by tag value but does not state whether the operation is read-only, describe the output format, or disclose any other behavioral traits such as default behavior or side effects.
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, somewhat convoluted sentence. It is short and not overly verbose, but the structure is run-on and could be clearer. The information is packed awkwardly, reducing readability.
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 no output schema and no annotations, so the description must provide complete context. It lists some return fields (name, best for, tags) but fails to explain the output format, pagination, or the exact behavior of the filter. An agent would not know what to expect from a call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description coverage for filterKey or filterValue. The description mentions filtering by a tag value but does not explain what filterKey should be (e.g., 'tag'), the expected format of filterValue, or any constraints. This is insufficient for an agent to correctly populate the parameters.
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 identifies the resource ('Types of freight intermediary') and the fields returned (name, what it is best for, tags), but it lacks a clear action verb and is awkwardly phrased ('what each does comparison'). It doesn't clearly state that the tool lists or compares options, making the purpose somewhat vague.
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 provided on when to use this tool versus sibling tools such as compare_criteria or compare_table. The description does not mention any context, exclusions, or alternative selection criteria.
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 Types of freight intermediary, and what each does 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, the description carries full responsibility for behavioral disclosure. It only describes table content, not behavior: no read-only guarantee, output shape, or filtering behavior beyond the vague notion of a 'full table.'
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 run-on, awkward sentence that is hard to parse, and the title 'The comparison table' already repeats the obvious noun. A clearer front-loaded rewrite such as 'Returns a comparison table showing every option on every criterion' would serve an agent much better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool this is minimally viable, but it is incomplete: it does not state what the rows and columns are, what values the option parameter should take, or how this relates to the sibling comparison tools. No output schema exists to fill those 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?
The single optional parameter is already fully documented in the schema with 'one option's name, else all.' The description's 'full table' loosely supports the else-all default, but it adds no additional syntax, format, or semantic detail, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gestures at a full comparison table of options against criteria, which is a recognizable purpose, but it lacks an explicit verb and the phrase 'what each does comparison' is ungrammatical. It does not clearly differentiate the tool from sibling tools like compare_criteria or compare_options.
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 about when to use this tool versus alternatives such as compare_criteria or compare_options. An agent cannot tell whether this is the general table and the siblings are filtered views, or some other relationship.
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 Freight Forwarder Finder: 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, the description must carry the behavioral burden. It clearly discloses that 'Nothing is bought, ordered or paid; no quote is guaranteed; it is free,' which reassures about the underlying submit_enquiry behavior. It also specifies what the tool returns (who receives details, consent wording, confirmation process), giving the agent a clear picture of the output. It does not mention side effects, but for a read-only descriptor, this is sufficient.
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 concise, with two sentences that front-load the key point ('Read first') and then state the tool's function and return content. It avoids fluff, though the phrasing 'States plainly what submit_enquiry does' could be tightened. Overall, every sentence 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?
For a no-parameter, no-output-schema descriptive tool, the description fully covers what an agent needs: it explains the purpose, the scope, and the specific information returned. There are no missing elements that would prevent correct invocation or interpretation.
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 is empty (0 parameters), so the baseline is 4. The description adds no parameter-specific information because there are none. No compensation needed, and the description does not introduce confusion about parameters.
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 that the tool explains what submit_enquiry does on Freight Forwarder Finder, and that it returns who receives details, consent wording, and confirmation method. This is a clear purpose, though the tool's own role as a pre-submission informational tool could be more explicit. It distinguishes itself from siblings like submit_enquiry by being descriptive rather than action-oriented.
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 'Read first' implies the tool should be used before submitting an enquiry, but it does not explicitly state when not to use it or mention alternatives. It provides contextual guidance (it describes the submission process) but lacks clear exclusions or comparison with sibling tools like compare_options or enquiry_fields.
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 Freight Forwarder Finder 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, the description carries the full burden. It discloses the output contents thoroughly (six field properties and conditional allowed options) and implicitly signals a read-only operation by describing a listing rather than a mutation. It could explicitly say 'this does not submit the enquiry', but the submit_enquiry reference makes that clear enough.
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?
Two sentences with no filler. The first sentence front-loads the scope and returns the content list; the second gives the practical usage. It avoids repeating the title or restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter retrieval tool with no output schema, the description covers what is returned and how to use the result. It could specify the exact return shape (e.g., array of objects), but the property list and submit pointer are sufficient for an agent to call and use it 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, so the schema provides no parameter documentation; the baseline of 4 applies. The description adds semantic value by explaining what the returned data represents and how to map it to submit_enquiry parameters, going beyond the empty 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 states a clear scope: 'Every field of the Freight Forwarder Finder enquiry' followed by the exact properties returned (key, label, type, required, help text, allowed options). It distinguishes itself from the compare_* siblings and from submit_enquiry by clarifying it only exposes the field structure and that answers should go to 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?
It gives a concrete usage pointer: 'Pass answers to submit_enquiry keyed by field key', telling the agent when to use this tool (before submitting). It does not explicitly contrast with enquiry_describe or the compare_* tools, so choosing among those siblings is left to inference rather than stated.
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 Freight Forwarder Finder — 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?
With no annotations provided, the description carries the full behavioral burden. It discloses that step 1 only validates, that step 2 submits the enquiry, that an email with a clickable link is sent, and that providers only see the enquiry after the person clicks. It also clarifies the exact meaning of consent, so there is no ambiguity about side effects.
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 long enough to cover a genuinely two-step flow, but every sentence is functional. It front-loads the core purpose and the critical 'not a purchase' caveat, then structures step 1 and step 2 clearly. The consent line is repeated because the agent needs it verbatim to show the person.
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 tool with no output schema and no annotations, the description fully compensates: it explains return values from step 1 (summary, consent line, confirmation token), the trigger of the email in step 2, and the condition under which providers see the enquiry. Nothing essential for correctly invoking the tool is 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?
Schema description coverage is 100%, so the schema already documents answers, consent, and confirmation. The description adds workflow-level meaning: answers must be keyed by field key from enquiry_fields, consent=true must reflect the quoted agreement, and confirmation is the token returned from step 1. This exceeds the baseline of relying on schema alone, though it partly restates schema content.
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 opens with a specific verb and resource: 'Submits an enquiry to Freight Forwarder Finder', and immediately disambiguates with 'NOT a purchase, NOT a guaranteed quote'. This clearly separates it from comparison and enquiry-description sibling tools, so an agent can tell what this tool is for and what it is not.
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 two-step usage protocol is explicit: Step 1 calls with answers and consent=true to obtain a confirmation token; Step 2 calls again only if the person agrees, with the same answers, consent=true, and the token. It also tells the agent to show the person the summary and consent line before proceeding, which is strong when-to-use guidance.
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!
FBA Forwarders: the site's own MCP server — compare, enquiry (enquiry = a human handoff, not a...
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...