Spurvik

spurvik_find_unwrapped_calls

Read-onlyIdempotent

Heuristic static scan of one directory inside the workspace root for AI client calls that are not passed through withSpurvik, spurvikMiddleware, withSpurvikMastra, withSpurvikModel, withSpurvikModelProvider, withSpurvikLangGraph, or spurvikInterrupt. A StateGraph constructor is reported when the file does not call withSpurvikLangGraph. A bare interrupt() call is reported when the file does not call spurvikInterrupt or resolveLangGraphInterrupts. The scan reads .ts, .tsx, .js, .jsx, .mjs, .cjs, .mts, and .cts files. It does not read .md or .mdc files. Results are file:line. The line number is 1-based and counts every newline, including comments and strings. This is a heuristic, so it can miss a call or report one that is already wrapped. The scan does not change files and does not use the network. Paths that leave the workspace, including '..', are rejected. The scanner skips files named .env or .env.* (any case), including through symlinks and hard links. Over HTTP there is no workspace directory. Pass code (a string, max 128 KB) or files (an array of { path, content }). If neither is passed, this tool explains that, and how to run the local stdio MCP server or /spurvik:check for a directory scan.

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": "spurvik_find_unwrapped_calls"
  }
}

Input Schema

Name	Required	Description	Default
`code`	No
`files`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the safety profile, yet the description adds substantial context: it is explicitly a heuristic that can miss or over-report, it never modifies files, makes no network calls, rejects paths leaving the workspace, and skips .env files including via symlinks and hard links. It also discloses the file:line result format with 1-based line counting. This is rich disclosure well beyond the annotations.

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?

It is long but front-loaded, leading with the scan purpose before the detection rules and the transport caveat. Each sentence carries real information, with only minor redundancy in re-listing the wrapper set.

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 two-parameter, non-destructive scan with no output schema, the definition covers detection rules, file types, path constraints, transport differences, and error fallback. The one unfinished edge is what happens if both code and files are supplied, which keeps it from a 5.

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?

With 0% schema description coverage, the description must carry the load, and it does: code is a string capped at 128 KB, files is an array of { path, content }, and it explains the fallback behavior when neither is supplied. The main gap is that it never clarifies precedence if both code and files are passed.

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

Purpose4/5

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

The description gives a specific verb and resource ("Heuristic static scan ... for AI client calls that are not passed through withSpurvik") and enumerates the exact wrappers it looks for, so an agent knows precisely what it detects. There is a mild internal tension between the directory-scan framing in the first sentence and the code/files interface described later, and it is not explicitly differentiated from the three siblings, keeping it just below a 5.

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

Usage Guidelines3/5

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

The definition tells you what happens if neither parameter is passed (it explains how to run the local stdio server or /spurvik:check), which implicitly frames when this tool applies. However, it never states explicitly when to reach for this versus other tools or the recommended preconditions, so guidance is implied rather than spelled out.

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

All Spurvik tools Inspect

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.