How do I use wrapper-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wrapper-mcp show my open tasks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

wrapper-mcp

by uvaresearch

Overview Schema Related Servers Score Discussions

TypeScript

Remote

@uvaresearch/wrapper-mcp

Stdio MCP server for QMS Wrapper. Lets MCP-capable clients (Claude Code, Claude Desktop, Cursor, generic stdio hosts) drive a QMS Wrapper instance over HTTPS using a Personal Access Token (PAT). Communication is JSON-RPC over stdin/stdout; outbound traffic is HTTPS to a single configured origin.

The server is built domain-by-domain. v0.1 ships task management — 8 task tools, 4 lookup / identity resources, 3 task resource templates, 5 prompts. Subsequent versions will expand to additional QMS Wrapper domains (projects, processes, storage, risk, etc.) under the same package and PAT-auth model.

Status: v0.1.0. package.json is private: true so an accidental npm publish cannot ship it. Flip when ready.

Install

Via npx (no install)

Use this in your MCP host configuration (see Step 2 below). npx will download the package on first run and cache it; subsequent runs reuse the cache.

npx -y @uvaresearch/wrapper-mcp

(Once the package is flipped to public on the registry. While private: true is set, only an authenticated registry user with read access can install it.)

Via npm install -g

For users who want wrapper-mcp on PATH:

npm install -g @uvaresearch/wrapper-mcp
wrapper-mcp --help

The binary lands in your global npm bin dir. Find it with:

npm bin -g

On macOS/Linux this is typically /usr/local/bin or ~/.npm-global/bin; on Windows it is %AppData%\npm.

From source (contributors)

git clone https://github.com/uvaresearch/wrapper-mcp.git
cd wrapper-mcp
npm install
npm run build
node dist/index.js --help

Point your MCP host at the absolute path to dist/index.js.

Configure

Step 1: get a Personal Access Token

Log in to your QMS Wrapper instance.
Go to Profile -> Access Tokens -> Create token.
Name it for the device it will live on (e.g. "Claude Desktop laptop").
Pick scopes. Defaults cover read/write/create on tasks. Only tick tasks:assign and attachments:upload if you need reassignment and file uploads respectively.
Submit and copy the wrapper_<32 chars> plaintext that is shown exactly once. Store it in your OS keychain or a password manager.

Step 2: configure your MCP host

WRAPPER_BASE_URL is the URL you use to sign in to QMS Wrapper in the browser (the user-facing app). For the hosted SaaS that is https://app.qmswrapper.com. Self-hosted instances use their own host.

Claude Code

Either project-scoped (.mcp.json in repo root) or user-scoped (~/.claude.json under the mcpServers key):

{
  "mcpServers": {
    "wrapper": {
      "command": "npx",
      "args": ["-y", "@uvaresearch/wrapper-mcp"],
      "env": {
        "WRAPPER_PAT": "wrapper_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "WRAPPER_BASE_URL": "https://app.qmswrapper.com"
      }
    }
  }
}

Claude Desktop

Edit claude_desktop_config.json (Settings -> Developer -> Edit Config):

{
  "mcpServers": {
    "wrapper": {
      "command": "npx",
      "args": ["-y", "@uvaresearch/wrapper-mcp"],
      "env": {
        "WRAPPER_PAT": "wrapper_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "WRAPPER_BASE_URL": "https://app.qmswrapper.com"
      }
    }
  }
}

Restart Claude Desktop after editing.

Cursor

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "wrapper": {
      "command": "npx",
      "args": ["-y", "@uvaresearch/wrapper-mcp"],
      "env": {
        "WRAPPER_PAT": "wrapper_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "WRAPPER_BASE_URL": "https://app.qmswrapper.com"
      }
    }
  }
}

Generic stdio MCP client

