Which integrations are available for this server?

Exposes Prometheus-compatible metrics for monitoring probe results, including verdict counts, latency percentiles, and freshness scores. Uses YAML for defining 'freshness-as-code' policies, allowing users to configure domain-specific thresholds for staleness, latency, and TLS health.

freshprobe

by Sudhan30

Overview Schema Source Related Servers Discussions Admin

Hybrid

"I asked my agent to check flight prices. It gave me options. I booked one. The fare had changed 3 hours ago."

AI agents routinely act on stale data without knowing it. A financial agent queries cached quotes from 47 minutes ago. A support bot tells a customer their order doesn't exist because the CRM hasn't synced. An RAG pipeline confidently answers with yesterday's docs.

freshprobe sits between your agent and the external world. Before the agent acts, it asks: is this data fresh enough? The answer is always a deterministic JSON verdict: FRESH, STALE, or UNKNOWN.

$ freshprobe check https://api.example.com/v2/quotes

{
  "verdict": "STALE",
  "confidence": 0.94,
  "endpoint": "https://api.example.com/v2/quotes",
  "freshness": {
    "data_age_seconds": 2847,
    "freshness_score": 0.12,
    "cache_control": "max-age=3600"
  },
  "liveness": {
    "status": "DEGRADED",
    "latency_p50_ms": 342,
    "latency_p95_ms": 1847,
    "body_size_bytes": 4096,
    "error_rate": 0.03
  },
  "redirects": {
    "total_hops": 1,
    "final_url": "https://api-v2.example.com/quotes",
    "has_redirect": true
  },
  "nist_mapping": {
    "ai_rmf_function": "MEASURE",
    "control": "MS-2.6-001"
  }
}

Single Go binary. No dependencies. Runs as CLI, MCP server, or HTTP microservice.

Why this matters

Problem	Cost
E-commerce agent used 6-month-old product data	$5M+ revenue loss
Enterprise RAG with overlapping refresh infrastructure	$340K/year wasted
AI project failures from data quality issues	60%+ of failures (Gartner)

Unlike crashes that trigger alerts, stale data produces confident, well-formatted, completely wrong responses. Chain a few of those in a multi-agent pipeline and every component reports green while the output is catastrophically wrong.

Related MCP server: unphurl-mcp

Install

Go install (recommended):

go install github.com/Sudhan30/freshprobe/cmd/freshprobe@latest

Docker:

docker run --rm ghcr.io/sudhan30/freshprobe:latest check https://example.com

From source:

git clone https://github.com/Sudhan30/freshprobe.git && cd freshprobe && make build
./bin/freshprobe --version

GitHub Releases: Download pre-built binaries for Linux, macOS, and Windows from Releases.

Quick start

# Basic freshness check
freshprobe check https://api.example.com/data

# Human-readable output
freshprobe check https://api.example.com/data --output text

# Content fingerprinting: detect if data actually changes
freshprobe check https://api.example.com/data --repeat 3 --interval 2s

# Check against a freshness policy
freshprobe check https://api.example.com/data --policy-dir ./policies --policy financial-data

# Batch check multiple endpoints
freshprobe batch https://api1.example.com https://api2.example.com https://cdn.example.com

# Continuous monitoring (Ctrl+C to stop)
freshprobe watch https://api.example.com/data --interval 30s --output text

# Only alert on verdict changes (FRESH -> STALE)
freshprobe watch https://api.example.com/data --interval 1m --on-change --output text

# View probe history for an endpoint
freshprobe history https://api.example.com/data --limit 20 --output text

Six verification signals

Signal	What it checks
HTTP cache headers	Parses `Last-Modified`, `Cache-Control`, `Age`, `ETag`, `Date`, `Expires`. Computes 0.0 to 1.0 freshness score
Endpoint liveness	Measures response latency (P50/P95/P99), status codes, body size, degradation patterns
Content fingerprinting	SHA-256 hashes response bodies across repeated probes to detect stale caches
TLS certificate health	Certificate validity, days remaining, OCSP stapling status
DNS resolution timing	DNS lookup latency as infrastructure health signal
Redirect chain analysis	Tracks 301/302/307/308 hops, detects stale CDN configs

Three deployment modes

CLI

freshprobe check <url> [flags]
freshprobe batch <urls...> [flags]
freshprobe watch <url> --interval 30s [flags]
freshprobe history <url> --limit 20

MCP server (for AI agents)

Add to your AI tool config:

{
  "freshprobe": {
    "type": "stdio",
    "command": "freshprobe",
    "args": ["serve", "--mode", "mcp", "--policy-dir", "/path/to/policies", "--stateless"]
  }
}

In .cursor/mcp.json:

{
  "mcpServers": {
    "freshprobe": {
      "command": "freshprobe",
      "args": ["serve", "--mode", "mcp", "--stateless"]
    }
  }
}

In .vscode/mcp.json:

{
  "servers": {
    "freshprobe": {
      "type": "stdio",
      "command": "freshprobe",
      "args": ["serve", "--mode", "mcp", "--stateless"]
    }
  }
}

This exposes three tools to AI agents:

Tool	Description
`freshprobe_check`	Probe a single endpoint. Returns JSON verdict
`freshprobe_batch`	Probe multiple endpoints concurrently
`freshprobe_policy`	Check an endpoint against a named freshness policy

HTTP server

freshprobe serve --mode http --addr :8080

POST /api/v1/check    {"url": "https://..."}
POST /api/v1/batch    {"urls": ["https://...", "https://..."]}
POST /api/v1/policy   {"url": "https://...", "policy_name": "api-realtime"}
GET  /healthz
GET  /metrics          # Prometheus-compatible metrics

Policies (freshness-as-code)

Define freshness thresholds per domain in YAML:

version: "1"
policies:
  financial-data:
    name: "Financial Data"
    domains: ["*.market.*", "*.trading.*"]
    max_staleness: "30s"
    min_freshness_score: 0.9
    max_latency_p95_ms: 200
    require_tls: true
    min_tls_days_left: 30
    require_changing: true

  api-standard:
    name: "Standard API"
    domains: ["api.*"]
    max_staleness: "5m"
    min_freshness_score: 0.6
    max_latency_p95_ms: 2000
    require_tls: true

When a probe violates a policy:

{
  "policy_result": {
    "policy_name": "Financial Data",
    "passed": false,
    "violations": [
      {"check": "max_staleness", "expected": "<= 30s", "actual": "2m15s"},
      {"check": "max_latency_p95", "expected": "<= 200 ms", "actual": "847 ms"}
    ]
  }
}

Four built-in policies included: api-realtime, api-standard, static-content, financial-data.

Continuous monitoring

# Watch an endpoint, print every probe
freshprobe watch https://api.example.com/quotes --interval 30s --output text

# Only print when verdict changes (FRESH -> STALE transitions)
freshprobe watch https://api.example.com/quotes --interval 1m --on-change --output text

# Run 10 probes and exit
freshprobe watch https://api.example.com/quotes --count 10 --interval 5s

Example output:

Watching https://api.example.com/quotes every 30s
[14:22:01] FRESH conf=0.90 score=0.87 p95=142ms
[14:22:31] FRESH conf=0.90 score=0.85 p95=156ms
[14:23:01] STALE conf=0.85 score=0.22 p95=1847ms [FRESH -> STALE]

Prometheus metrics

The HTTP server exposes /metrics with Prometheus-compatible text format:

freshprobe_probes_total 142
freshprobe_verdict_total{verdict="FRESH"} 98
freshprobe_verdict_total{verdict="STALE"} 31
freshprobe_verdict_total{verdict="UNKNOWN"} 13
freshprobe_latency_p95_seconds 0.234000
freshprobe_freshness_score 0.7200

How it compares

Feature	freshprobe	Uptime Kuma	Gatus	freshcontext-mcp
Purpose	Data freshness for AI agents	Uptime monitoring	Health dashboards	Web extraction timestamps
Knows data is stale	Yes (cache headers + fingerprinting)	No (only checks HTTP status)	No (only checks response assertions)	Partial (timestamps, no verification)
MCP server	Yes (3 tools)	No	No	Yes
Policy engine	Yes (YAML, per-domain)	No	Yes (YAML conditions)	No
Continuous monitoring	Yes (`watch` command)	Yes (dashboard)	Yes (dashboard)	No
Prometheus metrics	Yes	No (push-based)	Yes	No
Deployment	Single binary	Docker + DB	Single binary	npm package

Architecture

                    +------------------+
                    |   freshprobe     |
                    |   single binary  |
                    +--------+---------+
                             |
              +--------------+--------------+
              |              |              |
         +----+----+   +----+----+   +-----+-----+
         |   CLI   |   |   MCP   |   |   HTTP    |
         | (cobra) |   | (stdio) |   | (net/http)|
         +---------+   +---------+   +-----------+
              |              |              |
              +--------------+--------------+
                             |
                    +--------+---------+
                    |   Probe Engine   |
                    |                  |
                    | HTTP headers     |
                    | Latency P50/95/99|
                    | Content SHA-256  |
                    | TLS/OCSP        |
                    | DNS timing       |
                    | Redirect chains  |
                    +--------+---------+
                             |
              +--------------+--------------+
              |              |              |
         +----+----+   +----+----+   +-----+-----+
         | Verdict |   | Policy  |   |   Store   |
         | Engine  |   | Engine  |   | SQLite /  |
         |         |   | (YAML)  |   | Stateless |
         +---------+   +---------+   +-----------+

Kubernetes deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: freshprobe
spec:
  replicas: 1
  selector:
    matchLabels: { app: freshprobe }
  template:
    metadata:
      labels: { app: freshprobe }
    spec:
      containers:
        - name: freshprobe
          image: ghcr.io/sudhan30/freshprobe:latest
          args: ["serve", "--mode", "http", "--addr", ":8080",
                 "--policy-dir", "/etc/freshprobe/policies", "--stateless"]
          ports:
            - containerPort: 8080
          resources:
            requests: { cpu: 50m, memory: 64Mi }
            limits: { cpu: 200m, memory: 128Mi }
          readinessProbe:
            httpGet: { path: /healthz, port: 8080 }
          livenessProbe:
            httpGet: { path: /healthz, port: 8080 }

Claude Code plugin

/plugin install github:Sudhan30/freshprobe

After installing, ask Claude:

"Is the trading API returning fresh data?"
"Check all our endpoints before running the batch job"
"Does this API meet our real-time SLA?"

Development

make build       # Build binary
make test        # Run tests with race detector
make lint        # go vet
make cross       # Cross-compile (linux, macOS, Windows)
make docker      # Docker build

Contributing

See CONTRIBUTING.md. High-value areas:

Policy packs for specific domains (healthcare, weather, finance)
WebSocket/gRPC/GraphQL probe signals
OpenTelemetry integration
Homebrew formula

License

MIT. See LICENSE.

Available Tools

3 tools

freshprobe_batchB

Probe multiple endpoints concurrently for data freshness. Returns an array of JSON verdicts.

ParametersJSON Schema

Name	Required	Description
`urls`	Yes	list of URLs to probe
`repeat`	No	number of repeat probes per URL
`concurrency`	No	max concurrent probes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose all behavioral traits. It mentions concurrency and return type, but fails to mention error handling, timeouts, side effects, or performance implications of concurrent probing.

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?

Two short sentences front-load the purpose and output. Every word adds value; no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 required params and no output schema, the description captures core purpose and output. However, it omits important context like concurrency limits, error behavior, and what 'verdicts' contain, leaving the agent underinformed.

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?

Schema coverage is 100% with descriptions for all parameters, so baseline 3 is appropriate. The description adds no extra parameter meaning beyond what the schema already provides.

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 uses a specific verb ('Probe') and resource ('multiple endpoints'), clearly states the action is concurrent and for 'data freshness', and distinguishes from siblings via the 'batch' name implying multiple endpoints.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings like freshprobe_check (likely single-probe) or freshprobe_policy. The agent gets no information about appropriate contexts or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

freshprobe_checkA

Probe a single endpoint for data freshness and liveness. Returns a deterministic JSON verdict with freshness score, latency percentiles, TLS status, and content fingerprint.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	the URL to probe for freshness
`repeat`	No	number of repeat probes for fingerprinting
`timeout_secs`	No	probe timeout in seconds
`skip_tls`	No	skip TLS certificate checks
`skip_dns`	No	skip DNS resolution timing

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries the full burden. It describes the return but not side effects, modification risks, auth requirements, rate limits, or other behavioral traits beyond the probe action.

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?

Two sentences, front-loaded with purpose, no redundancy or fluff. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and no annotations, the description covers the basic operation and return fields but lacks details on parameter interplay, edge cases, and usage constraints.

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?

Schema coverage is 100% with descriptions for all 5 parameters. The description adds minimal extra meaning beyond the schema (e.g., mentions deterministic JSON return), meeting the baseline for high coverage.

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 clearly states the action ('probe'), the resource ('a single endpoint'), and the output ('deterministic JSON verdict'). It distinguishes from siblings like freshprobe_batch (batch) and freshprobe_policy (policy).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for single endpoint probing but does not explicitly state when to use this tool vs siblings like freshprobe_batch or freshprobe_policy, nor does it provide exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

freshprobe_policyA

Check an endpoint against a named freshness policy. Returns verdict with pass/fail evaluation against policy thresholds.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	the URL to check
`policy_name`	Yes	name of the freshness policy to evaluate against

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It states the tool returns a verdict with pass/fail but does not disclose potential side effects, error conditions (e.g., missing policy), or permission requirements. Minimal behavioral detail.

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?

