Skip to main content
Glama
nucleusv

Linux MCP daemon

by nucleusv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

network/curl

Destructive

Make one HTTP(S) request to fetch or change a remote endpoint and get status, headers, and body; supports POST, PUT, DELETE, redirects, timeouts, and size limits.

Instructions

Makes one HTTP(S) request with Go's HTTP client and returns status, headers and body. NOT read-only: any method (default GET) is sent as given, so POST, PUT or DELETE change the remote system. Follows redirects (up to 10); a non-2xx status is not an error, check status_code. The default timeout is 10 s (timeout, whole seconds) and the 30 s worker limit caps anything larger. The body is cut at max_body (default 1 MiB, max 10 MiB) and truncated is then true. insecure skips TLS verification. The daemon's proxy environment is honored unless the user has a network: policy in mcp-sudo.yaml; such a policy applies to every call and redirect hop, and a blocked destination fails to connect. Header and body values are redacted in the audit log. Returns JSON with status_code, status, headers (values comma-joined), body, truncated; output_format is ignored. For DNS use network/nslookup, for TCP reachability network/ping, for local files files/read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesFull URL including scheme, e.g. https://example.com/api
bodyNoRequest body
methodNoHTTP method, default GET; any method is sent as given
headersNoRequest headers, e.g. {"Content-Type": "application/json"}
timeoutNoWhole seconds (default 10; the 30 s worker limit caps it)
insecureNoSkip TLS certificate verification
max_bodyNoReturn at most this many bytes of the response body (default 1048576 = 1 MiB, max 10 MiB); a cut body has truncated: true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.4.1
    • addedInput schema / properties / method / description
      Added value: +"HTTP method, default GET; any method is sent as given"
    • addedInput schema / properties / timeout / description
      Added value: +"Whole seconds (default 10; the 30 s worker limit caps it)"
    • addedInput schema / properties / url / description
      Added value: +"Full URL including scheme, e.g. https://example.com/api"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description goes well beyond them: method is sent as given so POST/PUT/DELETE mutate remote state, redirects follow up to 10, non-2xx is not an error, the 10 s default timeout and 30 s worker cap, body truncation at max_body with truncated=true, insecure skipping TLS, the proxy/policy interaction (network: policy in mcp-sudo.yaml applies to every call and redirect hop), and audit-log redaction. This is unusually complete behavioral disclosure.

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?

Front-loads the core purpose and the NOT-read-only warning, then stacks behavioral facts, and closes with sibling routing — a sensible order. It is dense and long for a one-call tool, but nearly every clause carries distinct operational information, so little is wasted.

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?

For a 7-parameter tool with a nested headers object and no output schema, the description still enumerates the returned JSON fields (status_code, status, headers, body, truncated) plus the ignored output_format. Combined with the safety, timeout, truncation, and policy notes, an agent has everything needed to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description meaningfully enriches it: method is sent as given with GET default, timeout is whole seconds with the 30 s cap, and max_body's default (1 MiB) and max (10 MiB) with the truncated flag tie the parameter to observable output. It adds real meaning over the schema rather than restating it.

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+resource ('Makes one HTTP(S) request') and the exact return shape (status, headers, body). It actively distinguishes itself from siblings by routing DNS to network/nslookup, TCP reachability to network/ping, and local files to files/read — an agent can pick this tool without opening any other schema.

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

Usage Guidelines5/5

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

Explicitly names three alternative tools and the condition that selects each (DNS, TCP reachability, local files). It also sets usage context: a non-2xx status is not an error, and one call is one request. Nothing about when to reach for this tool is left to inference.

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