6.4 Connect read-only MCP tools

Verify a read-only tool before connecting a system that can write business data. This example uses the repository's public reference service. It does not read private directories or call a model.

1. Prepare and run protocol checks

Set up the source development environment, then run this command from the repository root:

pnpm test:references

The protocol tests start a real MCP service over stdio, list tools, read a reference, and verify that invalid identities, versions, and extra arguments are rejected.

The service entry point is packages/mcp-reference/src/main.ts. When started manually, it waits for MCP protocol messages on standard input. The absence of a normal chat prompt is expected.

2. Read a reference

Tool	Arguments	Result
list_references	Empty object {}	IDs, sources, and SHA-256 versions of available references
read_reference	id and version	Content and source for that exact version

List references first, then use the id and 64-character version from the actual response to read one. Do not hard-code a version from a documentation example: the version changes when the content changes.

3. Check rejected requests

Calling with an unavailable reference ID should return reference/not-found. Calling with an old version should return reference/version-conflict. An extra path field or an arbitrary disk path is not accepted.

These checks verify the reference boundary enforced by the MCP service itself. They do not replace tests of role-level tool permissions in Teloa.

4. Use it in Teloa

The default composition already configures the teloa_reference stdio service. In Settings, use the runtime configuration entry to check its connection. Pause the relevant colleague before editing its tool permissions, then grant read access to the reference using the candidates shown on the page. Resume the colleague afterward. The full protocol tool names are mcp__teloa_reference__list_references and mcp__teloa_reference__read_reference.

Without permission, a call made in a role task should be rejected. After granting permission, retry the same reference task and inspect the tool records. Ordinary conversations and role tasks have different contexts. Testing only an ordinary conversation does not establish that role authorization works throughout the execution path.

For a new service, use the transport, authentication, and credential fields available in the current DSH configuration page. This guide verifies the stdio path; it does not claim that every remote transport and authentication combination has been tested.