Skip to main content
Glama
Sign In
syncause-debug-mcp

syncause-debug-mcp

by Syncause
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

search_debug_traces

Find relevant error logs, slow queries, or business ID execution traces using natural language queries to diagnose runtime issues and fix root causes with evidence.

Instructions

Entry point for troubleshooting. Search for relevant error logs, slow queries, or specific business ID execution traces based on user questions or error descriptions.

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": {
      "projectId": "<projectId>",
      "query": "<query>"
    },
    "name": "search_debug_traces"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of most relevant trace records to return.
queryYesA natural language description of the issue or context you are investigating. It can include specific error messages, symptoms (e.g., 'high latency'), business IDs (e.g., 'order #123'), or any general question about the request execution flow you want to analyze.
sinceNoOptional time range for the search (e.g., '30m', '1h', '1d'). Defaults to empty, which means no time limit.
projectIdYesThe unique identifier of the project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.15

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, and it mostly stops at purpose. It does not say the operation is read-only, that results are ranked by relevance, what a trace record contains, or how the time window interacts with the limit; the only behavioral hints ('most relevant', default time range) come from the schema rather than the description.

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?

Two compact sentences with the troubleshooting role front-loaded before the list of searchable content. There is no filler, though the second sentence is a long clause chain that could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description is the only place an agent could learn what a returned 'trace record' looks like and in what form, and it does not say. It also leaves the follow-up workflow unspecified across four sibling tools, so it is adequate for issuing a call but thin for interpreting results.

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 every parameter is already documented in the schema, which sets the baseline at 3. The description's mention of error messages, slow queries, and business IDs loosely reinforces the 'query' parameter's intent, but adds little meaning beyond what the schema text already states.

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 ('Search') and a clearly delimited resource ('error logs, slow queries, or specific business ID execution traces'), plus it frames the tool as the troubleshooting entry point. An agent can tell it apart from analysis-oriented siblings like diff_trace_execution or get_trace_insight, though those siblings are never named explicitly.

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?

'Entry point for troubleshooting' implies this should be called first when investigating an issue, which is a real usage signal. However, it never states when NOT to use it, nor does it route the agent to get_trace_insight or diff_trace_execution for follow-up work, so the guidance stays implicit rather than explicit.

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