Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@US Gambling Regulations MCP Server Calculate sports betting fees for Pennsylvania with projected revenue of $50 million"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server providing comprehensive gambling licensing information across US states, UK, Spain, Malta, and Gibraltar.
This MCP server provides detailed, up-to-date information about gambling regulations, licensing requirements, fees, and compliance obligations across US states. It's designed to help legal professionals, gaming operators, compliance officers, and researchers access accurate US regulatory data quickly.
Related MCP server: contractor-license-mcp-server
Comprehensive data for 32 US states including:
License types and categories
Application and renewal fees
Tax structures and rates
Compliance requirements
Market data and statistics
Regulatory contact information
Problem gambling resources
License Information - Detailed breakdown of all license types per jurisdiction
Fee Calculations - Calculate licensing fees based on projected revenue
Compliance Requirements - Comprehensive compliance obligations
Jurisdiction Comparisons - Compare regulations across states/countries
Market Data - Launch dates, revenue statistics, operator counts
Recent Updates - 2024-2025 regulatory changes
Node.js 18 or higher
npm or yarn
Claude Desktop app
Clone the repository:
cd /Users/adamavery/us-gambling-regulations-mcp/Install dependencies:
npm installBuild the TypeScript server:
npx tscConfigure Claude Desktop:
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"us-gambling-regulations": {
"command": "node",
"args": ["/Users/adamavery/us-gambling-regulations-mcp/build/index.js"]
}
}
}Restart Claude Desktop
us-gambling-regulations:get_license_typesGet detailed information about gambling license types for a specific US state.
Parameters:
state (string, required): State jurisdiction (use kebab-case: new-jersey, pennsylvania, nevada, etc.)
Example:
Get license types for New Jerseyus-gambling-regulations:calculate_feesCalculate licensing fees based on projected revenue for a specific state.
Parameters:
state (string, required): State jurisdiction
license_type (string, required): Type of license (e.g., 'sports-betting', 'online-casino')
projected_revenue (number, required): Projected annual gross gaming revenue in USD
Example:
Calculate sports betting fees for Pennsylvania with projected revenue of $50 millionus-gambling-regulations:compare_jurisdictionsCompare gambling regulations between multiple states.
Parameters:
states (array, required): List of states to compare (minimum 2)
aspect (string, required): Aspect to compare - 'licensing', 'fees', 'compliance', 'taxes', or 'all'
Example:
Compare licensing requirements between New Jersey, Pennsylvania, and Nevadaus-gambling-regulations:get_compliance_requirementsGet specific compliance requirements for one or more states.
Parameters:
states (array, required): List of state jurisdictions
Example:
What are the compliance requirements for online casino operators in Michigan?us-gambling-regulations:get_regulatory_updatesGet recent regulatory changes and updates for specific states.
Parameters:
states (array, required): States to get updates for
Example:
Show me recent regulatory updates for Illinois and New Yorkus-gambling-regulations:calculate_market_sizeCalculate potential market size and revenue projections for a state.
Parameters:
state (string, required): State jurisdiction
Example:
What's the market size projection for sports betting in Ohio?Arkansas (92%)
Louisiana (92%)
Illinois (90%)
Nevada (90%)
New Jersey (90%)
Pennsylvania (90%)
Michigan (100%)
Arizona (85%)
Colorado (80%+)
Connecticut (65%+)
Delaware (85%)
Florida (85%)
Indiana (88%)
Iowa (85%)
Kansas (78%+)
Kentucky (83%)
Maine (~85-90%)
Maryland (80%+)
Massachusetts (82%)
Mississippi (~85-90%)
New Hampshire (75%+)
New York (88%)
North Carolina (82%)
Ohio (85%)
Oregon (70-75%+)
Rhode Island (88%)
Tennessee (85%)
Vermont (~85-88%)
Virginia (85%)
Washington (88%)
Washington DC (~85-88%)
West Virginia (85%)
Wyoming (85%)
Puerto Rico (~85-88%)
State data files are located in /data/states/completed/[state-name].json
Each state file includes:
{
"state_name": "state-name",
"state": "State Name",
"state_code": "XX",
"regulator": "Regulatory Authority Name",
"regulation_source": "Legal citations",
"license_types": {
"license_type_id": {
"description": "...",
"eligibility": [...],
"application_fee": 0,
"requirements": [...]
}
},
"tax_structure": {...},
"compliance_requirements": {...},
"market_data": {...},
"enforcement": {...},
"contact_information": {...},
"data_quality": {
"completeness_score": 90,
"data_extraction_date": "2025-10-08"
}
}Research state gambling regulations thoroughly
Create comprehensive data file using the template structure
Ensure state_name field uses lowercase, hyphenated format
Target 90%+ completeness score
Include all sections: licensing, fees, taxes, compliance, market data, enforcement, contacts
Modify the JSON file in /data/states/completed/
Update data_extraction_date field
Rebuild TypeScript: npx tsc
Restart Claude Desktop
After making changes:
npx tsc
# Restart Claude Desktop
# Test with: "Get license types for [state-name]"For 90%+ completeness:
Comprehensive license types - All categories with fees, requirements, durations
Tax structure - Rates, bases, collection frequency, revenue allocation
Fee calculations - Breakdowns for all license types
Compliance requirements - Responsible gaming, age verification, geolocation, internal controls, reporting
Market data - Launch dates, handle/revenue, current operators
Enforcement - Regulatory authority, penalties, recent actions
Application process - Steps, timeline, forms required
Contact information - Regulator details, problem gambling resources
Regulatory updates - Recent changes, upcoming legislation
Competitive analysis - Market strengths and challenges
"What are the licensing requirements for online sports betting in Pennsylvania?"
"Calculate the licensing fees for an online casino in New Jersey with projected revenue of $25 million"
"Compare sports betting regulations between Illinois, Michigan, and Ohio"
"What are the responsible gaming requirements for operators in Nevada?"
"Show me the market size and operator count for sports betting in New York"
State enhancement workflow:
Identify lowest completion state
Research regulations thoroughly
Create comprehensive enhancement script
Test and verify completeness
Document completion score increase
For questions or issues:
Check state data files in /data/states/completed/
Verify Claude Desktop configuration
Ensure TypeScript is compiled: npx tsc
Restart Claude Desktop after changes
[Add your license information]
Enhanced 6 states to 80%+ completion: Connecticut, Oregon, New Hampshire, Kansas, Colorado, Maryland
Fixed Arkansas (45% → 92%) and Louisiana (78% → 92%)
Added comprehensive compliance requirements
Updated market data through Q3 2025
Added 2024-2025 regulatory changes
32 states in database
UK, Spain, Malta, Gibraltar coverage
Fee calculation tools
Market size projections
Regulatory update tracking
Enhance remaining states to 90%+ completion
Add tribal gaming compact details
Include historical regulatory timeline
Add license application checklists
Include sample compliance documents
Current Status: 32 US states, 12 states at 90%+ completion
Calculate licensing fees based on projected revenue for a specific state
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State jurisdiction for fee calculation | |
| license_type | Yes | Type of gambling license (e.g., 'sports-betting', 'online-casino', 'interactive-gaming') | |
| projected_revenue | Yes | Projected annual gross gaming revenue in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It merely states that fees are calculated, without revealing what output format to expect (e.g., total amount, breakdown), whether calculations are estimates, or any jurisdiction-specific logic. This is insufficient for a financial calculation tool.
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 verb and core purpose. No filler or redundancy.
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 and no annotations, the description must clarify what users will receive. It does not mention return format, edge cases, or that the result may be an estimate. This leaves significant gaps for a calculation tool operating across multiple states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions provide meaningful context (e.g., 'Projected annual gross gaming revenue in USD' includes units; license_type includes examples). The tool description itself adds no parameter details, so the baseline 3 is appropriate given the schema's contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Calculate') and resource ('licensing fees') with a clear scope ('based on projected revenue for a specific state'). It distinguishes from siblings like calculate_market_size by focusing on fees, not market size.
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 when to use the tool (when projected revenue and a state are known) but does not explicitly mention alternatives or exclusions. It lacks direct comparisons to sibling tools, but the context of requiring projected revenue makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate potential market size and revenue projections for a state based on available market data
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State jurisdiction for market size calculation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions 'based on available market data' but doesn't disclose whether data is locally available, how projections are made, or if the operation is read-only. It also lacks details on limitations or assumptions, leaving uncertainty about the tool's internal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It avoids fluff while including essential scope ('for a state') and a qualifier ('potential') that adds nuance without excess.
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 (1 required param, no output schema), but the description leaves uncertainty about output format and data sources. It is adequate for basic understanding but lacks contextual depth, such as whether it returns a numeric value, a report, or requires specific state codes.
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 already fully documents the 'state' parameter, and the description's phrase 'for a state' aligns with it. With 100% schema coverage, the description adds no additional semantic meaning beyond the schema, matching the baseline of 3.
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's function—calculating market size and revenue projections for a state—with a specific verb and resource. It is distinct from sibling tools like calculate_fees or compare_jurisdictions, which deal with different aspects of regulatory analysis.
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, what prerequisites exist, or how it relates to sibling tools. It does not state when to choose this over calculate_fees or get_license_types, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare gambling regulations between multiple states
| Name | Required | Description | Default |
|---|---|---|---|
| aspect | Yes | Regulatory aspect to compare | |
| states | Yes | States to compare (minimum 2) |
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 states the high-level action and does not disclose output format, handling of missing data, or any limitations of the comparison, leaving significant behavioral 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 a single, focused sentence with no filler, effectively conveying the core function. It is appropriately sized 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?
While the schema covers inputs well, the lack of any output description and minimal behavioral context means an agent has incomplete information to anticipate the tool's response. The description is adequate but not comprehensive given no annotations or output schema.
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 already provides complete descriptions for both parameters, including the enum for 'aspect' and the min 2 requirement for 'states'. The description adds no additional parameter-level detail beyond what the schema offers.
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 uses the verb 'compare' and identifies the resource as 'gambling regulations' between multiple states, which distinguishes it from sibling tools that focus on single-state details like licensing or fees. This makes the tool's purpose immediately obvious and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (comparing states) but does not explicitly mention when to choose this tool over alternatives or when not to use it. No alternative tools or exclusions are referenced, so guidance is limited to an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific compliance requirements for one or more states
| Name | Required | Description | Default |
|---|---|---|---|
| states | Yes | List of state jurisdictions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only states the action and scope, without specifying return format, handling of invalid states, or whether results are jurisdiction-specific.
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 fluff, immediately stating the action and target. It is concise 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 tool with one parameter and no output schema, the description is minimal. It doesn't explain what 'specific compliance requirements' means or what the response looks like, leaving ambiguity despite its simplicity.
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 describes the 'states' parameter as 'List of state jurisdictions', and the description adds 'one or more states'. This is consistent but adds little beyond the schema, so a baseline score 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 uses a specific verb 'Get' and identifies the resource 'compliance requirements' with scope 'for one or more states'. This clearly distinguishes it from sibling tools like calculate_fees or get_regulatory_updates.
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. It does not mention any prerequisites, complementary tools, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about gambling license types for a specific US state
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | State jurisdiction (use kebab-case: new-jersey, pennsylvania, nevada, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries no behavioral disclosure. It does not state whether the operation is read-only, what happens on invalid state inputs, whether any authentication is required, or what kind of 'detailed information' will be returned. The description simply restates the tool's purpose without adding any behavioral context.
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 purpose. There is no unnecessary padding or repetition. For a tool with one parameter and a straightforward function, this length is appropriate.
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 and no annotations, the description needs to compensate by explaining what 'detailed information' includes and what the caller can expect. It does not describe the return format, potential errors, or any caveats. The description is too sparse to be considered complete for an agent to reliably invoke and interpret results.
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 fully describes the 'state' parameter with examples of kebab-case values, giving 100% coverage. The tool description itself does not add any parameter-specific meaning beyond what the schema provides. Since schema coverage is high, 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 clearly states the tool's function: getting detailed information about gambling license types for a specific US state. It uses a specific verb ('Get') and resource ('gambling license types'). While it doesn't explicitly distinguish itself from sibling tools like 'get_compliance_requirements' or 'compare_jurisdictions', the focus on license types is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'calculate_fees' or 'compare_jurisdictions', nor does it specify any prerequisites or exclusions. Usage is only implicit through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent regulatory changes and updates for specific states
| Name | Required | Description | Default |
|---|---|---|---|
| states | Yes | States to get updates for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It adds 'recent' and 'specific states' as behavioral scoping, but does not disclose what 'recent' means, the output structure, or any limitations. Still, as a read tool, safety is implied and no contradictions exist.
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 with no filler words, effectively communicating the tool's 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?
For a simple one-parameter tool with no annotations or output schema, the description provides a basic understanding but lacks details about the return value, the meaning of 'recent', or how it differs from related tools.
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% for the single 'states' parameter, which is already described in the schema. The description's phrase 'specific states' simply mirrors the schema without adding extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource ('recent regulatory changes and updates') and scope ('for specific states'). It is distinct from sibling tools like 'get_license_types' and 'get_compliance_requirements'.
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. There is no mention of context, exclusions, or conditions under which this tool should be chosen over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of US gambling regulations: license types, fee calculation, jurisdiction comparison, compliance requirements, regulatory updates, and market size. No two tools have overlapping purposes, making selection unambiguous.
All tool names follow a consistent verb_noun pattern using lowercase snake_case (get_*, calculate_*, compare_*). The naming is predictable and uniform throughout the set.
With 6 tools, the server is well-scoped for its purpose. It provides a focused set of capabilities without being overly sparse or bloated, each tool earning its place.
The tool set covers core regulatory needs: license types, fees, compliance, updates, and market analysis. Missing is a general state overview or direct legal status tool, but agents can work around this with existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
U.S. casino directory + a player's loyalty data, comps, tiers, and gambling tax docs.
Verified hemp & cannabinoid regulatory data for all 50 US states + DC. Requires a HempData API key.
Verified, tier-0 regulatory data for AI across 850+ official sources and 50+ jurisdictions.
US federal and state cybersecurity/privacy law MCP server with cross-state comparison
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Angeltooth/us-gambling-regulations-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
