Skip to main content
Glama

api_post

Send data to an API endpoint using a POST request. Specify the URL, JSON body, and headers to interact with web services and automate API-based tasks effectively.

Instructions

Perform a POST request to an API endpoint

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesRequest body data (JSON string)
headersNoRequest headers
urlYesAPI endpoint URL

Implementation Reference

  • The handler function that executes the api_post tool: sends POST request with provided data and headers, retrieves response, and returns formatted result or error.
    async function handleApiPost(client: APIRequestContext, args: any): Promise<{ toolResult: CallToolResult }> {
      try {
        const options = {
          data: args.data,
          headers: args.headers || { 'Content-Type': 'application/json' }
        };
    
        const response = await client.post(args.url, options);
        const responseData = await getResponseData(response);
    
        return {
          toolResult: {
            content: [
              {
                type: "text",
                text: `POST ${args.url} - Status: ${response.status()}`,
              },
              ...responseData
            ],
            isError: false,
          },
        };
      } catch (error) {
        return {
          toolResult: {
            content: [{
              type: "text",
              text: `POST request failed: ${(error as Error).message}`,
            }],
            isError: true,
          },
        };
      }
  • The Tool schema definition for api_post, including name, description, and inputSchema with required url and data.
    {
      name: "api_post",
      description: "Perform a POST request to an API endpoint",
      inputSchema: {
        type: "object",
        properties: {
          url: { type: "string", description: "API endpoint URL" },
          data: { type: "string", description: "Request body data (JSON string)" },
          headers: { 
            type: "object", 
            description: "Request headers",
            additionalProperties: { type: "string" }
          }
        },
        required: ["url", "data"]
      }
    },
  • Switch case in executeToolCall that registers and dispatches the api_post tool call to its handler.
    case "api_post":
      return await handleApiPost(apiClient!, args);
  • API_TOOLS constant listing api_post among API tools, used to identify and initialize API client in executor.
    export const API_TOOLS = [
      "api_get",
      "api_post",
      "api_put",
      "api_patch",
      "api_delete"
    ];
  • Helper function getResponseData used by api_post handler to process and format API response body.
    async function getResponseData(response: any): Promise<TextContent[]> {
      const contentType = response.headers()['content-type'] || '';
      let responseText: string;
      if (contentType.includes('application/json')) {
        try {
          const json = await response.json();
          responseText = JSON.stringify(json, null, 2);
        } catch (e) {
          responseText = await response.text();
        }
      } else {
        responseText = await response.text();
      }
      return [{
        type: "text",
        text: `Response body:\n${responseText}`,
      } as TextContent];
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention authentication requirements, rate limits, error handling, response formats, or any side effects. For a general-purpose API tool with mutation capability, this leaves critical behavioral traits undocumented.

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

Conciseness5/5

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

The description is a single, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a straightforward tool and front-loads the essential information.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address authentication, error handling, response expectations, or when to use versus siblings. Given the complexity of making API calls and the lack of structured safety information, more context is needed.

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 documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline expectation but not providing extra 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 description clearly states the verb ('Perform a POST request') and resource ('to an API endpoint'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling api_* tools beyond the HTTP method, missing an opportunity to clarify when POST is specifically appropriate versus other methods.

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?

No guidance is provided about when to use this tool versus alternatives like api_put or api_patch, nor when it's appropriate versus browser-based tools. The description merely restates what the tool does without contextual usage advice, leaving the agent to infer appropriate scenarios.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/imprvhub/mcp-browser-agent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server