# Tool Calling (/academy/tool-calling)



A chatbot can only talk. An [agent](/academy/agent) fills out a work ticket and hands it to something that does the job.

**Tool calling** (sometimes "function calling") is that ticket: a name, arguments, a description the model reads. It picks `ds_create_project`. Your code runs. The model gets structured results back — a folder, an error — not a paragraph about folders.

The model never stops being words in a box. It cannot reach through the glass and charge a card. It writes the ticket *exactly*: tool name, inputs, a shape a machine can run without guessing. The [harness](/academy/harness) reads the ticket, hits the real [API](/academy/api) or [CLI](/academy/cli), and feeds the receipt back. That is the hinge in the loop. Decide, do, look, decide again.

**The menu is the fence**

You publish a short board: `ds_get_schema`, `ds_plan_project`, `ds_create_project`. [MCP](/academy/mcp) (`npx create-hackhaton-space-stack@latest mcp`) is a standard way to hang that board in Cursor, Claude Code, Codex. If a dish is not printed, it cannot be ordered. The model can talk about deleting the repo. It cannot order it.

Without the right tool, a clever agent will either say it cannot, or worse, *pretend* it did. That is how you get a "project" that is only a speech.

The plugin's [skills](/academy/skill) exist to make the intern pick these tickets instead of hand-rolling a [stack](/academy/stack).

**What this unlocks**

Every time an agent actually *did* something — scaffolded the app, posted Slack, fetched rows — that was a function call underneath. Words are a draft. A ticket is a commit.

The model decides. The tools do. The ticket is the line between them.