Skip to main content
Glama
Sign In
Smart Quota Orchestrator

Smart Quota Orchestrator

by ElNeMeR70
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

sqo_pinpoint_error

Parses multi-language crash stack traces and extracts the exact source window around every local workspace frame in one call, helping you locate failure points without manual file searches.

Instructions

Parse any multi-file crash stack trace (Python, Node/TS, Dart/Flutter, Go, Rust, PHP) and extract the exact +-10 line source window around every local workspace frame in 1 call.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workspace": "<workspace>",
      "stack_trace": "<stack_trace>"
    },
    "name": "sqo_pinpoint_error"
  }
}

Input Schema

NameRequiredDescriptionDefault
radiusNoContext lines above/below crash line (default: 10).
workspaceYesWorkspace root path.
stack_traceYesRaw stack trace / traceback text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv13.0.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: it parses raw text, restricts output to 'local workspace frame' entries (implicitly skipping frames outside the workspace), and returns a bounded source window per frame. What it omits is failure behavior (missing/unreadable files, unparsable traces) and rough output size, which matter for a tool that reads files off disk.

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?

A single front-loaded sentence that leads with the action and outcome, with no filler. The parenthetical language list is long but earns its place by defining supported inputs; otherwise the sentence is tight.

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 three-parameter tool with fully documented schema and no output schema, the description covers purpose, input scope, and the shape of the result. It is slightly incomplete on error handling and output volume, which an agent needs to know before pointing it at a large trace.

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 100%, so all three parameters are already documented, and the baseline is 3. The description adds only marginal meaning: '+-10 line' ties the default of radius to the described window size, and 'local workspace frame' clarifies how workspace constrains which frames are resolved.

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 states a precise verb and resource: parse a multi-file crash stack trace and extract the +-10 line source window around each local workspace frame. It enumerates supported languages (Python, Node/TS, Dart/Flutter, Go, Rust, PHP), which sharply bounds scope. It does not explicitly differentiate itself from any sibling such as sqo_code_search, so it stops short of 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?

Usage is implied rather than stated: an agent can infer it should be called when a raw stack trace needs source context, and 'in 1 call' hints at replacing manual file reads. There is no explicit when-not guidance, no prerequisites (e.g., that the workspace path must contain the referenced files), and no named alternative tool.

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