Skip to main content
Glama
Sign In
cmcp

cmcp

by DeveshB-1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Request Methods/PUT Request

request_methods_put_request
Destructive

Sends an HTTP PUT request to transfer data to a server and return its response, supporting query parameters and a raw request body.

Instructions

The HTTP PUT request method is similar to HTTP POST. It too is meant to transfer data to a server (and elicit a response). What data is returned depends on the implementation of the server.

A PUT request can pass parameters to the server using "Query String Parameters", as well as the Request Body. For example, in the following raw HTTP request,

PUT /hi/there?hand=wave

(Postman request: Request Methods/PUT Request | PUT https://postman-echo.com/put)

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

Input Schema

NameRequiredDescriptionDefault
bodyNoRaw request body.Etiam mi lacus, cursus vitae felis et, blandit pellentesque neque. Vestibulum eget nisi a tortor commodo dignissim. Quisque ipsum ligula, faucibus a felis a, commodo elementum nisl. Mauris vulputate sapien et tincidunt viverra. Donec vitae velit nec metus.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.1/5.0
Behavior2/5

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

Annotations already disclose readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the safety profile is covered. The description adds only generic HTTP semantics and a note that the returned data depends on the server implementation; it does not disclose tool-specific behavior such as what the echo endpoint returns, whether the request body is reflected, or any auth/rate-limit details. It does not contradict the annotations.

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

Conciseness2/5

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

The description is written as textbook HTTP documentation rather than a front-loaded tool definition. It spends most of its length on generic PUT semantics and a raw HTTP example, and the only operationally useful endpoint detail appears at the end in a parenthetical. Several sentences do not help an agent select or invoke this specific tool.

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: one optional body parameter and no output schema. Annotations already cover the destructive/open-world safety profile. However, the description still omits the essential tool-specific outcome, namely that it sends a PUT request to postman-echo.com and returns an echo response. For an echo-testing tool, that omission leaves the agent with an incomplete operational picture.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single optional body parameter, which already documents 'Raw request body.' The description does not clarify body format or content type. Worse, it states that a PUT request can pass parameters via query string parameters as well as the request body, which is not represented in the schema and may mislead the agent into expecting query parameters that this tool does not expose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explains the HTTP PUT method in general terms rather than stating what this specific tool does. The only tool-specific detail is the trailing parenthetical naming the Postman request and endpoint, so an agent must infer that the tool sends a PUT request to postman-echo.com. It also blurs sibling differentiation by saying PUT is 'similar to POST' without clarifying when to use this tool rather than request_methods_post_request or request_methods_patch_request.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance. The description notes that PUT is similar to POST, but it does not explain how to choose between PUT, POST, PATCH, or the other request-method siblings. It also does not mention prerequisites, constraints, or the fact that this tool targets an echo endpoint.

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