Spawn wrapper-mcp (or npx -y @uvaresearch/wrapper-mcp) as a subprocess with WRAPPER_PAT and WRAPPER_BASE_URL in the child environment, and speak JSON-RPC over its stdin/stdout. Other hosts (for example GitHub Copilot CLI) generally follow the same shape, but config file locations differ; see https://modelcontextprotocol.io/clients for the current list.

Step 3: verify

In Claude Code, run /mcp and confirm:

Server wrapper shows status connected.
Tools: 8. Resources: 4 (plus 3 templates). Prompts: 5.

CLI smoke test (no PAT required):

npx -y @uvaresearch/wrapper-mcp --help
npx -y @uvaresearch/wrapper-mcp --version

If the server fails to start it writes a single-line reason to stderr and exits with code 64.

Environment variables

Variable	Required	Default	Notes
`WRAPPER_PAT`	yes		Personal access token, `wrapper_<32 alnum>`. Must come from env, not CLI flag.
`WRAPPER_BASE_URL`	yes		Browser sign-in URL of your QMS Wrapper instance. HTTPS only; plain HTTP allowed only for loopback or `*.local`.
`WRAPPER_UPLOAD_DIR`	for `task.attach`		Absolute path. `task.attach` will only read files inside this directory. Default-deny when unset.
`WRAPPER_UPLOAD_MAX_BYTES`	no	`52428800` (50 MB)	Per-file upload size cap.
`WRAPPER_CACHE_DIR`	no	`~/.cache/wrapper-mcp`	Scratch dir, created with mode 0700.
`DEBUG`	no	unset	When set (any value), emits verbose HTTP and session logs to stderr.

Tools, resources, prompts at a glance

All v0.1 surfaces live in the task.* namespace. Future domains will use sibling namespaces (project.*, process.*, etc.) without breaking existing tool names.

Task tools (8)

Name	Effect	Annotations
`task.list`	List my tasks, newest first.	read-only, idempotent
`task.get`	Full task detail (journal, attachments, etc.).	read-only, idempotent
`task.update`	Apply one batched change (R2 enforced).	write, non-destructive
`task.create`	Create bug/task; requires previewed hash (R9).	write, non-destructive
`task.assign`	Reassign; requires `userExplicitlyRequested`.	write, destructive
`task.relate`	Link this task to another.	write, non-destructive
`task.tag`	Merge claude-* tags (idempotent).	write, idempotent
`task.attach`	Upload one or more files in one multipart POST.	write, non-destructive

Resources (4 concrete + 3 templates)

URI	Returns
`wrapper://lookups/statuses`	All issue statuses.
`wrapper://lookups/priorities`	All issue priorities.
`wrapper://lookups/trackers`	All trackers (bug, task, etc.).
`wrapper://me`	Identity of the PAT owner.
`wrapper://task/{id}`	Full task detail.
`wrapper://task/{id}/journal`	Journal entries for the task.
`wrapper://task/{id}/attachments/{fileId}`	Signed download URL + metadata for one file.

Task prompts (5)

Slash command	Purpose
`/qms-plate`	Summarize my open tasks grouped by priority.
`/qms-summary`	Read a task plus attachments; produce a user-language recap.
`/qms-start`	Flip a task to in-progress in one atomic update.
`/qms-finish`	Close out a task with status=resolved + comment in one call.
`/qms-file`	Gather, preview, approve, hash, and create a new task (R9).

Security and threat model

This section reflects what the code in src/ actually enforces. If a claim is not backed by code, it is not made here.

What the client does

Opens one outbound TCP connection per request to WRAPPER_BASE_URL using Node's built-in fetch.
Sends Authorization: Bearer <PAT> plus a small set of X-Mcp-* headers (X-Mcp-Session-Id, X-Mcp-Tool-Name, optional X-Mcp-Request-Id) so the backend can audit each call.
Reads/writes only inside WRAPPER_CACHE_DIR (default ~/.cache/wrapper-mcp, created with mode 0700). The HTTP layer is stateless; the cache dir is reserved for ancillary scratch state.
For task.attach, reads file paths supplied by the user in the tool arguments and includes their full contents as multipart fields. Reads are restricted to WRAPPER_UPLOAD_DIR.

