Define MCP Tools
Why tool definitions matter
An AI agent doesn’t read your API spec at runtime. Instead, it reads the tool name and description you provide here to decide:
- Whether a tool is relevant to the user’s request
- What parameters to pass
- How to interpret the response
Writing clear, specific descriptions is the single most impactful thing you can do for agent quality. A vague description like "Gets products" will be ignored or misused. A precise one like "Search the product catalog by category. Use this when the user wants to browse or filter available products." tells the agent exactly when and how to use it.
The MCP tools and mapping screen
On this step you see a table — one row per API endpoint — auto-generated from your Exchange spec. Each row shows:
| Column | Description |
|---|---|
| Enabled | Toggle to include or exclude this tool from the bridge |
| AI tool name | The identifier the agent sees — auto-derived from the resource path |
| Resource | The endpoint path (e.g. /products, /products/{id}) |
| Method | HTTP method badge (e.g. GET) |
| Description | Auto-populated from the spec’s description field; edit to improve agent guidance |
| Action | ⋮ menu to edit the tool name and description |
At the top, Enable matching criteria is toggled on by default — leave it on.
If you see “0 Tools Enabled”: Your API spec in Exchange does not have any endpoints defined. Go back to Design Center, ensure the full OAS spec with
/productsand/products/{id}paths is saved, republish to Exchange, then return to this step.
Step 1 — Review the auto-generated tools
After publishing the full Product Catalog API spec, the table shows 2 Tools Enabled:
| AI tool name | Resource | Method |
|---|---|---|
get_products |
/products |
GET |
get_products_id |
/products/{id} |
GET |
Both tools are enabled by default. The descriptions are pulled from the spec’s description fields.
Step 2 — Edit tool names and descriptions
The auto-generated names work, but more descriptive names and richer descriptions improve agent behavior. Click the ⋮ Action menu on each row to edit.
Edit get_products → list_products
Click ⋮ → Edit on the /products row:
AI tool name:
list_products
Description:
Search and list products in the catalog. Use this when the user wants to browse
products, filter by category, or find what products are available. Supports an
optional 'category' filter and a 'limit' for the number of results.
Save the change.
Edit get_products_id → get_product_details
Click ⋮ → Edit on the /products/{id} row:
AI tool name:
get_product_details
Description:
Retrieve full details for a specific product by its ID. Use this when the user
asks about a particular product's price, description, or specifications.
Requires the product ID from a previous list_products call.
Save the change.
Step 3 — Click Next
Once both tools are enabled and descriptions look good, click Next to proceed to the Review step.
Tips for writing good tool descriptions
Do
- State the purpose — what task this tool accomplishes
- List when to use it — the user intent that should trigger this tool
- Mention dependencies — e.g. “requires an ID from list_products”
- Describe filters or options available
Don’t
- Use technical jargon the agent won’t understand (“invokes the GET /products endpoint”)
- Be too brief (“gets products”)
- Duplicate descriptions across tools
Example: weak vs. strong description
| Description | |
|---|---|
| Weak | Get product by ID |
| Strong | Retrieve the price, description, and stock level for a specific product. Use this when the user asks about a product they found from list_products. Requires the exact product ID. |
What’s next
With tools defined, the next step is the Review screen — verify all settings and deploy.
Continue to Review and Deploy →