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

fakestore_update_user

Modify user details in a simulated e-commerce environment by providing user ID and updated information like email, address, or username for testing and development purposes.

Instructions

Update an existing user (simulation - does not persist)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUser ID to update
emailNoNew email address
usernameNoNew username
passwordNoNew password
firstnameNoNew first name
lastnameNoNew last name
cityNoNew city
streetNoNew street name
numberNoNew street number
zipcodeNoNew ZIP code
latNoNew latitude
longNoNew longitude
phoneNoNew phone number

Implementation Reference

  • Core execution logic for updating a user. Validates input, constructs partial update object for name and address fields, and sends PUT request to `/users/${id}`.
    export async function updateUser(args: {
      id: number;
      email?: string;
      username?: string;
      password?: string;
      firstname?: string;
      lastname?: string;
      city?: string;
      street?: string;
      number?: number;
      zipcode?: string;
      lat?: string;
      long?: string;
      phone?: string;
    }): Promise<User> {
      const {
        id,
        email,
        username,
        password,
        firstname,
        lastname,
        city,
        street,
        number,
        zipcode,
        lat,
        long,
        phone,
      } = args;
    
      validatePositiveInteger(id, 'User ID');
    
      const updateData: Record<string, unknown> = {};
      if (email !== undefined) {
        validateEmail(email);
        updateData.email = email;
      }
      if (username !== undefined) updateData.username = username;
      if (password !== undefined) updateData.password = password;
      if (phone !== undefined) {
        validatePhone(phone);
        updateData.phone = phone;
      }
    
      // Handle name updates
      if (firstname !== undefined || lastname !== undefined) {
        updateData.name = {};
        if (firstname !== undefined) (updateData.name as Record<string, unknown>).firstname = firstname;
        if (lastname !== undefined) (updateData.name as Record<string, unknown>).lastname = lastname;
      }
    
      // Handle address updates
      if (city !== undefined || street !== undefined || number !== undefined || zipcode !== undefined || lat !== undefined || long !== undefined) {
        updateData.address = {};
        if (city !== undefined) (updateData.address as Record<string, unknown>).city = city;
        if (street !== undefined) (updateData.address as Record<string, unknown>).street = street;
        if (number !== undefined) (updateData.address as Record<string, unknown>).number = number;
        if (zipcode !== undefined) (updateData.address as Record<string, unknown>).zipcode = zipcode;
    
        if (lat !== undefined || long !== undefined) {
          (updateData.address as Record<string, unknown>).geolocation = {};
          if (lat !== undefined) ((updateData.address as Record<string, unknown>).geolocation as Record<string, unknown>).lat = lat;
          if (long !== undefined) ((updateData.address as Record<string, unknown>).geolocation as Record<string, unknown>).long = long;
        }
      }
    
      return put<User>(`/users/${id}`, updateData);
    }
  • Input schema and metadata for the fakestore_update_user tool, part of the userTools array.
    {
      name: 'fakestore_update_user',
      description: 'Update an existing user (simulation - does not persist)',
      inputSchema: {
        type: 'object',
        properties: {
          id: {
            type: 'number',
            description: 'User ID to update',
          },
          email: {
            type: 'string',
            description: 'New email address',
          },
          username: {
            type: 'string',
            description: 'New username',
          },
          password: {
            type: 'string',
            description: 'New password',
          },
          firstname: {
            type: 'string',
            description: 'New first name',
          },
          lastname: {
            type: 'string',
            description: 'New last name',
          },
          city: {
            type: 'string',
            description: 'New city',
          },
          street: {
            type: 'string',
            description: 'New street name',
          },
          number: {
            type: 'number',
            description: 'New street number',
          },
          zipcode: {
            type: 'string',
            description: 'New ZIP code',
          },
          lat: {
            type: 'string',
            description: 'New latitude',
          },
          long: {
            type: 'string',
            description: 'New longitude',
          },
          phone: {
            type: 'string',
            description: 'New phone number',
          },
        },
        required: ['id'],
      },
    },
  • src/index.ts:40-44 (registration)
    Tool registration via ListToolsRequestSchema handler, including userTools which defines fakestore_update_user.
    server.setRequestHandler(ListToolsRequestSchema, async () => {
      return {
        tools: [...productTools, ...cartTools, ...userTools],
      };
    });
  • Dispatch logic in CallToolRequestSchema handler that calls the updateUser function for this tool.
    if (name === 'fakestore_update_user') {
      const result = await updateUser(args as {
        id: number;
        email?: string;
        username?: string;
        password?: string;
        firstname?: string;
        lastname?: string;
        city?: string;
        street?: string;
        number?: number;
        zipcode?: string;
        lat?: string;
        long?: string;
        phone?: string;
      });
      return {
        content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
      };
    }
  • User type definition used as return type for the updateUser handler.
    export interface User {
      id: number;
      email: string;
      username: string;
      password: string;
      name: UserName;
      address: Address;
      phone: string;
    }
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the critical behavioral trait that this is a simulation that 'does not persist,' which is valuable context not inferable from the name or schema. However, it lacks other important details like error handling, response format, or side effects, leaving gaps in transparency.

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 front-loads the core action ('Update an existing user') and appends crucial behavioral context ('simulation - does not persist'). There is no wasted verbiage, and every word serves a clear purpose.

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

Completeness3/5

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

Given the tool's complexity (13 parameters, mutation operation) and lack of annotations and output schema, the description is moderately complete. It covers the simulation nature but misses details like return values, error cases, or prerequisites. It's adequate as a minimum viable description but has clear gaps for a mutation tool.

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 fully documents all 13 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples, constraints, or usage tips). According to the rules, this earns a baseline score of 3 when schema coverage is high.

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 ('Update') and resource ('existing user'), making the purpose evident. It distinguishes from sibling tools like fakestore_add_user (create vs. update) and fakestore_get_user (read vs. update). However, it doesn't specify what fields can be updated beyond the generic 'user' reference, which keeps it from being a perfect 5.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., user must exist), exclusions, or comparisons to siblings like fakestore_update_product or fakestore_update_cart. The agent must infer usage 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.

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