What the client does NOT do

No telemetry. No analytics. No usage pings.
No auto-update. The binary you installed is the code that runs.
No remote config. All configuration is local env vars and tool args.
No outbound network calls beyond WRAPPER_BASE_URL. There is no fallback host and no DNS prefetch.
No filesystem access outside WRAPPER_CACHE_DIR and explicit file paths inside WRAPPER_UPLOAD_DIR passed to task.attach.

What the PAT grants and does not grant

A PAT carries the scopes the user ticked at creation time. With default scopes the bearer can read, write, and create tasks they would normally have access to in the web UI. It is bearer-only: anyone who holds the plaintext value can act as the user until the token is revoked. It does not grant filesystem, OS, or shell access on the QMS Wrapper host. The server scopes the bearer to the issuing user; it does not elevate.

Hardening baked into v0.1.0

URL guard (src/security/urlGuard.ts): refuses WRAPPER_BASE_URL that is not https://, except for loopback hosts (localhost, 127.0.0.1, ::1) and *.local. Also rejects userinfo (user:pass@host) and any RFC1918 / link-local / cloud-metadata IP literal. Fails closed at process start before any HTTP call.
Response scrubber (src/security/responseScrubber.ts): runs over every tool / resource / error payload before it leaves the process and replaces any wrapper_<32 alnum> substring with [REDACTED]. The check happens on the serialized JSON string, so exotic types cannot bypass. If a match ever fires it also emits a stderr warning so the regression is visible.
Safe logger (src/security/safeLog.ts): writes only to stderr (stdout is reserved for JSON-RPC framing). Every line is scrubbed twice: once by the PAT regex and once by literal-replacing the current WRAPPER_PAT env value even if it does not match the regex shape.
CLI flag refused: --pat, --token, --bearer, --auth, -p, -t, their =value forms, glued shorts (-pSECRET), case variants, and positional wrapper_<32 alnum> arguments all exit with code 64 before doing anything else. Rationale: command-line tokens land in shell history and ps.
Minimal dependency tree: runtime deps are @modelcontextprotocol/sdk and zod. No HTTP client library, no logger framework, no arg parser. Smaller supply-chain attack surface.
No telemetry, no auto-update, no remote config (see above).
Provenance prep: publishConfig.provenance is true and publishConfig.access is restricted; package.json is private: true for v0.1 so accidental npm publish is blocked. When ready, flip private to false and publish with npm publish --provenance --access public to ship a sigstore attestation.
task.attach default-denies. Requires WRAPPER_UPLOAD_DIR env to be set; resolves and bounds every path inside it; rejects symlinks; caps file size at 50 MB by default.

Known limitations

Cookie jar deferred: the client is Bearer-only. If the backend ever starts requiring a session cookie alongside the PAT, this client will need a cookie store; today it sends no cookies.
task.attach reads each uploaded file fully into memory before posting. Very large attachments will be bounded by Node's heap.

What users should do

Issue PATs with the narrowest scope set that gets your work done.
Rotate PATs periodically; revoke on device loss or job change.
Prefer HTTPS endpoints. The URL guard will refuse anything else outside of loopback / *.local dev hosts.
Keep the PAT in the MCP host's env block (which most hosts read from a permissioned config file), not in shell rc files.
Set WRAPPER_UPLOAD_DIR to a tightly-scoped directory if you need task.attach.

Troubleshooting

