quillink-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QUILLINK_TOKEN | No | A Personal Access Token — bypasses OAuth login entirely | |
| QUILLINK_API_BASE | No | Override the API base URL (default: production) | |
| QUILLINK_CLIENT_ID | No | Override the OAuth client id used by `login` |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_notesA | List the caller's notes. folder_id="" lists notes with no folder; omit it to list across all folders. status is "active" or "trashed". Locked notes are included but their body is withheld (null). |
| get_noteA | Get a single note by id. Fails with 403 if it isn't owned by the caller, 404 if it doesn't exist. |
| search_notesA | Full-text search over the caller's active notes' titles and body text. Locked notes only match on title (their body is never substring-matched, so a search hit can't leak hidden content). |
| get_note_statsA | Aggregate stats: total active notes, total storage bytes used, pinned-note count, and a created-at histogram by day. |
| list_note_recipientsA | List who a note (owned by the caller) has been shared with. |
| list_shared_notesA | List notes that have been shared with the caller by someone else (received copies), most recently shared first. |
| list_foldersC | List the caller's notebooks/folders. |
| get_folderA | Get a single folder by id. |
| list_tagsA | List every tag used across the caller's active notes. |
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 9 tools
Every tool targets a distinct resource and action: notes, folders, tags, stats, sharing, and shared-with-me. There is no overlap in purpose; even list_notes and search_notes are clearly separated by behavior. An agent can unambiguously pick the right tool for a query.
All tools follow a consistent verb_noun pattern in snake_case, e.g., list_notes, get_note, search_notes, list_folders. No mixed conventions or vague verbs appear. The naming is predictable and self-documenting.
Nine tools is a well-scoped set for a note-taking/sharing domain. Each tool covers a distinct read or metadata feature without bloat or redundancy. The count feels appropriate and complete for a read-focused server surface.
The tool surface is entirely read-only: there is no way to create, update, delete, share, or organize notes, folders, or tags. Agents can retrieve information but cannot perform any write workflow, which is a significant gap for a note management service. The lack of any mutating operations will cause failures in most practical tasks.