customs-dog-mcp
Server Details
Pet travel docs + border readiness. Keyless: look up entry rules + sign up. Keyed: household docs.
- 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.8/5 across 8 of 8 tools scored. Lowest: 2.6/5.
Each tool targets a distinct function: public rules lookup, account-based trip readiness, listing pets/documents, dashboard overview, session prep, signup, and calendar integration. No two tools have overlapping purposes.
All tools start with 'customs_' and use lowercase with underscores. Most follow verb_noun (check_rules, list_pets), but 'overview' and 'upcoming_trips' are noun and adjective_noun respectively, and 'prep' is a short verb. Minor inconsistency but overall clear pattern.
With 8 tools, the server covers signup, session prep, pet/document listing, rule checking, trip readiness, dashboard, and calendar integration. This is well-scoped for a pet travel assistant without being excessive.
The set lacks tools for creating, updating, or deleting pets and documents, which are core to the domain. While listing and checking are covered, the inability to add or modify data creates significant gaps for a management tool.
Available Tools
8 toolscustoms_check_rulesAInspect
Per-destination pet border-entry requirements — NO account needed. What documents a dog needs to enter a country and re-enter the US. Use this to answer 'what does my pet need to travel to X?' for anyone. Omit destination to list every corridor.
| Name | Required | Description | Default |
|---|---|---|---|
| destination | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses no account needed and covers entry and re-entry to the US. However, it lacks details on output format, behavior for invalid destinations, or whether it covers only dogs or all pets, leaving some ambiguity.
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 four short, front-loaded sentences. Each sentence adds distinct value: stating the core function, the target question, and a special usage case. No unnecessary words or repetition.
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 tool with one optional parameter and no output schema, the description covers the main use cases and constraints. It explains purpose, target audience, and a special case (list all corridors). It does not describe return values, but the tool's simplicity makes this acceptable.
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 the 'destination' parameter and explains the effect of omitting it. However, it does not elaborate on the enum values beyond what the schema already provides, so the additional meaning is minimal.
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's for per-destination pet border-entry requirements, with a specific example of documents for a dog. It distinguishes from sibling tools by emphasizing no account needed and focusing on rules rather than trip readiness or document listing.
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 specifies when to use: to answer 'what does my pet need to travel to X?' and to omit destination for all corridors. It provides clear context but does not explicitly state when not to use or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_check_trip_readinessAInspect
Cleared / caution / blocked for pet + destination + return_date. NEVER assert clearance without this. (For rules without an account, use customs_check_rules.)
| Name | Required | Description | Default |
|---|---|---|---|
| pet_id | Yes | ||
| destination | Yes | ||
| return_date | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the tool's behavioral outcome (returning clearance statuses) and its limitation (requires an account; otherwise use sibling). This provides good transparency for a simple read-only check.
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 two short sentences, no redundancy, and front-loads the core function. Every sentence adds value.
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 covers the primary output (cleared/caution/blocked) and usage context. Given the tool's simplicity and no output schema, it is nearly complete, though it could mention what happens on error or missing return_date.
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 0%, and the description does not add meaning to individual parameters. While 'pet + destination + return_date' implies their roles, no details on expected format, valid values, or constraints are given beyond the schema's enum for destination.
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 checks clearance status ('Cleared / caution / blocked') for a pet given a destination and return date. It distinguishes from the sibling tool customs_check_rules by noting that tool is for rules without an account.
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 explicitly instructs 'NEVER assert clearance without this,' providing a strong usage directive. It also tells the agent when to use the alternative tool customs_check_rules, making guidance comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_list_documentsCInspect
List documents for a pet.
| Name | Required | Description | Default |
|---|---|---|---|
| pet_id | Yes | ||
| status | No | ||
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks behavioral details (e.g., safety, permissions). Minimal info only.
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?
Single sentence is concise but under-specifies the tool; not fully earning 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?
With 3 params, 2 enums, no output schema, and no annotations, description fails to provide necessary context for correct invocation.
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 0%, and description does not explain any of the 3 parameters (pet_id, status, category) or their values.
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?
Description clearly states 'List documents for a pet' – specific verb and resource, distinguishing from siblings like customs_list_pets.
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 or alternatives; only a basic statement without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_list_petsBInspect
List the household's pets (source of pet_id).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only list operation, but does not disclose potential constraints such as authentication needs, rate limits, or what happens if the household has no pets. The description is too minimal for full transparency.
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 unnecessary words. It is front-loaded and efficiently conveys the core purpose.
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, but without an output schema, the description should explain what is returned (e.g., list of pet objects, fields included). It fails to do so, leaving ambiguity about the output format.
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?
There are no parameters, and the schema coverage is trivially 100%. According to guidelines, 0 parameters baseline is 4. The description adds context beyond the empty schema by clarifying the purpose and the fact that pet_id originates here.
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 lists the household's pets and explicitly identifies it as the source of pet_id. It uses a specific verb-resource combination and is easily distinguishable from sibling tools like customs_list_documents or customs_check_rules.
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 alternatives. The description does not mention prerequisites, context, or scenarios where this tool is preferred, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_overviewAInspect
Counts of pets/documents by status, what's expiring soon, recent household activity, and MCP usage stats (per-tool call counts, public-tier reach, verdict distribution).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses that the tool returns counts, expiring items, activity, and usage stats. It is a read-only dashboard, and the description coverage is adequate, though missing details like data freshness.
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 key outputs. No unnecessary words.
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 parameterless tool with no output schema, the description comprehensively lists all return categories: status counts, expiring soon, recent activity, and detailed MCP usage stats. It is complete for an overview 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?
There are no parameters (schema coverage 100%), so the description naturally cannot add parameter info. Baseline score of 4 applies as the description is not required to elaborate.
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 provides counts of pets/documents by status, expiring items, recent household activity, and MCP usage stats. It distinguishes from sibling tools like customs_list_documents or customs_check_rules, which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting an overview via the name 'overview', but it does not explicitly state when to use this tool over siblings or provide exclusions. The guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_prepAInspect
Validate the session, confirm the pet roster, report health. Call first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It only lists high-level actions (validate, confirm, report) without disclosing side effects, authentication needs, or error conditions, making it insufficient for informed invocation.
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—one sentence with key actions and a usage directive. While it lacks structured formatting, it remains minimal and 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 zero-parameter tool with no output schema, the description provides the essential purpose but lacks details on session validation specifics, reporting format, or failure modes, leaving gaps for the agent.
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 schema coverage is 100%. The description adds no parameter-level information, which is acceptable since no parameters exist 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 clearly states what the tool does: 'Validate the session, confirm the pet roster, report health.' It uses specific verbs and resources, distinguishing its role as a preparatory step among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call first,' providing a usage directive that positions this tool as the initial step. It does not include when-not-to-use or alternatives, but the guidance is clear and contextually appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_start_signupAInspect
Start a FREE customs.dog account for a NEW user by email and send them a magic sign-in link (no password). Use this to onboard someone who wants to store and track their pet's travel documents after you've shown them their border requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the magic link email but does not mention expected behavior for existing users, error scenarios, rate limits, or authorization 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?
Two sentences; the first clearly states the action and the second provides usage context. No unnecessary words, all sentences add value.
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, but the description misses the optional 'name' parameter and does not detail the return behavior. With no output schema, the agent may need more information on success/failure indications.
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% (no parameter descriptions in schema). The description only indirectly covers the 'email' parameter by explaining its use, and completely omits the optional 'name' parameter, leaving its purpose unclear.
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 creates a FREE account for a NEW user via email with a magic sign-in link. It distinguishes well from siblings which focus on checking rules, trips, documents, etc.
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 use context: 'onboard someone who wants to store and track their pet's travel documents after you've shown them their border requirements.' It does not explicitly state when not to use it, but the purpose is specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
customs_upcoming_tripsAInspect
Upcoming trips from the household's connected travel calendar (TripIt/Flighty/Google/Apple), each with per-pet readiness (cleared/caution/blocked). Use to proactively flag paperwork needed before travel.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It notes the source (connected calendars) and output (readiness), but omits behavioral aspects like read-only nature, required authentication, or performance implications.
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 that are direct and free of redundancy. Every word adds value, clearly conveying purpose and output.
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 adequately describes the return type (trips with readiness). However, it lacks specifics on date range or how 'upcoming' is defined. Sibling context suggests this is a list, but completeness could be improved.
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 zero parameters, so the description need only explain the tool's action. It adds meaning by detailing the data source and readiness information, exceeding baseline expectations.
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 returns upcoming trips with per-pet readiness levels, using a specific verb ('list upcoming trips') and distinguishes from siblings like customs_check_trip_readiness and customs_list_pets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context: 'Use to proactively flag paperwork needed before travel.' However, it does not explicitly state when not to use or mention alternatives, which are addressed in sibling tools.
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!