Symptom	Likely cause / fix
`WRAPPER_PAT is not set`	Env var missing or empty in the MCP host config. Restart the host after editing the config file.
HTTP 401 from any tool	PAT expired or revoked. Mint a new one in Profile -> Access Tokens.
HTTP 403 with `insufficient_scope`	PAT lacks a scope. For `task.assign` tick `tasks:assign`; for `task.attach` tick `attachments:upload`.
HTTP 404 on every request	`WRAPPER_BASE_URL` points at the wrong host. Use the URL you would type into the browser to sign in (e.g. `https://app.qmswrapper.com`).
`WRAPPER_BASE_URL must use https://`	URL guard rejected a plaintext HTTP URL on a non-loopback host. Use `https://` or move to a `localhost` / `*.local` dev URL.
`PAT must be supplied via the WRAPPER_PAT environment variable`	You passed `--pat=...` on the command line. Move the token into the env block of your MCP host config.
`task.attach refused: WRAPPER_UPLOAD_DIR is not set`	Upload safety is default-deny. Set `WRAPPER_UPLOAD_DIR` in the host's env block to a directory you trust.
Empty tools list in Claude Code after `/mcp`	The server crashed at startup. Run `wrapper-mcp --version` in a terminal to confirm the binary works, then check stderr.
`npm install` fails	Node 20+ is required (see `.nvmrc`). Check `node --version`.
`previewedHash mismatch`	You called `task.create` directly. Use the `/qms-file` prompt; it gathers fields, previews, hashes, and posts in one flow.
`task.assign refused: userExplicitlyRequested must be true`	The agent tried to reassign without explicit user instruction (R1). Confirm with the user, then re-call with the flag.

Contributing

Node 20+ (.nvmrc is the source of truth).
npm install.
npm run build (strict TypeScript; warnings are errors).
npm test (vitest).
Source: https://github.com/uvaresearch/wrapper-mcp.
Do not land changes that introduce a new runtime dependency without discussion; the minimal-deps property is a security feature, not laziness.

License

MIT. See LICENSE.

Available Tools

8 tools

task.assignReassign taskA

Destructive

Transfer assignment to another user. Typically IRREVERSIBLE — once transferred the previous assignee may lose access. Never call without explicit user instruction. userExplicitlyRequested MUST be true.

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`assigneeId`	Yes
`userExplicitlyRequested`	Yes	Must be true. Attests that the user explicitly asked for this reassignment.
`kind`	Yes	Which of the three R1 patterns this is.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true; description expands on this by noting irreversibility and potential access loss for previous assignee. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: purpose, behavioral warning, usage rule. No unnecessary text, front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers irreversible nature and usage constraint, but does not explain kind parameter or return behavior. However, given annotations and schema enums, it is sufficient for safe agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description does not add meaning beyond schema for id and assigneeId; only reiterates the const on userExplicitlyRequested already in schema. With 50% coverage, description fails to compensate for undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'transfer assignment' and resource, distinguishing from sibling tools. Includes important behavioral note about irreversibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states that it should only be called with explicit user instruction and that userExplicitlyRequested must be true. Does not mention alternatives but provides sufficient contextual guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.attachAttach filesA

Upload one or more files to a task in a single multipart request (one journal entry).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`files`	Yes

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate non-destructive, non-read-only behavior. The description adds context about the multipart request and journal entry creation, complementing annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that directly states the action and method, with no extraneous information. Highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter tool with no output schema, the description covers the core action but omits parameter details and success/failure outcomes, making it minimally adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds no explanation of the 'id' or 'files' parameters—their purpose, format, or constraints—leaving the agent to infer from names alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Upload', the resource 'task', and the method 'single multipart request (one journal entry)', which distinguishes it from sibling tools like task.assign or task.create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for attaching files to a task but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.createCreate task (preview required)A

Create a new bug or task via the unified create-with-submission flow. REQUIRES a previewed-and-approved payload — call this only after the /qms-file prompt has gathered fields, rendered a preview, and the user has explicitly approved. previewedHash is the SHA-256 of the canonical preview JSON; the client refuses mismatches.

ParametersJSON Schema

