Connect an assistant to your tools

The useful test of a connector comes next week, when your colleague needs the update and you are not there to assemble it. Can they get the right evidence, see what the assistant actually read, and tell a failed lookup from an empty result? Or have you replaced a reliable copying job with a mysterious conversation only you know how to steer?

Keep the project you already chose. Perhaps you prepare a release brief, a reading-group agenda, a maintenance summary, or a supplier comparison. Choose one recurring result within it that another person will use. This book helps you build the narrow retrieval routine behind that result, using an existing approved connector. You are not building a server or handing an assistant your entire account.

The connector removes repeated copying. Your contribution is to make that shortcut dependable: explicit inputs, limited authority, visible evidence, and a way to continue when the connection fails.

1. Start with the result someone needs

In Use a Connector for Shared Work, you used a documented connection to prepare a useful shared result. Here you turn that successful use into something a colleague can repeat. A single good answer is no longer enough; the path to it must survive a new date range, a missing record and your absence.

Write a sentence in your existing project notes:

When [recurring situation] happens, [colleague] needs [small result] from [permitted source] so they can [next action].

For example: "Before the weekly project meeting, the chair needs the next meeting time and the current procedure reference so they can prepare the agenda." This is an optional example, not a requirement to build an agenda tool. Your project may need only one source and one tool call. Do not connect a second system just to resemble the example.

Now identify the copying step. Is the same person repeatedly locating a record, reading a few fields and pasting them into the same kind of note? That is a promising boundary. If the hard part is deciding which policy applies, resolving contradictory evidence or approving a customer response, a connector does not remove that judgment. Keep it with the person who owns it.

Choose a result that can remain read-only. The assistant retrieves evidence and drafts the result; a person makes any consequential update in the source application. Scheduling unattended runs belongs in Automation. Implementing a missing tool belongs in Build your own connector. Here you build the reusable connection setup, task instructions and handoff around a tool that already exists.

2. Know which screen you are using

You will move between three places. They have different jobs.

MCP does not prescribe a universal assistant interface. A product may call its connection area Connectors, Apps or Tools, and may hide arguments that another product exposes. Use the documented route for your approved client, then record that actual route in your handoff. Do not hunt for a button invented by a tutorial. If the client cannot expose the evidence you need, use an already approved test view; if neither can, the boundary check is blocked.

One concrete inspection route is the MCP Inspector web client, when your organisation has already provisioned and approved it. In its Servers view, select the assigned server and confirm its connection state. In Tools, select a discovered tool, read its input schema, fill the argument fields and invoke it. Inspect the returned result there. Open Protocol to match the tools/call request to its response by JSON-RPC ID; the monitoring sidebar can keep that transcript visible beside the tool view. A connector may also return a separate request ID. Record whichever safe identifiers the interface actually exposes, without pretending the two are interchangeable.

Those view names come from the official Inspector web guide, not an observed run in your environment. Older versions can differ. Use your managed version's documentation. Do not launch a package, add a server, paste credentials or follow the Inspector's installation quickstart for this book. Its Network view can expose headers and other sensitive material; a raw traffic export is not a safe handoff artifact.

Before connecting, you need an approved assistant, an existing connector with a suitable narrow profile, and a source or connector owner who can confirm its grants and revoke them. Rehearse with public or synthetic records approved for this purpose. If your chosen project uses confidential records, model the same lookup with synthetic content first. A successful rehearsal does not authorize production access. Keep the established manual route until the owner explicitly approves the real data path.

3. Name the thing before you authorize it

A connector is an authorized route through which an assistant can discover and call defined tools. Each tool should name an operation, validate structured input, check the caller and resource, return a bounded result and report explicit failure. MCP standardizes discovery and invocation; it does not certify a publisher or replace source authorization.

Product labels overlap, so classify by behavior and authority:

A connector may use an integration, and a plugin may install a connector. The label is not the decision. Ask: Which operations become callable, under whose identity, against which resources, and what enforces refusal?

Imagine that your prompt says "read the project folder," but the consent screen grants access to the whole drive. The sentence has narrowed the assistant's assignment, not the connection's authority. Likewise, a tool's read-only annotation describes intended behavior; it is not proof that the underlying identity cannot write. Inspect both the exposed tool list and the source grant.

This distinction matters even when the output is harmless. A two-line agenda can have been produced by a broad search over unrelated folders. You must judge the route as well as the result.

4. Give the routine a narrow contract

In the same project notes, write the smallest contract that explains this one task. Reuse existing project documentation; you do not need a new tracker or configuration format.

