Moving Helper
Server Details
Help estimating move size, inventory and quotes for house or office movers.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.2/5 across 3 of 3 tools scored. Lowest: 2.5/5.
The two quote request tools have very similar descriptions, both requiring personal and move data and providing quotes based on pictures. An agent may struggle to distinguish when to use each, leading to potential misselection.
All tool names follow a consistent verb-noun pattern with hyphens (e.g., get-lead-status, request-free-instant-moving-estimate), making them predictable and easy to understand.
With 3 tools, the server is slightly sparse but still reasonable for its focused domain of moving quotes. It's not overly heavy, but a few more tools might be expected for completeness.
The tool set covers lead status retrieval and quote requests, but lacks tools for updating leads, managing quotes after submission, or handling photos separately. The two similar quote tools also feel redundant rather than complementary.
Available Tools
3 toolsget-lead-statusGet Lead detailsARead-onlyInspect
Read the current information for a lead
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | The ID of the lead |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | No | First and last name |
| No | Email address | |
| phone | No | Phone number |
| leadId | No | The ID of the lead |
| moveDate | No | Date of the move |
| moveSize | No | Size of the move |
| pictureCount | No | The number of pictures in the survey |
| originAddress | No | Origin address as address string |
| volumeInCubicFeet | No | The volume in cubic feet |
| destinationAddress | No | Destination address as address string |
| originGooglePlaceId | No | Origin address as google place id |
| analyzedPictureCount | No | The number of analyzed pictures |
| weightInImperialLibs | No | The weight in imperial pounds |
| costEstimateLowerBound | No | The lower bound of the cost estimate |
| costEstimateUpperBound | No | The upper bound of the cost estimate |
| destinationGooglePlaceId | No | Destination address as google place id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true and destructiveHint=false. The description's 'Read' phrase matches these, but adds no extra behavioral details like error handling or access requirements beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it could afford a bit more detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param, annotations present, and an output schema exists), the minimal description is sufficient. The output schema handles return value details, so repeating them is unnecessary.
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 for the single parameter 'leadId' is 100% with a basic description. The tool description does not add any additional semantic meaning beyond the schema's own description.
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 it reads current information for a lead, aligning with the tool name. Sibling tools ('request-free-instant-moving-estimate', 'request-free-moving-quote') are in a different domain, so no confusion arises.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied by the sibling context (different domains), but no when-not or alternative naming is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request-free-instant-moving-estimateRequest free instant moving estimateAInspect
Submit the necessary data about you and your move and get an instant quote based on pictures for house or office movers in United States.
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) indicate a non-read, non-destructive operation, which aligns with the description of submitting data and receiving a quote. The description adds that it is based on pictures, but it does not disclose any other behavioral traits, such as data handling or authentication needs.
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 that conveys the core purpose without unnecessary words. It is front-loaded with the key action ('Submit the necessary data') and immediately clarifies the outcome.
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 no output schema, the description should clarify the required data more precisely. The mention of 'pictures' and 'your move' is left undefined, and the return value is only vaguely described as 'instant quote'. Siblings suggest alternative tools, but the description does not integrate this 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 schema has only one fully described parameter (phone), yet the description mentions 'data about you and your move' and 'based on pictures', implying additional inputs that are not reflected in the schema. This discrepancy reduces clarity and adds confusion rather than value.
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 action ('submit the necessary data') and resource ('instant moving estimate'), specifying it is for house or office movers in the United States. It distinguishes from siblings by referencing the instant and picture-based nature.
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 the tool is for getting an instant quote after submitting move details and pictures, but it does not explicitly state when to use it over siblings like 'request-free-moving-quote' or 'get-lead-status', nor does it provide when-not or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request-free-moving-quoteRequest free moving quoteCInspect
Submit important data about you and your move and get an accurate quote from a mover based on pictures for house or office movers in United States.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | First and last name | |
| Yes | Email address | ||
| phone | Yes | Phone number |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds little behavioral context. It says a quote will be provided based on pictures, but does not disclose what happens after submission (e.g., email, call) or any 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 sentence, but it contains filler words like 'important' and 'accurate'. It is concise but not optimally structured for quick scanning.
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 no output schema, the description should explain what the agent can expect after invoking the tool (e.g., confirmation, email delivery). It does not cover the outcome or how the quote is delivered, and it does not differentiate from the sibling 'request-free-instant-moving-estimate'.
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% for the three parameters (name, email, phone). The description adds the phrase 'important data about you and your move' but does not provide meaningful additional semantics beyond the 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 the tool submits data to get a quote from movers, which is clear. However, it mentions 'pictures' as basis for the quote, but the input schema has no picture parameter, creating confusion. The purpose is somewhat clear but has a mismatch.
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 its siblings ('get-lead-status', 'request-free-instant-moving-estimate'). It does not explain what distinguishes this quote request from an instant estimate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!