treg: OpenRouter for AI Agent Tools

treg: The OpenRouter for AI Agent Tools

AI coding agents are getting better at reasoning, but they still depend on a messy layer of external tools. An SEO task may need keyword data, SERP results, backlinks, competitor research, analytics, and social signals. A sales workflow may need company enrichment, email verification, CRM data, and advertising intelligence. Each provider has its own account, API key, pricing model, authentication flow, and rate limits.

Superdesign’s open-source treg is built to simplify that layer. It presents itself as “OpenRouter for agent tools”: one base URL, one token, and a catalog of more than 2,600 endpoints across roughly 40 providers. Instead of asking an agent to know which vendor sells a particular capability, treg lets it search for the job, compare providers, see prices, and call the selected endpoint.

The project is available at treg.superdesign.dev and is published as open-source software under AGPL. Its hosted catalog covers SEO and SERP data, backlinks, social and trend intelligence, people and company enrichment, advertising, measurement, and scraping. Teams can also register their own APIs, OAuth connections, CLIs, and SKILL.md packages alongside the public catalog.

What is treg?

treg is a tool registry and credential gateway for AI agents. Its central idea is simple: an agent should ask for an outcome—such as “find verified work emails for these companies” or “compare backlink providers for this domain”—rather than hard-code a particular provider into the workflow.

The platform combines three layers:

1. A catalog of external tools: More than 2,600 endpoints across dozens of providers.
2. A credential gateway: One treg token identifies the agent or organization, while provider credentials are injected server-side.
3. A team tool shelf: Internal services, paid API accounts, OAuth connections, vendor CLIs, and reusable skills can be registered for shared use.

The public catalog is designed for agents that need live or external data. The private tool layer is designed for teams that want to make their own capabilities available to every teammate’s agent without copying secrets into individual machines or configuration files.

The project’s documentation describes the design as “ask for the task, not the tool.” That is the important abstraction. A developer does not need to decide in advance whether Semrush, Moz, SerpApi, DataForSEO, Hunter, Apollo, or another provider is the best fit for every request. The agent can inspect the available options and use evidence such as price, observed success rate, median speed, and the time of the last successful call.

Why agent tools are becoming the bottleneck

AI agents are often presented as model problems: choose a stronger model, provide more context, and the agent will do more. In practice, many production workflows fail one layer below the model.

The agent may know what it wants to do, but it cannot reliably access the required data. A provider may have an invite-only API, a complex OAuth flow, a subscription that is too expensive for occasional use, or no public endpoint at all. Even when an API exists, the team must store credentials, handle retries, interpret provider-specific errors, and keep the integration working as the upstream changes.

This creates a fragmented stack:

A registry does not eliminate these constraints, but it gives agents and teams one interface for discovering and calling them. That can reduce integration duplication and make tool access more visible.

The one-call model

The core mechanism is a /call/ endpoint. A catalog tool can be called by its identifier with the organization’s treg token:

1curl "https://treg.superdesign.dev/call/tikhub.tiktok.user.profile?uniqueId=tiktok" \\
2  -H "X-Treg-Token: $TREG_TOKEN"

For a tool that a team owns, the agent can prefix the normal upstream URL with the treg gateway:

1curl "https://treg.superdesign.dev/call/https://api.stripe.com/v1/charges" \\
2  -H "X-Treg-Token: $TREG_TOKEN"

The method, path, query string, and body are passed through. treg resolves the tool, injects the relevant credential, and relays the upstream response. The agent does not need a separate provider key for every service.

The same pattern can be used from the CLI. A basic setup looks like this:

1curl -fsSL https://treg.superdesign.dev/install.sh | sh
2treg login
3treg catalog search "backlinks for a domain"
4treg catalog get hunter.people.email.find
5treg call hunter.people.email.find \\
6  --query domain=example.com \\
7  --query full_name="Alexis Ohanian"
8treg balance

The CLI is aimed at both interactive users and agent or CI environments. The repository documents token-based access, catalog search, balance inspection, tool registration, CLI execution, proxy sessions, and server-side runs.

A catalog organized around jobs

Most developer tool registries begin with vendor names. treg’s interface is intended to begin with capabilities. The catalog groups endpoints by what they do, including:

• Keyword and rank tracking
• Keyword ideas and search volume
• Live SERP results
• Competitor keywords and domain history
• Backlinks, anchors, and referring domains
• AI search visibility and citation tracking
• TikTok, Instagram, X, YouTube, Reddit, and LinkedIn research
• Social publishing
• People and company enrichment
• Work-email discovery and deliverability
• Funding, investors, and firmographics
• Google Ads, Meta Ads, TikTok Ads, and Microsoft Ads
• Analytics and conversion measurement
• Scraping and actor runs

That organization is useful for agentic systems because the user’s request is usually capability-oriented. A marketing agent does not begin with a vendor preference; it begins with a campaign or research objective.

When multiple providers serve the same task, treg exposes selection data. Its documentation says agents should first match the provider to the inputs they actually have, then consider observed reliability, price, and the last successful call. The platform does not silently fail over between providers because only the agent or application knows whether the result is acceptable and whether retrying would duplicate a paid operation.