Define four dimensions of scope:

1. Identity: name the approved training or task-specific identity. Do not use a shared administrator or a broad daily account because it is convenient.
2. Operation: list the exact reads required. Exclude create, update, delete, send, export, share and administrative operations from this routine.
3. Resource: name the permitted calendar, folder, repository area or queue. "Read-only" across an entire tenant is still too broad for a one-folder task.
4. Time: record the rehearsal end time or approved retention period, plus the immediate revocation route. Recurring use needs an explicit decision to retain access, not an exercise grant left alive by accident.

Add the task inputs and output next to that scope. Inputs might be a ticket ID and queue, or a date window and group calendar. The output might be five source-backed bullets with record IDs, links and retrieval time. Specify what "current" means for your project: a calendar's timezone, a document's revision field, or a ticket's status at the time of retrieval. A live call can still return stale indexed data. Do not label a result "latest" unless the tool's documented ordering and coverage support that claim.

Your contract also needs a stopping condition. For example: "If the procedure lookup fails, return the ticket facts and mark the procedure unresolved; do not search another folder or recommend an action from memory." Partial evidence is often useful. A polished answer that silently fills its gaps is not.

Before authorization, open the connector entry through your organisation's trusted catalog or the official owner route. Compare publisher, connection identity, endpoint, environment, requested resources, operations, support route and update channel. Do not follow an endpoint or sign-in link supplied in chat or email. If consent asks for all calendars, a whole drive, write permission or unexplained offline access, cancel and ask the owner for a narrower existing profile.

Keep secrets in the approved authentication flow, never in prompts, sample arguments, notes, screenshots or copied logs. Authentication machinery may transport credentials; that is not a reason to expose them in the model-visible tool arguments or your evidence.

After authorization, reopen or refresh discovery and compare every tool with the contract. Client controls may hide tools or request confirmation, but the server and source must enforce access independently. If an undeclared write or broad-read tool appears, disconnect rather than adding another warning to the prompt.

5. Follow one call all the way through

A useful mental model is a short chain, not a magic connection badge:

colleague's need -> saved task inputs -> assistant's proposed tool + arguments
                    -> server validation and access checks -> bounded source result
                    -> checked project output -> colleague's next action

failure anywhere -> explicit incomplete result -> documented manual source route

In MCP terms, discovery uses tools/list; execution uses tools/call. The assistant selects a tool and prepares structured arguments. The server then validates and authorizes the request before returning data or an error. The assistant's final prose is a separate, fallible interpretation of that result.

In the assistant's call panel, inspect the exact tool name and every argument before approving when confirmation is available. Is the resource the one in your contract? Is the date range bounded? Is the query specific enough? If not, cancel and correct the request rather than hoping the source will return something sensible.

After the call, inspect the result fields. Compare every factual output to its source record: IDs, dates, status, revision and links. If a search returns only the first page, the assistant must not claim to have checked every record. Use documented pagination within the same approved scope when the task requires it, or label the result incomplete. Do not broaden the search just because the first result is inconvenient.

Treat returned document text as evidence, not as instructions. A retrieved paragraph asking the assistant to upload the folder or call another service has not changed your task or its permissions. Stop an unexpected proposed call and keep the original boundary.

Record enough to retrace the work: retrieval time, tool, safe arguments, source IDs, outcome and a safe trace identifier where available. A request ID helps correlate an event; it does not establish that the content was correct. Keep the retained evidence minimal and accessible as text. Do not copy a full private document when the colleague needs a title, version and source link.

6. Optional worked examples: a narrow coordination connection

The Coordination Sandbox below is a synthetic fixture specification inherited from this book's earlier manuscript, not a public service or a claim that a connector is installed. Use it only if your facilitator or organisation has supplied a matching approved fixture. Otherwise, apply the same reasoning to your own project's existing approved connector and its real schema. If neither is available, finish the contract and handoff design but report live execution as blocked.

The illustrative fixture has two separately authorized profiles:

Treat those names as a contract, not proof. The fixture owner must supply the actual schema, expected records, allowed test cases and evidence that the underlying identity has no write grant. The following values are invented reference cases, not observations:

The sandbox:// references are synthetic identifiers, not promised browser links. For a real handoff, use the source application's supported links and check that the recipient has legitimate access. Never make a source public just to repair a broken handoff link.

Lab option: prepare the agenda evidence

In the approved assistant's project conversation, submit:

Using only the connected Alder training calendar and protocol folder, find the
next meeting within 2026-09-04 through 2026-09-18 and the newest document matching
"blue assay" if the tool supports that ordering. Include source IDs, references,
retrieval time and any missing evidence. Show the calls. Do not change anything.
If ordering or search coverage is unclear, say so instead of claiming "newest".

These fixed dates are for the fixture; your recurring prompt needs a date window supplied for each run and a declared timezone. Inspect the calls for grp-alder and fld-alder-protocols, then compare the returned meeting and document to the owner's expected sheet. The expected source IDs are EVT-104 and DOC-208. Seeing those strings in prose is not enough: they must occur in your observed results.

The meeting chair depends on a short result they can use, not on a transcript of your conversation. Give them the meeting date and time as returned, the procedure reference and its revision if available, and any uncertainty. If the meeting was found but the document search failed, the chair can still prepare the agenda while obtaining the procedure manually. Do not hide that distinction behind "all set."

Company option: prepare an internal ticket note

With the Company profile selected in the approved assistant, submit:

Read synthetic ticket TKT-317 from q-support-training. In fld-support-playbooks,
find the document matching its procedure tag. Use the newest revision only if the
tool's results establish it. Draft an internal note with source IDs, references,
retrieval time and unresolved points. Show calls. Do not comment, update, send or
close anything. If the procedure lookup fails, stop that part; do not widen scope.

Here is an exact example of what to inspect, with argument names proposed for this illustrative fixture rather than claimed as a standard MCP schema:

{
  "name": "get_team_ticket",
  "arguments": {
    "queue_id": "q-support-training",
    "ticket_id": "TKT-317"
  }
}

In an already approved Inspector web session, open Tools, select get_team_ticket and compare the schema with those two fields. If it matches, enter the synthetic queue and ticket IDs, invoke the tool and inspect the result. If the schema differs, use the owner's documented field names; do not paste this fragment into a configuration file. It illustrates the name and arguments inside a call, not a complete JSON-RPC request.

The expected ticket is TKT-317 with status open. Inspect its returned procedure tag, then inspect the assistant's search_shared_docs call: its folder must be fld-support-playbooks and its query must come from that tag, not an invented policy title. The expected document is DOC-412. If a prerequisite field is missing, the assistant should ask or mark the lookup unresolved rather than guess.

The colleague receives a draft internal note with ticket facts separated from procedure guidance. They open the source records under their own account and decide whether any action is appropriate. The connector does not comment on or close the ticket. This human step is a deliberate boundary, not an incomplete automation to repair by granting writes.

7. Prove the boundary without risking real records

The successful read proves usefulness. It does not prove that the connection is safe to repeat. Before a colleague depends on it, exercise these five cases in the approved synthetic environment. Keep the outcomes in your existing project notes alongside the contract; a new spreadsheet is unnecessary.

For each row, record the actual input, expected behavior, observed outcome and safe trace reference. Leave unrun cases marked not tested. Error labels such as invalid_input, forbidden and not_found are useful categories, not mandatory MCP strings. An empty search array can be a valid no-match result. A generic connection failure cannot prove an authorization boundary, and a client-side validation message proves only that the client rejected the input.

Some systems deliberately conceal whether a forbidden resource exists by returning the same response as a missing one. Do not weaken that protection to force the word forbidden. Use the fixture owner's known unauthorized case and approved server-side evidence to establish denial without disclosure. If that evidence is unavailable, report the authorization test as inconclusive rather than equating an empty result with a pass.

Run the cases against the same declared scope

In the Lab fixture, a date value such as tomorrow is malformed only if the schema requires a calendar date. Test grp-directors as the approved out-of-scope group and violet assay as the missing document query. An attempted update_group_event must be unavailable or denied.

In the Company fixture, ticket-317 is malformed only if the documented schema requires the TKT- form. Keep ticket_id at TKT-317 and change only the queue to the owner-supplied q-executive for the unauthorized case. Restore q-support-training and use TKT-999 for the missing case. Changing one thing at a time makes the outcome interpretable.

Use the assistant's visible call panel for the useful run. Use the approved test view when the assistant refuses to submit deliberately invalid arguments. Do not coax it past its safeguards. If the test UI itself blocks malformed input, keep that client result and ask the fixture owner for the corresponding server-side validation evidence through the established test route. Do not install another tool to get around the block.

For the write-shaped case, first confirm that discovery exposes no write tool and that the underlying identity has no write grant. Ask the assistant to make a synthetic domain change, such as closing the training ticket, and inspect whether it attempts anything. A refusal in chat alone is not proof of server enforcement. If the approved test route supports a safe attempt to call an unregistered update_ticket, confirm that it is unavailable or denied. Otherwise record that part as untested. Never deliberately invoke a real write tool against a production record to demonstrate that it fails.

