Skip to main content
Glama

Last Price

create_function

Register a pricing function in your workspace. execution_type is how it prices: rule based, ML model, LLM prompt, external API (your own endpoint) or composite. name is its unique lowercase id, such as acme/surge. Set is_public to list it for other workspaces. A new function starts as a draft unless status is active: make it active with update_function to have it routed to. A rule_based function prices by the rule you send (base, then steps such as margin, tiers, floor and price ending). Needs a Last Price credential with function publish scope. Needs a claimed workspace: a sandbox key from self-registration is refused (403) until a person claims the workspace.

Input Schema

NameRequiredDescriptionDefault
nameYesUnique lowercase id: letters, digits, hyphens, underscores and slashes.
ruleNoFor a rule based function: the rule it prices by. Its input schema is made from the rule, and a rule based function needs one before it can be active. On update null removes it.
tagsNoThe tag list. On update it replaces the whole list.
statusNodraft (the default) or active, to have it routed to at once. A self-registered sandbox saves drafts only.
is_publicNoList it for other workspaces to use. Defaults to false.
auth_configNoHow to authenticate to the endpoint, such as { type: "bearer", token: "..." }. Stored encrypted and never returned: a read says only whether one is saved. On update an object replaces it and null removes it. Treat the secret as sensitive: it passes through this conversation.
descriptionNoWhat the function does.
display_nameYesThe name people and agents see.
endpoint_urlNoFor a function that calls your own service: the https endpoint that returns the price.
input_schemaNoJSON Schema of what a price request supplies to the function.
cost_per_unitNoWhat one call to the function costs, in USD.
output_schemaNoJSON Schema of what the function returns.
execution_typeYesHow the function computes a price.
cost_multiplierNoMultiplies the cost of each call, for a more expensive model tier. 1 is the default; stored to 4 decimal places.
inference_configNoFor a function that runs on a model. On update an object replaces it and null removes it, so the function uses the rule-based formula.
quote_valid_secondsNoHow long a price this function computes stays valid, in seconds (30 to 86400). Prices carry it as valid_until where quote expiry is switched on for the workspace. Omit for the default of 15 minutes; on update null returns to the default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / rule
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "For a rule based function: the rule it prices by. Its input schema is made from the rule, and a rule based function needs one before it can be active. On update null removes it.",
      +  "properties": {
      +    "base": {
      +      "additionalProperties": {},
      +      "description": "Where the price starts: {\"from\":\"current_price\"}, {\"from\":\"unit_cost\"}, {\"from\":\"competitor_prices\",\"pick\":\"min\"|\"avg\"|\"max\"} or {\"from\":\"field\",\"field\":\"<context field>\"}.",
      +      "type": "object"
      +    },
      +    "steps": {
      +      "description": "Applied in order: adjust_pct, margin (target_margin_pct), scale, tiers, floor, ceiling, ending (cents such as 0.99) and round. A floor or ceiling holds through every later step.",
      +      "items": {
      +        "additionalProperties": {},
      +        "type": "object"
      +      },
      +      "maxItems": 20,
      +      "type": "array"
      +    }
      +  },
      +  "required": [
      +    "base"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / status
      Added value: +{
      +  "description": "draft (the default) or active, to have it routed to at once. A self-registered sandbox saves drafts only.",
      +  "enum": [
      +    "draft",
      +    "active"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the write/non-idempotent/non-destructive profile; the description adds real behavioral context beyond that: new functions start as drafts, activation requires a second call, a scope-bound credential is mandatory, and an unclaimed workspace yields a 403. These are the failure modes an agent will actually hit.

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-loaded with purpose, then execution_type, then naming, then visibility, then lifecycle and prerequisites — a sensible order. A few clauses (the rule/steps enumeration) largely restate the schema, but the paragraph is dense and mostly earns its length for a 16-parameter tool.

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?

With 16 parameters, nested objects and no output schema, the description covers the workflow essentials: what is created, default draft state, how to activate, and blocking prerequisites. It omits the secret-handling caution for auth_config and cost/expiry details, but those are documented in the schema, so the gap is minor.

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 the baseline is 3; the description still adds value by giving a concrete name example ('acme/surge') not present in the schema and by summarizing the rule shape (base, then steps such as margin, tiers, floor, price ending). Much of this overlaps the schema's own nested descriptions, which keeps it from a 5.

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 and resource ('Register a pricing function in your workspace') and immediately scopes it with the five execution_type variants, so an agent knows this creates a pricing function of any kind rather than a hosted model or routing policy. It also names the sibling used for the next step (update_function), separating creation from activation.

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?

Explicit about prerequisites ('Needs a Last Price credential with function publish scope', 'Needs a claimed workspace: a sandbox key from self-registration is refused (403)') and about the follow-up path ('make it active with update_function to have it routed to'). The default-versus-active status distinction tells the agent exactly what state the function lands in.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources