_ registry / mcp streamable-http · checked 3h ago

3gpp-spec-server

https://mcp.specproof.ai

Registry code: 268a0d7b0f7849a2

api record

SpecProof serves 3GPP, IETF and MPEG specification text indexed from the published documents.

Equations are preserved verbatim from the source specification and are delimited with $...$

endpoint
https://mcp.specproof.ai
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is 3gpp-spec-server live?
Yes — it answered the hub's last check (checked 3h ago). It answered 98% of checks over the last 30 days.
Is 3gpp-spec-server free to use?
Not anonymously — it asks for a key or a login before it will serve. Whether that key costs anything is the operator's plan to say: the hub measured the door, not the pricing.
What tools does 3gpp-spec-server have?
17 tools: get_spec_dependents, get_database_stats, build_cross_spec_suite, semantic_search, get_spec_references, get_document_content, search_specifications, get_most_referenced_specs, ….
Is 3gpp-spec-server safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
97.5%

90 days 98.5%· all time 98.6%

latency
863ms

last good check

priced tools
0

of 17 tools

_ answered our checks, 90 days 544 checks · signed record
  • degraded → live
  • live → degraded· timeout after 20000ms
  • degraded → live
  • live → degraded· timeout after 20000ms
  • degraded → live
_ what it is for
used for
  • search 3gpp and ietf specifications
  • list normative requirements of a spec
  • diff two spec versions
  • generate a conformance test
