Trust Engine MCP

scan_for_models

Scan a codebase or provided text to find all AI model IDs in use and flag which are deprecated or retired, with dates, platform, and replacements. Use before upgrades or when calls fail.

Instructions

Find every AI model id used in this codebase (OpenAI, Anthropic, Gemini, Bedrock, Mistral) and tell which ones are being retired or deprecated, by when, on which platform, and the vendor's replacement, with the source link. Use it before upgrading dependencies, when a model call starts failing, or when asked "are we using any deprecated models?". Read-only and local.

Inputs: path (optional, a file or folder inside the current working directory; default: the working directory) or texts (a list of {name, content} you already have). Limits: 2,000 files / 5 MB. Skips .git, node_modules, virtualenvs, dist, build, lockfiles and binaries; never opens .env files (reports them by name). Returns file:line for each model found and the check_my_models result for those models.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_for_models"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No
`texts`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Nov 14, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so: it declares the tool is read-only and local, publishes hard limits (2,000 files / 5 MB), enumerates the directories and file types skipped, and discloses the .env policy (never opened, reported by name only). That is exactly the safety and side-effect context an agent needs before running a filesystem scan.

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-loaded with the outcome first, then usage triggers, then a clearly separated Inputs/Limits/Returns block, so an agent can stop reading early and still act. It is on the long side and the vendor parenthetical (OpenAI, Anthropic, Gemini, Bedrock, Mistral) plus the skip list add density, though both carry real information.

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?

An output schema exists, so return values did not need spelling out, yet the description still summarizes the shape (file:line per model plus the check_my_models result), removing any doubt about what comes back. Combined with the limits, skip rules, and .env handling, nothing an agent needs to invoke this correctly is missing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must define both parameters, and it does: path is 'a file or folder inside the current working directory' defaulting to the working directory, and texts is a list of {name, content} pairs already in hand. The only remaining ambiguity is that the 'or' framing never says whether the two inputs are mutually exclusive or can be combined.

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 and resource ('Find every AI model id used in this codebase') plus the enrichment it performs (retirement/deprecation dates, platform, replacement, source link). The scope is concrete enough that an agent can distinguish it from sibling utilities such as model_retirements or check_my_models without opening any schema.

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?

Gives three explicit trigger conditions: before upgrading dependencies, when a model call starts failing, and when asked about deprecated model usage. It also implicitly positions itself upstream of check_my_models by saying it returns that tool's result. It does not state when NOT to use it (e.g. a single known model id), so it falls short of a full routing rule.

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

Deploy Server