# SpecProof

> SpecProof: Search standards specs with MCP-ready precision.

- name: ai.specproof/specproof-mcp
- version: 1.0.0
- connection class: R0 (autonomous)
- trust: 85/100
- quality: 85/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/ai.specproof%2Fspecproof-mcp
- tools: https://api.protogrid.dev/v1/servers/ai.specproof%2Fspecproof-mcp/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "specproof-mcp": {
      "type": "http",
      "url": "https://mcp.specproof.ai/"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 100
- freshness: 45
- provenance: 85
- drivers: +repository +dns-namespace +website +reachable +uptime-100% -stale-261d
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 85/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 86 (weight 30)

- pass `tools.descriptions`: every tool has a description
- pass `tools.description_length`: descriptions are concise
- pass `tools.schemas`: every tool has an object input schema
- warn `tools.annotations`: only 11 of 17 tools declare readOnlyHint or destructiveHint
- warn `tools.directory_hints`: 11 of 17 tools declare all four hints; missing: get_spec_dependents (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_spec_metadata (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); get_spec_references (readOnlyHint, destructiveHint, idempotentHint, openWorldHint); …
- pass `tools.token_cost`: about 3,238 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 17, about 3,238 tokens to load them all
- tool set hash: 7aff5efef43a69cff1b7fa8017c357e2
- badge: [![protogrid quality](https://protogrid.dev/badge/ai.specproof/specproof-mcp.svg)](https://protogrid.dev/servers/ai.specproof/specproof-mcp)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Remotes

- https://mcp.specproof.ai/ (streamable-http, auth none, reachable true, uptime30d 1)

## Packages

_none_

## Tools (17)

- `build_cross_spec_suite`: Assemble the normative requirements for one procedure across a spec AND the specs it
    normatively references — a procedure like registration or handover is never described in a
    single document. Returns a cited suite plan; feed the requirement_ids to generate_tests.

    Args:
        spec_base: The anchor spec, e.g. "23502" or "38331"
        keyword: The procedure/topic, e.g. "registration", "handover", "authentication"
        include_references: Also pull matching clauses from specs this one references (default: True)
        limit: Max requirements in the plan (default: 20, max: 50)
    
- `diff_spec_versions`: Diff two versions of a specification at the NORMATIVE level: which requirements were
    added, removed, or reworded. Not a textual diff — a clause that merely moved page or was
    recased counts as unchanged.

    Args:
        spec_base: Spec identity without the version, e.g. "38331" or "23501"
        from_version: Older version label, e.g. "j20" (default: the second-newest in the corpus)
        to_version: Newer version label, e.g. "j30" (default: the newest in the corpus)
        obligation: Only report changes at this strength — "must", "must_not", "should", "should_not", "may"
        limit: Max requirements to list per bucket (default: 25)
    
- `generate_tests`: Generate a cited, runnable conformance test that verifies one normative requirement.

    The test is grounded in the requirement sentence plus its surrounding clause from the
    corpus, and every test cites the spec, section and page it enforces. If the requirement
    is not testable (boilerplate, scope text), the generator abstains rather than inventing
    a test.

    Args:
        requirement_id: The requirement's id, as shown by get_requirements
        target: "pytest" for a runnable Python test module, or "gherkin" for a reviewable
                .feature file (default: pytest)
    
- `get_database_stats`: Get comprehensive database and system statistics.
- `get_document_content`: Get specific content from a specification document.
    
    Args:
        filename: Document filename (required)
        page_range: Page range like "10-15" or single page "20" (optional)
        section: Section title filter (optional)
    
- `get_most_referenced_specs`: Get the most referenced (most important) specifications ranked by incoming reference count.

        Args:
            doc_type: Filter by "3gpp" or "ietf"
            series: Filter by series number
            limit: Maximum results (default: 20)
        
- `get_relationship_graph`: Get a relationship graph centered on a specification, expanding N hops.

        Returns JSON with nodes and edges suitable for graph visualization.
        Each node includes title, series, working group, and reference counts.
        Each edge includes source, target, reference type, and count.

        Args:
            spec_number: Center specification number
            depth: Number of hops to expand (1-3, default: 1)
            reference_type: Filter by type - "normative", "informative" (optional)
        
- `get_requirements`: List normative requirements (RFC 2119 / BCP 14 "shall/should/may" statements)
    extracted from specifications, each cited back to its source clause.

    Args:
        spec_number: Filter by spec number, e.g. "23.501" or "RFC 9110" (optional)
        obligation: Filter by strength - "must", "must_not", "should", "should_not", or "may" (optional)
        search: Keyword to search within the requirement text (optional)
        limit: Maximum number of requirements to return (default: 30, max: 100)
    
- `get_rfc_lineage`: An RFC's revision history. RFCs are immutable — an RFC is never revised, it is obsoleted
    or updated by a *different* RFC — so this Obsoletes/Updates graph, not a version diff, IS
    its change history. Use it to find out whether an RFC you depend on has been superseded.

    Args:
        rfc: The RFC, e.g. "7231", "rfc7231" or "RFC 7231"
    
- `get_schema_definitions`: Look up formal, machine-checkable structure defined in the specifications: ASN.1 types
    (3GPP RRC/NAS message grammars) and JSON Schema / OpenAPI models (5G Service Based
    Interfaces).

    Prefer this over prose search when the question is about a message's *structure* — field
    names, types, ranges, optionality. The definition is returned verbatim from the spec, so
    it is exact rather than recalled.

    Args:
        name: Type or schema name, e.g. "RRCSetup", "MeasConfig", "SmContextCreateData"
        spec_number: Restrict to a spec, e.g. "38.331"
        kind: "asn1", "openapi" or "json_schema"
        limit: Maximum definitions to return (default: 10, max: 25)
    
- `get_series_overview`: Get an overview of all specification series with document counts, reference statistics, and working group assignments.
- `get_spec_dependents`: Get all specifications that reference a given spec (reverse lookup).

        Args:
            spec_number: Specification number to find dependents of
            max_results: Maximum results (default: 50)
        
- `get_spec_metadata`: Get enriched metadata for specifications with filtering.

        Args:
            spec_number: Filter by spec number (partial match)
            series: Filter by series (e.g., "26" for 26.xxx codecs)
            working_group: Filter by working group (e.g., "SA4")
            doc_class: Filter by document class - "TS" or "TR"
            limit: Maximum results (default: 50)
        
- `get_spec_references`: Get all specifications referenced by a given spec.

        Args:
            spec_number: Specification number (e.g., "23.501", "26.230")
            reference_type: Filter by type - "normative", "informative", "inline" (optional)
        
- `list_documents`: List available specification documents.
    
    Args:
        doc_type: Filter by document type - "3gpp", "ietf", or "mpeg" (optional)
        search_pattern: Search pattern for spec number or title (optional)
        limit: Maximum number of results (default: 20, max: 100)
    
- `search_specifications`: Search across 3GPP, IETF, and Multimedia specification documents using full-text search.

    Args:
        query: Search query terms (required)
        doc_type: Filter by document type - "3gpp", "ietf", or "mpeg" (optional)
        spec_number: Filter by specification number (optional) 
        max_results: Maximum number of results to return (default: 10, max: 50)
    
- `semantic_search`: Perform semantic search using vector embeddings with FAISS acceleration.
    
    Args:
        query: Natural language search query (required)
        max_results: Maximum number of results to return (default: 5, max: 20)
        similarity_threshold: Minimum similarity threshold 0.0-1.0 (default: 0.3)
        index_type: FAISS index type - "hnsw", "ivf", or "flat" (optional, auto-selected)