-
Notifications
You must be signed in to change notification settings - Fork 0
Tools and Capabilities
Draggy can do more than answer from memory. Which tools are available depends on your settings and on the model — a model that does not support tool calling gets a text-based fallback, and one under about 4B parameters will describe a tool call instead of making one often enough to be irritating.
search_web runs a query and returns titles and snippets; read_url fetches a
page and extracts its text.
Search has three modes, set in Settings → Tools:
- Auto — the model decides for itself whether the question needs the web
- On — always search before answering
- Off — never search, and never claim to have
Set to Automatic, providers are tried in order until one answers: your own SearXNG instance if you configured one, Brave's API if you supplied a key, then DuckDuckGo, Startpage, and two further fallbacks — DuckDuckGo Lite and Brave Search without a key. You do not need a key for anything except Brave's API. You can also pin it to one specific provider instead of automatic.
Results are cached briefly, so asking a follow-up does not re-run the same query.
For sites that need interacting with rather than just reading, Draggy drives a
real browser window: browser_navigate, browser_get_elements,
browser_click, browser_type, browser_press_key, browser_get_text,
browser_close.
Elements are given to the model as an indexed list, so it clicks item 4 rather than guessing at a CSS selector. The window has the same ad blocker your own browsing does, which exists here less for comfort than because ad markup is most of what a page costs a small model to read.
Some sites answer a request with a Cloudflare, hCaptcha or reCAPTCHA challenge
instead of a page. Draggy does not try to defeat those. read_url recognises
one, stops immediately rather than retrying, and tells the model plainly that
the page needs a person — so you get a straight answer and a link rather than
five reworded attempts at the same URL.
Open that link yourself and pass the check, and the model can read the site afterwards: your browsing and its page reads share one session, so the cookie the site gives you is the cookie it sees.
create_file writes into created_files/ in the Draggy data folder, reachable
from Created files in the sidebar. Word documents from Markdown, PowerPoint
from Markdown with a heading per slide, Excel from CSV, plus code and plain
text.
Draggy refuses to write anything the operating system would execute on a
double-click. Ask for a .bat or a .sh and it will tell you to use .txt
instead. The path is checked too, so a file name cannot escape the output
folder.
You can read those formats back by attaching them to a message.
run_code executes short Python and JavaScript programs, off by default —
enable it in Settings → Tools.
The point is not that Draggy can program for you. It is that a model that can run its code will catch its own mistakes: arithmetic gets checked instead of guessed, and a non-trivial function gets executed before you are told it works.
Each run gets a fresh scratch directory under code_runs/, with no network
access, and is killed after twenty seconds. Python is found on your PATH; if you
have no Python, the tool says so instead of failing strangely. Anything the
program writes to its directory shows up alongside it.
It is not a real sandbox. It is a time limit and a directory, and code you ask for still runs as you. Do not turn it on and then paste something you have not read.
See Document Library.
Draggy reads images when the running model supports vision. Attach one and, if the model does not, you will be told plainly rather than getting a confident description of nothing.
Every tool can be disabled. A model with fewer tools available is a model with fewer ways to go wrong, and on a small model that trade is often worth making. The system prompt is assembled from what is actually enabled, so a disabled tool is not mentioned to the model at all.