name	froglet
description	Use when a user asks what Froglet can prove, whether they should install Froglet, or how to implement a Froglet-backed use case.

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:

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.
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.
After the profile is confirmed, call get_install_guide and execute its shell commands through the host agent shell, not through the Froglet runtime.
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.
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.

name	froglet
description	Use when a user asks what Froglet can prove, whether they should install Froglet, or how to implement a Froglet-backed use case.

Froglet

Default flow:

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.
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.
After the profile is confirmed, call get_install_guide and execute its shell commands through the host agent shell, not through the Froglet runtime.
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.
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.