flori
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FLORI_PORT | No | Port to listen on when using HTTP transport | |
| FETCHER_URL | Yes | URL of the fetcher service (e.g., http://127.0.0.1:8765) | |
| KAGI_API_KEY | Yes | Your Kagi API key | |
| FLORI_DB_PATH | No | Path to the SQLite database | |
| FLORI_TRANSPORT | No | Transport mode for the MCP server (stdio or http) | |
| FLORI_SESSION_ID | No | Session identifier |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| searchA | Discover candidate sources. Runs a search-engine query and returns URLs with titles, snippets, and engine metadata. Registers each URL as discovered; this is the sole way a URL becomes readable. |
| readA | Read a discovered source against a goal and capture citable evidence. Fetches
and stores the page on first access (no fetch if already stored), selects the
heading sections around the passages most relevant to |
| openB | Inspect a stored source in full: returns a window of the stored page text
starting at |
| grepA | Query a stored source, or the whole corpus when |
| corpus_searchA | Retrieve across the accumulated corpus by content: ranks all stored pages against
a natural-language query and returns the top |
| corpus_listC | Retrieve across the accumulated corpus by metadata: URL, domain, length, fetch time, how many searches surfaced the page, how many evidence entries cite it, and its CSL-JSON record. |
| citeA | Convert an inspected span of a stored page into a citation. Validates that the page is stored and 0 <= start < end <= len(text) within the length cap, records the verbatim span as an EvidenceEntry, and returns it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a fairly distinct role: search discovers URLs, read extracts goal-relevant evidence, open inspects raw windows, grep is regex retrieval, corpus_search/corpus_list retrieve across the accumulated corpus, and cite builds citations. The main soft spot is that read, open, and grep all surface text from stored pages, so an agent must read carefully to pick the right one, but the descriptions differentiate them well.
Most names are bare verbs (search, read, open, grep, cite) while the corpus family uses a prefix (corpus_search, corpus_list), so conventions are mixed. It is still readable and the corpus_ prefix sensibly groups related tools, but there is no single predictable pattern.
Seven tools is well-scoped for a search-read-cite research workflow, with each tool earning a clear place in the pipeline (discovery, reading, inspection, corpus retrieval, citation). No redundancy or padding.
The core research lifecycle is covered: discover sources, read them against a goal, inspect/grep stored text, search the corpus, and create citations. Minor gaps exist, such as no explicit bibliography export, no tool to list/prioritize collected evidence, and no way to unregister a source, but agents can work around these.