Skip to main content
Glama

proxy_http

Send HTTP requests through a preset that supplies the base URL and credentials. Allow-listed methods and paths are validated before credentials are injected, and each call is audit-logged.

Instructions

Make an HTTP request through a preset. The preset selects the base URL and authentication; you supply path, method, and optional body / query. Allow-listed methods and paths are validated server-side BEFORE any credential is injected. Sensitive presets trigger a desktop / TUI approval prompt; you cannot bypass approval. If the user previously approved a time-boxed window for this preset+action, the call proceeds without a new prompt and is recorded as 'windowed' in the audit log. Every call is recorded to a local audit log.

Input Schema

NameRequiredDescriptionDefault
bodyNoOptional JSON body.
pathYesPath relative to the preset's `base_url`. Must start with `/`.
queryNoOptional query string parameters.
methodYesHTTP method. Must be in the preset's `allowed_methods`.
preset_nameYesName of the preset to use (must exist in `list_presets`).

Output Schema

NameRequiredDescriptionDefault
bodyYesResponse body parsed as JSON; `null` if the upstream body is not JSON.
statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses important behavior: server-side allow-list validation before credential injection, approval prompts for sensitive presets, non-bypassable approval, time-boxed approval windows, and audit logging. This is unusually complete for a security-sensitive proxy tool.

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 front-loaded with the core action and then adds relevant security and audit details. It is generally efficient, though the audit-log point is slightly repeated across sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no annotations, five parameters, and an output schema; the description covers purpose, validation, authentication flow, approval behavior, and audit logging. An agent has enough context to invoke it correctly without needing return-value details.

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 schema already explains all five parameters. The description reinforces the preset/path/method/body/query roles but does not add syntax or semantic detail beyond what the input schema provides.

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?

States a specific verb and resource: making an HTTP request through a preset. It also explains the preset's role and the caller-supplied fields, which clearly distinguishes it from sibling tools like ssh_exec, sftp_transfer, or db_query.

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

Usage Guidelines4/5

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

Provides clear operational context: the preset supplies base URL and authentication, while the caller supplies path, method, and optional body/query. It does not explicitly compare this tool against alternatives or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.