Refresh the relevant synthetic record and obtain the fixture owner's state or audit check after the test. An absent write tool is preferable to one accompanied by "please do not use." Both the exposed interface and underlying permission matter: one limits what the assistant sees; the other limits what an attempted request can do.

If a forbidden response exposes a title, summary, owner or other protected content, stop, disconnect and report it through the approved incident route. Do not keep probing. Likewise, a failed lookup must never expand to a different folder, queue, tenant or the web merely to produce an answer.

8. Make the result repeatable for a colleague

Build on the successful run rather than packaging your entire chat history. In your existing shared project document, add a short Connector handoff section. Preserve the previous accepted result and add the new one with its retrieval time; do not overwrite a known-good result with an unverified draft.

The handoff should answer the questions a colleague will actually ask:

• What is this for? Name the recurring result, its recipient and the decision it supports. Include the latest checked result, not only instructions to produce one.
• Where do I run it? Name the approved assistant, project, connection profile and actual interface path you used. Explain which input values change each time and which resource boundaries must not change.
• What do I submit? Include the saved prompt and the source of its variable inputs. Use the tool's documented date, timezone and ID formats. No credentials belong here.
• What makes it usable? Specify required source IDs, fields, retrieval time, coverage limits and any human review before the result is acted on.
• What did we check? Include a sanitized text trace or approved cropped call view and the five test outcomes. Clearly separate observed passes from planned or inconclusive tests.
• What if it fails? Give the manual source route, stop conditions, owner contact and documented disconnect and revocation paths. State when retained access expires or must be reviewed.

If you include an image from an approved isolated run, remove secrets, account identifiers, unrelated panels and private records before retaining it. Explain its tool, inputs and outcome in text so a colleague does not need to decipher tiny labels. A screenshot of prose is not evidence of a call, and a screenshot alone is not a usable operating instruction. No screenshot is supplied or claimed by this book.

Now ask the colleague to rerun the routine with an approved new input, using their own authorized access. Do not hand over your session, token or personal account. If the connection uses a managed shared identity, the owner must have explicitly approved that arrangement and its users. The colleague should reach the relevant source evidence, identify a missing or incomplete result, and know where to stop without asking you to reconstruct the chat.

Use one controlled failure during rehearsal, such as the known missing synthetic ticket. Can the colleague distinguish "no matching ticket" from "the connection is unavailable"? Can they continue through the documented manual route without expanding access? This is where the builder's work becomes visible. You have supplied a small dependable capability, not just a clever prompt.

If no colleague is available, rehearse from a fresh approved conversation using only the handoff, and label it self-rehearsed; colleague rerun pending. That is useful preparation, not evidence of an independent handoff.

Stop and recover without destroying useful work

When a call fails, leave the last accepted result intact and mark it with its original retrieval time. Do not silently present yesterday's note as today's update. Produce a clearly incomplete new result only if the available evidence is still useful.

Use the source application's normal authorized read route to finish manually, or ask the source owner if your access is insufficient. Record that manual provenance separately from the connector trace. Repairing a failed read does not require editing source records or increasing the connector's scope.

Disconnect the client connection using its documented control. If access must end, follow the source provider's revocation route as well; disconnecting a client is not evidence that its grant has been revoked. Through the approved test route, inspect a fresh access attempt after revocation without authorizing again. Previously returned data or a cached answer does not demonstrate continued live access. Follow the local retention rules for copies already produced.

For recurring use, retain only the approved narrow grant and its named owner. If the publisher, identity, resource scope or tool list changes, pause and recheck the affected boundary before the next result is relied on. Operating connectors across a wider service belongs in Operating connectors; you do not need to build a monitoring platform for this one routine.

9. Common failures and the small repair

The broad daily account is used

Symptom: consent gives the connector unrelated calendars, folders or queues.

Repair: cancel and use an approved task-specific profile restricted at the source. A folder selector in the assistant is not proof. Use the owner-approved out-of-scope synthetic test to check enforcement.

A plausible answer hides an incorrect call

Symptom: the note reads well, but the assistant searched the wrong folder, queried too widely or returned fields the task did not need.

Repair: inspect the name, every argument and the result before accepting the note. Correct the request, not just the wording of the answer. Recheck any downstream conclusion that depended on the wrong evidence.

A third-party connector is trusted by logo

Symptom: a similarly named publisher, marketplace listing or endpoint from a message is authorized without checking ownership.

