Skip to main content
Glama
KazKozDev
by KazKozDev

Search Text in Document

search_text

Find specific text strings in Markdown files and locate their structural positions using semantic search to identify content within document hierarchies.

Instructions

Performs a semantic search for text strings and returns their structural paths.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathYes
queryYesString to search for

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsNoList of matching elements with their paths

Implementation Reference

  • Core implementation of search_text method in Document class. Recursively traverses the element tree to find elements containing the query string (case-insensitive) and returns list of dicts with path, type, and preview.
    def search_text(self, query: str) -> List[Dict[str, Any]]:
        """Search text across all elements"""
        query = query.lower()
        results = []
    
        def walk(elements):
            for el in elements:
                if query in el.content.lower():
                    results.append(
                        {"path": el.path, "type": el.type, "preview": el.content[:100]}
                    )
                walk(el.children)
    
        walk(self.elements)
        return results
  • Registers the search_text tool with the MCP server, defining its name, title, description, input schema (file_path and query), and output schema.
    Tool(
        name="search_text",
        title="Search Text in Document",
        description="Performs a semantic search for text strings and returns their structural paths.",
        inputSchema={
            "type": "object",
            "properties": {
                "file_path": {
                    "type": "string",
                    "examples": ["./document.md", "/path/to/file.md"],
                },
                "query": {
                    "type": "string",
                    "description": "String to search for",
                    "examples": ["TODO", "urgent", "deadline"],
                },
            },
            "required": ["file_path", "query"],
            "additionalProperties": False,
        },
        outputSchema={
            "type": "object",
            "properties": {
                "results": {
                    "type": "array",
                    "description": "List of matching elements with their paths",
                }
            },
        },
    ),
  • Tool dispatch handler in server.py that calls search_in_document with file_path and query, formats the result with count, and returns as CallToolResult.
    elif name == "search_text":
        res = await search_in_document(file_path, arguments["query"])
        result = {"results": res, "count": len(res)}
        return CallToolResult(
            content=[TextContent(type="text", text=json.dumps(result, ensure_ascii=False, indent=2))],
            structuredContent=result,
            isError=False,
        )
  • Helper method in EditTool class that loads the Document instance and delegates to its search_text method.
    async def search(self, file_path: str, query: str) -> List[Dict[str, Any]]:
        doc = self.get_doc(file_path)
        return doc.search_text(query)
  • Top-level async wrapper function that invokes the singleton EditTool instance's search method.
    async def search_in_document(file_path: str, query: str):
        return await _instance.search(file_path, query)
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'semantic search' and 'returns structural paths', but lacks details on permissions, rate limits, error handling, or what 'structural paths' entail (e.g., format, depth). This is a significant gap for a search tool with zero annotation coverage.

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?

The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague phrasing. It's appropriately sized for a tool with two parameters and an output schema.

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

Completeness3/5

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

Given the tool's moderate complexity (semantic search), no annotations, and an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral traits and parameter nuances, leaving gaps in understanding how to use it effectively beyond basic invocation.

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 50% (only 'query' has a description), and the description adds no parameter-specific information beyond what's in the schema. It doesn't explain 'file_path' semantics (e.g., supported formats, relative vs. absolute paths) or clarify 'semantic search' for the 'query' parameter. Baseline 3 is appropriate as the schema partially documents parameters.

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?

The description clearly states the action ('performs a semantic search for text strings') and the resource ('in document'), distinguishing it from siblings like 'search_tools' (which appears to be a meta-tool) and 'get_document_structure' (which retrieves structure without searching). The verb 'search' is specific and the scope is well-defined.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'search_text' over 'search_tools' or 'get_context', nor does it specify prerequisites like file existence or format compatibility. Usage is implied but not explicitly stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KazKozDev/markdown-editor-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server