takes → gives
text → text, data, code
tools
17 reads
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 17 tools
17 auth-required 17 of 17 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • get_spec_dependents reads auth-required 10h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_spec_dependentsArguments",
      "required": [
        "spec_number"
      ],
      "properties": {
        "max_results": {
          "type": "integer",
          "title": "Max Results",
          "default": 50
        },
        "spec_number": {
          "type": "string",
          "title": "Spec Number"
        }
      }
    }
    arguments 18 lines
  • get_database_stats reads auth-required 45d ago

    Get comprehensive database and system statistics.

    mcp-tool

    {
      "type": "object",
      "title": "get_database_statsArguments",
      "properties": {}
    }
    arguments 5 lines
  • build_cross_spec_suite reads auth-required 18h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "build_cross_spec_suiteArguments",
      "required": [
        "spec_base",
        "keyword"
      ],
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 20
        },
        "keyword": {
          "type": "string",
          "title": "Keyword"
        },
        "spec_base": {
          "type": "string",
          "title": "Spec Base"
        },
        "include_references": {
          "type": "boolean",
          "title": "Include References",
          "default": true
        }
      }
    }
    arguments 28 lines
  • semantic_search reads auth-required 18h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "semantic_searchArguments",
      "required": [
        "query"
      ],
      "properties": {
        "query": {
          "type": "string",
          "title": "Query"
        },
        "index_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Index Type",
          "default": null
        },
        "max_results": {
          "type": "integer",
          "title": "Max Results",
          "default": 5
        },
        "similarity_threshold": {
          "type": "number",
          "title": "Similarity Threshold",
          "default": 0.3
        }
      }
    }
    arguments 35 lines
  • get_spec_references reads auth-required 3h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_spec_referencesArguments",
      "required": [
        "spec_number"
      ],
      "properties": {
        "spec_number": {
          "type": "string",
          "title": "Spec Number"
        },
        "reference_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Reference Type",
          "default": null
        }
      }
    }
    arguments 25 lines
  • get_document_content reads auth-required 3h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_document_contentArguments",
      "required": [
        "filename"
      ],
      "properties": {
        "section": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Section",
          "default": null
        },
        "filename": {
          "type": "string",
          "title": "Filename"
        },
        "page_range": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Page Range",
          "default": null
        }
      }
    }
    arguments 37 lines
  • search_specifications reads auth-required 21h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "search_specificationsArguments",
      "required": [
        "query"
      ],
      "properties": {
        "query": {
          "type": "string",
          "title": "Query"
        },
        "doc_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Doc Type",
          "default": null
        },
        "max_results": {
          "type": "integer",
          "title": "Max Results",
          "default": 10
        },
        "spec_number": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Spec Number",
          "default": null
        }
      }
    }
    arguments 42 lines
  • get_most_referenced_specs reads auth-required 14h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_most_referenced_specsArguments",
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 20
        },
        "series": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Series",
          "default": null
        },
        "doc_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Doc Type",
          "default": null
        }
      }
    }
    arguments 35 lines
  • get_spec_metadata reads auth-required 14h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_spec_metadataArguments",
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 50
        },
        "series": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Series",
          "default": null
        },
        "doc_class": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Doc Class",
          "default": null
        },
        "spec_number": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Spec Number",
          "default": null
        },
        "working_group": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Working Group",
          "default": null
        }
      }
    }
    arguments 59 lines
  • get_schema_definitions reads auth-required 7h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_schema_definitionsArguments",
      "properties": {
        "kind": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Kind",
          "default": null
        },
        "name": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Name",
          "default": null
        },
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 10
        },
        "spec_number": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Spec Number",
          "default": null
        }
      }
    }
    arguments 47 lines
  • get_series_overview reads auth-required 7h ago

    Get an overview of all specification series with document counts, reference statistics, and working group assignments.

    mcp-tool

    {
      "type": "object",
      "title": "get_series_overviewArguments",
      "properties": {}
    }
    arguments 5 lines
  • list_documents reads auth-required 14h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "list_documentsArguments",
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 20
        },
        "doc_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Doc Type",
          "default": null
        },
        "search_pattern": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Search Pattern",
          "default": null
        }
      }
    }
    arguments 35 lines
  • diff_spec_versions reads auth-required 18h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "diff_spec_versionsArguments",
      "required": [
        "spec_base"
      ],
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 25
        },
        "spec_base": {
          "type": "string",
          "title": "Spec Base"
        },
        "obligation": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Obligation",
          "default": null
        },
        "to_version": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "To Version",
          "default": null
        },
        "from_version": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "From Version",
          "default": null
        }
      }
    }
    arguments 54 lines
  • generate_tests reads auth-required 3h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "generate_testsArguments",
      "required": [
        "requirement_id"
      ],
      "properties": {
        "target": {
          "type": "string",
          "title": "Target",
          "default": "pytest"
        },
        "requirement_id": {
          "type": "integer",
          "title": "Requirement Id"
        }
      }
    }
    arguments 18 lines
  • get_relationship_graph reads auth-required 21h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_relationship_graphArguments",
      "required": [
        "spec_number"
      ],
      "properties": {
        "depth": {
          "type": "integer",
          "title": "Depth",
          "default": 1
        },
        "spec_number": {
          "type": "string",
          "title": "Spec Number"
        },
        "reference_type": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Reference Type",
          "default": null
        }
      }
    }
    arguments 30 lines
  • get_rfc_lineage reads auth-required 21h ago

    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"

    mcp-tool

    {
      "type": "object",
      "title": "get_rfc_lineageArguments",
      "required": [
        "rfc"
      ],
      "properties": {
        "rfc": {
          "type": "string",
          "title": "Rfc"
        }
      }
    }
    arguments 13 lines
  • get_requirements reads auth-required 7h ago

    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)

    mcp-tool

    {
      "type": "object",
      "title": "get_requirementsArguments",
      "properties": {
        "limit": {
          "type": "integer",
          "title": "Limit",
          "default": 30
        },
        "search": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Search",
          "default": null
        },
        "obligation": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Obligation",
          "default": null
        },
        "spec_number": {
          "anyOf": [
            {
              "type": "string"
            },
            {
              "type": "null"
            }
          ],
          "title": "Spec Number",
          "default": null
        }
      }
    }
    arguments 47 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id 268a0d7b0f7849a2.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/268a0d7b0f7849a2/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/268a0d7b0f7849a2/badge.svg)](https://brick.blue/agent/268a0d7b0f7849a2?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.