Function Calling Definition for LLMs

A function definition does two jobs at once: it tells the model what tool is available, and it tells your runtime what shape of input is safe to accept. If either side is vague, you get arguments that are technically valid JSON but operationally useless.

The cleanest pattern is to keep the function name stable, write a short description that explains the boundary of the action, and make the parameters schema stricter than your prompt. That shifts ambiguity out of runtime handling and into explicit validation.

1. Keep the name operational, not marketing-driven

Names like do_everything_for_customer are broad enough that the model cannot infer when to call them. Prefer narrow names such as get_weather, lookup_order_status, or create_support_ticket.

{
  "type": "function",
  "function": {
    "name": "lookup_order_status",
    "description": "Fetch the current status of an order by id.",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": { "type": "string" }
      },
      "required": ["order_id"],
      "additionalProperties": false
    }
  }
}

2. Treat the schema as a contract

A weak schema forces your application to guess intent later. A strict object with required fields, enums, and additionalProperties: false removes a large class of runtime cleanup work.

This matters even more when the same tool is called by different prompts, different models, or replayed through evaluation pipelines. Stable schemas are easier to diff, test, and explain.

3. Generate the shell, then review manually

Inferring a first schema from sample JSON is useful, but it should be treated as a starting point. Sample payloads rarely capture optional fields, enum restrictions, or the business rules that matter most in production.

Use a generator for speed, then inspect field names, required arrays, defaults, and descriptions before wiring the definition into your API layer.

4. Practical workflow

1. Start from a real example payload or an existing request schema.
2. Generate the function definition shell.
3. Review names, required fields, and disallowed extras.
4. Test the definition with adversarial prompts before shipping.