Name	Required	Description
`subject`	Yes
`description`	No	HTML, ASCII, no code identifiers.
`tracker`	Yes
`projectId`	Yes
`status`	No	Status identifier (e.g. 'new', 'inprogress'). Required for bug/task. Optional for custom.
`priority`	No	Required for bug/task. Optional for custom.
`assigneeId`	No	Required for bug/task. Optional for custom.
`previewedHash`	Yes	SHA-256 of the canonical preview string the user approved. Client recomputes; mismatch is refused.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate non-readonly, non-destructive. The description adds that previewedHash is required and that the client refuses mismatches, disclosing a key behavioral constraint beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences convey purpose and critical usage constraint without redundancy. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers the creation flow, precondition, and one key parameter. It is complete enough for an agent to use effectively, though more detail on error states could push it to 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds essential meaning for previewedHash (SHA-256, mismatch refusal) and sets the overall workflow context. Schema covers other parameters well (63% coverage), so the description enhances rather than repeats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new bug or task via a specific unified flow. It distinguishes itself from sibling tools like task.update or task.assign by focusing on creation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly requires a previewed-and-approved payload and specifies the prerequisite steps, giving clear when-to-use guidance. It could be improved by mentioning when not to use it (e.g., if no preview available), but the precondition is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.getGet task detailA

Read-onlyIdempotent