This is a valuable design choice. Automatic failover sounds convenient, but it can create hidden costs and inconsistent data. A 4xx error usually indicates a bad parameter and should not be retried against every provider. A timeout or 5xx may justify trying another endpoint, but the decision belongs in the agent’s policy.

Pay per result instead of buying every subscription

The hosted catalog addresses a common problem for startups and agent builders: many useful data services are sold as monthly subscriptions even when an agent needs only a handful of calls.

The treg homepage highlights examples such as Semrush, Moz, Crunchbase, Hunter, and other services that can cost tens or hundreds of dollars per month. When a team does not already hold a provider account, treg can serve eligible catalog endpoints on its own credential and charge the organization’s prepaid balance per call.

The product describes this as fractions of a cent for many calls, with the exact price shown before execution. New teams receive a $1.00 starting balance according to the project documentation. If the team already owns a provider key, it can connect that key and route calls through it without metering them against the treg balance.

The credential ladder is:

1. The organization’s registered tool and credential
2. An organization-level secret or virtual tool
3. treg’s own provider credential, where a published price is available

The team’s own credential takes priority. This prevents a customer from paying twice for a service it already subscribes to, while still allowing occasional users to access catalog capabilities without opening every provider account.

Before calling a paid endpoint, agents should inspect the estimated cost and include it in their own budget policy. A tool gateway makes billing easier to centralize, but it does not make external data free. Good agent design still needs limits on per-task spend, retries, concurrency, and provider selection.

Server-side credential injection

One of treg’s strongest security claims is that vendor credentials are injected server-side rather than stored on the agent’s machine. The agent holds a treg token, while the registry handles the provider binding.

This can reduce common operational problems:

• API keys copied into .env files across laptops
• Secrets embedded in agent prompts or skill instructions
• Credentials committed accidentally to repositories
• Separate key rotation for every developer machine
• Provider logins duplicated across CI runners

The project also supports team-owned tools. A teammate can register an internal service, a paid API account, an OAuth connection, a vendor CLI, or a skill package. Other agents can then call the shared capability through the registry while the underlying credential remains on the server.

That does not remove the need for access control. A shared gateway can become a concentrated privilege layer. Organizations should define who can register a tool, who can call it, which agents can access it, what actions are allowed, and how calls are audited. A token that can reach a write-capable payment or advertising API should not be handed to an untrusted coding agent just because the secret itself is hidden.

The project’s llms.txt describes every call as audited. Teams should still confirm retention, log visibility, redaction, and incident-response behavior before routing sensitive production data through a hosted registry.

Bring your own keys, skills, and CLIs

The public catalog is only one side of treg. The other side is a team’s internal tool shelf.

The project can register:

• Internal HTTP services
• Paid API accounts
• OAuth connections
• Vendor CLIs such as Stripe, GitHub, or Vercel
• SKILL.md instructions and recipes
• Bundles that combine a skill with tools and secrets

A scan-and-upload workflow is intended to make onboarding easier. The CLI can inspect a project, identify known environment variables, find skills, and detect supported catalog CLIs before registering them. This helps a team move from local experimentation to shared agent access.

For command-line tools, treg documents local and server-side execution. Local execution can run under a dedicated isolated user with an egress allow-list, while server execution keeps the credential off the developer’s machine and streams the result back. A shell mode can inject credentials for a session, and a proxy mode can capture ordinary HTTPS requests to registered hosts.

The proxy approach is powerful but should be used carefully. HTTPS interception, trust bundles, certificate pinning, local CA files, and process-level environment settings all create operational and security considerations. A direct treg call or server-side CLI run may be easier to audit than allowing a broad shell session to reach multiple registered hosts.

How treg fits into an AI agent architecture

A practical architecture could look like this:

1User request
2     |
3     v
4Agent / coding assistant
5     |
6     |  search by capability
7     v
8Treg catalog ----------------------+
9     |                             |
10     | select endpoint              | team-owned tools
11     v                             v
12Provider gateway              Internal API / CLI / skill
13     |                             |
14     +-------------+---------------+
15                   |
16                   v
17          Result + audit record

The model remains responsible for deciding what the user asked for, selecting a suitable capability, preparing parameters, and interpreting the result. treg handles discovery, credential resolution, routing to the upstream endpoint, and the common call surface.

For an agent built with MCP, treg can serve as a tool backend or a capability registry behind a narrower MCP server. For coding agents such as Claude Code, Codex, or other terminal-based systems, the CLI and proxy modes provide a path to use shared tools without editing every agent’s configuration.

This is complementary to an agent framework, not a replacement for one. A tool gateway does not provide planning, memory, policy enforcement, approval logic, or evaluation by itself. Those responsibilities remain with the harness around the model.

Developers building local agent stacks may also compare treg with OpenClaw-style tool and skill workflows, where capabilities are packaged and made available to an agent runtime. The distinction is that treg focuses heavily on external data providers, credential brokering, catalog discovery, and usage accounting.

