Free MCP tools: permit quotes, jurisdiction index, track record, attestation.
What this house can attest about another agent: ERC-8004 registry events + liveness probes (sealed on-chain census), collected public incident candidates, sealed first-report sea protests, and aggregate first-party x402 payment observations for a payer wallet. Text/identifier matching — not verified identity, not a reputation score. Sources degrade individually and honestly.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional chain filter for the ERC-8004 registry source (e.g. 'base', 'optimism'). Case-insensitive exact match. | |
| limit | No | Max matches per source (1-100, default 20). | |
| query | Yes | Agent identifier to look up: a name, an agent-URI substring, or a 0x wallet address (an address also unlocks first-party payment observations). | |
| agent_id | No | Optional exact ERC-8004 agent id (registry token id). Overrides text matching for the registry source; combine with chain to disambiguate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses important limitations: data is text/identifier matched, not verified identity or reputation, and sources 'degrade individually and honestly.' It also lists the source categories transparently, though it does not state whether the operation is read-only or describe any authentication or rate-limit 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 compact and front-loaded, covering the main purpose in the first sentence and then adding important limitations without excess fluff. The phrase 'sealed first-report sea protests' is somewhat jargon-heavy, but overall each sentence contributes useful 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?
The description lists multiple data sources and limitations, which is helpful, but there is no output schema and no return-shape explanation. An agent may still be uncertain how the results are structured, how sources are represented, or how matching behaves across the different source types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter semantics are already well documented in the schema. The description adds context about matching behavior and source degradation, but it does not provide additional parameter-level detail beyond what the schema already states for query, chain, limit, and agent_id.
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 names a specific action (attestation about another agent) and enumerates the concrete data sources involved: ERC-8004 registry events, liveness probes, incident candidates, sealed first-report sea protests, and x402 payment observations. It also explicitly distinguishes itself from verified identity and reputation scoring, which helps separate it from sibling tools like verified_track_record or seal_lookup.
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 on what the tool is for and what it is not for, stating 'Text/identifier matching — not verified identity, not a reputation score.' It implies this is for attestation-style lookups rather than verified identity or reputation tasks, but it does not name specific sibling tools or provide explicit when-to-use/when-not-to-use routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ERC-8004 agent-census stats — per-chain registration counts, distinct agents, and URI-scheme mix from the latest sealed on-chain sample, with the run's batch-sha256 attestation and honest per-run chain coverage. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Optional chain filter (e.g. 'polygon', 'base'). Case-insensitive exact match; a chain absent from the latest sealed day returns count=0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and discloses meaningful behavior: the data comes from the 'latest sealed on-chain sample,' the result includes batch-sha256 attestation and 'honest per-run chain coverage,' and the output is an Ed25519-signed receipt. It could additionally state read-only/side-effect or authentication implications, but the key behavioral traits are well covered.
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 dense, front-loaded sentence that opens with the resource identity and then lists the metrics, attestation, coverage, and receipt format in order. There is no filler or repetition; every clause contributes useful 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?
Because there is no output schema, the description reasonably compensates by enumerating the main response contents: per-chain counts, distinct agents, URI-scheme mix, attestation, coverage, and signed receipt. The remaining gap is that 'honest per-run chain coverage' and the receipt's exact structure are not elaborated, which would be more important if the tool were more complex.
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 input schema already documents the optional chain filter, case-insensitive exact matching, and the count=0 behavior for absent chains. The tool description only adds the contextual 'per-chain' framing, so it provides little semantic value beyond the schema; the 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 names a specific deliverable ('ERC-8004 agent-census stats') and enumerates exact metrics: per-chain registration counts, distinct agents, URI-scheme mix, batch-sha256 attestation, chain coverage, and an Ed25519-signed receipt. This makes it easy for an agent to distinguish this tool from sibling tools like agent_attestation without opening schemas.
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 for when to use the tool: it serves census/statistics requests over the latest sealed on-chain sample and supports an optional chain filter. It does not explicitly name alternatives or provide when-not-to-use guidance, so it stops short of full routing, but the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agentic-commerce adoption snapshot — per-merchant presence of the agent-checkout discovery surfaces (ucp, llms.txt, agent cards, MCP documents) across a fixed ~276-merchant panel on the latest sealed day, with the run's batch-sha256 attestation. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Optional merchant domain — returns that merchant's per-surface rows instead of the panel-wide tally. A domain outside the panel returns count=0. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral traits: the return of an Ed25519-signed receipt and inclusion of the run's batch-sha256 attestation. The word 'snapshot' also implies a read-only, non-mutating operation, though this is not stated explicitly.
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 core purpose and packs in specifics without waste. Every clause contributes meaningful detail: panel size, surfaces covered, time scope, attestation, and receipt. This is an example of concise, efficient specification.
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 key context: the fixed panel, the specific surfaces, the latest sealed day, the attestation, and the signed receipt. With no output schema, it could more explicitly describe the response payload structure beyond 'receipt', but for a one-optional-parameter tool with full schema coverage, it is largely complete.
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 description does not mention the domain parameter at all, but the input schema's description covers it fully (100% coverage), explaining the filtering behavior and out-of-panel count=0. Since the schema already provides complete semantics, the description adds no extra parameter-level value, 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 as an adoption snapshot for agent-checkout discovery surfaces across a fixed 276-merchant panel, naming specific surfaces (ucp, llms.txt, agent cards, MCP documents). It does not explicitly differentiate from sibling tools like agent_census_stats or agent_attestation, so it lacks the explicit sibling distinction needed for a 5.
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 an agentic-commerce adoption snapshot is needed) but provides no explicit guidance on when not to use it or which sibling tools to prefer. The schema documents the optional domain filter, but the description itself does not discuss usage conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Operator-level Datacenter Buildout Activity Index — index headline, state counts, and per-operator assessable/active tallies from the latest sealed issue, with a content-sha256 attestation. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden, and it adds meaningful behavioral details: it returns a content-sha256 attestation and an Ed25519-signed receipt, implying a read-only, integrity-protected response. It does not explicitly mention auth, side effects, or failure modes, but the zero-parameter read-shaped operation makes those less critical.
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 dense passage with no filler; each listed output element earns its place. It is slightly awkward with 'Index — index headline' repeating the word 'index,' but it remains compact and front-loaded with the resource name.
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 zero parameters and no output schema, the description does a good job enumerating the return values: index headline, state counts, per-operator tallies, attestation, and signed receipt. It leaves domain-specific terms ('sealed issue', 'assessable/active') undefined, but a zero-input tool at this complexity is adequately specified.
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 is empty, so there are no parameters to explain; the schema coverage is trivially 100%. The description appropriately focuses on the output rather than inputs.
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 starts with a specific resource ('Operator-level Datacenter Buildout Activity Index') and lists its exact contents: headline, state counts, per-operator assessable/active tallies from the latest sealed issue, plus attestation and a signed receipt. The 'Returns an Ed25519-signed receipt' sentence makes the action and output clear. The 'operator-level' scope distinguishes it from sibling tools like datacenter_site_changes.
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 intended use is implied by the resource name and contents: call this when you need an operator-level breakdown of datacenter buildout activity from the latest sealed issue. However, the description never names alternatives or states when not to use it, so the agent must infer the boundary from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-site Datacenter Buildout Activity Index — observed ground-activity state (Sentinel-2 bare-soil/earthworks change) for each publicly-announced datacenter site, with a content-sha256 attestation. The per-site granularity the free public page omits. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Optional activity-state filter (the per-site `state` field, e.g. 'active_earthworks', 'stable_no_change', 'insufficient_data'). Lowercase exact value. | |
| operator | No | Optional operator substring filter (case-insensitive). | |
| min_confidence | No | Optional floor on per-site confidence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden and does a solid job: it describes the observation source, per-site scope, content-sha256 attestation, and Ed25519-signed receipt. It does not mention auth, rate limits, or pagination, but the core behavior and output integrity mechanism are disclosed.
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 compact and well-structured: a lead phrase establishes the resource, the second sentence explains differentiation from the public page, and the final sentence states the return format. Every sentence adds distinct value 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 no output schema, the description reasonably conveys what the tool returns and its integrity guarantees. The three optional filter parameters are fully documented in the schema, so the remaining gap is mainly the absence of an explicit response shape or pagination details, which is a minor omission for an index-style 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?
Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description adds no additional parameter meaning, which matches the baseline of 3 since the schema handles the semantic load.
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 a per-site datacenter buildout activity index, naming the observed data source (Sentinel-2 bare-soil/earthworks change), the scope (each publicly-announced datacenter site), and the output (signed receipt). It also differentiates from siblings by highlighting the per-site granularity that the free public page omits.
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?
Usage context is implied: this tool is for per-site granularity not available on the free public page. However, it does not explicitly state when to choose this tool over related siblings like datacenter_operator_breakdown or permit_lookup, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-incident enclosure evidence pack — one domain's observed policy-surface change (robots.txt / ai.txt / llms.txt / TDM-Rep) as a self-contained bundle: before/after observations, the stored response bodies re-hashed at read time, and the per-day custody record (rows in store vs rows batch-committed, gaps disclosed). Sealed-run attestation. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain whose policy-surface change to document (lowercased, e.g. 'flickr.com'). | |
| resource | No | Policy surface (default 'robots'). | robots |
| event_date | No | Optional change-event date (YYYY-MM-DD) to select a specific incident; default = the most recent change. A date with no change event returns incident_found=false. | |
| include_bodies | No | Include the stored before/after response bodies, re-hashed at read time (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals meaningful traits: response bodies are re-hashed at read time, the custody record exposes gaps between rows stored and rows batch-committed, and the result is a signed Ed25519 receipt. This goes beyond a simple 'returns an evidence pack' statement.
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 dense but well-organized: main purpose first, then contents, then attestation and receipt. Each clause adds relevant information. The second sentence is a fragment, but it still conveys a distinct behavioral guarantee.
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?
There is no output schema, so the description should explain the return value more fully. It mentions a signed receipt and bundle contents, but does not describe the receipt structure, the incident_found=false behavior, or how the custody record is presented. For a complex 4-parameter tool, this leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description relates to domain and resource by naming policy-surface types, but it adds no parameter-specific detail beyond what the schema already documents for event_date or include_bodies.
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 output—a per-incident evidence pack about a single domain's policy-surface change—and enumerates the included resources (robots.txt, ai.txt, llms.txt, TDM-Rep). It distinguishes this from likely siblings like web_policy_history by emphasizing 'per-incident' and 'self-contained bundle', though it lacks a direct action verb like 'retrieve' or 'generate'.
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 conveys what the tool returns but does not state when to use it versus alternatives such as web_policy_history. There is no explicit when-to-use or when-not-to-use guidance, and sibling tools are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AZ jurisdictions with permit data available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does show the boundary of the operation: it lists all such jurisdictions and filters by availability of permit data. It does not mention pagination, ordering, or auth, but those are minor for a zero-parameter read-only list.
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 one efficient sentence, front-loaded with the action and resource, and contains no filler or repeated information from the tool name.
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, zero-input listing tool, the description is fully sufficient: it identifies the geographic scope, the inclusion criterion, and the operation. No output schema exists, but the description adequately conveys the high-level return content.
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 zero parameters and 100% schema description coverage (empty schema), so the description does not need to document inputs. The 0-parameter baseline of 4 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 states a specific action ('List') and a specific resource ('all AZ jurisdictions with permit data available'). It clearly differentiates this from the sibling permit-lookup tools by focusing on jurisdictions rather than individual 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 usage context is implied: it should be used when an enumeration of Arizona jurisdictions with permit data is needed. However, it does not explicitly state when not to use it or mention any alternative tools, leaving referral decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up permit fees, turnaround, required docs for a jurisdiction.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | Yes | Slug like 'phoenix' or 'gilbert'. Use jurisdiction_index to enumerate. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. 'Look up' clearly signals a read-only operation, but the description adds no detail about edge cases (e.g., invalid slug), response shape, or any limitations. It is sufficient for a simple lookup but not rich in 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, front-loaded sentence that names the action and the specific data categories. It contains no filler and earns 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?
For a one-parameter lookup with a well-described schema, the description covers the core purpose and data items. It does not mention output format or behavior for unknown jurisdictions, but the schema's jurisdiction_index reference mitigates the main ambiguity, making it nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the jurisdiction property already explains the slug format and points to jurisdiction_index. The tool description adds no new parameter semantics, so 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 a specific verb ('look up') and resource ('permit fees, turnaround, required docs') scoped to a jurisdiction. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like search_permits, so it misses the top score.
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: when you need permit information for a specific jurisdiction. However, it gives no explicit guidance on when to prefer this tool over alternatives like search_permits or rebate_eligibility_check, and the only usage hint in the schema (use jurisdiction_index) is a prerequisite, not a comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find rebate programs and eligible measures for an AZ service area.
| Name | Required | Description | Default |
|---|---|---|---|
| measure | No | Optional measure filter: 'HVAC', 'Heat Pump', 'Solar', etc. | |
| jurisdiction | Yes | AZ jurisdiction slug. Used to filter to programs serving that area. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. The verb 'Find' clearly implies a read-only lookup, but the description does not disclose return format, error behavior, or authorization needs. This is adequate for a simple search tool but not richly transparent.
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?
A single, front-loaded sentence that states exactly what the tool does with no filler or repetition. Every word earns 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?
For a two-parameter lookup with fully documented schema fields, the description plus schema is sufficient for correct invocation. The lack of an output schema means return values are not formally specified, but the description's mention of 'rebate programs and eligible measures' conveys the expected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters. The description does not add parameter-level detail beyond naming the eligible-measures filter concept, meeting the baseline but not exceeding it.
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 'Find' with the resource 'rebate programs and eligible measures' and scopes it to 'AZ service area', making the tool's purpose immediately clear. No sibling tool targets rebates, so there is no confusion among the listed 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 phrase 'for an AZ service area' gives clear context for when the tool applies, and no rebate-related alternative exists among the siblings to exclude. It does not explicitly state when not to use it, but for a focused lookup tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store one consent-bound, agent-attributed quote request for a canonical US Tech Automations offer priced at $200 or more. A human reviews it; no message, charge, checkout, contract, or work start occurs automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| sku | Yes | Canonical US Tech Automations offer SKU priced at $200 or more. | |
| name | No | ||
| Yes | Reply address for the consenting human. Stored privately; never returned. | ||
| scope | Yes | Coarse business scope only. No URLs, credentials, code, files, or private, customer, personal, medical, or regulated data. | |
| company | No | ||
| agent_name | Yes | Agent product or runtime name for source attribution. | |
| agent_version | No | ||
| idempotency_key | Yes | Opaque non-PII retry key, such as a UUID. The server stores only its SHA-256. | |
| human_authorized | Yes | True only when the named human authorized this agent to file this scope. | |
| transactional_email_consent | Yes | True only when that human consents to a human reply about this quote request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It clearly states the core side-effect boundary: only a stored record, human review, and no automatic messaging, charging, checkout, contract, or work start. It also highlights consent and agent-attribution requirements. It does not mention persistence semantics, idempotency behavior, or error/response behavior, but the safety-relevant aspects are well covered.
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 deliver the purpose, constraints, and behavioral guardrails without filler. The action and primary qualifiers are front-loaded, and every clause earns its place. The structure is tight and immediately scannable for an agent.
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 10-parameter tool with no output schema and no annotations, the description is reasonably complete on purpose and safety boundaries. However, it lacks guidance on what the agent will receive in response, how retries interact with the idempotency key, and how to shape the scope string. It also does not position itself relative to sibling tools, though the distinct vocabulary ('quote request') compensates somewhat.
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 70%, with several parameters already having descriptions. The description adds the $200+ pricing threshold that relates to the sku enum and the 'consent-bound' and 'agent-attributed' concepts tie to human_authorized and agent_name. However, it does not elaborate on idempotency_key, scope formatting, or the boolean consent flags beyond what the schema already states. This is adequate for the moderate 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 states a specific verb ('Store'), a distinct resource ('quote request'), and key constraints (consent-bound, agent-attributed, canonical US Tech Automations offer priced at $200 or more). The second sentence further disambiguates it from execution or commerce tools by stating that no automatic message, charge, checkout, contract, or work start occurs, clearly separating it from potential 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 clearly conveys when to use this tool: when a consenting human has authorized an agent to file a quote request for an eligible offer. It also sets expectations that a human will review the request and that no automatic fulfillment will happen. It does not name specific sibling tools or enumerate explicit exclusions, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether a SHA-256 (or artifact filename) was sealed into this house's OTS/Bitcoin-anchored priority manifest, and when. Proof-of-priority lookup at the cheapest possible price so an agent can exercise the paid rail end-to-end. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| sha256 | No | 64-hex-char SHA-256 to look up. Matches either the sealed artifact's content_sha256 or its sha256_file. A hash not in the manifest returns found=false. | |
| artifact | No | Artifact filename (case-insensitive exact match, e.g. 'dcbi_2026-06-22.json'). Provide this or sha256, never both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does add useful behavior: it accepts SHA-256 or artifact filename, verifies sealing, and returns an Ed25519-signed receipt. However, it does not disclose whether the operation is read-only, whether it incurs a cost, what failure modes exist, or what exactly the receipt contains.
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 compact at three sentences, and the purpose is front-loaded in the first sentence. The second sentence adds usage motivation but is slightly tangential; still, it earns its place by clarifying cost positioning.
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 is adequate for a simple lookup: it explains what is verified, the input variants, and the signed receipt return. However, with no output schema and no annotations, it omits details like receipt contents, error behavior, cost amount, and any authentication or read-only expectations, so an agent might not have full confidence in the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only a high-level mention of SHA-256 or artifact filename, while the schema already thoroughly documents both parameters, their formats, and the found=false behavior.
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?
States a specific verb ('Verify') and resource ('OTS/Bitcoin-anchored priority manifest'), and clarifies it returns the time it was sealed. This clearly differentiates it from the sibling lookup tools, which target different domains like permits or contractors.
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 concrete usage context: this is the cheapest proof-of-priority lookup for exercising the paid rail end-to-end. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FTS5 search across the permit corpus (jurisdictions, rebates, templates).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | FTS5 query across jurisdictions, rebates, templates. | |
| record_type | No | Optional filter to a single record type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that this is an FTS5 search, which implies full-text matching semantics and a read-only nature, and it scopes the corpus to three record types. It does not mention return shape, ordering, or any caveats, but for a search tool the core behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the verb, scope, and the exact record types covered in minimal characters.
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 simple schema and absence of output schema, the description is sufficient for a basic invocation but omits useful context such as expected return values, FTS5 syntax nuances, and guidance relative to sibling tools. It is functional but minimal.
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 67%: query and record_type are documented in the schema, while limit is not. The description adds only the phrase 'permit corpus' and the three record types, which largely echoes the schema. No extra parameter-level guidance is provided.
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 action ('FTS5 search') and the resource ('permit corpus') with explicit record categories: jurisdictions, rebates, templates. However, it does not differentiate itself from sibling tools like permit_lookup or jurisdiction_index, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when performing full-text search across permit-related records, but it provides no explicit guidance about when not to use it or which sibling tools might be better for specific lookups. The use case is inferable, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
This house's verified prediction track record — per-loop calibration scores (Brier, ECE, MCE, ROC-AUC, coverage, base rate) computed monthly from sealed prediction snapshots against observed public outcomes, with a reproducible content-sha256 seal. Bad numbers are published alongside good ones. Free: verify the record before buying any paid feed.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | Optional loop-name filter (e.g. 'permits:psir_prob'). Case-insensitive exact match; an unknown loop returns count=0. | |
| include_reliability | No | Include each loop's per-bin reliability curve (mean predicted vs mean observed per probability bin). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the computation cadence (monthly), the data source (sealed prediction snapshots against observed public outcomes), the reproducibility mechanism (content-sha256 seal), and the honesty policy ('bad numbers are published alongside good ones'). It does not explicitly state read-only behavior, but nothing suggests mutation and the described function is clearly a read-style accessor.
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 sentences, each earning its place: the first defines the resource and contents, the second adds transparency, the third gives a call-to-action use case. The description is front-loaded with the core identity and wastes no 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 tool has no required parameters and no output schema, but the description covers what the record contains, how it is computed, how it is sealed, and why to use it. The input schema covers the optional filter and reliability-curve flag. Minor gaps like the exact response envelope are not critical for this low-complexity read 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?
Schema description coverage is 100%, so both parameters already have adequate inline documentation. The description's mention of 'per-loop calibration scores' slightly reinforces the loop parameter, but it adds no new parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource — the house's verified prediction track record — and enumerates its content (per-loop calibration scores: Brier, ECE, MCE, ROC-AUC, coverage, base rate). It lacks an explicit verb like 'get' or 'list', and does not differentiate from sibling tools such as seal_lookup, but the resource is unambiguous.
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 a clear use context: verify the record before buying any paid feed. It does not explicitly contrast this tool with siblings or state when not to use it, but the 'Free: verify the record before buying any paid feed' line gives actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a contractor license and (optionally) cross-reference jurisdiction permit context. Returns an Ed25519-signed receipt the agent can store as proof of verification.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | Optional jurisdiction slug — if given, the response includes the jurisdiction's permit context so an agent doesn't need a second paid call to find fees / required documents. | |
| license_number | Yes | Contractor license number (e.g. 'ROC123456'). Spaces stripped; matched case-insensitively. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral disclosure burden. It usefully discloses that the result is an Ed25519-signed receipt suitable for storage as proof. However, it does not mention failure behavior, permissions, cost, or whether the operation is purely read-only, leaving notable transparency gaps.
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 focused sentences: the first states the core action and optional capability, the second states the return format and practical value. Every sentence earns its place and the key behavior is 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?
With no output schema, the description appropriately tells the agent what to expect (a signed receipt) and why it matters (storable proof). It omits failure handling and explicit routing to alternatives, but for a two-parameter tool the core call path is adequately explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both license_number and jurisdiction already well documented including normalization, pattern, and the cost-saving benefit of jurisdiction. The description reinforces jurisdiction's purpose but adds no information beyond the schema, so the 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 states a concrete action ('Verify a contractor license') and an optional capability (cross-reference jurisdiction permit context), and makes the tool's identity distinct from sibling lookup tools by emphasizing verification and a signed receipt. Even without naming a sibling, an agent can tell this is for license verification rather than permit search or census stats.
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 for when the optional jurisdiction parameter adds value: it includes permit context and avoids a second paid call. It does not explicitly name alternatives or state when not to use this tool, but the optional/combined behavior is a useful, concrete usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-domain agent-access policy history — exact-date sealed declarations for robots.txt / ai.txt / llms.txt / TDM-Rep, with row, retained-body and collection-membership verification. A pre-coverage date returns NOT-HELD without inference. The existing timeline view remains available when no date is given. Returns an Ed25519-signed receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional exact capture date. The response is HELD only for rows sealed on this date; pre-coverage and missing dates return NOT-HELD without carrying another value. | |
| limit | No | Max snapshot rows returned (newest first). | |
| domain | Yes | Registrable domain to look up (e.g. 'openai.com'). Lowercased; must be in the sealed Tranco top-100k universe to have history (a miss returns count=0). | |
| resource | No | Optional filter to one policy surface. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It states that rows are exact-date sealed declarations, that verification includes row/retained-body/collection-membership, that pre-coverage dates return NOT-HELD without inference, and that the response is an Ed25519-signed receipt. This is unusually transparent.
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 sentences with no filler. The core purpose is front-loaded, and each subsequent sentence adds a distinct behavioral detail (exact-date verification, NOT-HELD handling, timeline fallback, signed receipt). Every clause earns 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?
For a lookup/retrieval tool with no output schema and no annotations, the description covers the key behaviors an agent needs to know: what is returned, edge-case behavior for dates, fallback behavior without a date, and cryptographic signing. Combined with the rich schema, nothing essential is missing.
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 describes all 4 parameters with 100% coverage, so the baseline is 3. The description reinforces the date behavior (NOT-HELD for pre-coverage) but does not add meaning beyond what the schema's own parameter descriptions already state, so no score above baseline is warranted.
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 opens with 'Per-domain agent-access policy history', clearly naming the resource (policy history) and scope (per-domain). It enumerates the policy surfaces (robots.txt / ai.txt / llms.txt / TDM-Rep) and adds verification/receipt specifics, making it distinct from siblings like seal_lookup or verified_track_record.
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 usage context: exact-date lookups with NOT-HELD handling for pre-coverage dates, and notes that omitting the date preserves the timeline view. It does not explicitly compare to sibling tools, but the behavioral guidance is sufficient for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
request_quote1 field changedInput schema / properties / sku / enumPrevious value: -[
- "agent-continuity-record",
- "agent-fleet-truth-probe-review",
- "agent-job-output-review",
- "agent-venture-change-ledger",
- "agentic-commerce-census",
- "ai-answer-repeatability-report",
- "ai-crawler-configuration-review",
- "ai-promise-change-record",
- "arizona-contractor-roster-receipt",
- "brand-choice-evidence",
- "citation-repair-sprint",
- "cited-question-answer",
- "contextual-offer-bridge",
- "copper-retirement-scope",
- "copyright-records-search",
- "dataset-endpoint-refresh-pack",
- "dataset-hygiene-observation-report",
- "erc8004-endpoint-observation-pack",
- "erc8004-liveness-report",
- "excel-powerbi-cleanup-pilot",
- "federal-source-research-brief",
- "flood-map-change-research-pack",
- "geo-content-retrofit-pilot",
- "github-actions-document-extraction-feasibility",
- "hubspot-crm-hygiene-qa-pilot",
- "jetbrains-data-file-inspector-pilot",
- "lead-service-line-inventory-record",
- "mcp-api-launch-pack",
- "npdes-portfolio-field-normalization",
- "nyc-building-record-brief",
- "openpermitfees-commissioned-jurisdiction",
- "permits-close-file",
- "permits-market-report",
- "product-catalog-structured-data-pack",
- "proof-backed-data-page-pilot",
- "public-page-capture-receipt",
- "quake-record-attestation",
- "recall-search-certificate",
- "robots-policy-change-record",
- "salesforce-record-hygiene-pilot",
- "schema-text-extraction-api",
- "sealed-pricing-change-report",
- "sec-8k-change-watch",
- "seo-software-migration-sprint",
- "sponsored-benchmark-brief",
- "sponsored-content-rate-brief",
- "streamgage-observation-record",
- "tariff-version-comparison",
- "tax-exempt-public-record-workpaper",
- "terminal-change-ledger",
- "trademark-register-search",
- "ttb-permit-ledger",
- "vendor-page-hash-change-record",
- "washington-contractor-observation-pack"
-]New value: +[
+ "agent-continuity-record",
+ "agent-fleet-truth-probe-review",
+ "agent-job-output-review",
+ "agent-venture-change-ledger",
+ "ai-answer-repeatability-report",
+ "ai-crawler-configuration-review",
+ "ai-promise-change-record",
+ "arizona-contractor-roster-receipt",
+ "brand-choice-evidence",
+ "citation-repair-sprint",
+ "cited-question-answer",
+ "contextual-offer-bridge",
+ "copper-retirement-scope",
+ "copyright-records-search",
+ "dataset-endpoint-refresh-pack",
+ "dataset-hygiene-observation-report",
+ "erc8004-endpoint-observation-pack",
+ "erc8004-liveness-report",
+ "excel-powerbi-cleanup-pilot",
+ "federal-source-research-brief",
+ "flood-map-change-research-pack",
+ "geo-content-retrofit-pilot",
+ "github-actions-document-extraction-feasibility",
+ "hubspot-crm-hygiene-qa-pilot",
+ "jetbrains-data-file-inspector-pilot",
+ "lead-service-line-inventory-record",
+ "mcp-api-launch-pack",
+ "npdes-portfolio-field-normalization",
+ "nyc-building-record-brief",
+ "openpermitfees-commissioned-jurisdiction",
+ "permits-close-file",
+ "permits-market-report",
+ "product-catalog-structured-data-pack",
+ "proof-backed-data-page-pilot",
+ "public-page-capture-receipt",
+ "quake-record-attestation",
+ "recall-search-certificate",
+ "robots-policy-change-record",
+ "salesforce-record-hygiene-pilot",
+ "schema-text-extraction-api",
+ "sealed-pricing-change-report",
+ "sec-8k-change-watch",
+ "seo-software-migration-sprint",
+ "sponsored-benchmark-brief",
+ "sponsored-content-rate-brief",
+ "streamgage-observation-record",
+ "tariff-version-comparison",
+ "tax-exempt-public-record-workpaper",
+ "terminal-change-ledger",
+ "trademark-register-search",
+ "vendor-page-hash-change-record",
+ "washington-contractor-observation-pack"
+]agent_attestationagent_census_statsagentic_commerce_adoptiondatacenter_operator_breakdowndatacenter_site_changesenclosure_evidence_packjurisdiction_indexpermit_lookuprebate_eligibility_checkrequest_quoteseal_lookupsearch_permitsverified_track_recordverify_contractor_licenseweb_policy_historyClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Free MCP tools: the only MCP linter, health checks, cost estimation, and trust evaluation.
Built-environment forecasts, public benchmarks, and permit or zoning readiness through remote MCP.
23 MCP tools: compliance, verification, messaging, booking, US contracts. 15 need no key.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
Add one secure layer between your agents and this server.
Several tool pairs overlap heavily: permit_lookup, search_permits, and jurisdiction_index all address permit discovery, while web_policy_history and enclosure_evidence_pack both track the same robots.txt/ai.txt/llms.txt/TDM-Rep policy surface. Agents would need to read very long descriptions carefully to avoid selecting the wrong tool.
All names are snake_case but the pattern is mixed: most are noun phrases like agent_census_stats and web_policy_history, while request_quote, search_permits, and verify_contractor_license use verb-first naming. The names are readable but do not follow one consistent convention.
Fifteen tools is at the high end of a reasonable scope, and the set spans permits, datacenter indices, agent attestations, web policy history, and quote requests. The count is not absurd, but it feels like several different products bundled into one server.
The permit lookup/search/rebate/contractor side is reasonably covered for read-only queries, and there is useful verification and attestation tooling. However, the 'Agent Market' side has no way to browse or complete a purchase beyond one request_quote action, and some data products like datacenter and agentic commerce feel disconnected from the core permits domain.
