Knowledge · MCP

    Building MCP Tools

    Good MCP tools map to complete business actions, validate their inputs, fail loudly and stay idempotent. The design rules that separate usable tools from demos.

    What makes a good MCP tool?

    A good MCP tool represents one complete business action, accepts a small typed set of arguments, validates everything server-side, returns a structured result including failures, and is safe to retry. Tools that mirror database tables instead of business actions force the model to orchestrate — and that is where errors appear.

    Key takeaways

    • One tool = one business outcome, not one database write.
    • Typed, minimal arguments beat flexible free-text parameters.
    • Return structured errors — silence teaches the model nothing.
    • Make writes idempotent so a retry cannot duplicate work.
    • Write the description for a reader who has never seen your schema.

    Design around outcomes, not tables

    'Convert this appointment into a job' is a tool. 'Insert a row into jobs' is not — it leaves the model responsible for the six other things that must happen alongside it.

    Every step you leave out of the tool becomes a step the model has to guess at.

    Rules for arguments

    • Prefer canonical identifiers over names the model might mis-transcribe.
    • Keep required arguments few; make optional behaviour explicit.
    • Use enums for anything with a fixed set of valid values.
    • Never accept a raw query or filter string from the model.
    • Validate on the server even though the schema already constrains it.

    Make failure informative

    A tool that returns an empty result on failure will be retried blindly. A tool that returns a typed error — not found, not permitted, missing prerequisite — lets the model correct itself or stop and ask.

    Include what was missing and what would make the call succeed.

    Idempotency and retries

    Network calls fail and agents retry. If a retry can create a second invoice, the tool is unsafe.

    The usual fix is a reservation step: the first call reserves an operation key, the second finalises it, and a repeat of either is a no-op that returns the original result.

    Gate the dangerous ones

    Sending, signing, charging and deleting deserve a preview-then-confirm pattern. The preview describes the exact effect; the confirmation token authorises only that effect and expires quickly.

    Tool design: weak versus strong

    CapabilityAspectWeak toolStrong tool
    GranularityOne table writeOne business outcome
    ArgumentsFree-text filtersTyped IDs and enums
    ErrorsEmpty resultTyped reason and remedy
    Retry safetyCreates duplicatesIdempotent by key
    Destructive actionsImmediatePreview then confirm
    DescriptionNames the tableStates purpose and limits

    Where URBLD fits

    URBLD's tool catalog is organised by operational outcome — qualify a lead, book an appointment, convert to a job, send a contract — with reserve-finalise semantics on every write.

    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