You give an MCP server real tools by describing HTTP endpoints you already have — the URL, the parameters, where the credentials go — and attaching them to the server. On SuperCognit, any HTTP tool you build for an agent becomes a callable MCP tool the moment you publish: no SDK, no protocol code, no separate deployment. If your CRM and your calendar have APIs, and they do, they can be tools.

Knowledge answers; tools act

A knowledge base makes an assistant good at questions: what is the refund policy, what does the premium tier include. Tools make it useful for the part after the question — look up this customer's account, check availability on Thursday, log the request. Most real workflows need both halves, and most MCP servers ship only the first, because the second historically required writing and hosting a server.

The unglamorous insight of HTTP tools is that the second half mostly exists already. Your CRM has an API. Your calendar has an API. The internal service someone built in 2019 has an API, undocumented but functional. A tool is a described wrapper around one endpoint of one of those.

The description is the interface

The model never sees your code. It sees the tool's name, its description and its parameters, and it decides when to call the tool, and with what, from those alone. 'Look up a customer by email address; returns their plan, renewal date and open tickets' will be called correctly. 'CRM integration' will be called wrongly, or constantly, or both. Writing tool descriptions is the closest thing this workflow has to programming, and it is done in prose.

01

Pick one endpoint per tool

A tool should do one job. Look up a contact by email. List open slots for a given week. Create a draft invoice. Narrow tools get called correctly; a do-everything tool forces the model to guess which of its moods you meant.

02

Describe it for a reader who cannot see the code

Say what the tool does, what each parameter means, and what comes back. Name the formats and the units. If a parameter is an email address, say so — the description is the only documentation the model gets.

03

Attach, publish, done

Attach the tool to the build and publish. It is now exposed as an MCP tool with a typed schema any client understands — and the chat agent from the same build can call it too. Credentials stay server-side in the tool configuration; they never travel to the client.

04

Test where your team lives

Connect the server in Claude or any MCP client, ask something that requires the tool, and watch the call. A vague description reveals itself within three questions. Fix the prose, not the endpoint.

Design rules that save you later

  • Least privilege: if the tool only reads, put a read-only API key behind it. A tool cannot exceed the credential it carries.
  • Return what is needed, not the whole record — a customer lookup does not need to ship every field your CRM stores.
  • Keep writes small and deliberate: a tool that creates a calendar hold is safer than one that can also delete events.
  • Prefer several narrow tools over one clever one; the model composes them better than it decodes flags.

What not to expose

A useful test: would you give a new hire this capability on day one, unsupervised? Access to the server runs through OAuth 2.1 with per-seat identity, and each workspace is isolated, so the blast radius is contained — but the cheapest safety mechanism is not attaching the dangerous endpoint in the first place. Deletion, bulk export and anything irreversible can wait until the read-only tools have earned their keep.

Start with two read-only tools: a CRM lookup and calendar availability. That pair turns a knowledge server into something that answers 'can we meet Thursday, and is this customer on the premium plan' in one exchange — and it ships in an afternoon.