Skip to main content
Glama
Sign In
kr-pc-deals-mcp

kr-pc-deals-mcp

by edward-kim-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

build_remove

Remove a chosen component category from your PC build to refresh assembly estimates and compatibility checks.

Instructions

빌드에서 특정 카테고리의 부품을 제거합니다.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "category": "<category>"
    },
    "name": "build_remove"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryYes제거할 부품의 카테고리

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.7

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says parts are removed from the build, without stating whether the removal is permanent, whether it removes all parts in the category or a specific one, or what the effect on the build is.

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?

The description is a single short sentence with no filler, and the action/resource are front-loaded. It is efficiently written, though it omits contextual details that would make it more useful.

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?

The tool is simple, with one fully documented enum parameter and no output schema, so a long description is not required. However, because there are no annotations and the description is ambiguous about the scope of removal, it is only minimally complete for an agent calling the tool.

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 covers 100% of the parameter: category is required, enum-valued, and described. The description adds no meaning beyond the schema's own description, so the baseline score of 3 is appropriate.

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 states the action ('removes') and the object ('parts in a category from the build'), which clearly distinguishes it from siblings such as build_add and build_status. An agent can understand the tool's role without opening the schema.

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 use when the user wants to remove a category part from a build, but it gives no explicit when-to-use guidance or mention of alternatives. It does not clarify when this tool should be preferred over build_add or other build-related tools.

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