GLM Tool Calling: Writing Tool Descriptions and Parameter Constraints

When tool calling underperforms, the problem is usually not the model but sloppy tool descriptions. The GLM-5/5.3 series handles structured function calling well, and thinking mode reasons before picking a tool — but only if you clearly explain when to use the tool and what each parameter means. Here are two copy-ready templates based on the BigModel API tools field; check official docs for details.

A Tool Description Must Answer Three Questions

Each tool's description should cover: its scope (when to call it), how it differs from other tools (to prevent wrong picks), and what the return value means (so the model can continue). One line is not enough — aim for 2–4 lines.

Bad: "description": "query weather" — the model doesn't know when to invoke it or how it differs from "query city info".

A good example: "Call when the user asks about current weather or a multi-day forecast for a city. Supports Chinese cities only; no historical weather. If the user also asks what to wear, call this first, then answer based on the result."

The same applies to parameters: describing query as "search keyword" is far worse than "Chinese city name, e.g. Beijing; no province/district suffix". During parameter filling, GLM relies mainly on parameter-level descriptions — being specific meaningfully reduces hallucinated arguments.

Template 1: Single Tool + Strict Parameter Constraints

For scenarios with few tools and strict formats. Put constraints in descriptions and enums rather than hoping the model behaves:

json
{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "search_flights",
        "description": "Search domestic flights. Call only when the user specifies origin, destination, and travel date. No international routes. If the date is missing, ask the user before calling.",
        "parameters": {
          "type": "object",
          "properties": {
            "from_city": {
              "type": "string",
              "description": "Origin city name without the 'City' suffix, e.g. Shanghai"
            },
            "to_city": {
              "type": "string",
              "description": "Destination city name without the 'City' suffix, e.g. Chengdu"
            },
            "date": {
              "type": "string",
              "description": "Departure date, format YYYY-MM-DD. Resolve 'tomorrow/day after' against the current date in context"
            },
            "cabin_class": {
              "type": "string",
              "enum": ["economy", "business", "first"],
              "description": "Cabin class; default to economy if unspecified"
            }
          },
          "required": ["from_city", "to_city", "date"]
        }
      }
    }
  ],
  "tool_choice": "auto"
}

Key points: put only truly required fields in required, and let optional fields follow default rules in their descriptions; spell out date-resolution rules explicitly — that's the most error-prone spot.

Template 2: Multiple Tools + System Prompt Role Split

With many tools, the model picks the wrong one. Dividing responsibilities in the system prompt works better than piling up descriptions:

text
You have three tools with these rules:
1. search_docs: retrieve internal technical docs. Prefer it for questions about product features or API usage.
2. query_order: check order status. Call only when an order ID appears or the user explicitly asks to check an order.
3. create_ticket: create a support ticket. Call only when search_docs found nothing AND the user explicitly requests human help; confirm the issue with the user before calling.

General rules:
- Call one tool at a time; decide the next step after seeing the result.
- Never invent information a tool didn't return; if a tool returns empty, say so honestly.
- Extract tool parameters from the conversation; never use placeholders like "xxx" or "TBD".

Use this alongside the tools field; each tool's description can then be shorter, avoiding duplication with the system prompt. Under this explicit division of labor, the GLM-5 series chooses among multiple tools noticeably more accurately than with descriptions alone.

Three Practical Tips for Parameter Constraints

1. Use enums whenever possible: for statuses, types, languages and other finite values, an enum is far more reliable than writing "fill in one of…" in the description. 2. Put numeric ranges in descriptions: "1–10; higher means more diverse results" beats a bare "temperature parameter". 3. Use nested objects with per-level descriptions for complex structures: GLM handles nested schemas well, but keep it to two levels deep — accuracy drops for everyone beyond that.

Also, enabling thinking mode helps complex multi-tool tasks — the model drafts a call plan first, at the cost of latency. Skip it for simple lookups.

Common Pitfalls

• Example values in descriptions help a lot: "e.g. '2024-06-01'" is clearer than a bare format spec.
• Don't stuff broad free-text fields into parameters: e.g. a user_intent string; split it into enum fields instead.
• Constrain the tool's return format too: describe the returned JSON structure in the tool description so the model cites the right fields.
• On cross-model differences: GPT/Claude and others differ in schema parsing details (e.g. strict mode support). When migrating the same tools definition across models, run a small regression test first; defer to each vendor's official docs.

Writing tool descriptions is essentially writing API documentation for the model: scope, parameter meanings, default rules, and error handling — none can be missing. Adapt the two templates to your own tool list and compare tool-call hit rates on a few real cases before and after tuning; that beats adjusting by feel.