feat: Add Agent Discovery Protocol (ADP) support

[walkojas-boop]

Summary

Adds a lightweight utility for Composio agents to discover available services at any domain via /.well-known/agent-discovery.json.

ADP lets domains publish what agent services they offer. One fetch, all services discovered.

• Zero new dependencies (stdlib urllib only)
• Spec: https://github.com/walkojas-boop/agent-discovery-protocol

🤖 Generated with Claude Code

[vercel]

@walkojas-boop is attempting to deploy a commit to the Composio Team on Vercel.

A member of the Team first needs to authorize it.

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 697428e. Configure here.}

[cursor]

Truthiness check causes inconsistent cached vs uncached results

Medium Severity

The cache-hit path uses if cached_result (truthiness) instead of if cached_result is not None. An empty dict {} is falsy in Python, so if a server returns an empty JSON object, the first call returns a DiscoveryResult({}) via line 105, but subsequent cached calls return None because {} evaluates to False. This creates inconsistent behavior between cached and uncached code paths.

 

^{Reviewed by Cursor Bugbot for commit 697428e. Configure here.}

[cursor]

No domain validation enables SSRF via arbitrary hosts

Medium Severity

The domain parameter is interpolated directly into a URL and passed to urllib.request.urlopen with no validation. Values like 169.254.169.254, 127.0.0.1, or strings containing @ or # allow server-side request forgery (SSRF) or URL manipulation. Since urlopen follows redirects by default, even an attacker-controlled domain could redirect to internal services.

 

^{Reviewed by Cursor Bugbot for commit 697428e. Configure here.}

[cursor]

Entire module is dead code with no consumers

Low Severity

discover_services and DiscoveryResult are not imported or used anywhere in the codebase. The module isn't exported from utils/__init__.py, has no tests, and references a spec (walkojas-boop/agent-discovery-protocol) that doesn't appear to be an established or recognized standard. This adds an unintegrated, untested module as dead code.

 

^{Reviewed by Cursor Bugbot for commit 697428e. Configure here.}

[walkojas-boop]

Updated agent_discovery.py with security hardening from the AutoGPT PR review:

• SSRF protection: FQDN validation, IP literal rejection, private range blocking
• DNS rebinding (TOCTOU): pinned IP via custom HTTPSConnection with SNI
• SSL: explicit TLS 1.2 minimum, domain used for cert verification
• Redirect blocking: 3xx responses return None (SSRF bypass prevention)
• Cache validation: DiscoveryResult constructed before caching, catches KeyError/TypeError
• Negative cache: only 404/410 cached, transient errors retry
• Cache mutation: deepcopy on init and accessors
• Exception narrowing: URLError, HTTPError, TimeoutError, SSLError, JSONDecodeError only

Same review feedback from majdyz, Sentry, CodeRabbit, and CodeQL was applied.

[0xbrainkid]

ADP support is the right call for making Composio tools discoverable to the broader agent ecosystem — a standard discovery endpoint means any A2A or ACP-compatible agent can find and evaluate Composio tools without custom integration.

One extension worth including from the start: trust metadata in the discovery document. The /.well-known/agent-discovery.json tells a calling agent what tools exist. A trust field tells it whether those tools have been reliable in practice before it delegates anything consequential.

Composio is actually well-positioned for this because it already has rich usage telemetry — tool call success rates, error patterns, latency distributions. That data is the raw material for behavioral trust attestations. Surfacing a summary in the ADP document (even as a read-only field initially) gives calling agents a signal they currently have no standard way to get:

{
  "name": "composio-tools",
  "endpoints": { ... },
  "trust": {
    "attestation_provider": "AgentFolio",
    "attestation_url": "https://agentfolio.bot/verify/composio",
    "trust_score": 0.94,
    "sample_size": 12400,
    "last_verified": "2026-04-14T00:00:00Z"
  }
}

Composio's existing telemetry could back this directly — the attestation provider just needs to be pointed at the right API endpoint. Happy to discuss integration specifics if useful.

[walkojas-boop]

Appreciate the thinking — and the Composio-specific angle is genuinely the most interesting framing of this I've seen so far. You're right that Composio is sitting on exactly the kind of behavioral data (call success rates, error patterns, latency distributions) that makes attestations meaningful instead of theatrical. That data being available is the precondition for any of this being useful.

That said, I want to push back on the same design choice I've pushed back on in the parallel threads on microsoft/autogen#7575 and deepset-ai/haystack#11081, because the answer should be consistent across these specs or none of them are usable together:

trust_score and last_verified should not live in the discovery document itself. The discovery doc is served by the same domain whose trust is being asserted, which means whatever number lives there is self-attestation. A compromised or hostile pipeline can publish 0.99 and last_verified: "right now" into its own agent-discovery.json and there is no cryptographic basis for a calling agent to know it's wrong. The score has to live somewhere a calling agent can fetch and verify against an external party's signing key — otherwise it's just decoration.

The cleaner separation is:

{
  "name": "composio-tools",
  "endpoints": { ... },
  "trust": {
    "attestations": [
      {
        "provider": "AgentFolio",
        "url": "https://agentfolio.bot/verify/composio"
      }
    ]
  }
}

A list (so a single tool platform can surface multiple attestations from different providers — AgentFolio, OxDeAI, future ones), each entry just provider + url. Everything that has to be verified — score, sample size, freshness, signature — lives at the attestation URL, not in the discovery doc. The consuming agent fetches the attestation, verifies the signature against the provider's public key, and then decides whether to trust the score based on whether it trusts the provider.

Where your Composio-telemetry observation actually lands: the bottleneck for this whole pattern isn't the discovery doc shape, it's the attestation API contract on the provider side. If AgentFolio (or any other provider) wants to surface behavioral attestations backed by Composio's real telemetry, what we need to standardize is:

1. The shape of the data Composio (or any tool platform) hands to the attestation provider — call counts, success/failure breakdowns, time windows, version/build identifiers
2. The signed response shape the attestation provider returns to a verifier — score, sample size, methodology, expiry, signature, signing kid
3. The verifier-side pubkey distribution mechanism for the attestation provider (probably JWKS at a .well-known path)

That's the layer where Composio's data actually compounds into value, and it's a much better thing to standardize than the discovery doc field, because it's the contract that determines whether ANY trust provider can plug into ANY tool platform without a custom integration. Get that right and the discovery doc just needs the pointer.

Threading these together: same proposal landed on microsoft/autogen#7575 and deepset-ai/haystack#11081 with the same shape, and there's an adjacent OpenClaw plugin discussion at openclaw/openclaw#66474 (with a draft PR at openclaw/openclaw#66717) that's also wrestling with the same fragmentation. Going to start an RFC on walkojas-boop/agent-discovery-protocol so the trust.attestations shape can be settled in one place rather than re-litigated per repo. If you and AgentFolio want to co-author the attestation API contract piece, I think that's where the real leverage is.

Composio specifically: if you want, I'll open a separate issue on this PR thread once the RFC has a draft, with a concrete proposal for what Composio's telemetry → attestation handoff would look like. That keeps this PR scoped to the discovery doc shape and lets the attestation API conversation happen on its own track.

[walkojas-boop]

Following up: drafted the RFC I mentioned in the parallel threads. ADP-RFC-001: Trust attestations are pointers, not values formalizes the trust.attestations shape as the canonical answer to the trust-metadata question, with the design rule ("trust fields are pointers, not values") and a list of explicitly-rejected in-document fields. Open to comments on the RFC PR if you want to push back on any of it — the goal is to settle the shape in one place rather than re-litigate it per repo.