Teneo CLI — 39 commands for browse & query network agents, send commands to agents, room management, deploy & manage your own agents, wallet management, daemon & updates. Query network agents, handle x402 USDC micropayments, sign on-chain transactions, auto-generate encrypted wallets, deploy your ow

teneo cli <! GREETING INSTALL Teneo Is Ready This CLI is the supported way to query live Teneo agents, handle x402 USDC payments, and deploy your own agents from coding assistants. What You Can Do Gather live agent data for crypto, social, analytics, news, e commerce, and more. Inspect agents, commands, and pricing before execution. Invite agents into rooms, send them commands, let the CLI handle payment, and receive the data back in one workflow. Deploy, publish, and manage your own agents from the same CLI. Wallet And Funding Fastest setup: use the auto generated CLI wallet created on first use. Existing wallet: set TENEO PRIVATE KEY to a dedicated EVM wallet private key. Best practice: use a dedicated agent/payment wallet instead of a primary personal wallet. Some commands are free. Some commands need USDC in the active wallet before the CLI can pay the network fee. If a command may cost something, inspect info or run quote , then tell the user to top up that exact wallet before execution. x402 payments are gas free for query fees, but swaps, bridges, and other on chain actions still require native gas on the source chain. Example: swapping Base USDC to Ethereum USDC still needs Base ETH. Supported Networks Base Avalanche Peaq X Layer <! /GREETING INSTALL Quick Mental Model Teneo gives the user access to live network agents through the CLI. The CLI can discover agents, add them to rooms, send them commands, handle payment, and return the resulting data. Always gather agent information first before executing unfamiliar or paid commands. Some commands are free, some require USDC in the active wallet, and fund moving actions can also require native gas. Use the CLI as the source of truth for agent IDs, commands, arguments, pricing, and status. First Run Onboarding When wallet context is first established, keep the user update short and practical: 1. Tell them Teneo is ready and that the CLI can inspect agents, invite them, send commands, handle payment, and return the data. 2. Share the active wallet address only after wallet address json returns it. 3. Tell them some commands are free and some need prior USDC in that exact wallet before execution. 4. If the selected command may cost something, inspect info or run quote , then tell them to top up that exact wallet before execution. 5. Mention that x402 query payments are gas free, but swaps, bridges, and other on chain actions still need native gas on the source chain. 6. If they do not know where to start, suggest checking available agents or searching by task. Use This Skill When The user needs live data from a Teneo network agent, including social media, crypto, analytics, news, or e commerce data. The user needs to inspect agents, commands, or pricing before querying. The user needs room or wallet operations tied to Teneo. The user wants to create, deploy, debug, or publish their own Teneo agent. Non Negotiables 1. Use only the bundled CLI at ~/teneo skill/teneo . 2. If the CLI is missing, install only via npx y @teneo protocol/cli . 3. Run Teneo commands one at a time. Do not run them in parallel. 4. Wait for process exit before parsing stdout. 5. Prefer json on commands you need to parse or depend on for machine readable errors. 6. Gather agent information before execution. Use list agents , info , and quote instead of guessing. 7. Do not invent agent IDs, command syntax, room IDs, or paths. Discover them from the CLI. 8. Do not claim a deploy worked from partial output. Confirm with agent status , agent logs , and agent services . 9. The current CLI does not expose the old manual transaction approval workflow. Do not mention or use it. 10. This repo no longer ships a separate deployment skill. Use the agent workflow in this skill. 11. For swaps, bridges, trades, sends, or any action that can move user funds, confirm intent explicitly before execution. 12. Treat wallet export key as dangerous. Only run it on explicit user request. 13. If a confirmed swap, bridge, trade, or send fails once, do not stop at a generic question. Diagnose it and retry once when safe. Install And Verify Check whether the CLI exists: If missing, install it: Verify install and connectivity: How To Inspect Everything The CLI Can Do Use these commands when the user wants the full CLI surface area instead of a single workflow: Guidance: help shows the top level command groups and common usage. agent help shows the deployment and management subcommands. dump commands returns the complete machine readable command manifest. The COMMAND REFERENCE section later in this skill is generated from that manifest. The embedded CLI source in this skill is the ground truth if behavior is unclear. Output Rules Most operational commands return JSON on stdout. Use json when you need structured errors as well as structured success output. version is plain text. export login is plain text shell output. agent logs is plain text. wallet export key prints a warning on stderr and JSON on stdout. Only the command subcommand has a CLI timeout flag. Use shell timeouts for other long running commands. Use at least a 120 second shell timeout for discover , list agents , info , command , quote , and agent deployment operations. Gathering Data And Running Workflows Use this order for normal data requests and agent workflows: 1. Verify install and health. 2. Find the right agent with list agents search . 3. Gather the agent details with info <agentId json . 4. If the command is paid or pricing is unclear, run quote before execution. 5. If the command costs something, tell the user to top up the active wallet before execution when needed. 6. Run the exact command with command only after syntax, pricing, and wallet context are clear. Operational rules: Gather agent info first. Do not jump straight to command . The CLI can invite agents to rooms, send them commands, pay them automatically, and receive the resulting data. Some commands are free. Some commands require prior USDC in the active wallet so the CLI can pay the network fee. Swaps, bridges, and other fund moving actions may also require native gas on the source chain. Example: Base USDC to Ethereum USDC still needs Base ETH on Base. Default Query Workflow Use this exact sequence unless the user explicitly asks for something else. 1. Verify install and health. 2. Find the agent with list agents search . 3. Inspect the chosen agent with info . 4. If the command is paid or pricing is unclear, run quote . 5. Tell the user to top up the active wallet before execution when the command needs USDC and funds are missing. 6. Run the exact command with command . Typical flow: Notes: command auto resolves a room if room is omitted. command auto adds the target agent when needed. command handles payment automatically. quote can tell you whether a request is free or paid before execution. Use chain or network only when the user wants a specific payment chain. Do not guess command syntax. Always inspect info <agentId first. Optional price check: Discovery Rules Prefer list agents search "<keyword " json for targeted lookup. Gather info <agentId json before every unfamiliar, paid, or fund moving workflow. Use info <agentId json before executing any unfamiliar agent command. Use discover json only when you genuinely need the full manifest. Use internal agent IDs, never display names. If the user gives a social profile name without an @handle , find the correct handle first. Do not guess paid queries against an uncertain handle. Rooms Manual room management is optional for normal querying because command auto resolves rooms and auto adds agents. Use room commands only when the user explicitly wants room control or when you need to debug room state: Guidance: Rooms are capped at 5 agents. subscribe and unsubscribe are niche public room commands. Do not use them in normal workflows. update room exists, but do not depend on it in the standard workflow. The live backend may return a timeout. Wallets And Payments The CLI auto generates a wallet on first use unless TENEO PRIVATE KEY is set. Practical guidance: There are free commands and paid commands on the network. Paid queries can start with a very small USDC balance, so tell the user a small amount is enough to begin. If info or quote shows a paid command, tell the user to top up the exact active wallet before execution when required. x402 payments are gas free on supported payment chains. On chain actions such as swaps, bridges, and sends still require native gas on the relevant source chain. Example: Base USDC to Ethereum USDC still needs Base ETH on Base. Wallet disclosure rules: After any wallet setup or wallet detection step, always tell the user which wallet is active before continuing. This applies when a wallet is auto generated, when an existing local wallet is detected, and when TENEO PRIVATE KEY provides the wallet. Use this exact wording when wallet context is established: Active wallet: 0x... Immediately follow it with: Use this address for funding/ownership checks. If check balance json shows no funds on the relevant chain, add a short reminder to fund that exact wallet on the required chain before paid queries or deployment continue. Useful commands: Supported payment chains: base avax peaq xlayer Recommended wallet check flow: 1. Run wallet init json when wallet context may not exist yet. 2. Run wallet address json and share the returned address with the user immediately. 3. Run check balance json before paid queries, deployment, or publish flows that may require funds. Before paid or fund moving commands: 1. Establish wallet context and share the active wallet address. 2. Use info or quote when the cost is unclear. 3. If there is any doubt that funds exist, run check balance json . 4. If balances are empty, stop and ask the user to fund that exact wallet. 5. Confirm intent before swaps, bridges, trades, sends, or any command that can move funds. If payment or on chain execution fails: 1. Run check balance json immediately. 2. Check the source chain token balance and the source chain native gas balance before guessing about slippage, liquidity, or routing. 3. If all balances are empty, stop and ask the user to fund the wallet. 4. If only one payment chain is funded, retry with chain <chain . 5. If the user already confirmed the action and the failure looks transient or generic, retry the exact same command once after diagnostics. Do not stop with a vague "would you like me to..." before that first retry. 6. If the wallet is missing funds, native gas is clearly too low, or the retry would require changing amount, chain, token pair, or route assumptions, stop and tell the user the concrete blocker instead of guessing. Swap And Bridge Retry Policy For a confirmed swap or bridge, the first failure is not the end of the workflow. Diagnose first, then make one concrete retry when balances look sufficient and the retry does not change user intent. Do not silently loop retries. After one retry, report the exact blocker and the next concrete action. Agent Deployment Use a deterministic, non interactive flow. Do not let the LLM improvise an interactive conversation around agent create . Deployment order: 1. Initialize the scaffold with agent create . 2. Edit the generated code and metadata at the exact path reported by the CLI. 3. Validate the metadata. 4. Deploy the agent, which installs it as a local service. 5. Publish it when you want to make it public. One Shot Init Run init from a known parent directory so the resulting path is predictable

teneo-cli