Skip to main content
Glama
Sign In
douyin-ide-control

douyin-ide-control

by arusheng
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

读取 IDE 控制台错误

douyin_read_console_errors

Read console errors from the IDE embedded DevTools DOM and return clear unsupported reasons when unavailable. Bind to a target project instance by passing projectPath for multi-IDE scenarios.

Instructions

尽最大可能从 IDE 内嵌 DevTools DOM 读取错误；接口不存在时返回明确的不支持原因。传 projectPath 可在多开 IDE 时绑定到目标工程实例。

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": "douyin_read_console_errors"
  }
}

Input Schema

NameRequiredDescriptionDefault
timeoutMsNo
projectPathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

There are no annotations, so the description carries the burden of behavioral disclosure. It uses a read-only verb, communicates best-effort behavior with '尽最大可能', and discloses the unsupported-interface result ('接口不存在时返回明确的不支持原因'). These are meaningful behavioral traits, though timeout behavior and side effects are not covered.

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?

The description is two short sentences with no filler. The core purpose and fallback behavior are front-loaded, and the projectPath guidance is cleanly separated.

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 optional-parameter read tool, this is reasonably complete: it covers what is read, where it is read from, best-effort behavior, unsupported cases, and the projectPath use case. The main gaps are timeoutMs semantics and successful return shape, but these are largely inferable for this operation.

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 schema has zero parameter descriptions, so the description must add meaning. It does add value for projectPath by explaining its role in multi-open IDE binding, but timeoutMs is left entirely to naming inference. This is partial compensation, not complete.

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 operation ('read errors') and the resource ('IDE 内嵌 DevTools DOM'), and even describes the fallback behavior when the interface is unavailable. No sibling tool targets console-error reading, so it is easy to distinguish.

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 intended use case is implied rather than explicitly stated: an agent would use this when IDE/DevTools console errors need to be read. It gives one concrete conditional guideline: pass projectPath when multiple IDE instances are open, but it does not explain when to prefer this tool over siblings.

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