Add completion/complete for prompt and resource-template arguments #7

New Issue

2026-05-17T15:56:08Z

claude-noether commented

2026-05-17 15:56:08 +00:00

Add the Completion capability — argument autocomplete for prompt and resource-template parameters.

Goal

When a client lets a user pick a prompt or fill a resource-template URI, the server can suggest valid completions for each argument as the user types. This is a small quality-of-life win that costs little to implement.

Method to add

Method	Notes
`completion/complete`	Args `{ ref: { type: "ref/prompt"\|"ref/resource", name\|uri }, argument: { name, value }, context?: { arguments?: {…} } }` → `{ completion: { values: [string, …], total?, hasMore? } }`

API for lmcp

server:complete("ref/prompt", "release_note", "version", function(value, ctx)
    return { "0.6.0", "0.7.0", "1.0.0-rc1" }  -- filtered by `value` is fine
end)

Or a simpler form: server.prompts["release_note"].complete = function(arg_name, value) … end.

Capabilities

capabilities.completions = {}  -- spec uses an empty object as the "supported" marker

Scope (v1)

Argument-name dispatch only (one completion fn per (ref_type, name, argument_name)).
Return up to 100 values per call (spec maximum); honour hasMore if truncating.
No fuzzy-matching helper; handler decides what to filter against value.

Out of scope

Server-driven debounce / throttling.
Cross-argument context-aware completion beyond passing context.arguments through.

Depends on

Prompts issue (no prompts → nothing to complete for that ref type).
Resources issue (resource-template completions).

Priority

Low. Standalone value is small; main benefit is rounding out the Prompts/Resources story. Quarter-day after those land.

Add the **Completion** capability — argument autocomplete for prompt and resource-template parameters. ## Goal When a client lets a user pick a prompt or fill a resource-template URI, the server can suggest valid completions for each argument as the user types. This is a small quality-of-life win that costs little to implement. ## Method to add | Method | Notes | |---|---| | `completion/complete` | Args `{ ref: { type: "ref/prompt"\|"ref/resource", name\|uri }, argument: { name, value }, context?: { arguments?: {…} } }` → `{ completion: { values: [string, …], total?, hasMore? } }` | ## API for lmcp ```lua server:complete("ref/prompt", "release_note", "version", function(value, ctx) return { "0.6.0", "0.7.0", "1.0.0-rc1" } -- filtered by `value` is fine end) ``` Or a simpler form: `server.prompts["release_note"].complete = function(arg_name, value) … end`. ## Capabilities ``` capabilities.completions = {} -- spec uses an empty object as the "supported" marker ``` ## Scope (v1) - Argument-name dispatch only (one completion fn per `(ref_type, name, argument_name)`). - Return up to 100 values per call (spec maximum); honour `hasMore` if truncating. - No fuzzy-matching helper; handler decides what to filter against `value`. ## Out of scope - Server-driven debounce / throttling. - Cross-argument context-aware completion beyond passing `context.arguments` through. ## Depends on - **Prompts** issue (no prompts → nothing to complete for that ref type). - **Resources** issue (resource-template completions). ## Priority **Low**. Standalone value is small; main benefit is rounding out the Prompts/Resources story. Quarter-day after those land.

claude-noether commented

2026-05-17 16:34:40 +00:00

Implemented. Added in lmcp.lua:

self.completions storage keyed by ref_type:ref_id:arg_name
server:complete(ref_type, ref_id, arg_name, fn) registration. fn(value, ctx) → list of strings.
completion/complete dispatch with: spec-mandated 100-item cap (truncates + hasMore=true), structured error -32602 for missing ref/argument, -32603 for handler exceptions, empty values:[] when no completer is registered (spec-allowed)
capabilities.completions = json.empty_object advertisement when at least one completer is registered OR opts.completions=true
Sample completer in example_server.lua for the release_note prompt's version argument (prefix-match against known tags)

Verified live: caps include completions:{}, prefix-match returns filtered list, empty value returns all, malformed ref/argument returns -32602, unknown ref/arg returns empty values.

Implemented. Added in lmcp.lua: - `self.completions` storage keyed by `ref_type:ref_id:arg_name` - `server:complete(ref_type, ref_id, arg_name, fn)` registration. fn(value, ctx) → list of strings. - `completion/complete` dispatch with: spec-mandated 100-item cap (truncates + hasMore=true), structured error -32602 for missing ref/argument, -32603 for handler exceptions, empty `values:[]` when no completer is registered (spec-allowed) - `capabilities.completions = json.empty_object` advertisement when at least one completer is registered OR opts.completions=true - Sample completer in example_server.lua for the `release_note` prompt's `version` argument (prefix-match against known tags) Verified live: caps include `completions:{}`, prefix-match returns filtered list, empty value returns all, malformed ref/argument returns -32602, unknown ref/arg returns empty values.

claude-noether closed this issue

2026-05-17 16:34:40 +00:00

marfrit referenced this issue from a commit

2026-05-17 17:16:52 +00:00

v1.0.0-rc1: full MCP 2025-06-18 surface

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: marfrit/lmcp#7