> For the complete documentation index, see [llms.txt](https://yvechat.gitbook.io/wp/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yvechat.gitbook.io/wp/capabilities/tool-gateway.md).

# Tool Gateway

Models reach the outside world through a defined gateway with a fixed set of tools, disclosed activity, and an explicit consent boundary.

***

### Initial Tools

| Tool              | Function                                                    | Status       |
| ----------------- | ----------------------------------------------------------- | ------------ |
| `web_search`      | Query a configured search provider and return cited results | Available    |
| `open_url`        | Fetch a specific public page                                | Experimental |
| `find_on_page`    | Locate content within a fetched document                    | Experimental |
| `extract_article` | Pull readable article text from a page                      | Experimental |
| `read_pdf`        | Read a public PDF document                                  | Experimental |

The four page tools are implemented in the gateway and exposed in its catalogue. Chat orchestration currently uses search, so they are reachable through the gateway ahead of full chat integration.

All five are read-only and run without confirmation. They share one safety sandbox: redirects are followed manually and capped, addresses are checked against a public URL policy before each request, content types are restricted, and responses are capped at 2 MB.

Every response drawing on these tools carries clickable source citations, and tool activity is disclosed in the interface as it happens.

***

### The Consent Boundary

```mermaid
graph TD
    M["Model requests a tool"] --> Q{"Does it change<br/>anything?"}
    Q -->|"Reads only"| A["Runs automatically<br/>with visible status"]
    Q -->|"Writes, sends, pays,<br/>or authenticates"| C["Waits for your<br/>explicit confirmation"]
    A --> R["Cited result"]
    C --> R
```

Search and read operations run automatically, with their activity visible. Any operation that writes files, sends messages, makes purchases, changes settings, or authenticates to an account waits for confirmation.

This boundary is a requirement. The Model Context Protocol specification states that tools "represent arbitrary code execution and must be treated with appropriate caution", that hosts "must obtain explicit user consent before invoking any tool", and that users "should understand what each tool does before authorizing its use".

Source: [MCP specification, Security and Trust & Safety](https://modelcontextprotocol.io/specification/2025-06-18/index)

***

### Search Providers

| Provider                   | Suited to                                        | Disclosed tradeoff                                                                                             |
| -------------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------- |
| **Ollama Web Search**      | Simplest Ollama-first onboarding                 | Requires an Ollama account and API key, and queries reach Ollama's servers, even though the model runs locally |
| **Self-hosted SearXNG**    | Privacy-focused users running their own instance | Provides a JSON HTTP API. Queries still reach the configured upstream engines                                  |
| **User-supplied provider** | Users who hold their own search API key          | The key stays in the Engine                                                                                    |

Sources: [Ollama web search](https://docs.ollama.com/capabilities/web-search), [SearXNG search API](https://docs.searxng.org/dev/search_api.html)

{% hint style="warning" %}
No web search option keeps a query on the user's machine. SearXNG breaks the link between the user and the query. The query text still reaches the upstream engines. Search is stated here as a deliberate exit from sovereignty, chosen per conversation.
{% endhint %}

***

### Roadmap Priority

1. Web search with citations
2. Page and PDF reading with summarization
3. Local file attachment and document retrieval
4. Calculator and deterministic date handling
5. Sandboxed local code execution
6. MCP connections with per-tool permissions
7. Weather, finance, and location through explicit providers
8. Authenticated services such as Drive, Notion, and GitHub

***

### Model Context Protocol

MCP standardizes resources and model-controlled tools, and the gateway adopts it with the specification's own safety guidance applied.

Four constraints carry directly into the design:

| Constraint                     | Source text                                                                                                      |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| **Tool metadata is untrusted** | Descriptions and annotations "should be considered untrusted, unless obtained from a trusted server"             |
| **Sampling requires approval** | "Users must explicitly approve any LLM sampling requests", with control over the prompt and what the server sees |
| **Credentials stay put**       | Token passthrough is "explicitly forbidden". Servers receive credentials issued for them alone                   |
| **Enforcement is ours**        | MCP "cannot enforce these security principles at the protocol level"                                             |

The last point is the important one. Every security property described on this page is YveChat's responsibility to implement. None of it is inherited from the protocol.

Local MCP server installation is the highest-risk surface in the product, and the specification requires showing the exact command untruncated before execution. The gateway treats it accordingly.

Source: [MCP security best practices](https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices)

***

### Isolation From the Engine

`open_url` and `read_pdf` are server-side request primitives by construction. MCP's security guidance directs clients to block requests to loopback and private address ranges, and the Engine deliberately listens on loopback.

The gateway therefore cannot reach the Engine. They are separately authorized channels, and the tool gateway's outbound requests are filtered against private and reserved ranges.

***

Tools that read, run in the open.

Tools that act, wait to be told.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://yvechat.gitbook.io/wp/capabilities/tool-gateway.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.