Cortex

Search memories

search

Read-only

Use this at the start of a conversation when the user's request about their own work, projects or plans could benefit from relevant context saved in earlier conversations. Use this when the answer depends on the user's own context: facts about them or their work, decisions they made, preferences or constraints they stated, or anything they refer back to from an earlier conversation ("as we agreed", "my project", "the client we discussed"). Use it as well when the user asks for something done their usual way, in their format, tone, style or stack ("the way I normally write these", "my usual setup"): their way is what the memory holds. Also use it when the user asks what you know or remember about something. Returns the matching memories with id, title and url to cite; fetch returns the full text of one. Cortex is the user's own memory layer: what is saved through it stays available in the other AI apps they connect to the same account. Do not use it for general knowledge, for questions that do not depend on this particular user, or when everything needed is already in this conversation. Do not include personal health information, special categories of personal data (including political opinions, religion, trade-union membership or sex life), credentials, government identifiers, payment card data or confidential private details about other people in a search query or any other Cortex input.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	What to look for, in natural language and in the user's own words, e.g. "which database we chose for billing"

Output Schema

Name	Required	Description	Default
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 18, 2026

changedInput schema / properties / query / description

Previous value: -"Query in linguaggio naturale"New value: +"What to look for, in natural language and in the user's own words, e.g. \"which database we chose for billing\""

First observedAug 20, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/non-destructive/closed-world, but the description adds substantial context beyond them: it describes the return shape (id, title, url), names the fetch follow-up for full text, explains Cortex's cross-app persistence, and imposes explicit privacy prohibitions (no PHI, special-category data, credentials). That is rich behavioral disclosure the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary usage trigger is front-loaded and every clause carries instruction. It is slightly repetitive, stacking four near-parallel 'use this when' clauses plus a long privacy block, which costs some tightness but no sentence is truly wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with an output schema, an openWorldHint=false annotation, and named siblings, the description covers triggers, exclusions, return handling, and privacy constraints. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only one parameter at 100% schema coverage, the schema already documents that the query is natural language in the user's own words with an example. The description reinforces this style but adds no syntax, format, or constraints beyond what the schema states, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search/retrieve memories) and resource (the user's own memory layer), and distinguishes itself from the sibling `fetch` by noting the latter returns the full text of one memory. An agent can tell it apart from cortex_recall/fetch without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly enumerates when to use (start of conversation, user-specific facts/decisions/preferences, 'their usual way', questions about what you remember) and when not to (general knowledge, non-user-specific questions, or when context is already in-conversation). This is a textbook when/when-not/alternative specification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Cortex tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.