Tusk Drift MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool serves a clear, distinct purpose: aggregation, schema discovery, span detail retrieval, trace tree, field value exploration, and search. No overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores (e.g., aggregate_spans, list_distinct_values, query_spans). No mixing of styles.
Tool Count5/5
6 tools is well-scoped for a telemetry/observability server, covering all necessary operations without being overwhelming or too sparse.
Completeness5/5
The tool set covers querying, aggregation, trace retrieval, span details, schema exploration, and field value discovery. No obvious gaps for the domain of analyzing API traffic spans.
Average 4.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It does not disclose any behavioral traits such as read-only nature, pagination, limits on results (though limit parameter exists), or potential performance implications. The description focuses on capabilities rather than behaviors or constraints.
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 concise at around 100 words, with a clear structure: primary purpose sentence, bulleted use cases, and code examples. Every sentence adds value with no redundancy. It is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema, the description only covers groupBy, metrics, and timeBucket in examples. It omits explanation for parameters like where, orderBy, limit, and doesn't describe the return format. The tool is complex and the description leaves gaps.
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 100%, but schema descriptions are minimal (e.g., 'Fields to group by'). The description adds significant value with concrete examples showing how to use groupBy and metrics together (e.g., groupBy = ['name'], metrics = ['count', 'avgDuration', 'p95Duration']), and includes use of timeBucket for time-series data.
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 clearly states 'Calculate aggregated metrics and statistics across spans' and provides examples of specific outputs (latency percentiles, error rates, request counts). It distinguishes itself from sibling tools like query_spans or get_trace by focusing on aggregation rather than raw data retrieval.
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?
The description lists explicit use cases with bullet points ('Get latency percentiles', 'Calculate error rates', etc.), guiding the agent on appropriate scenarios. It does not explicitly state when not to use or name alternatives, but the context of siblings implies that raw span queries should use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It indicates fetching includes payloads, but does not disclose any side effects, permissions, or rate limits. For a read-only tool, this is acceptable but not comprehensive.
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?
Extremely concise: two sentences plus a bulleted list. No filler, all sentences are informative and front-loaded.
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?
No output schema, so description should compensate for return value details. It mentions 'full details including payloads' but not the structure or default fields. Adequate for a straightforward fetch tool but leaves some ambiguity.
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 coverage is 100% with good parameter descriptions. The description adds context about 'full details including payloads' which complements the 'includePayloads' parameter, but does not significantly extend parameter understanding beyond the schema.
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?
Clear verb-resource combination ('Fetch specific span recordings by their IDs') and distinguishes from sibling tool 'query_spans' by emphasizing retrieval via known IDs rather than searching.
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?
Explicitly states when to use ('when you have span IDs from a previous query') and lists concrete use cases, providing clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It implies read-only by describing search/filter actions, but does not explicitly mention safety or side effects. The examples show querying, but pagination and performance are not discussed. Adequate but not fully comprehensive.
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?
The description is clear and well-structured with a purpose statement, use cases, and examples. It is relatively long but each part is useful. It could be slightly more concise without the examples, but the examples provide significant value.
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?
Given the complexity (nested 'where' clause, 7 parameters, no output schema), the description covers common scenarios and parameter usage well. It does not explain return format, but the examples hint at output fields. Adequate for most use cases.
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 coverage is 100%, baseline 3. The description adds concrete examples for the 'where' clause, showing how to filter by status, duration, and endpoint name. This adds practical meaning beyond the schema definitions, earning a 4.
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 clearly states 'Search and filter API traffic span recordings' and provides specific use cases (find by endpoint, errors, slow requests, recent traffic). It distinguishes itself from siblings like aggregate_spans and get_spans_by_ids by focusing on general filtering and searching.
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?
The description lists explicit use cases with examples, providing clear guidance on when to use the tool. However, it does not explicitly state when not to use it or compare with alternatives, though the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool as returning schema information and examples, implying a read-only operation. However, it does not explicitly state non-destructiveness, auth requirements, or rate limits. The description is adequate but lacks explicit behavioral guarantees.
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 concise with about 10 sentences, well-structured with a clear opening statement, bullet points for use cases, and a list of common packages. Every sentence adds value, and the length is appropriate for the tool's complexity.
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?
Given the tool has 6 parameters and no output schema, the description is quite complete: it explains the purpose, use cases, common parameter values, and what the tool returns (schema info, examples). It could be improved by mentioning the format of the output or any limitations, but overall it provides sufficient context.
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 input schema covers all 6 parameters with descriptions (100% coverage). The description adds value by listing common package names and their typical fields, which helps parameter selection. The schema descriptions are clear, so the description provides additional context rather than being essential for understanding parameters.
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 clearly states the tool's purpose: 'Get schema and structure information for span recordings on Tusk Drift.' It explains what the tool returns (fields, example payloads) and distinguishes it from sibling tools like query_spans and aggregate_spans by focusing on metadata rather than data retrieval.
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?
The description explicitly lists three use cases (understand available fields, see example payloads, learn what to filter on) and provides common package names with relevant fields. It does not explicitly mention when not to use or provide alternatives, but the use cases are clear and sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Clearly states it returns a hierarchical tree of spans, indicating read-only behavior. Does not mention side effects, authorization, or rate limits, but main behavioral traits are transparent. Schema covers parameter details.
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?
Description is structured with bullet-pointed use cases and clear workflow. It is reasonably concise, though could be slightly more streamlined. Every sentence adds value.
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?
Given four parameters and no output schema, description provides good contextual completeness: explains purpose, use cases, prerequisite sibling tool, and parameter implications. Lacks details about return format beyond 'hierarchical tree', but sufficient for selection.
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% with per-parameter descriptions. Description adds overall context (e.g., uses traceId to fetch full trace) but does not enhance individual parameter semantics beyond schema. Baseline 3 is appropriate.
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?
Description clearly states it retrieves all spans in a distributed trace as a hierarchical tree, distinguishing it from sibling tools like query_spans. The verb 'get' and specific resource 'spans' with shape 'hierarchical tree' provide exact purpose.
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?
Explicitly states to use query_spans first to find spans, then use traceId. Lists clear use cases: debug end-to-end, see call chain, understand timing, identify bottlenecks. Provides workflow and context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates read-only behavior and ordering by frequency. However, it omits details like output format (e.g., whether counts are included) and any constraints on field selection.
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 concise and well-structured, with a clear opening sentence followed by bullet-pointed use cases. Every sentence adds value without redundancy.
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?
While the description provides good usage examples, it is incomplete regarding output format (no output schema) and does not explain the structure of the returned data. For a data exploration tool, this is a notable gap.
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 coverage is 100%, so baseline is 3. The description adds value by providing concrete examples for the 'field' parameter (name, packageName, environment, outputValue.statusCode), explaining its purpose beyond the schema. No significant additional detail for other parameters.
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 clearly states 'List unique values for a field, ordered by frequency' and provides concrete use cases (discovering endpoints, instrumentation packages, environments, JSONB values). This distinguishes it from sibling tools like query_spans or aggregate_spans.
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?
The description explicitly lists when to use the tool (e.g., discovering available endpoints) and implies usage before building specific queries. However, it does not name alternative tools for different scenarios, leaving a slight gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![drift-mcp MCP server](https://glama.ai/mcp/servers/Use-Tusk/drift-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Use-Tusk/drift-mcp)

Score Badge

Copy to your README.md:

[![drift-mcp MCP server](https://glama.ai/mcp/servers/Use-Tusk/drift-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Use-Tusk/drift-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Use-Tusk/drift-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server