Manage display of "Run as Task" checkbox on Tools Tab

[cliffhall]

Summary

The "Run as Task" button is always available on the Tools Tab. But if a tool that cannot be run as a task has this checkbox checked when you run it, you get an error. This is confusing, because the availability of the "Run as Task" checkbox would indicate to a user that this tool could be run as a task.

• "Run as Task" is hidden for tools whose execution.taskSupport setting is forbidden.
• "Run as Task" is shown, enabled, and unchecked for tools whose execution.taskSupport setting is optional.
• "Run as Task" is shown, disabled, and checked for tools whose execution.taskSupport setting is required.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Build/CI improvements

Changes Made

• In ToolsTab.tsx
  • define ExtendedTool interface for augmenting with execution, meta, icons
  • in hasMeta function,
    • cast tool as ExtendedTool
  • add getTaskSupport function
    • returns forbidden if input is not a tool
    • returns the setting of execution.taskSupport if set and valid
    • returns optional otherwise
    • in useEffect map callback
      • set runAsTask to true if getTaskSupport returns "required", else false
    • in IconDisplay instances cast tool as ExtendedTool instead of as WithIcons
    • hide "Run as Task" checkbox if getTaskSupport returns "forbidden" for the selected tool
    • disable the "Run as Task" checkbox if getTaskSupport returns "required"
• In ToolsTab.test.tsx
  • added unit test
    • "should show/hide/disable run-as-task checkbox based on taskSupport"
      • tests checkbox checked and disabled states for "forbidden", "required", and "optional" states

Related Issues

• Fixes Always present "Run as Task" checkbox is confusing #1071

Testing

• Tested in UI mode
• Tested in CLI mode
• Tested with STDIO transport
• Tested with SSE transport
• Tested with Streamable HTTP transport
• Added/updated automated tests
• Manual testing performed

Test Results and/or Instructions

1. Run the Everything server npx @modelcontextprotocol/server-everything@latest streamableHttp
2. Run the Inspector: npx @modelcontextprotocol/inspector@latest
3. Click Connect
4. Click List Tools
5. Click "Echo" tool in list (this tool's execution.taskSupport setting is "forbidden")
6. See "Run as Task" checkbox is not available.
7. Click "Simulate Research Query" tool in list
8. See "Run as Task" checkbox is available, checked, and disabled (this tool's execution.taskSupport setting is "required")
   NOTE: We don't have a tool that has an execution.taskSupport setting of "optional", but it's unit tested.

taskSupport == "forbidden"

taskSupport == "required"

Checklist

• [x ] Code follows the style guidelines (ran npm run prettier-fix)
• Self-review completed
• Code is commented where necessary
• [] Documentation updated (README, comments, etc.)

Breaking Changes

Nope.

[Randgalt]

I can confirm the checkbox is now disabled and checked. But, we still get this behavior: #1073

[cliffhall]

But, we still get this behavior: #1073

That turns out to be an SDK spec compliance gap that should be closed when modelcontextprotocol/typescript-sdk#1210 lands.

[BobDickinson]

@claude /review

[claude]

Claude finished @BobDickinson's task in 2m 24s —— View job

---

Code Review

• Gather context
• Read changed files
• Analyze diff
• Check MCP spec for task support
• Post review feedback

---

Overview

This PR addresses a real UX problem: the "Run as Task" checkbox was always visible, leading users to believe any tool could be run as a task, then getting a confusing error when it couldn't. The approach — hiding/disabling the checkbox based on execution.taskSupport — is conceptually correct and aligns with the MCP spec.

---

Issues

1. Default fallback contradicts the MCP spec (significant)

client/src/components/ToolsTab.tsx:85

// Current code - returns "optional" when taskSupport is absent
return "optional";

The MCP spec is explicit:

"forbidden": Tool does not support task-augmented execution (default when absent)
If execution.taskSupport is not present or "forbidden", clients MUST NOT attempt to invoke the tool as a task.

The current fallback of "optional" means any tool that doesn't explicitly declare taskSupport will show the checkbox enabled — which is both spec-incorrect and can still cause errors for tools that don't actually support tasks. The fallback should be "forbidden":

return "forbidden"; // Default per MCP spec when execution.taskSupport is absent

This also makes the fix more impactful: instead of only hiding the checkbox for tools that declare taskSupport: "forbidden", it will be hidden for all tools that don't explicitly opt in. Fix this →

2. Missing server capability check (moderate)

The MCP spec also states:

If a server's capabilities do not include tasks.requests.tools.call, then clients MUST NOT attempt to use task augmentation on that server's tools, regardless of the execution.taskSupport value.

The ToolsTab component doesn't receive serverCapabilities as a prop, so there's no way to enforce this rule. Even if a tool declares taskSupport: "required", if the server doesn't advertise tasks.requests.tools.call, the checkbox shouldn't appear. This could be a follow-up issue but is worth noting for spec compliance.

3. Import path inconsistency (minor)

client/src/components/ToolsTab.tsx:53

// Changed from:
} from "@/utils/metaUtils";
// To:
} from "../utils/metaUtils";

Every other import in the file uses the @/ alias (lines 1–45). This appears to be an accidental change. Fix this →

4. Misleading comment (minor)

client/src/components/ToolsTab.tsx:71

// Type guard to detect execution.taskSupport
const getTaskSupport = (tool: Tool | null): "forbidden" | "required" | "optional" => {

getTaskSupport is not a type guard — type guards return boolean and use is type predicates. The comment should say something like // Returns the execution.taskSupport value for a tool, defaulting to "forbidden".

5. getTaskSupport called twice in render (minor)

client/src/components/ToolsTab.tsx:691–714

{getTaskSupport(selectedTool) !== "forbidden" && (
  // ...
  disabled={getTaskSupport(selectedTool) === "required"}

getTaskSupport is a pure function with no side effects, so calling it twice is functionally fine, but it reads cleaner with a variable:

const taskSupport = getTaskSupport(selectedTool);
{taskSupport !== "forbidden" && (
  // ...
  disabled={taskSupport === "required"}

6. Duplicated ExtendedTool interface in tests (minor)

ExtendedTool is defined both in ToolsTab.tsx and re-declared identically in ToolsTab.test.tsx. If ExtendedTool were exported from the component file, the test could import it rather than duplicating the definition.

---

Test Coverage

The new test covers the three taskSupport states and verifies correct checkbox visibility, checked state, and disabled state — good. One note: the test is marked async but contains no await calls. This is harmless but may indicate the test was written with intent to use async matchers that weren't ultimately needed.

---

Summary

The core idea is sound and the implementation handles the three explicit states correctly. The primary concern is the default fallback should be "forbidden" per the MCP spec — this is both a spec compliance issue and affects the user-facing behavior for the large majority of tools that don't declare execution.taskSupport at all. The import path regression is a small but clean fix.