Knowledge · MCP

    MCP server, client, tool, resource and transport

    The five parts of any Model Context Protocol setup — server, client, tool, resource and transport — and why confusing them leads to false claims about what an AI agent can do.

    What are the parts of an MCP setup?

    An MCP server publishes tools and resources. An MCP client is the assistant that connects to it. A tool is a callable action with a declared input schema. A resource is readable context. A transport is the connection that carries the messages. Each part is separate, and each can be present while the others are broken.

    Key takeaways

    • Server publishes, client consumes, tool executes, resource informs, transport carries.
    • A reachable transport proves connectivity, not working capability.
    • Tools declare schemas; clients validate against them before calling.
    • Resources are read-only context, not execution paths.
    • Each layer fails independently and needs to be tested independently.

    The five parts, plainly

    • Server: the endpoint that advertises what is available and executes calls.
    • Client: the assistant or application that connects and decides what to call.
    • Tool: a named action with a typed input schema and a handler behind it.
    • Resource: readable context the client can pull without executing anything.
    • Transport: the HTTP or streaming connection that carries requests and responses.

    Why the separation matters

    Vendors describe MCP support as a single feature. It is not. A server can answer a handshake while advertising zero tools. It can advertise ten tools where three have handlers. A handler can exist in source and never be deployed. A deployed handler can run and still not persist anything the business can verify later.

    Reading the layers separately turns a vague claim into five specific questions with five specific answers.

    Transport exposure is not verified capability

    The most common overstatement in agent infrastructure is treating a live endpoint as proof of function. A successful connection means the transport works. It says nothing about whether the tool you care about exists, whether your role may call it, or whether the write it claims to perform actually landed in a record you can open afterwards.

    Where URBLD fits

    URBLD exposes a single MCP endpoint whose tool list is generated from the server definition at build time and written to a manifest. Tools are registered explicitly in code; nothing is advertised implicitly. A build-time parity check refuses to pass when a catalog entry has no handler or no permission mapping.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in MCP

    The protocol that lets AI do work instead of describing it.

    Browse MCP
    Share this page