Skip to main content
Glama
Sign In
dify-canvas-mcp

dify-canvas-mcp

by elegant01
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

dify_browser_status

Checks which Chrome browser channels are available for Dify canvas automation, including pool, debug-port, dedicated instances, and zero-restart autoConnect, without triggering Chrome authorization.

Instructions

查看当前可用的浏览器通道：chrome-pool、日常 Chrome 的调试端口、专用 Chrome，以及能否用 autoConnect 直接连日常 Chrome（零重启）。不会触发 Chrome 授权。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dify_browser_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
aliasNo可选。实例别名。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses one key side effect — 'won't trigger Chrome authorization' — but does not say whether probing channels could start anything, how long it takes, or what form the answer takes.

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

Conciseness4/5

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

A single front-loaded sentence enumerating the channels, followed by the no-authorization guarantee. Dense but every clause carries information; minor cost is the parenthetical '(零重启)' which reads as emphasis rather than new facts.

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 read-only status/probe tool with one optional parameter and no output schema, the description covers what is inspected and one important non-effect. The main remaining gap is the absence of any hint about the shape of the status result an agent should expect.

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 description coverage is 100% and there is only one optional 'alias' parameter, so the schema already explains it. The description adds nothing about what an alias scopes to, leaving the baseline score appropriate.

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 names a specific verb and resource — reporting the available browser channels (chrome-pool, daily Chrome debug port, dedicated Chrome) and whether autoConnect can attach to daily Chrome. This is clearly distinct from dify_browser_launch, but the description never names that sibling to make the difference explicit.

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?

Use is only implied: an agent can infer this is a pre-flight/diagnostic check, especially given the note that it won't trigger authorization. There is no explicit 'call this before dify_browser_launch' or statement of when it should be skipped.

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

Deploy Server

Other Tools