Two concise sentences with no superfluous information. Purpose and output clearly stated in a front-loaded manner.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity and 100% schema coverage, the description adequately covers what the tool does. However, no output schema exists, and the description could elaborate on the verdict format. Still sufficient for a straightforward check tool.

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?

Schema coverage is 100% with descriptions for both parameters. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.

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 clearly states the verb 'check', the resource 'endpoint' against a 'freshness policy', and the outcome 'verdict with pass/fail evaluation'. It distinguishes from siblings by specifically mentioning policy-based evaluation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when a named freshness policy exists, but does not provide explicit guidance on when to use this tool over siblings like freshprobe_check or freshprobe_batch. No when-not-to-use or alternatives mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Apr 2, 2026
- First observedfreshprobe_batch
- First observedfreshprobe_check
- First observedfreshprobe_policy

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-09-09 19:19 across 3 tools

Disambiguation4/5

The three tools are mostly distinct: batch probes multiple endpoints, single checks one endpoint in detail, and policy evaluates against thresholds. The slight overlap between batch and single could cause minor confusion, but descriptions clarify the differences well.

Naming Consistency4/5

All tools follow a consistent 'freshprobe_' prefix with clear action verbs (batch, check, policy). The naming pattern is predictable and readable, though the prefix is not a standard verb_noun pattern.

Tool Count4/5

With 3 tools, the server is compact and covers the core functionality of probing freshness: single check, batch check, and policy evaluation. The count feels slightly thin but is appropriate for a focused utility server.

Completeness3/5

The tool surface covers probing, batch probing, and policy evaluation, but lacks management operations like creating/updating policies or listing endpoints. Key workflows are present, but there are notable gaps for a policy-based system.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

DeltaMesh Web Freshness A
io.github.buttacavoligiuse
Free public web freshness and response-metadata checks for AI agents.
Browser Automation Web Scraping Agent Orchestration
2
Unphurl A
io.github.123Ergo
URL intelligence for AI agents and developers. 16 tools, 25 signal weights, 20 free checks.
Web Scraping Security Search
1821
Agent Ready A
io.github.mlava
Scan any URL for AI agent readability — Vercel Spec, llmstxt.org, and agent-protocol manifests.
Agent Orchestration Browser Automation
321
AgentTrust — AI Agent Trust, Reliability & Reputation Checks A
io.github.agenttrust-ai
Trust infrastructure for AI agents: check reliability, verification, and trustDecision by URL.
Security Autonomous Agents
51

Related MCP Servers

depscan-api
Security Monitoring
robcqm-bot
F
license
Not graded
quality
D
maintenance
Dependency health checker for AI agent skills. Analyzes external endpoints for uptime, SSL validity, domain reputation, ownership changes, and abuse scores. Returns a 0-100 trust score per endpoint.
Updated 7 months ago (2026-03-02 16:11 UTC)
-
unphurl-mcp
Web Scraping Security Search
123Ergo
A
license
A
quality
D
maintenance
URL intelligence for AI agents. One URL in, structured security and data quality signals out across 7 dimensions. 13 tools, risk score 0-100 with 23 configurable weights.
Updated 5 months ago (2026-04-23 14:24 UTC)
16
63 npm
1
MIT
LinkPulse
Web Scraping Search Monitoring
walkojas-boop
F
license
Not graded
quality
Not graded
maintenance
URL reality check for AI agents — returns HTTP status, SHA-256 content hash, classification, readability score, title, and wayback-machine fallback when dead, cached 10 minutes at $0.001 per call.
Updated 5 months ago (2026-04-19 11:28 UTC)
-
Agundur GEO Scannerofficial
Marketing Search
Agundur-KDE
A
license
Not graded
quality
C
maintenance
Checks whether a website is readable and citable by AI search engines — llms.txt, Schema.org structured data, AI-bot access in robots.txt, content freshness, answer directness, E-E-A-T signals, plus a LocalBusiness Rich Results validator. Free, no API key, remote Streamable HTTP.
Updated 2 months ago (2026-07-23 07:58 UTC)
1
MIT

Why this matters

Install

Quick start

Six verification signals

Three deployment modes

CLI

MCP server (for AI agents)

HTTP server

Policies (freshness-as-code)

Continuous monitoring

Prometheus metrics

How it compares

Architecture

Kubernetes deployment

Claude Code plugin

Development

Contributing

License

Available Tools

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

depscan-api

unphurl-mcp

LinkPulse

Agundur GEO Scannerofficial