MCP in Tigy: connecting tools to voice agents

Choose the actions you need

MCP, or Model Context Protocol, is a protocol for connecting applications to tools and resources exposed by compatible servers. In Tigy AI, an MCP tool lets an agent use actions from an external server. Inspect names, descriptions, parameters and permissions before selecting the catalog; an available action is not automatically appropriate for customer service.

The external server must offer the operation. Describing an action in a prompt cannot add a missing tool to the catalog.

Configure and check discovery

Ask the integration owner for the full MCP server address and an access key if required. In Tigy, create a tool in the MCP category, enter those settings and select which actions should appear. Save, refresh the catalog and attach the integration to the agent.

If an action is missing, check whether the filter excluded it and refresh the catalog. If the connection fails, send the error message to the integration owner so they can check whether the server is available and reachable by Tigy. Do not include the access key in your report.

Test inputs and results

Explain when to use each action and which data to collect first. Ask a question requiring the tool, inspect its parameters and confirm the response in the external system.

Also test rejected authentication, missing records and incomplete results. Use appropriate permissions and test records for writes. Catalog filtering does not replace server authorization.

Test one known tool before expanding the catalog

Start with a lookup having a known test result. Ask in different ways, omit a parameter and correct a value during conversation. Check tool selection and use of the latest correction.

Then simulate empty results and outages. Responses should explain limitations and the defined alternative. Plausibility cannot replace lookup evidence. For writes, verify external effects and repetition protection.

Record server configuration and the exposed catalog during testing. Rerun evaluation after description or parameter changes. Protocol compatibility does not guarantee business-contract stability, and valid credentials do not justify access to every resource.

Choosing MCP or HTTP

Choose the connection your team can maintain and test. If the company already has an MCP server offering the required actions, it can provide an organized tool catalog. If you need one particular lookup or change in a system, an HTTP tool may be more direct. Ask the integration team to confirm which option fits the case.

Compare discovery, authentication, validation, evidence and maintenance rather than advertised tool counts. Prefer the path where actions, parameters and conversational error behavior are explainable.

MCP does not remove adapters needed for data transformation or business rules. Document that logic's location. Separate selection, transport, authorization and operation failures instead of treating every problem as a prompt issue.

Inspect the catalog before writing the prompt

An MCP server provides actions an agent can use, but its presence does not establish that every conversational need is covered. Inspect the available catalog and identify a concrete action for each task. Order inquiries need an order-retrieval tool; contact creation needs a write action with its own contract. Do not ask the agent to improvise absent operations.

In Tigy, MCP configuration accepts the complete server URL, credentials where needed and a catalog filter. After saving, refresh the catalog and examine discovered actions. Confirm association with the tested agent. Creating a connection in the workspace does not establish that a particular conversation can use required actions.

Read names, descriptions and parameters for selected actions. They should let the model distinguish retrieval from changes. Vague descriptions can cause wrong selection even when connection works. If you control the server, improve the contract; otherwise restrict the catalog and write instructions consistent with actual capability.

Consider a fictional server offering contact search and contact creation. A caller asks whether they are already registered. The correct task starts with search under approved requirements. Creating another contact because its description is clearer produces an effect different from intent. Test the chosen action rather than speech alone.

Refresh the catalog before testing after server changes. Removed actions or new parameters may make old instructions incompatible. Record which tasks depend on the server and maintain compatibility checks. Conversation stability depends on the tool contract it actually encounters.

Restrict the catalog and authorize on the server

Catalog filtering helps select relevant actions but does not replace authorization. Tigy documentation makes this distinction. External systems must control which data an account may read and which changes it may perform. A tool accepting an identifier does not mean every identifier mentioned by a caller should be authorized.

Choose access proportional to the pilot. For retrieval testing, read-only credentials limited to fictional records are usually more appropriate than accounts modifying the entire operation. The server owner defines permissions, and agent configuration should respect that scope. Do not add broad access merely to avoid permission errors in testing.

Separate actions with different effects. Availability retrieval, reservation creation and cancellation are not a single capability. Each needs its own data, conditions and confirmation. Prompts guide when to invoke; servers validate whether execution is allowed. This preserves control under insistent requests.

Do not place credentials in prompts or examples. Use appropriate authentication configuration. Agents need tool purpose, not access secrets. When authentication fails, investigate credential selection, format and external permissions. Asking callers to repeat requests will not repair expired keys.

Test denied access as part of the contract. Results should support understandable explanations without exposing internal details or other records. Conversation should acknowledge limits and offer approved alternatives. Do not circumvent refusal with another action apparently returning the same data.

Confirm effects only after results

An MCP tool can retrieve data or produce external effects. For writes, spoken claims must depend on results. Agreement to create a contact does not prove it was saved. Follow the response contract and distinguish confirmed, received and pending states.

Define missing-response handling before testing. Creation may complete before connectivity fails. Servers need a way to recognize repetition or investigate outcomes. Trial-and-error retries can create duplicates. Conversation explains absent confirmation, while duplicate-effect prevention belongs to the responsible system.

Consider corrections during collection. Someone supplies an email and then replaces a letter. Invocation must send the new value. If correction occurs after an action was submitted, verify modification capability rather than announce “fixed” merely because the sentence was understood. Understanding intention differs from persisted state.

Test external responses containing insufficient information too. Acceptance alone does not authorize claiming final success. If an action requires later processing, next steps should reflect that state and have an owner. Asynchronous integration does not become instantaneous through conversational wording.

Investigate discovery, execution and explanation separately

When an action is missing, review refreshed catalog and filters. When present but unable to execute, review connection, authentication and parameters. When execution succeeds but speech is incorrect, inspect result interpretation. Separating stages prevents prompt changes that make external contracts more confusing.

Prepare success, missing input, unavailable action, denied access and temporary-failure cases. Define permitted actions and expected explanations for each. Repeat them after server updates. Apparently small changes can alter field meaning or returned states.

Use the external MCP tools guide to check connection, selection and catalog refresh. Verify which server actions were selected for the agent before testing their use during a call.

Keep a record of the catalog version or review date and the supported tasks. This helps explain whether a later failure followed a conversational change or an external capability change. It also gives the receiving team a concrete list of what the agent can actually complete.

Review available actions before expanding the pilot

Before releasing new tasks, compare the current catalog with approved scope. A new server action may be available without being necessary to the agent. Update filters and instructions deliberately while retaining external authorization. Discovering capability does not automatically decide to offer it to callers.

Review one retrieval case and one modification case with staff. They should explain minimum input, confirmation and the alternative when results are missing. If those conditions remain unclear, retain the existing scope until validation.

Include a request that appears similar but is outside permission. For example, a caller allowed to retrieve a booking asks to delete another record. The agent should recognize the boundary, and the server must enforce it independently. This practical check helps confirm that adding an action did not quietly expand authority beyond the agreed service. Save the case for later catalog reviews.