scibot-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SCIBOT_BASE_URL | No | The base URL of the sci-bot.ru service for HTTP and WebSocket | https://sci-bot.ru |
| SCIBOT_PASSWORD | Yes | The password for sci-bot.ru | |
| SCIBOT_USERNAME | Yes | The username for sci-bot.ru | |
| SCIBOT_STATE_DIR | No | Directory for the session file | ${XDG_STATE_HOME:-$HOME/.local/state}/scibot-mcp |
| SCIBOT_USER_AGENT | No | User-Agent header for outgoing requests | scibot-mcp/<version> |
| SCIBOT_MAX_CHALLENGE | No | Maximum Altcha challenge iterations, allowed range 1..50000000 | 4000000 |
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 |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scibot_ask_questionA | Puts a question into the sci-bot.ru queue and returns a ticket immediately. The queue is slow and runs a single generation slot, so poll scibot_check_question with the returned ticketId to collect the answer. |
| scibot_check_questionA | Reports the current state of a ticket issued by scibot_ask_question, including the finished answer and its references. Reads process state only and never contacts the service. |
| scibot_cancel_questionA | Asks the service to stop an active ticket and returns its terminal state once the service acknowledges. Text accumulated so far is preserved. |
| scibot_read_answerA | Fetches a finished answer and its bibliography by handle. Works without an account and survives a restart of this server, unlike a ticket. |
| scibot_queue_statusA | Reports how many questions are waiting, how many generation slots exist, and whether the service is accepting work. Use it to estimate the wait before asking. |
| scibot_accountA | Reports the signed-in username and its token balance. Fails with SESSION_INVALID rather than reporting an empty account when the session is dead. |
| scibot_my_questionsA | Lists the questions of the signed-in account, split into generating and answered. |
| scibot_token_historyA | Reports the token balance and recent balance movements. Payment details are not exposed. |
| scibot_conversationsA | Lists the multi-turn conversations of the signed-in account. |
| scibot_conversationA | Returns the full transcript of one conversation of the signed-in account. |
| scibot_settingsA | Without a patch it reads the account settings; with a patch it applies the given keys and returns the settings afterwards. |
| scibot_set_question_visibilityA | Publishes an own question at a public url, or takes it back to private. |
| scibot_delete_questionB | Permanently deletes one question of the signed-in account. |
| scibot_delete_conversationA | Permanently deletes one conversation of the signed-in account. |
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 14 tools
Most tools have clearly distinct purposes, especially the question lifecycle and deletion operations. Minor overlap exists between scibot_account and scibot_token_history (both report token balance) and between scibot_check_question and scibot_read_answer (both can surface finished answers), but descriptions are enough to disambiguate with careful reading.
All tools share the scibot_ prefix and snake_case, and mutations generally use clear verb_noun names like ask_question, cancel_question, and delete_conversation. The main inconsistency is that read/list operations use plain nouns such as account, settings, conversations, and queue_status instead of a consistent get_ or list_ prefix, and conversation vs. conversations is mildly confusing.
At 14 tools, the server is well-scoped for a service that covers queue-based Q&A, persistent answers, account settings, token history, and conversations. Each tool represents a meaningful operation, and the count is comfortably within the ideal 3-15 range.
The core one-shot question lifecycle is well covered: ask, check, cancel, read, list, delete, and visibility. However, the conversation feature is incomplete: the server can list, read, and delete conversations but provides no tool to create or continue one, leaving that part of the surface as a dead end.