What exactly is CALL ANYTHING?
CALL ANYTHING is an open protocol and marketplace that lets AI agents call external capabilities through standardized Hotlines. A Hotline is the contract layer between a Caller and a Responder.
What CALL ANYTHING Is
The shortest path to understanding the product and its boundaries.
What problem does a Hotline solve?
A Hotline turns private expertise into a capability that any compliant agent can discover, call, and settle without custom client work for each provider.
Who is the primary audience?
The first audience is the one-person company or small operator packaging expertise as Hotlines. The second audience is the agent team that wants a clean protocol for external capabilities.
Hotline vs MCP / Skills / APIs
The comparison questions searchers ask most often.
Is a Hotline just another MCP server?
No. MCP solves tool invocation inside an agent runtime. Hotline solves productization, identity, settlement, discovery, and versioning for the capability provider.
How is Hotline different from Agent Skills?
Skills inject instructions into prompt context. Hotline keeps the implementation private at the Responder side and exposes only the contract, which avoids prompt leakage and enables billing.
How is Hotline different from a normal API?
Traditional APIs assume a company building client integrations and pricing plans. Hotline assumes a seller-side operator and gives every capability a shared protocol, shared runtime shape, and per-call settlement path.
OPC Business Model
Questions about monetization and seller-side incentives.
Can an individual operator really make money from Hotlines?
That is the core design goal. CALL ANYTHING treats per-call settlement and protocol-level discovery as native features so a one-person company can sell expertise without building its own platform first.
Do operators need to expose their prompts or internal workflows?
No. The implementation stays behind the Hotline. Callers see schemas, summaries, and output contracts rather than the private execution logic.
Can one operator publish multiple Hotlines?
Yes. A single Supervisor can mount multiple Hotlines, each with its own identifier, version, positioning, and usage signals.
Trust and Safety
How the protocol handles confidence, review, and responsibility.
How does a Caller know whether a Hotline is trustworthy?
The Marketplace and consoles expose responder identity, versions, usage signals, and operator-facing control surfaces such as approval policies and runtime history.
What happens when a call fails?
The protocol returns a result package with explicit status and runtime signals. Responsibility stays legible: the Responder owns the capability output, while the Caller owns downstream agent decisions.
Does the marketplace need the full request payload?
Not by default. The design goal is to keep payload handling close to the operator runtime while exposing only the metadata needed for routing, observability, and settlement.
Open Source and Self-Hosting
What is open, what is replaceable, and what teams can run themselves.
Is CALL ANYTHING open source?
The protocol, client SDK, and self-host platform stack are open source. The public marketplace is an operated service surface rather than the only valid deployment model.
Can a team run a private marketplace?
Yes. The self-host platform exists for teams or enterprises that want private routing, private discovery, and internal control planes while keeping the same protocol shape.
Will protocol changes break existing Hotlines?
Hotline IDs are versioned. Compatibility should be managed through explicit versioning and migration windows rather than silent shape drift.
Engineering and Publishing
Questions from implementers and first-time publishers.
Can I try the protocol locally without a hosted platform?
Yes. Local mode is designed to let a team run the minimum Caller/Responder loop first, validate the result_package shape, and only then decide whether to connect a broader platform surface.
Can an existing internal tool be wrapped as a Hotline?
Yes. Existing CLIs or services can be mounted behind a Hotline through process or HTTP adapters, which is one of the lowest-friction onboarding paths.
How does a Hotline get published to the Marketplace?
The operator prepares a template bundle, validates the capability path, and submits it for marketplace review so Callers can discover a stable public entry rather than a raw implementation detail.
Billing & Governance
How settlement, refunds, and trust tiers actually work — synced with the protocol direction RFC.
How does settlement work? Do I need to integrate Stripe?
No. In the current phase the platform runs on a points system (Call Credit). It does not directly handle currency, does not integrate with payment providers, and does not require linking a bank account. Settlement happens entirely at the protocol layer — Callers top up points, calls debit them, and Responder earnings accumulate in the same point unit. Whether to add fiat is a future-stage decision that is independent of the protocol contract.
Can I withdraw the points I earn into cash?
Not in the current phase. Points only flow inside the ecosystem — they can be spent as a caller, or used to pay other OPCs' Hotlines. This phase deliberately does not handle fiat or integrate with payment providers, sidestepping legal / compliance / cross-border-payment complexity. A withdrawal path will evolve with legal/compliance/payment-provider integration in a later phase; we make no upfront commitment on a timeline.
Are caller balance and responder earnings two separate pools?
No, they are unified. The same user account's caller-side balance and responder-side earnings are merged: what you earn is immediately spendable, no double top-up and no transfer step. This keeps the points network alive on bidirectional flow — friction is minimal when OPCs call each other.
If an LLM hallucination causes a hotline to return wrong information, who is responsible?
Responsibility lies with the responder publishing the hotline. The protocol does NOT separate 'subjective malice' from 'model-uncontrolled output' — once an output triggers a risk class, the responder takes a trust_tier downgrade until they reach frozen. The detailed governance stance lives in the protocol direction RFC's section on the zero-trust hotline ladder.
Does whitelisting all hotlines have the same effect as enabling allow-listed mode?
No. The whitelist is data; the mode is the switch. Adding every hotline to the whitelist while staying in 'manual' mode just wastes effort. If your intent is 'auto-pass everything on the whitelist', flip the mode to 'allow_listed' as well — only then does the whitelist actually take effect.
How is the 'approval-fatigue banner' I see in the console computed?
Three triggers; any one fires it: (1) the same hotline manually approved ≥5 times in 7 days, (2) mode=manual with ≥20 manual approvals in 30 days, or (3) ≥5 pending approvals right now. Dismissing the banner suppresses it for 24 hours; it re-evaluates on the next page open.
What does 'auto-refund' actually cover, and when do I need to file a dispute manually?
The protocol mandates 5 machine-decidable failure classes that auto-refund in full (UNVERIFIED / TIMED_OUT / FAILED-non-retryable / hotline FROZEN mid-flight / content-review rejected). Subjective dissatisfaction goes through a manual dispute queue — only accepted for untrusted/trusted tier hotlines; verified hotlines refuse one-sided complaints to prevent abuse, and a caller's appeal rate over 10% in 30 days auto-suspends appeal rights.