The first time an AI asked me to "review the tools list" I pictured a dashboard. It is actually a blob of JSON, and it is the heart of how an MCP server introduces itself. Learn to read one of these and you can figure out what any server can do in about ten seconds. Let me walk through what you are actually looking at.
What a Tools List Is
When a client connects to an MCP server, it asks "what can you do?" The server replies with a tools/list response: an array of tool definitions. Each entry names a tool, describes it in plain text, and declares what arguments it accepts. That catalog is everything the assistant knows before it decides to call anything. In fact, the /mcp-tools.json file at IPIPAI is exactly that catalog served as a static page.
The Shape of a Single Tool
Every tool in the list looks structurally the same. You have a name, a description, and an inputSchema. Ignore the parentheses for a second and it reads like a job posting: this is what it is called, this is what it does, and these are the inputs it expects. An example entry for checking an IP looks like this:
{
"name": "lookup_ip",
"description": "Get details about a public IP address.",
"inputSchema": {
"type": "object",
"properties": {
"ip": { "type": "string", "description": "The IP to look up." }
}
}
}If that format is new to you, it is the same language used across the protocol, so the JSON-RPC 2.0 guide is a handy refresher on where this response sits in the conversation.
Three Fields Worth Reading
Do not skim all of it. Focus on three things. First, the name, because that is the exact string the assistant must call. Second, the description, because that is what the model reads to decide whether this tool fits. Third, the properties inside the schema, because those tell you which arguments are expected and which are optional. Experienced users learn to spot "these are the real specs" from those three quickly.
Why Descriptions Matter So Much
Here is the subtle part that trips people up. The AI does not understand your tool by magic. It understands it by reading the description and names. If your description says "check if an IP is clean," the model will reach for it when a user asks exactly that. Read the list on IPIPAI's tool catalog and you will see each description worded the way a model should read it.
How This Connects to Tool Calling
The tools list is the menu; tool calling is the order. After the assistant reads the list, it picks a tool, fills in the arguments your schema allows, and the client sends a tools/call. That flow from menu to order is broken down concretely in this guide to how LLMs call tools. Reading the list is step one in that whole story.
Common Reading Mistakes
A few slips happen over and over. People assume the tool name must match an API endpoint; it often does not. They assume every property is required; the schema marks required explicitly, so check there. And they assume a longer description is better; for a model, a short precise one beats a wall of text. Understanding these before you build your own server saves real pain. When you do build one, this starter guide shows the same schema appearing in actual code.
Wrapping Up
An MCP tools list is just a tidy JSON catalog of what a server offers. Read the names, the descriptions, and the input schemas, and you will know exactly what any assistant can invoke. It is the twelve-second orientation that unlocks everything else. The IPIPAI articles page is a good place to keep building on that foundation.