Claude 및 기타 LLM에 고급 HTTP 요청 기능을 제공하는 모델 컨텍스트 프로토콜(MCP) 서버입니다. rquest 기반으로 구축된 이 서버는 정확한 TLS/JA3/JA4 지문을 사용하여 현실적인 브라우저 에뮬레이션을 지원하여 모델이 웹사이트와 더욱 자연스럽게 상호 작용하고 일반적인 봇 방지 조치를 우회할 수 있도록 합니다. 또한 LLM의 더 쉬운 처리를 위해 PDF 및 HTML 문서를 마크다운으로 변환하는 기능도 지원합니다.
완전한 HTTP 메서드 : GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS 및 TRACE 지원
브라우저 지문 : 정확한 TLS, JA3/JA4 및 HTTP/2 브라우저 지문
콘텐츠 처리 :
토큰 카운팅을 통한 대량 응답 자동 처리
더 나은 LLM 처리를 위한 HTML에서 Markdown으로의 변환
Marker 라이브러리를 사용하여 PDF를 Markdown으로 변환
시스템 임시 디렉토리에 응답을 안전하게 저장합니다.
인증 지원 : 기본, 베어러 및 사용자 정의 인증 방법
사용자 정의 요청 :
헤더, 쿠키, 리디렉션
폼 데이터, JSON 페이로드, multipart/form-data
쿼리 매개변수
SSL 보안 : 현실적인 브라우저 지문을 사용하여 안전한 연결을 위해 BoringSSL을 사용합니다.
Related MCP server: URL Fetch MCP
HTTP 요청 도구 :
http_get - 선택적 매개변수를 사용하여 GET 요청 수행
http_post - POST 요청을 통해 데이터 제출
http_put - PUT 요청으로 리소스 업데이트
http_delete - DELETE 요청으로 리소스 제거
http_patch - 리소스를 부분적으로 업데이트합니다
http_head - 리소스에서 헤더만 검색
http_options - 리소스에 대한 옵션 검색
http_trace - 진단 요청 추적
응답 처리 도구 :
get_stored_response - 저장된 대용량 응답을 검색합니다(옵션으로 줄 범위별로).
get_stored_response_with_markdown - 더 나은 LLM 처리를 위해 HTML 또는 PDF 응답을 Markdown 형식으로 변환합니다.
get_model_state - PDF 모델 로딩 프로세스의 현재 상태를 가져옵니다.
restart_model_loading - PDF 모델 로딩 프로세스가 실패하거나 중단된 경우 다시 시작합니다.
mcp-rquest는 이제 PDF에서 Markdown으로의 변환을 지원하여 PDF 파일을 다운로드하여 LLM이 쉽게 처리할 수 있는 Markdown 형식으로 변환할 수 있습니다.
자동 PDF 감지 : PDF 파일은 콘텐츠 유형에 따라 자동으로 감지됩니다.
원활한 변환 : 동일한 get_stored_response_with_markdown 도구가 HTML 및 PDF 파일 모두에 적용됩니다.
고품질 변환 : 정확한 PDF에서 Markdown으로의 변환을 위해 Marker 라이브러리를 사용합니다.
최적화된 성능 : 요청 처리 중 지연을 방지하기 위해 패키지 설치 중에 모델이 미리 다운로드됩니다.
uv 사용하면 별도의 설치가 필요하지 않습니다. uvx 사용하여 mcp-rquest를 직접 실행하겠습니다.
또는 pip를 통해 mcp-rquest 설치할 수 있습니다.
지엑스피1
설치 후 다음을 사용하여 스크립트로 실행할 수 있습니다.
python -m mcp_rquestClaude 설정에 추가:
uvx 사용:
{
"mcpServers": {
"http-rquest": {
"command": "uvx",
"args": ["mcp-rquest"]
}
}
}pip 사용하기:
{
"mcpServers": {
"http-rquest": {
"command": "python",
"args": ["-m", "mcp_rquest"]
}
}
}pipx 사용하기:
{
"mcpServers": {
"http-rquest": {
"command": "pipx",
"args": ["run", "mcp-rquest"]
}
}
}mcp-rquest는 rquest의 강력한 브라우저 에뮬레이션 기능을 활용하여 현실적인 브라우저 지문을 제공합니다. 이를 통해 봇 탐지를 우회하고 일반적으로 표준 브라우저에서만 제공되는 콘텐츠에 접근할 수 있습니다. 지원되는 브라우저 지문은 다음과 같습니다.
크롬(여러 버전)
파이어폭스
Safari(iOS 및 iPad 버전 포함)
가장자리
OkHttp
이렇게 하면 mcp-rquest를 통해 전송된 요청이 봇 요청이 아닌 합법적인 브라우저 트래픽으로 표시됩니다.
저장소를 복제합니다
uv를 사용하여 가상 환경을 만듭니다.
uv venv가상 환경을 활성화합니다.
# Unix/macOS
source .venv/bin/activate
# Windows
.venv\Scripts\activate개발 종속성 설치:
uv pip install -e ".[dev]"Get the current state of the PDF models(used by get_stored_response_with_markdown) loading process
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not mention side effects, read-only nature, or any state-changing behavior. The word 'get' suggests a safe operation, but this is not explicitly stated.
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 sentence that directly conveys the tool's purpose without unnecessary detail. Minor punctuation issues do not detract from its clarity.
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?
While the description names the resource (PDF models) and the action (get state), it does not specify the format or nature of the state (e.g., loading, loaded, error). The reference to another tool provides some context, but the lack of output schema and details leaves some ambiguity.
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?
There are zero parameters, so the baseline is 4. The description does not need to explain parameters since none exist, and it adequately describes the tool's action.
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 retrieves the loading state of PDF models, referencing a related tool. However, it does not explicitly differentiate from sibling tools like `restart_model_loading`, though the intent is understandable.
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 provides no guidance on when to use this tool versus alternatives. It only mentions that it is used by `get_stored_response_with_markdown`, implying a supporting role, but does not state explicit conditions or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a stored HTTP response by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| end_line | No | Ending line number (inclusive) | |
| start_line | No | Starting line number (1-indexed) | |
| response_id | Yes | ID of the stored response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states a read operation ('Retrieve') but does not mention any side effects, error handling, auth requirements, or return format. It also does not mention that the response can be filtered by line numbers, which is a behavioral capability not disclosed. The description is minimal and adds no depth beyond the action itself.
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 wasted words. The key action and target are front-loaded. It is appropriately sized for a simple retrieval tool, though it could have been enriched with sibling differentiation without sacrificing conciseness.
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 incomplete for an agent to use correctly. It does not mention the optional start_line and end_line parameters, which allow partial retrieval of the stored response. It also fails to distinguish this tool from the sibling 'get_stored_response_with_markdown', leaving the agent uncertain about which output format to expect. With no output schema and no additional context, the description leaves significant gaps for correct invocation.
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?
The schema provides 100% coverage for all three parameters (response_id, start_line, end_line) with descriptions. The tool description adds nothing beyond identifying response_id as the lookup key. It does not explain the relationship between start_line and end_line or their purpose, though the schema does. Since the schema already documents the parameters, the description's contribution is neutral, meeting the baseline for high schema coverage.
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 verb 'Retrieve' and the resource 'stored HTTP response', and identifies the key parameter 'by its ID'. However, it does not differentiate from the sibling 'get_stored_response_with_markdown', which likely serves the same core purpose with a different output format. The purpose is clear but not uniquely distinguished.
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?
There is no guidance on when to use this tool versus alternatives such as 'get_stored_response_with_markdown'. No context is given about when line parameters should be used or when this tool is preferred over the markdown variant. The description offers no usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a stored HTTP response by its ID and convert it to Markdown format. Supports HTML and PDF content types. (Converting large PDF to Markdown may cause timeout, just wait and try again.)
| Name | Required | Description | Default |
|---|---|---|---|
| response_id | Yes | ID of the stored response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It covers the main operation, supported formats, and a timeout caveat for large PDFs, but it does not mention potential side effects, error cases, or whether the operation is strictly read-only.
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 concise and well-structured, with a clear two-sentence explanation plus a useful timeout note. No unnecessary words or repetition are present.
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 gives enough context for a simple retrieval-and-convert tool: what it does, the supported formats, and a practical timeout warning. It lacks explicit error behavior details, but the main use case is adequately covered for an agent to call it correctly.
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?
The schema already describes response_id as 'ID of the stored response', and the tool description only repeats 'by its ID'. No additional meaning is added beyond the schema, so the baseline score applies.
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 identifies the action: retrieving a stored HTTP response by ID and converting it to Markdown. It also specifies supported content types (HTML, PDF), making the tool's purpose distinct from the sibling get_stored_response.
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 for retrieving stored responses and converting them to Markdown, and it mentions HTML/PDF support. However, it does not explicitly state when to prefer this tool over the sibling get_stored_response or other HTTP tools, leaving the choice somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP DELETE request to the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects, response handling, error behavior, or authentication requirements. The one-sentence description reveals none of these, making it almost tautological.
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 extremely concise and clearly structured, using a single active-voice sentence. It has no redundant words or filler, making it easy to read and parse.
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?
Given the rich parameter set and sibling tools, the description lacks essential context: when to use DELETE over other methods, expectations about response retrieval, or implications of the many options. It is not sufficient for an agent to decide confidently.
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?
The schema provides descriptions for all 11 parameters, so the baseline is 3. The tool description adds no extra meaning to the parameters; it only repeats 'specified URL' which is already in the schema.
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 action: making an HTTP DELETE request to a specified URL. It distinguishes itself from sibling HTTP methods by explicitly naming the DELETE verb.
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 does not provide any guidance on when to use this tool versus alternatives like POST or PUT, nor does it mention typical use cases such as resource deletion. It only states what the tool does without contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP GET request to the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral aspects. It does not state that GET is read-only, how redirects or auth are handled, or what happens with response content. The description is silent on side effects and safety.
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, focused sentence with no redundant information. It is concise and efficiently communicates the core action, though it could be slightly more informative without becoming verbose.
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 lacks essential context for an agent. It does not explain how the response is returned or stored, how to access response content (especially given sibling get_stored_response tools), or any error-handling behavior. This makes the tool incomplete from a usability standpoint.
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?
The schema provides descriptions for all 11 parameters, achieving 100% coverage. The description itself adds no extra semantic detail beyond the schema, so a baseline score of 3 is appropriate.
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 action (make an HTTP GET request) and the object (specified URL). However, it lacks any contextual distinction from sibling tools (e.g., other HTTP methods or response retrieval tools), so the purpose is clear but minimal.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that responses are stored and may be retrieved via get_stored_response, nor does it discuss any preconditions or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP HEAD request to retrieve only headers from the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It does not mention redirect following (though parameters exist), whether response content is stored, or any side effects. The description is too sparse to set expectations beyond the bare request.
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, focused sentence with no extraneous words or repletion. It effectively communicates the essential purpose without padding.
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?
Without an output schema, the description should clarify what is returned (e.g., status code, headers, no body) and possible error behavior. It only states 'retrieve only headers' without specifying the response structure, leaving significant gaps for the agent.
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?
The schema provides 100% coverage with clear descriptions for each parameter (e.g., query parameters as array of key-value pairs). The tool description adds no extra nuance or guidance on how parameters interact with the HEAD request, so it stays at the baseline for schema-complete coverage.
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 action (make an HTTP HEAD request) and the specific resource (headers from a URL). It distinguishes from siblings by emphasizing 'retrieve only headers', which sets it apart from GET/POST/other methods.
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 only implicitly suggests when to use the tool ('retrieve only headers') but does not explicitly direct the user to choose this over GET or other methods when a body is not needed. No comparison with alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP OPTIONS request to retrieve options for the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only says 'retrieve options,' implying a read operation, but it does not mention whether the request is stored, how redirects are handled, authentication requirements, or any side effects. The description fails to disclose the behavior of the 11 parameters or the nature of the response, leaving significant uncertainty for a tool that makes network calls.
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 sentence with no wasted words. It is concise and front-loaded with the action. It achieves clarity without verbosity, 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 tool has 11 parameters, no output schema, and no annotations. The description provides no information about response format, error handling, authentication nuances, or the meaning of parameters like auth vs. basic_auth vs. bearer_auth. It is far too sparse to fully inform an agent about how to correctly invoke this tool and interpret its results, especially given the richness of the parameter set.
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 all parameters are already described in the input schema. The description adds no additional parameter semantics beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when the schema handles parameter documentation thoroughly.
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 verb (Make an HTTP OPTIONS request) and the resource (specified URL), and specifies the action as retrieving options. It is distinct from siblings by naming the HTTP method, though it doesn't explicitly contrast with GET/POST/etc., which is implicit in the tool name. The purpose is clear and unambiguous.
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 provides no guidance on when to use this tool versus alternatives like http_get or http_post. It doesn't mention typical use cases for OPTIONS (e.g., CORS preflight) or when it would be preferable. There is no exclusion criteria or context for choosing this method, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP PATCH request to the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| body | No | Request body | |
| form | No | Form data as [[key, value], ...] | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| multipart | No | Multipart data as [[key, value], ...] | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| json_payload | No | JSON payload | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any side effects, potential destructive nature, or special behavior of the request (e.g., whether it modifies resources). It only states the action, leaving behavioral transparency minimal.
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 words. It conveys the core functionality efficiently.
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?
Given the tool has 15 parameters and no output schema, the description is too sparse. It does not explain what the response contains, whether content is stored, or any error/redirect behavior. The minimal information may leave agents uncertain about expected outcomes beyond making the request.
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?
The schema covers all 15 parameters with basic descriptions (e.g., 'URL to send the request to'), achieving 100% coverage. However, the descriptions are terse and do not clarify distinctions between overlapping fields like auth, basic_auth, and bearer_auth beyond their obvious names. The baseline score of 3 applies because schema coverage is complete, but no added meaning is provided.
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 it makes an HTTP PATCH request to a specified URL, which is a specific verb and resource. It naturally distinguishes itself from sibling tools like http_get, http_post, etc., making its purpose unambiguous.
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?
While it doesn't explicitly say when to use this tool over alternatives, the HTTP method name itself implies its use case (e.g., partial updates). The context of sibling tools with different HTTP verbs provides implicit guidance, which is sufficient for straightforward selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP POST request to the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| body | No | Request body | |
| form | No | Form data as [[key, value], ...] | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| multipart | No | Multipart data as [[key, value], ...] | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| json_payload | No | JSON payload | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only states the action without mentioning response handling, error behavior, redirects, authentication requirements, or side effects. The extensive parameter list (auth, redirects, etc.) is entirely unaddressed.
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 sentence with no fluff, achieving high conciseness. However, it is so minimal that it omits critical context, making it under-specified rather than appropriately concise. It is front-loaded but lacks substance.
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?
With 15 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the purpose of the many body/form/multipart options, auth mechanisms, or how responses are stored (given sibling tools like get_stored_response). An agent would need to rely heavily on parameter names and descriptions.
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 all 15 parameters have descriptions. The tool description adds no extra meaning beyond the schema, which is acceptable given the high coverage. However, it does not clarify ambiguous parameters like 'auth' versus 'basic_auth' or 'bearer_auth', but the schema descriptions already exist.
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 action 'Make an HTTP POST request' with a specific verb and resource (URL). However, it does not differentiate from sibling tools like http_put or http_patch beyond the method name, so it lacks explicit sibling distinction.
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?
No guidance is provided on when to use this tool versus alternatives like http_get or http_put. The description does not mention typical use cases, prerequisites, or exclusions, leaving the agent to infer the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP PUT request to the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| body | No | Request body | |
| form | No | Form data as [[key, value], ...] | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| multipart | No | Multipart data as [[key, value], ...] | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| json_payload | No | JSON payload | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries all responsibility for disclosing side effects, auth requirements, or other behavioral implications. It states no such information, omitting whether the request mutates state, requires special headers, or has any known pitfalls.
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 short sentence with no redundancy, but it is under-specified. It fails to front-load key information such as the purpose of PUT or anything about the request body, making it too lean to be genuinely helpful.
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 tool has 15 parameters and no output schema, so the description must provide context about expected behavior and response handling. It offers none, leaving the agent without essential information for correctly using all the options.
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?
The schema descriptions for parameters are present and cover 100% of the 15 parameters, so the baseline is 3. The tool description adds no extra semantic meaning to any parameter, relying entirely on the per-parameter descriptions already in the schema.
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 action ('Make') and the resource ('HTTP PUT request to the specified URL'), distinguishing it from sibling methods like http_post or http_patch by explicitly naming PUT. It is not a tautology, though it lacks a brief note on the typical use case (e.g., updating resources).
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention idempotency, or contrast PUT with POST or PATCH, leaving the agent without direction for method selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make an HTTP TRACE request for diagnostic tracing of the specified URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to send the request to | |
| auth | No | Authentication credentials | |
| proxy | No | Proxy to use for the request | |
| query | No | Query parameters as [[key, value], ...] | |
| cookies | No | Cookies to include in the request | |
| headers | No | Headers to include in the request | |
| basic_auth | No | Basic auth credentials as [username, password] | |
| bearer_auth | No | Bearer token for authentication | |
| max_redirects | No | Maximum number of redirects to follow | |
| allow_redirects | No | Whether to follow redirects | |
| force_store_response_content | No | Force storing response content regardless of size |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states what the tool does and gives no information about side effects, safety, idempotency, or whether it is read-only. Since no annotations are provided, the description carries the full burden and falls short.
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, clear sentence with no fluff or redundancy. It is appropriately sized for the tool's purpose.
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?
Given there is no output schema and the tool is a straightforward HTTP method, the description is adequate but not fully complete. It omits details about response handling, error behavior, and the practical implications of the many configurable parameters (e.g., force_store_response_content), which could leave an agent uncertain in complex scenarios.
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% (all 11 parameters are described in the input schema). The tool description adds no additional meaning, constraints, or relationships beyond the schema, so it stays at the baseline score of 3.
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 states a specific verb ('Make') and resource ('HTTP TRACE request') with a clear target (specified URL), instantly distinguishing it from sibling http_get, http_post, http_delete, etc. tools.
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?
While 'for diagnostic tracing' hints at a use case, the description does not explicitly state when to choose TRACE over other HTTP methods, nor does it mention alternatives or conditions under which it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the PDF models(used by get_stored_response_with_markdown) loading process if it failed or got stuck
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'restart' without disclosing potential side effects (e.g., whether it terminates an ongoing process, clears state, or is destructive). The tool's impact on the system is vague, leaving the agent uncertain about its consequences.
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, focused sentence. The parenthetical reference to `get_stored_response_with_markdown` adds relevant context without unnecessary verbosity. It is concise and well-structured.
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 explains the purpose, the related tool, and the trigger condition, providing enough context for a simple no-parameter action. It does not discuss expected outcomes or post-conditions, but for this straightforward tool, the given context is adequate.
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?
The tool has no parameters, so the empty schema is fully covered. There is nothing to describe, making this a neutral score. The description does not mention parameters because none exist.
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 identifies the action (restart), the target (PDF models loading process), and the condition (if failed or stuck). Referencing the related tool `get_stored_response_with_markdown` adds useful context, though the exact nature of 'restart' could be slightly more explicit.
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?
It provides specific conditions for use: only when the process failed or got stuck. This implicitly communicates when not to use it, but it does not elaborate on any prerequisites or fallback steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1get_model_stateget_stored_responseget_stored_response_with_markdownhttp_deletehttp_gethttp_headhttp_optionshttp_patchhttp_posthttp_puthttp_tracerestart_model_loadingScored across 12 tools
The HTTP method tools are clearly distinct, and the two stored response tools are differentiated by markdown conversion. However, get_stored_response and get_stored_response_with_markdown could be confused by an agent without careful reading, but descriptions mitigate ambiguity.
All tool names follow a consistent snake_case verb_noun pattern, with http_ prefix for HTTP methods and clear action words like get, restart, and retrieve. The naming is highly predictable and uniform.
12 tools is well-scoped for an HTTP client with model management and stored response retrieval. Each tool has a clear purpose, and the count is neither sparse nor overwhelming.
The HTTP methods cover all standard request types, and stored response handling is present. Minor gaps include no tool to clear or list stored responses, and model state tools are limited to get and restart, but core functionality is complete.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Remote streamable-HTTP MCP server running on a single Cloudflare Worker. Your assistant gets live Airbnb, Amazon, Booking.com, Google Flights, Maps and Reddit data, social search on X, Instagram and TikTok, the Meta Ad Library, and image/video generation without any keys. Connect your own accounts to let it send WhatsApp or Telegram messages, work an IMAP inbox, manage Meta Ads campaigns and publish to X and LinkedIn. OAuth 2.1 with PKCE; stored credentials are AES-256-GCM encrypted.
A Model Context Protocol server for Wix AI tools
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
