특정 엔드포인트의 응답을 수정하거나 새 엔드포인트를 추가합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | API 경로 (예: /users/{id}) | |
| method | Yes | HTTP 메서드 | |
| status | No | HTTP 상태 코드 (기본: 200) | |
| headers | No | 추가 응답 헤더 (선택) | |
| mock_id | Yes | 목업 서버 ID | |
| response | No | 반환할 응답 JSON 객체 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It does state the dual behavior (modify or add), but it fails to disclose important behavioral traits such as overwrite behavior, whether existing configurations are replaced, required authentication, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded with the core action and clearly phrased, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate but leaves gaps. It mentions the modify-or-add behavior but does not explain that the endpoint is identified by mock_id, method, and path, nor that status/headers can be updated without 'response'. It also lacks context about whether the tool is scoped to a specific mock server or what happens on conflict. The schema fills in parameter details, but the overall workflow is not fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it only references endpoint response, which partially maps to 'response' and 'status' parameters but does not elaborate on format or syntax. The schema already documents all parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies an endpoint's response or adds a new endpoint, using specific verbs (수정/추가) and resource (특정 엔드포인트의 응답). This distinguishes it from sibling tools like create_mock or delete_mock, as it targets endpoint configuration within a mock server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to update an existing endpoint's response or add a new endpoint to a mock. However, it does not explicitly contrast with alternatives (e.g., create_mock for creating a whole mock server) or provide when-not-to-use guidance, leaving the context merely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a distinct operation: create, delete, list, get details, get logs, and update response. There is no overlap or ambiguity between any two tools.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_mock, delete_mock, list_mocks). The verbs are clear and predictably map to actions, with only minor pluralization differences that do not cause confusion.
With exactly 6 tools, the server is well-scoped for its purpose of managing mock API servers. It provides all essential operations without excessive or redundant tools.
The tool surface covers the full lifecycle of a mock server: create, read (list and get details), update responses, and delete. Logs add extra visibility, and there are no obvious missing operations for the intended use case.