Skip to main content
Glama
Sign In
cmcp

cmcp

by DeveshB-1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Request Methods/POST Request

request_methods_post_request

Sends an HTTP POST request with a raw body to an echo endpoint, returning echoed headers, query parameters, body contents, and the complete requested URI.

Instructions

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

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

POST /hi/there?hand=wave

The parameter "hand" has the value "wave". The request body can be in multiple formats. These formats are defined by the MIME type of the request. The MIME Type can be set using the Content-Type HTTP header. The most commonly used MIME types are:

  • multipart/form-data

  • application/x-www-form-urlencoded

  • application/json

This endpoint echoes the HTTP headers, request parameters, the contents of the request body and the complete URI requested.

(Postman request: Request Methods/POST Request | POST https://postman-echo.com/post)

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_post_request"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoRaw request body.Duis posuere augue vel cursus pharetra. In luctus a ex nec pretium. Praesent neque quam, tincidunt nec leo eget, rutrum vehicula magna. Maecenas consequat elementum elit, id semper sem tristique et. Integer pulvinar enim quis consectetur interdum volutpat.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior4/5

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

With annotations already declaring readOnlyHint=false, destructiveHint=false, and openWorldHint=true, the description adds useful behavior: the endpoint echoes request headers, parameters, body, and URI. It also explains supported request body formats and Content-Type relevance, though it does not discuss auth or rate limits.

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 dominated by a generic HTTP POST explanation, with the tool-specific behavior buried at the end. Much of the text does not help an agent decide when or how to invoke this particular tool, so it is not front-loaded or tightly scoped.

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 echo endpoint with one optional body parameter, annotations covering safety, and no output schema, the description is mostly complete: it explains that the response echoes request details and that the body can use multiple formats. The main gap is the lack of sibling-tool routing guidance.

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%, so the single body parameter is already documented in the schema. The description adds context about body formats and MIME types, but it also mentions setting Content-Type via an HTTP header even though no such parameter appears in the schema, which adds marginal rather than decisive value.

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 final sentence clearly states that this endpoint echoes HTTP headers, request parameters, request body contents, and the complete URI, and the title identifies it as a POST request tool. However, the description does not explicitly distinguish this tool from sibling request-method tools such as get_request, put_request, or 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?

The description explains the HTTP POST method generically but gives no guidance on when to use this tool versus the sibling request-method tools. It also does not state prerequisites, exclusions, or expected contexts for choosing this 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