Source-linked Georgia permit search, county coverage, contractor signals, and authorized watches.
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.
Average 4.2/5 across 8 of 8 tools scored.
Several tools have overlapping purposes: fetch and get_permit_record both retrieve a single permit record by ID, and search and search_georgia_permits both search permits. Although the descriptions attempt to differentiate them (fetch can also retrieve guides, search covers guidance + permits), an agent could easily select the wrong tool for a given task.
Most tools follow a verb_noun pattern (get_county_coverage, create_permit_watch, search_georgia_permits). The bare verbs 'fetch' and 'search' deviate from this pattern, but they are still clear and readable. Overall, the naming is largely consistent.
With 8 tools, the server is well-scoped for the Georgia permit intelligence domain. Each tool covers a distinct function (search, retrieve, coverage, leads, watch creation), and the count is neither too sparse nor too overwhelming.
The server covers read and search operations well, including permit records, coverage, and contractor leads. However, the watch feature is incomplete: create_permit_watch exists, but there is no way to update, cancel, or list watches, which is a notable gap in the lifecycle.
create_permit_watchCreate an authorized PermitReporter email watchACreate a pending email watch only after the user reviews the exact email, search query and optional county, explicitly authorizes this request and confirmation email, and accepts https://permitreporter.com/terms and https://permitreporter.com/privacy. This additive action stores the email and search for alerts; it does not file a permit or prove coverage. The address must confirm before alerts begin. Reuse submission_id for safe retries.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The user's reviewed email address. It is stored for confirmation and alerts, never returned. | ||
| query | Yes | The exact address, project, subdivision, business term or county-wide phrase the user approved. | |
| county | No | Optional Georgia county restriction. | |
| submission_id | Yes | Generate once for this watch; reuse it when retrying the same exact request. | |
| user_authorized | Yes | True only after the user reviews the exact email, query and county and explicitly asks PermitReporter to create this watch and send its confirmation email. | |
| terms_and_privacy_accepted | Yes | True only after the user accepts https://permitreporter.com/terms and https://permitreporter.com/privacy. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| watch | Yes | |
| status | Yes | |
| replayed | Yes | |
| next_step | Yes | |
| reference | Yes | |
| submission_meaning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enriches the annotations by explaining the pending state, the need for confirmation before alerts begin, the additive/non-destructive nature, and safe retries via submission_id. This goes beyond the readOnlyHint, destructiveHint, and idempotentHint annotations, giving the agent useful 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 three sentences, front-loaded with the purpose and prerequisites, followed by behavioral notes and retry guidance. Every sentence carries necessary information with no redundancy or fluff.
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 complexity of the consent workflow, the description covers prerequisites, behavior, limitations, and retry semantics. An output schema exists, so return values need not be described. The description is fully complete for selecting and invoking this tool 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 input schema already provides 100% coverage with detailed descriptions for all parameters, including submission_id reuse and the boolean consts. The description reiterates some of this (e.g., retry semantics) but does not add significant new parameter-level meaning beyond the schema, so the baseline 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 the specific verb 'Create' with the resource 'pending email watch' and clearly states what the tool accomplishes (stores email and search for alerts). It stands out from sibling tools, which are all read/search operations, and clarifies the additive nature of the action.
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 defines the prerequisites (user review, explicit authorization, acceptance of terms) and states what it does not do ('does not file a permit or prove coverage'). It provides clear context and a when-not, but does not name alternative tools as a replacement, slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch a Georgia permit sourceAFetch one reviewed PermitReporter guide or one collected permit record returned by search. Permit records retain source, record date, collection timestamp and coverage limits.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A guide:… or permit:… ID returned by search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds that permit records retain source, record date, collection timestamp, and coverage limits, which is useful behavioral context. It does not discuss error handling or pagination, but for a single-item fetch with a schema, this is acceptable.
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 redundant information. The first sentence states the action and object, the second adds relevant detail about the record contents.
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 a single parameter, an output schema, and annotations. The description explains what can be fetched and the provenance of the IDs, which is sufficient for an agent to invoke it correctly. No additional return format explanation needed due to 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?
Schema coverage is 100%, and the id parameter's description already explains the 'guide:…' and 'permit:…' format. The tool description mentions 'returned by search' but adds no new semantic detail beyond the schema's 'returned by search'. Thus baseline 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 states the tool fetches 'one reviewed PermitReporter guide or one collected permit record' and specifies these come from search results. It distinguishes from siblings like get_permit_record by limiting to search-returned items and including guides.
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 'returned by search' implies the tool is used after running a search, but it does not explicitly mention alternatives or when not to use it. Sibling tools like get_permit_record exist, but the description does not differentiate when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contractor_leadsFind Georgia contractor opportunity signalsAReturn recent, source-linked collected permits classified by trade and project scope for contractor research. Classifications are editorial signals, not official fields or guaranteed work.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| limit | No | ||
| trade | No | ||
| county | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds non-obvious context: permits are 'source-linked' (each result includes a source) and classifications are 'editorial signals, not official fields or guaranteed work,' telling the agent that the data is interpretive and not authoritative. This goes beyond annotations and improves understanding.
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 well-formed sentence that front-loads the action ('Return') and covers key aspects: recency, source-linking, classification dimensions, and research context. It then adds a sentence for data-quality caveat, which is valuable. No redundancy or filler.
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 moderate complexity (4 optional params, output schema present), the description provides enough context for an agent to know what the tool returns and the data caveats. It does not explain parameter usage or alternatives, which are covered by other dimensions, but overall the description plus annotations and output schema allow confident invocation for the intended use case.
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%, and the description does not compensate. It mentions 'classified by trade' which relates to the 'trade' parameter, and 'recent' relates to 'days', but it does not explain 'county' or 'limit', nor does it clarify allowed values or filtering behavior. The parameter names are semi-self-explanatory, but the description fails to add meaning beyond names.
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 'Return recent, source-linked collected permits classified by trade and project scope for contractor research.' This specifies a distinct resource (permits) and purpose (contractor leads), and the title adds 'opportunity signals.' It differentiates from siblings like get_permit_record (single record) and search_georgia_permits (search) by emphasizing classifications and contractor research.
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 explicit guidance on when to use this tool versus alternatives. It only offers an implied context ('for contractor research') but does not state when to prefer this over search_georgia_permits or get_statewide_snapshot, nor does it mention any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_county_coverageCheck Georgia county permit coverageAReturn the current source route, issuer, cadence, lag, through-date, collected record count, sources and statistical floor for one of Georgia's 159 counties. Call this before interpreting a missing county result.
| Name | Required | Description | Default |
|---|---|---|---|
| county | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context by enumerating the returned fields and emphasizing the 'current' nature of the data, which informs freshness expectations and the tool's role in interpreting missing results.
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 two sentences, front-loaded with the exact return payload and followed by a single usage directive. Every word earns its place; there is no redundancy or irrelevant detail.
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 an output schema and annotations covering safety/idempotence, the description provides the crucial usage context ('before interpreting a missing county result') and the full list of returned fields. The only gap is the parameter format, but overall it is sufficiently complete for an AI agent to decide when to invoke this 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 schema provides only a bare string parameter with maxLength 80 and no enum or description. The description references 'Georgia's 159 counties' but does not clarify the expected format (e.g., county name vs. FIPS code, case sensitivity, leading/trailing spaces). With 0% schema coverage, this is a significant gap that the description fails to address.
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 the clear verb 'Return' followed by a specific list of fields ('source route, issuer, cadence, lag, through-date, collected record count, sources and statistical floor') for one specific county. It clearly distinguishes from siblings by focusing on county coverage metadata versus statewide snapshots or permit records.
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 states 'Call this before interpreting a missing county result,' providing a clear trigger for when to use the tool. It does not explicitly name alternatives, but the usage context is specific and actionable enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_permit_recordGet a source-linked Georgia permit recordARetrieve one privacy-minimized collected building-permit record by PermitReporter record ID, including its canonical citation, official source link and collection timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds content details (citation, source link, timestamp) and the term 'privacy-minimized', but does not disclose additional behavioral traits like error handling, permissions, or what happens for missing IDs. It contributes modest context beyond the annotations.
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 is front-loaded with the verb 'Retrieve' and the resource, containing no filler or repetition. Every word 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?
For a single-parameter, read-only tool with an output schema and strong annotations, the description is adequately complete. It covers what the tool does and what the record includes. A minor gap is the lack of explicit mention of not-found behavior, but that is likely handled by the output schema. Overall it is sufficient for correct use.
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 0% schema description coverage, the description compensates partially by clarifying that record_id is the 'PermitReporter record ID', indicating it is an internal system identifier. However, it does not explain how to obtain the ID or its relationship to other entities, so the added semantic value is limited.
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 the action: 'Retrieve one privacy-minimized collected building-permit record by PermitReporter record ID', including the specific resource and identifier. The title 'Get a source-linked Georgia permit record' further distinguishes it from siblings like get_contractor_leads or search_georgia_permits.
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 when a known record ID is available ('by PermitReporter record ID'), but it does not explicitly state when to use this tool versus alternatives such as search or get_county_coverage. No exclusions or alternative tool recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statewide_snapshotGet the current Georgia permit-data snapshotAReturn current PermitReporter counts, route-status boundaries, record-date range and latest collection timestamp without returning personal data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds valuable context: it returns a 'current' snapshot and guarantees 'without returning personal data,' which is a meaningful privacy-relevant behavioral trait beyond the annotations.
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, well-structured sentence that front-loads the primary action ('Return current PermitReporter counts') and packs all necessary detail without 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?
Given the tool has no parameters, an output schema exists, and annotations cover safety, the description is complete for invocation. It clearly specifies what is returned (counts, boundaries, ranges, timestamp) and the privacy behavior (no personal data).
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 fully covers parameter space. Per rubric baseline, 0 params yields a score of 4; the description doesn't need to add parameter semantics.
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 a statewide snapshot with specific data elements (counts, route-status boundaries, record-date range, latest timestamp) and explicitly excludes personal data. This distinguishes it from sibling tools like get_permit_record and search, which likely return individual records.
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 aggregate, non-personal data needs via 'without returning personal data,' but it does not explicitly name alternative tools or provide when/when-not guidance. Sibling tools exist but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch Georgia permit sourcesASearch PermitReporter reviewed guidance and privacy-minimized collected building-permit records. Returns canonical URLs for citation. Call fetch with a returned ID for the full source.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A natural-language question about Georgia building permits or PermitReporter. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds context about the search corpus (reviewed, privacy-minimized) and the return of canonical URLs, plus the hand-off to fetch, which goes beyond the annotations without contradicting them.
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?
Three short, purposeful sentences: what the tool searches, what it returns, and the recommended next step. 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?
For a single-parameter, read-only search tool with an output schema and strong annotations, the description fully covers the invoke flow: search, receive canonical URLs, and call fetch for full sources. The only minor gap is not name-dropping the sibling search_georgia_permits, but the core usage is unambiguous.
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 documents the single query parameter with 100% coverage, describing it as a natural-language question about Georgia permits or PermitReporter. The description adds meaning by specifying the searched sources ('reviewed guidance and privacy-minimized... building-permit records') and the purpose of the query result, providing modest extra 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 uses the verb 'Search' with a specific resource: 'PermitReporter reviewed guidance and privacy-minimized collected building-permit records.' It also clarifies the output ('canonical URLs for citation') and the follow-up action ('Call fetch with a returned ID'), which distinguishes it from sibling search tools like search_georgia_permits.
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 clear context: search reviewed/collected records, get citation-ready URLs, then call fetch for the full source. However, it does not explicitly state when to avoid this tool or mention alternative siblings such as get_permit_record or search_georgia_permits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_georgia_permitsSearch collected Georgia building permitsASearch privacy-minimized collected building-permit records by public text, Georgia county, city, PermitReporter trade classification or record-date range. Returns no raw payloads or party arrays. An empty result means no matching record was collected, not that no permit exists.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No | ||
| query | No | ||
| trade | No | ||
| county | No | ||
| date_to | No | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/destructive behavior, so the description adds significant value by explicitly disclosing that no raw payloads or party arrays are returned and that an empty result means no collected record exists, not that no permit exists. This clarifies the tool's privacy-minimized nature and the open-world caveat beyond what annotations declare.
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 two sentences, front-loaded with the action and accessible filters, followed by two high-value caveats. There is no unnecessary repetition or filler; every clause adds meaningful information.
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 search tool with 7 optional parameters, an output schema, and rich annotations, this description covers the core searchable dimensions, key limitations, and an important empty-result interpretation. It does not discuss pagination or limit behavior, but the output schema and the tool's scope are sufficiently clear for an agent to select and invoke 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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does name the key filter dimensions (public text, county, city, trade, date range), mapping to query, county, city, trade, and date_from/date_to. However, it omits `limit` and does not explain parameter formats or combination semantics, so compensation is only partial.
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 precisely: 'Search privacy-minimized collected building-permit records by public text, Georgia county, city, PermitReporter trade classification or record-date range.' This clearly identifies the verb (search), the resource (collected building-permit records), and the available filters, distinguishing it from sibling tools like get_permit_record and generic search.
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 this tool (when searching collected permit records) and even hints at a limitation ('Returns no raw payloads or party arrays'), but it does not explicitly name alternatives or state when not to use it. For example, it does not mention that get_permit_record should be used to retrieve raw details, so the guidance is more implied than explicit.
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.
No comments yet. Be the first to start the discussion!