Skip to main content
Glama
Tokenectomy-Labs

Tokenectomy-Razor

by Tokenectomy-Labs
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Rust
Local

search_stack_overflow

Find verified programming solutions by querying the Stack Overflow API with an error signature, returning relevant discussions and answers with excerpts.

Instructions

Queries the public Stack Overflow / Stack Exchange API for verified programming solutions and discussions matching an error signature.

• Side Effects: None. Strictly read-only network search; does not mutate local files or repository state. • Auth & Permissions: No API key required for standard rate-limited anonymous queries. • Rate Limits: Subject to public Stack Exchange API rate limits (~300 requests/day per IP). Results are cached locally when possible. • Return Shape: Returns a JSON object containing 'query', 'total_results', and 'results' (array of objects with title, url, score, is_answered, answer_count, and answer excerpt). • Failure Modes: Returns empty results array if no matching questions exist. Returns an error message if network connectivity fails or API quota is exhausted. • When to use: Use when local code context from get_error_context is insufficient and external community patterns, known library bugs, or API migration examples are needed. • When NOT to use: Do NOT use with raw un-sanitized logs containing private tokens or file paths, do NOT use for local codebase inspection (use get_error_context), and do NOT use to edit code (use apply_code_patch). • Prerequisites: Outbound HTTP internet access to api.stackexchange.com.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesTargeted search query string (e.g. 'ValueError: unsupported operand type(s) for +: int and str'). Must be free of project-specific paths, private tokens, or proprietary variable names. 3 to 150 characters recommended.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.8
    • addedInput schema / properties / query / description
      Added value: +"Targeted search query string (e.g. 'ValueError: unsupported operand type(s) for +: int and str'). Must be free of project-specific paths, private tokens, or proprietary variable names. 3 to 150 characters recommended."
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and covers side effects (strictly read-only), auth requirements (no API key), rate limits, return shape, and failure modes. This is precisely the behavioral context an agent needs before invoking an external network tool.

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 front-loaded with the core purpose and then organized into clearly labeled bullet sections. Every bullet conveys necessary operational guidance, and there is no filler or redundant restatement of the tool name.

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?

Given that there is no output schema and the tool depends on external network behavior, the description fully covers return shape, failure modes, rate limits, and prerequisites. An agent has all the information needed to decide whether and how to call this tool safely and correctly.

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?

The schema already documents the query parameter at 100% coverage, so the baseline is 3. The description adds valuable semantics beyond the schema by advising that the query must be free of project-specific paths/tokens and recommending a 3-150 character length, which helps the agent formulate a valid and safe query.

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 states a specific verb and resource: 'Queries the public Stack Overflow / Stack Exchange API' for solutions matching an error signature. It also differentiates from siblings by referencing local context tools and code-editing tools, so an agent can clearly tell what this tool is for.

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?

The description includes explicit 'When to use' and 'When NOT to use' sections naming sibling tools get_error_context and apply_code_patch as alternatives. It specifies the conditions under which this tool is preferred and when it must be avoided, leaving no room for inference.

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