Open source and self-hosting

The superdesigndev/treg repository is public on GitHub and describes the project as self-hostable. The repository lists an AGPL license, a Python-based project structure, a CLI, tests, documentation, proxy examples, and a registry service.

Open source matters here because the gateway sits between agents and sensitive tools. Teams may want to inspect how credentials are handled, adapt the catalog, add internal providers, run the service in their own environment, or keep usage data inside their infrastructure.

AGPL also matters for organizations considering a hosted modification. Legal and licensing requirements should be reviewed before embedding or offering a modified version as a network service. Self-hosting is an operational choice, not just a download button: the team becomes responsible for secret storage, tenant isolation, audit logs, provider terms, rate limits, monitoring, upgrades, and abuse controls.

The hosted treg.superdesign.dev service is the fastest way to try the concept. Self-hosting is more appropriate when data residency, internal credentials, network policy, or customization requirements outweigh the convenience of the managed catalog.

What developers should evaluate before adoption

A tool registry is valuable only when it improves completed task outcomes. Before connecting a production agent, measure the entire path:

1. Discovery quality: Can the agent find the right capability from a natural-language task?
2. Parameter accuracy: Does it provide the correct identifiers, formats, and filters?
3. Provider reliability: How often do calls succeed, timeout, or return partial data?
4. Data consistency: Do results from different providers mean the same thing?
5. Cost control: Can the agent estimate and cap spending before execution?
6. Credential scope: Is the token limited to the tools the agent actually needs?
7. Write protection: Are destructive operations draft-only or approval-gated?
8. Auditability: Can the team identify the agent, tool, provider, parameters, cost, and result?
9. Fallback policy: What happens after a 429, timeout, 5xx, or malformed request?
10. Vendor terms: Are the provider’s data, scraping, and redistribution rules compatible with the use case?

Start with read-only research: keyword lookup, public SERP checks, backlink reports, company enrichment, and competitor analysis. Add write-capable tools only after the agent passes a frozen evaluation set and produces useful audit records.

treg compared with common alternatives

The best architecture may combine them. A company can keep core systems behind dedicated APIs, use MCP for stable internal tools, and use treg for the long tail of external research and enrichment providers.

Frequently asked questions

What does treg do?

treg gives AI agents one interface for discovering and calling external tools, team-owned APIs, CLIs, OAuth connections, and skills. The hosted catalog contains more than 2,600 endpoints across roughly 40 providers.

Is treg open source?

Yes. The superdesigndev/treg repository is public and describes the project as AGPL-licensed and self-hostable.

Does treg replace MCP?

Not necessarily. treg is a tool registry and credential gateway. It can sit behind an agent or be integrated into an MCP-based architecture, while MCP provides a protocol and tool interface for compatible clients.

Do I need an API key for every provider?

No. Eligible catalog tools can be served through treg’s own provider credentials and billed per call. If your team already has a provider key, you can register it and use your own credential instead.

Are credentials stored on the agent’s computer?

The product is designed to inject provider credentials server-side. The agent uses a treg token, while the gateway resolves the provider credential. Teams should still review hosted-service security, logs, retention, and access controls.

How much does a tool call cost?

Prices vary by endpoint and are shown in the catalog before execution. The project describes many calls as costing fractions of a cent and provides a starting balance for new teams. Your own registered provider key is not metered through treg’s catalog balance.

Can I add internal tools?

Yes. Teams can register internal APIs, paid accounts, OAuth connections, command-line tools, and SKILL.md packages for shared agent access.

Who should try treg?

It is most useful for developers and teams building agents that need live SEO, social, enrichment, advertising, analytics, scraping, or vendor data without maintaining a separate integration for every provider.

Final take

treg is an attempt to make agent tools as composable as model APIs. Its pitch is straightforward: give an agent one token and a searchable catalog, let it select tools based on the task, keep credentials behind a gateway, and charge for occasional use instead of forcing every team to buy every subscription.

The product is interesting because it targets a real bottleneck. Agent builders increasingly need external data, but the provider landscape remains fragmented and expensive. A shared registry can reduce setup friction and let agents work from capabilities rather than vendor-specific assumptions.

The hard part will be trust. A gateway that can reach SEO data, social accounts, CRMs, advertising platforms, internal CLIs, and financial tools must make permissions, costs, logs, and failure behavior understandable. Open source and self-hosting help, but they do not replace careful policy design.

For read-heavy research and enrichment workflows, treg is a promising layer to test. For high-impact writes, treat it as infrastructure that needs the same approval gates, least-privilege controls, and evaluation discipline as any other AI agent toolchain.

Sources

• treg official website
• treg LLM documentation
• treg GitHub repository
• Superdesign
• Agent Plugins 1.0: Portable AI Skills and MCP Guide

Visual: Agent loop

This original workflow diagram shows the plan-act-observe-verify loop behind the agent system discussed in this article.

Visual reading: an agent is useful because it can act and verify, not merely because it can produce a chat response. Every loop needs scope, permissions, budget, and an exit condition.