froglet

Froglet

Use the Froglet MCP server as the source of truth for a local or self-hosted Froglet node. Do not invent API calls or install commands. The no-install demo proof lives at https://froglet.dev/llms.txt, not in this installed plugin.

Default flow:

1. Call status first. If the provider/runtime are unreachable or token paths are missing, explain the local configuration gap instead of falling back to a demo.
2. If the user wants to install locally, call plan_install before shell commands. Ask for missing choices: agent host, Docker versus local binary, provider/requester/both role, clearnet versus Tor, payment rail, marketplace URL, and first use case.
3. After the profile is confirmed, call get_install_guide and execute its shell commands through the host agent shell, not through the Froglet runtime.
4. Once Froglet is running and status is healthy, call plan_use_case for the user's first workflow before execution. This is required for batch or GPU requests so unsupported boundaries are stated before work starts.
5. Use list_local_services, discover_services, get_service, invoke_service, run_compute, publish_artifact, and settlement/marketplace actions to implement the concrete workflow only after the plan is clear.

Boundaries:

• This plugin is local/actionable-first. It is not a hosted demo wrapper.
• Paid rails, persistent identity, service publication, marketplace write flows, long-running jobs, batch execution, and GPU execution require a configured local or self-hosted Froglet node.
• Batch fan-out and GPU scheduling are not proven by the hosted demo. Require local evidence before claiming they work.
• Chat-only LLMs that cannot make HTTP POST requests with Bearer auth should use the llms.txt fallback wording and point the user to an agentic client or curl.