Skip to main content
Glama

update_app_endpoint

Update an existing endpoint's exposed columns, methods, or active status. Pass endpoint ID from list_app_endpoints and column IDs from get_board_schema.

Instructions

Change an existing endpoint — most often to set exposedColumns on one that was created without them. Get the endpoint id from list_app_endpoints and the column ids from get_board_schema.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-readable name
slugNoURL slug: lowercase letters, digits and dashes
appIdYesApp id or slug (from list_apps / create_app)
isActiveNoWhether it is active
endpointIdYesEndpoint id (from list_app_endpoints)
allowedMethodsNoHTTP methods the endpoint accepts: GET, POST, PATCH, DELETE
exposedColumnsNoReplacement list of exposed columns (same shape as create_app_endpoint)
organizationIdNoOrganization id; defaults to the credential organization when omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.13.0
    • addedInput schema / properties / allowedMethods / description
      Added value: +"HTTP methods the endpoint accepts: GET, POST, PATCH, DELETE"
    • addedInput schema / properties / appId / description
      Added value: +"App id or slug (from list_apps / create_app)"
    • addedInput schema / properties / endpointId / description
      Added value: +"Endpoint id (from list_app_endpoints)"
    • addedInput schema / properties / exposedColumns / description
      Added value: +"Replacement list of exposed columns (same shape as create_app_endpoint)"
    • addedInput schema / properties / exposedColumns / items / properties / alias / description
      Added value: +"JSON key exposed for this column: letters, digits, underscore. Never one of the reserved item fields id, title, description, status, priority, dueDate, assignedTo, createdAt, updatedAt, order, appUserId — a business status column becomes repairStatus or orderStatus, not status."
    • addedInput schema / properties / exposedColumns / items / properties / columnId / description
      Added value: +"Column id (from get_board_schema)"
    • addedInput schema / properties / exposedColumns / items / properties / readOnly / description
      Added value: +"Expose the column for reading only; writes to it are refused with 400"
    • addedInput schema / properties / isActive / description
      Added value: +"Whether it is active"
    • addedInput schema / properties / name / description
      Added value: +"Human-readable name"
    • addedInput schema / properties / organizationId / description
      Added value: +"Organization id; defaults to the credential organization when omitted"
    • addedInput schema / properties / slug / description
      Added value: +"URL slug: lowercase letters, digits and dashes"
  2. First observedv0.7.0

TDQS

A4.2/5.0
Behavior3/5

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

The description mentions changing an endpoint but does not disclose side effects (e.g., whether exposedColumns is replaced entirely, whether other fields are updated, or if there are permission requirements). Annotations only say destructiveHint false, which doesn't cover mutation semantics.

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?

A single, focused sentence that states the primary purpose and how to obtain the necessary ids. No redundant or extraneous information.

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?

The description is sufficient for basic usage, but it does not mention that exposedColumns is a replacement list (vs. a merge), nor does it indicate what happens if other fields (name, slug, allowedMethods) are provided. These details are inferable from the schema but not spelled out.

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?

The schema covers all parameters with detailed descriptions, including reserved-word constraints for aliases. The description adds value by explicitly pointing to list_app_endpoints and get_board_schema as sources for the ids, which is not in the schema.

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 action ('Change an existing endpoint') and the specific resource (endpoint). It distinguishes from create_app_endpoint by focusing on existing endpoints and the most common use case (setting exposedColumns).

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 a concrete scenario (set exposedColumns on an endpoint created without them) and tells where to get the needed ids (endpoint id from list_app_endpoints, column ids from get_board_schema). It does not explicitly contrast with create_app_endpoint, but the phrase 'existing endpoint' implies it.

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