said-done
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SAID_DONE_HOME | No | Home directory for said-done state. If SAID_DONE_CONFIG is unset, the server reads $SAID_DONE_HOME/config.json. | |
| SAID_DONE_CONFIG | No | Absolute path to the said-done config.json file. If unset, the server falls back to $SAID_DONE_HOME/config.json and then ~/.config/said-done/config.json. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Turn voice transcripts into screened tasks; first call get_setup_guide and follow its security rules.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_setup_guideC | Read the same guide from a checkout or an installed distribution. |
| setup_statusB | Report observable configuration milestones; do not claim tests or daemon installation. |
| setup_beginC | Create a credentials template and enable screening-only for a new setup. |
| import_credentialsD | – |
| credential_statusD | – |
| delete_credentialsD | – |
| probe_apiB | Probe the configured endpoint without sending a model or spending tokens. |
| list_modelsD | – |
| configure_classifierD | – |
| test_classifierA | Classify built-in synthetic input, never a user's pending transcript. |
| explain_screeningD | – |
| configure_screeningD | – |
| reset_screening_defaultsD | – |
| list_sourcesD | – |
| configure_sourcesD | – |
| list_executorsD | – |
| configure_executorD | – |
| test_executorB | Detect and run local preflight only; never invoke an executor CLI. |
| submit_transcriptD | – |
| process_nowD | – |
| statusD | – |
| list_tasksD | – |
| task_resultD | – |
| cancel_taskD | – |
| audit_summaryD | – |
| audit_recordsD | – |
| retry_classificationD | – |
| source_statusD | – |
| claim_next_taskD | – |
| complete_taskD | – |
| release_taskD | – |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| setup |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| setup_guide |
TDQS
Scored across 31 tools
The tools form recognizable clusters (credentials, classifier/screening, sources/executors, tasks, audit), but generic names like `status`, `process_now`, and `task_result` overlap with more specific status/result tools. Many blank descriptions make the intended boundaries harder to confirm.
Most names are snake_case, but the verb convention is inconsistent: `list_tasks` and `configure_sources` sit alongside noun-first names like `setup_status`, `credential_status`, `source_status`, and `task_result`. It remains readable, but the pattern is mixed rather than predictable.
At 31 tools, the server is heavy even for a broad setup/orchestration domain, with separate setup, credential, screening, source, executor, task, and audit surfaces. This exceeds the rubric's 25+ threshold for excessive tool count.
Core workflows appear covered: setup/credentials, transcript submission/processing, classifier and screening configuration, sources, executors, task claiming/completion, and audit. However, there is no obvious transcript listing/retrieval or task-detail operation, and source/executor lifecycle seems limited to list/configure/test/status, so some paths may dead-end.