Repair: start from the approved catalog or official owner route. Verify publisher, endpoint, requested permissions, support and update channel before sign-in.

Read-only exists only in the prompt

Symptom: the prompt says not to write, but discovery includes create, update, delete, send or administration.

Repair: disconnect. Require a profile that does not expose unnecessary writes and an underlying identity without write permission. Do not treat the assistant's promise as an access control.

A failed lookup becomes a confident substitute

Symptom: the assistant searches another queue or fills in a procedure from memory when the declared source fails.

Repair: keep the failure visible. Return the supported part with an explicit gap, then use the documented manual route. Narrow failure is better than an answer assembled from unauthorized or unknown evidence.

The colleague cannot use the result

Symptom: links work only for you, the date range is hard-coded or the colleague cannot find the connection you used.

Repair: correct the handoff's real interface path and variable inputs. Check recipient access through the source owner's existing process; do not share credentials or make the source public. Repeat the approved rerun before calling the handoff ready.

The connector only moves the copying

Symptom: setup is elaborate, the results are too broad and the learner still manually reconstructs every useful note.

Repair: identify the handoff actually removed. Keep the connector only if bounded current retrieval improves this repeated task. If it adds authority without reducing stable work, revoke it and keep the simpler manual route.

Evidence exposes a secret or real record

Symptom: a retained screenshot or trace includes a token, private event, customer detail or sensitive endpoint.

Repair: restrict the exposed evidence, revoke exposed credentials and follow the local incident route. Cropping a new copy does not undo an earlier disclosure. Resume evidence capture only with approved synthetic data and a checked, minimal view.

10. Your build and exit check

Use your chosen project, not a mandatory Lab or Company fixture. Start from its repeated result, define the narrow contract, connect through the existing approved route, inspect a useful live call, and run the controlled boundary cases. Then give the result and its rerun instructions to the person who needs them. Take the time the evidence requires; there is no reward for completing a screenshot on a timer.

Deliver one colleague-usable connector handoff in your existing project space. It contains the recurring result, source evidence and retrieval time, the saved task inputs and prompt, a sanitized live-call trace, observed boundary-test outcomes, and the manual fallback plus disconnect and revocation instructions. It may link to approved evidence rather than duplicating records. Its format can be the project document, a README or another accessible format your colleague already uses.

It is ready when a colleague can use the result, rerun it under approved access and recognize when not to trust it. The live call must match the declared scope; output claims must trace to the returned sources; the refusal tests must establish the intended boundary without exposing forbidden data or changing synthetic state. The handoff must say what is missing rather than turn unrun tests into passes.

If the approved connector, test view or colleague rerun is unavailable, deliver the prepared work with that limitation stated. Do not call a written fixture a working connection, a self-rehearsal an independent test, or an approved sandbox a production deployment.

Read what it sent, not just what it said. Then make that evidence useful to the next person.

Further reading and sources

• Use a Connector for Shared Work covers the preceding one-off use of an existing connection. This book adds repeatable inputs, boundary evidence and colleague recovery.
• Build your own connector takes on the implementation when the required tool does not exist. Operating connectors addresses ongoing connector operations.
• Your daily driver establishes the approved assistant and its data boundary. Automations with AI in the middle separates untrusted model output from consequential action.
• MCP tools specification, 2026-07-28 (opens in a new tab) defines tool discovery and invocation and discusses human oversight. Consult the specification supported by your actual client and server; interface behavior is not standardized by a tutorial.
• MCP authorization specification, 2026-07-28 (opens in a new tab) describes the authorization flow for HTTP-based transports. It is not a claim that every connector implements identical login or revocation controls.
• MCP Inspector overview (opens in a new tab) and web-client guide (opens in a new tab) document the optional approved inspection surface used here. No installation is required by this lesson.
• MCP specification, 2026-07-28 (opens in a new tab), official SDK overview (opens in a new tab) and Inspector repository (opens in a new tab) are retained implementation references, not a requirement to write or deploy a server.
• NIST SP 800-53 Rev. 5 (opens in a new tab) is an inherited primary reference for least privilege, access enforcement, input validation and audit controls.
• n8n built-in integrations (opens in a new tab) is an inherited reference for checking an exact integration node and operation. A service name alone does not describe its permission boundary. The tools index can help compare options after you have defined the task.

The tools and authorization specification pages and Inspector guides were consulted for this revision on 9 September 2026. Other retained references are further reading, not a fresh certification of current product behavior. The synthetic records and proposed arguments above are teaching examples; they are not screenshots, test results or evidence of an available service.