Skip to main content
Glama
Sign In

secondbrain

by media.secondbrain
OverviewDiscussionsAdmin

search_workspace

Read-only

Búsqueda GLOBAL en TODO el workspace de una sola vez: documentos (contenido), notas diarias, entidades del knowledge graph / Atlas (nombre y contexto), reuniones (recaps) y tareas.

Para cuando el usuario pide encontrar algo y no se sabe en qué sección vive:
- "buscá X en todo", "¿dónde mencioné Y?", "encontrá todo lo relacionado con Z"
- Cuando querés una vista completa de dónde aparece un tema/persona/proyecto en el workspace.

Búsqueda HÍBRIDA: combina significado (embeddings) con coincidencia de texto, así que encuentra
también lo que NO comparte palabras con la consulta — "tokenización de tarjetas" trae la reunión
donde se habló de "PCI-PIN". No hace falta adivinar el término exacto que usó el usuario.

Devuelve un objeto con secciones:
  documents   → [{ document_id, name, snippet }]
  daily_notes → [{ date, snippet }]
  entities    → [{ id, canonical_name, type, description }]
  meetings    → [{ id, name, date, snippet }]
  tasks       → [{ id, title, status, due_date }]
  reports     → [{ id, name, date, snippet }]
  files       → [{ id, name, snippet }]
Para el detalle completo de cada resultado usar la tool específica: get_document(document_id), get_daily_note(date), get_entity_details(id), get_meeting(id), get_task_detail(id).

Input Schema

NameRequiredDescriptionDefault
limitNoMáximo resultados por sección (default: 8)
queryYesTexto a buscar en TODO el workspace (mínimo 2 caracteres)
workspace_idNoUUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir = TODOS los workspaces de la persona, en una sola llamada

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the readOnly/destructive/openWorld annotations by disclosing non-obvious behavior: the search is hybrid (embeddings + text match), so it retrieves results that share no literal words with the query, illustrated with a concrete example. It also describes the multi-section result envelope and routes to specific detail tools, none of which is derivable from annotations.

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?

Front-loads the core definition before guidance and the return listing, and every block is purposeful. The verbose return-object enumeration is long but justified because there is no output schema; otherwise structure is clean and skimmable.

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?

With no output schema, the description compensates by spelling out the return sections and their fields, and by directing the agent to the per-entity detail tools for full content. Nothing needed to invoke it correctly or interpret its output 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?

Schema description coverage is 100%, so query, limit, and workspace_id are already fully documented in the schema, including the 'omit = all workspaces' behavior. The description adds no syntax or format guidance beyond that, so the baseline 3 applies.

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+resource with explicit scope: 'Búsqueda GLOBAL en TODO el workspace de una sola vez' and enumerates the exact content types covered (documents, daily notes, entities, meetings, tasks, reports, files). This clearly distinguishes it from the section-specific search_* siblings an agent would otherwise have to guess between.

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

Usage Guidelines4/5

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

Provides an explicit trigger scenario ('cuando el usuario pide encontrar algo y no se sabe en qué sección vive') plus concrete example phrasings, and names follow-up detail tools. It stops short of explicitly naming the section-scoped search alternatives (search_documents, search_entities, search_daily_notes), which the 'when you don't know the section' framing only implies.

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

All secondbrain toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources