Skip to main content
Glama
Platano78

Smart-AI-Bridge

by Platano78

batch_analyze

Run one question across multiple files and aggregate findings into a cross-file summary. Use for codebase-wide audits, per-feature reviews, or pre-merge sweeps.

Instructions

Run the SAME question against a glob of files, then aggregate the findings into one cross-file summary. Use for codebase-wide audits ('any SQL injection under src/**/handlers/*.js?'), per-feature reviews, or pre-merge sweeps. For ONE file, use analyze_file (cheaper). For NL search without a known file set, use explore. Set aggregateResults:false to get raw per-file results instead of the aggregated summary. Read-only: by default reads every matched file (capped by maxFiles) and makes one LLM call per file (parallel by default). options.grepFilter (string or string[], plain substrings — never regex, case-insensitive) narrows the file set to files whose content contains ANY term; it widens the scan before applying maxFiles, so filtering never just re-filters an already-truncated glob. options.singlePass (default false) makes exactly ONE LLM call across all matched files instead of one call per file — much cheaper, but perFileResults only reports which files contributed evidence, not a real per-file summary/confidence; evidence per file is grep-matched lines (with context) when grepFilter is set, otherwise the file's head, capped to fit the model's context window (reported via evidence_truncated). Returns: shape depends on aggregateResults/singlePass. aggregateResults:true, singlePass:false (default): {success, status:'completed', filesAnalyzed, patterns, question, aggregatedSummary, aggregatedFindings:[strings], aggregatedActions:[strings], overallConfidence, perFileResults:[{filePath, summary, findingCount, confidence}], processing_time, tokens_saved}. singlePass:true: same shape but perFileResults:[{filePath, contributedEvidence}], plus singlePass:true, evidence_truncated (input side — evidence was trimmed before the call, with evidence_dropped_files/evidence_truncation_hint when true), and was_truncated (output side — the aggregated answer itself hit the token limit, with truncation_hint when true). aggregateResults:false: {success, status:'completed', filesAnalyzed, patterns, question, results:[full per-file analysis objects], processing_time}. When grepFilter is set, responses also include grepFilter:{terms, filesScanned, filesMatched}. Empty pattern match: {success, status:'no_files', message, patterns}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
optionsNo
questionYesQuestion to ask about each file
filePatternsYesGlob patterns or file paths (e.g., ["src/**/*.ts", "lib/*.js"])

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv2.14.0
    • changedInput schema / properties / options / properties / backend / enum
      Previous value: -[
      -  "auto",
      -  "local",
      -  "deepseek",
      -  "glm",
      -  "qwen3",
      -  "gemini",
      -  "groq"
      -]New value: +[
      +  "auto",
      +  "local",
      +  "deepseek",
      +  "glm",
      +  "gemini",
      +  "groq"
      +]
    • addedInput schema / properties / options / properties / grepFilter
      Added value: +{
      +  "description": "Plain substring(s) to content-filter matched files by before maxFiles is applied (case-insensitive, never regex)",
      +  "oneOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  ]
      +}
    • addedInput schema / properties / options / properties / singlePass
      Added value: +{
      +  "default": false,
      +  "description": "Make exactly ONE LLM call across all matched files instead of one call per file (cheaper; perFileResults reports evidence contribution, not real per-file analysis)",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / options / properties / backend / enum
      Previous value: -[
      -  "auto",
      -  "local",
      -  "deepseek",
      -  "qwen3",
      -  "gemini",
      -  "groq"
      -]New value: +[
      +  "auto",
      +  "local",
      +  "deepseek",
      +  "glm",
      +  "qwen3",
      +  "gemini",
      +  "groq"
      +]
  3. Addedv1.3.2

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses read-only behavior ('Read-only: by default reads every matched file'), describes the default one-LLM-call-per-file and parallel execution, explains how grepFilter widens the scan before maxFiles truncation, details the singlePass behavior and its effect on perFileResults, and enumerates exact return shapes for every combination of aggregateResults and singlePass. It even handles the empty-match case. This is exhaustive and accurate.

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 long but well-structured: it starts with the core purpose and usage, then flows into behavioral details and finally enumerates return shapes per mode. Every sentence carries unique information—no filler or tautology. It is not minimal, but the complexity of the tool justifies the length. It could be trimmed slightly (e.g., splitting return-shape legend into a code block), but overall it is organized and front-loaded with the most critical guidance.

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?

This is a multi-mode tool with no output schema, so the description must fully specify return contracts—and it does. It details shapes for aggregateResults:true/false and singlePass variations, includes evidence_truncated and truncation_hint flags, lists the grepFilter response object, and even covers the no-files-matched outcome. Given the complexity and absence of an output schema, this is complete and actionable.

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

Parameters5/5

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

Schema coverage is 67%, but the description adds substantial meaning to all parameters and options. It explains the filePatterns glob syntax, clarifies that grepFilter is plain substrings (never regex, case-insensitive) and how it interacts with maxFiles, details the token-saving trade-offs of singlePass, and specifies what aggregateResults:false returns. This goes far beyond the schema's terse descriptions and compensates fully for the coverage gap.

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 opens with a precise action: 'Run the SAME question against a glob of files, then aggregate the findings into one cross-file summary.' It names the resource (glob of files) and the aggregation behavior, and explicitly contrasts with siblings: 'For ONE file, use `analyze_file` (cheaper). For NL search without a known file set, use `explore`.' This makes the tool's role unmistakable without needing to open any sibling schemas.

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?

It provides concrete use cases ('codebase-wide audits', 'per-feature reviews', 'pre-merge sweeps') and explicit exclusion criteria: 'For ONE file, use analyze_file (cheaper)' and 'For NL search without a known file set, use explore.' It also explains when to toggle aggregateResults for raw per-file output. This leaves no ambiguity about when to pick this tool over its siblings.

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

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/Platano78/Smart-AI-Bridge'

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