Skip to main content
Glama

document_intelligence_grep_content

Destructive

Search and extract specific content from documents using natural-language objectives. Send a message describing what to find and get matching results through the document intelligence agent.

Instructions

Run the document_intelligence domain agent action grep_content.

Routes through the platform's domain-agent dispatcher under your JWT, tenant, and company scope.

Args: message: Free-text objective for the action. inputs: Optional JSON string of structured inputs for the action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNo{}
messageNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

The description adds only routing/auth context (JWT, tenant, company scope) and does not disclose what the action does. This is especially problematic because annotations mark destructiveHint=true and readOnly=false, yet the description does not explain possible side effects, while the grep name implies reading. There is no direct contradiction, but the behavioral burden is largely unaddressed.

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 description is compact, starts with the operative action, and uses a clear Args block. Every sentence contributes routing context or parameter role, with no filler.

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

Completeness2/5

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

Although an output schema exists, the description still misses the action's purpose, selection criteria, and expected message/input content. It is complete at the plumbing level but not at the level an agent needs to invoke grep_content correctly.

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 schema coverage at 0%, the description partially compensates: it tells users message is a free-text objective and inputs is an optional JSON string of structured inputs. This goes beyond the bare schema, but it does not clarify what objectives or input keys grep_content accepts.

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

Purpose3/5

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

The description states a specific verb and resource: it runs the document_intelligence domain agent action grep_content. However, it never explains what grep_content actually does, and with siblings like grep_documents, search_documents, and document_intelligence_search_documents, an agent cannot distinguish this wrapper from those. The purpose is clear at the mechanic level but vague at the semantic level.

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

Usage Guidelines2/5

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

No when-to-use guidance or exclusions are provided. The description explains routing and auth scope but gives no condition under which to choose this tool over document_intelligence_search_documents or grep_documents.

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

Deploy Server

Other Tools