coverage-trigger
Server Details
Leads of businesses that just legally need commercial insurance: new FMCSA authority + new entities.
- 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 3 of 3 tools scored.
Each tool serves a distinct purpose: aggregate pulse, listing sources, and delivering actual leads. There is no overlap or ambiguity.
All tools start with 'coverage_' and use consistent snake_case naming. The pattern is uniform and descriptive.
Three tools is appropriate for a focused feed server. It provides overview, source info, and data without being too thin or excessive.
The set covers the main functions: aggregate insights, source listing, and full feed retrieval. Missing drill-down or filtering, but core needs are met.
Available Tools
3 toolscoverage_pulseBInspect
Free aggregate pulse: how many entities newly needed coverage in the window, broken down by source, lead-value tier, and coverage line — with a small redacted sample. No contact data.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| state | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses redacted sample and no contact data, implying limited scope. However, it does not mention read-only nature, rate limits, or auth requirements. Adequate but not rich.
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?
Extremely concise: one sentence with a dash plus a short second sentence. No wasted words; front-loaded with key 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 description covers output (counts, breakdown, redacted sample) and constraints (no contact data), but misses explanation of the 'state' parameter and output format. Adequate for a simple tool but incomplete.
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%, so description must explain params. It relates 'days' to a time window but does not explain the 'state' parameter at all. Insufficient for 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing an aggregate pulse of entities newly needing coverage, broken down by source, lead-value tier, and coverage line, with a redacted sample. 'No contact data' distinguishes it from contact-related 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?
No explicit guidance on when to use this tool versus siblings or alternatives. It implies aggregate summary usage but does not highlight differences from coverage_sources or coverage_trigger_feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coverage_sourcesAInspect
List the public trigger-event sources this feed normalizes, their geographic coverage, and the agent buyer each is best for.
| 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 burden. It only states what is listed and does not disclose behavioral traits such as read-only nature, authentication requirements, 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 that efficiently conveys the tool's purpose without redundancy. It is front-loaded with the key action and resource.
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 (no parameters, no output schema), the description provides sufficient context: it lists sources with geographic coverage and buyer suitability. No additional information is necessary.
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?
With zero parameters, schema coverage is 100% by default, and the description adds meaning by specifying the content of the output (sources, locations, buyer). This meets the baseline of 4 for no-parameter tools.
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 'List[s] the public trigger-event sources' with additional details on geographic coverage and agent buyer. It uses a specific verb and resource, and distinguishes itself from sibling tools like coverage_pulse and coverage_trigger_feed.
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 to obtain source information but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
coverage_trigger_feedAInspect
Return businesses that JUST legally/practically NEED commercial insurance, drawn from public trigger events (new FMCSA DOT operating authority + newly formed commercial entities). Each lead is normalized to a NAICS family and a MANDATED-COVERAGE MAP (which policies it now needs: general liability, commercial auto, motor cargo, workers-comp, surety bond, etc.), deduped so one entity hitting multiple triggers = ONE lead, and tiered by lead value. Built for B2B insurance & surety AGENTS sourcing fresh, high-intent commercial leads.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 7). | |
| limit | No | Max leads (default 100). | |
| state | No | Two-letter state filter, e.g. 'CT'. | |
| sources | No | Subset of sources: 'fmcsa', 'ct-sos'. Omit for all. | |
| coverageLine | No | Filter to leads needing a line, e.g. 'commercial-auto', 'general-liability', 'surety-bond'. | |
| minLeadValue | No | Only leads with estLeadValueUsd >= this. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the processing steps (normalization, deduplication, tiering) and data sources. However, it does not disclose if the tool is read-only, any authentication needs, or rate limits, but the description is still highly informative.
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 (4 sentences), front-loaded with the main action, and every sentence adds value. No wasted 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?
The description explains the output (normalized, deduped, tiered leads) and sources, but lacks details on the output structure (fields, format) since no output schema is provided. Given the complexity (6 params, no output schema), it is incomplete.
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% with clear parameter descriptions. The tool description provides overall context but does not add extra meaning beyond the schema for individual parameters. 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 clearly states the tool returns businesses needing commercial insurance based on trigger events, specifies sources (FMCSA, newly formed entities), and explains normalization and deduplication. It distinguishes itself from siblings by focusing on fresh, high-intent leads.
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 targets B2B insurance agents sourcing fresh leads, providing clear context. However, it does not directly contrast with sibling tools (coverage_pulse, coverage_sources), so an explicit when-to-use vs alternatives is missing.
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!