Skip to main content
Glama
op-enny
by op-enny

fakestore_delete_product

Remove a product from the Fake Store API by specifying its ID. This tool simulates deletion for testing and demo purposes without persisting changes.

Instructions

Delete a product (simulation - does not persist)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesProduct ID to delete

Implementation Reference

  • Core handler function that validates the product ID and calls the API delete endpoint to remove the product.
    export async function deleteProduct(args: { id: number }): Promise<Product> {
      const { id } = args;
      validatePositiveInteger(id, 'Product ID');
      return del<Product>(`/products/${id}`);
    }
  • Tool schema definition including name, description, and input schema requiring a numeric 'id'.
    {
      name: 'fakestore_delete_product',
      description: 'Delete a product (simulation - does not persist)',
      inputSchema: {
        type: 'object',
        properties: {
          id: {
            type: 'number',
            description: 'Product ID to delete',
          },
        },
        required: ['id'],
      },
    },
  • src/index.ts:109-114 (registration)
    Registration in the MCP call tool handler that dispatches to the deleteProduct function and formats the response.
    if (name === 'fakestore_delete_product') {
      const result = await deleteProduct(args as { id: number });
      return {
        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
      };
    }
  • src/index.ts:41-42 (registration)
    Tool list registration for ListToolsRequestSchema, which includes the fakestore_delete_product schema from productTools.
    return {
      tools: [...productTools, ...cartTools, ...userTools],
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: the destructive nature ('Delete') and that it's a simulation without persistence. This covers the core safety profile, though it could add more about error handling or what 'simulation' entails specifically.

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 extremely concise with just one sentence that efficiently communicates both the action and critical behavioral context ('simulation - does not persist'). Every word earns its place, and it's front-loaded with the core purpose.

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 deletion tool with no annotations and no output schema, the description does well by clarifying it's a simulation. This addresses key safety concerns, though it could be more complete by mentioning what happens after deletion (e.g., returns success/failure) or linking to sibling tools for verification.

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%, with the parameter 'id' clearly documented as 'Product ID to delete.' The description doesn't add any additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.

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?

The description clearly states the specific action ('Delete') and resource ('a product'), distinguishing it from sibling tools like fakestore_update_product or fakestore_get_product. It also adds important context about it being a simulation that doesn't persist, which is valuable differentiation.

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

Usage Guidelines3/5

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

The description implies usage context through 'simulation - does not persist,' suggesting this is for testing rather than production. However, it doesn't explicitly state when to use this vs. alternatives like fakestore_update_product or provide clear exclusions, leaving some ambiguity about appropriate use cases.

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

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/op-enny/mcp-server-fakestore'

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