Full task detail incl. journal, attachments, sub-issues, relations.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark as read-only and idempotent. Description adds that response includes journal, attachments, sub-issues, relations, which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence conveying full scope with a list of included items. No unnecessary words, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple get tool with one parameter and no output schema, description covers what the response contains. Annotations cover behavioral aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description does not clarify that 'id' is the task ID. Parameter is self-explanatory from name, but description could add context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets full task detail including journal, attachments, sub-issues, relations. Distinguishes from sibling tools like task.list (which lists tasks) and task.update (which modifies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly indicates use when needing detailed information on a single task. Lacks explicit when-not or alternatives, but context with siblings makes it clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.listList my tasksA

Read-onlyIdempotent

List tasks assigned to me, newest first. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	No	Restrict to one project.
`includeWatching`	No	Include watched/authored issues instead of only assigned.
`limit`	No
`sort`	No		dateUpdated
`order`	No		desc

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only' adds no new behavioral info beyond confirming. The 'newest first' order is a useful default detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 optional parameters and no output schema, the description lacks details about filtering (projectId, includeWatching) and sort options. The schema descriptions fill some gaps but the overall description could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all parameters, so the description adds no additional semantic value. Baseline of 3 is appropriate given schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists tasks assigned to the user, ordered newest first. This verb-resource combination (list tasks) is distinct from sibling tools like task.get (single task) or task.create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (when needing a list of assigned tasks) but does not explicitly state when not to use or mention alternative tools. However, sibling names are sufficiently distinct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.relateRelate two tasksA

Link this task to another (relates / blocks / duplicates / etc). Prefer this over creating a duplicate when an existing task already covers the same issue (R8).

ParametersJSON Schema

Name	Required	Default
`id`	Yes
`relatedTaskId`	Yes
`relationType`	No	relates

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is not read-only and not destructive. The description adds context about possible relation types but does not disclose further behavioral traits like mutability or reversibility.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with a parenthetical, efficiently conveying purpose and usage guidance without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 3 parameters and no output schema. Description covers purpose and usage but lacks details on side effects, permissions, or link behavior, leaving gaps for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description mentions relation types (relates, blocks, duplicates) which hints at the relationType parameter's possible values, but does not explicitly map to schema parameters. With 0% schema coverage, additional param info is minimal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Link this task to another' with specific relation types (relates, blocks, duplicates, etc.). This distinguishes it from siblings like task.create or task.assign.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to prefer this tool over creating a duplicate when an existing task covers the same issue (R8). This provides clear guidance on when to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.tagTag taskC

Idempotent

Merge a set of claude-* tags into the task. Idempotent.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`add`	No
`remove`	No

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description claims idempotency, matching annotations, but omits the ability to remove tags (as shown in the schema). It also implies tags must start with 'claude-*', which is not enforced by the schema and may mislead agents about allowed tag patterns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with no wasted words. However, it sacrifices completeness, leaving out critical details such as the remove capability. The brevity is a mixed blessing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has three parameters and no output schema, the description should clarify both add and remove behavior. It only covers add, and the 'claude-*' restriction is unsupported. The agent cannot fully understand the tool's behavior from this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description must explain parameters. It partially covers the 'add' parameter by mentioning 'merge', but fails to describe the 'remove' array or the required 'id' parameter. The 'claude-*' prefix adds confusion rather than clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool merges tags into a task, which is clear and distinct from sibling tools that handle assignment, attachment, creation, etc. The verb 'merge' appropriately conveys both adding and removing, but the mention of 'claude-*' tags adds unnecessary specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. While it is the only tag-related tool among siblings, the description does not clarify its role relative to others, such as task.update, or when to prefer task.tag over direct manipulation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

task.updateUpdate task (batched)A

Apply ONE batched change to a task — all non-null fields go in a single journal entry. Use for: starting (status=inprogress), finishing (status=resolved + comment), fixing wrong title/priority alongside other work. Do NOT call twice in a row for the same task.

ParametersJSON Schema

Name	Required	Description
`id`	Yes
`subject`	No
`description`	No	HTML. ASCII only. No code identifiers.
`status`	No	Status identifier (e.g. 'inprogress', 'resolved'). See wrapper://lookups/statuses.
`priority`	No
`comment`	No	Comment text. HTML for structure. ASCII, no code identifiers.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds that non-null fields are batched into a single journal entry, implying atomicity. Annotations already indicate non-readonly and non-destructive. No contradictions; warning about double-calling adds useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and batched behavior. Every sentence adds value; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation tool with annotations and schema, the description covers key usage constraints and the batched nature. No output schema, but the return is likely standard. Completeness is high for the complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%, and the description adds no parameter-specific details beyond the batched nature. The schema itself provides descriptions for description, status, comment, and enum for priority, so the description does not add meaningful extra meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies 'ONE batched change to a task' and lists specific use cases (starting, finishing, fixing title/priority). It distinguishes itself from siblings like task.create and task.get by focusing on updates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'use for' scenarios and a prohibition ('Do NOT call twice in a row for the same task'). However, it does not name alternative tools for related operations (e.g., task.assign for assignments).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.1.0May 25, 2026
- First observedtask.assign
- First observedtask.attach
- First observedtask.create
- First observedtask.get
- First observedtask.list
- First observedtask.relate
- First observedtask.tag
- First observedtask.update

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct action (assign, attach, create, get, list, relate, tag, update) on tasks. There is no overlap; every verb clearly defines a different operation, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tools follow a perfect 'task.verb' pattern using lowercase and dot separation. This consistency makes the tool surface predictable and easy to navigate.

Tool Count5/5

With 8 tools, the set is well-scoped for a task management system. Each tool covers a necessary operation without redundancy or bloat.

Completeness5/5

The tools provide comprehensive coverage for task lifecycle: create, read (get/list), update, plus assignment, tagging, relating, and attachments. The only potential gap is an explicit delete, but the update tool can handle status changes and soft deletion if needed. Overall, it feels complete for the domain.

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QuLab Infinite MCP Server
io.github.Workofarttattoo
QuLab MCP remote server (Streamable HTTP) for computational science and lab tools.
Research & Data Command Line Code Execution
2
Tanjiren MCP Server
app.tanjiren
Hosted MCP server for task-first delegation to remote workstations and workers.
Agent Orchestration Autonomous Agents Developer Tools
2
mcp-serverOAuth
com.pdfgate
MCP server for the PDFGate API. Generate PDFs, manage documents and handle e-signatures.
Documentation Access File Systems
1
mcp-serverOAuth
com.ffmpeg-micro
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
Multimedia Processing App Automation
2

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uvaresearch/qmswrapper-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server