Skip to main content
Glama
Sign In

DialogBrain

by com.dialogbrain.api
OverviewDiscussionsAdmin

search_files

Read-onlyIdempotent

Search files and attachments across the workspace — by content, filename, document type, or origin. For message content use search.messages; for links use search.links.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum files to return.
queryNoWhat to search for (content or filename).
file_originNoFile origin: 'generated' (created by tools), 'received' (from messages), 'uploaded' (manual). Use 'generated' for files the user created/sent. OMIT to include all origins.
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.
document_typeNoFilter by document category. OMIT unless the user explicitly mentions one — picking a value narrows the search and is a common cause of zero-result mistakes.
attachment_nameNoExact filename filter. OMIT to skip (do NOT pass an empty string).
image_min_scoreNoMinimum similarity (0 to 1) for photo/screenshot matches. Affects image files only. OMIT to follow this call's `min_score` (0.25 unless set), the general similarity floor, which also applies to text matches. Image scores run lower than text scores: typically clear matches are about 0.40-0.50 and noise is usually below roughly 0.32. Raise it (e.g. 0.35) when photo hits are noisy; lower it (e.g. 0.20) to find weak matches such as scanned documents. A value outside 0..1 is refused, never clamped.
image_hub_marginNoHow far (0 to 1) an image match must stand above that image's own similarity to unrelated queries; this hides images that look close to every query. OMIT it: the default is tuned. Change it only when the results show a problem, and then lower it a little (e.g. 0.04) rather than 0, which turns the check off. A value outside 0..1 is refused, never clamped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / image_hub_margin
      Added value: +{
+  "description": "How far (0 to 1) an image match must stand above that image's own similarity to unrelated queries; this hides images that look close to every query. OMIT it: the default is tuned. Change it only when the results show a problem, and then lower it a little (e.g. 0.04) rather than 0, which turns the check off. A value outside 0..1 is refused, never clamped.",
+  "type": "number"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / image_min_score
      Added value: +{
+  "description": "Minimum similarity (0 to 1) for photo/screenshot matches. Affects image files only. OMIT to follow this call's `min_score` (0.25 unless set), the general similarity floor, which also applies to text matches. Image scores run lower than text scores: typically clear matches are about 0.40-0.50 and noise is usually below roughly 0.32. Raise it (e.g. 0.35) when photo hits are noisy; lower it (e.g. 0.20) to find weak matches such as scanned documents. A value outside 0..1 is refused, never clamped.",
+  "type": "number"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  4. Added
  5. Removed
  6. Added

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile needs no repetition. The description adds the workspace-wide scope, which is useful context, but says nothing about result ordering, relevance scoring, or pagination behavior beyond the `limit` parameter. With annotations doing the heavy lifting, this is adequate at 3.

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

Conciseness5/5

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

Two sentences, zero filler, with the scope and searchable dimensions front-loaded and the sibling routing immediately after. Nothing restates the tool title or annotations.

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

Completeness4/5

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

For a read-only search tool with fully documented parameters and no output schema, the description plus schema covers what an agent needs to call it. It could say a bit more about what a result contains (file id, name, score) since no output schema exists, but the gap is minor.

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%, and the eight parameters — including non-obvious ones like image_hub_margin and image_min_score — are thoroughly documented in the schema itself. The description adds no syntax or usage detail for any of them, so 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 (search) and resource (files and attachments) plus the four searchable facets: content, filename, document type, and origin. It also names the two adjacent search tools that handle different resource types, so an agent can place it in the search family without opening the 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?

'For message content use search.messages; for links use search.links' is an explicit when-not rule with named alternatives, exactly what a routing sentence should do. The workspace-wide scope is also stated, implicitly excluding non-workspace resources.

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

All DialogBrain toolsInspect
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.

Resources