Permits Engine — Agent Market

web_policy_history

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Permits Engine — Agent Market tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0

Disambiguation2/5

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.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness3/5

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.

Resources

Need Help?