Scouter MCP Server

Server Quality Checklist

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

Latest release: v1.0.5
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs like get_realtime_xlogs vs get_raw_xlog and get_agent_info vs get_thread_dump could be confused at first glance. Descriptions are detailed enough to separate them, but the boundaries are not perfectly crisp.
Naming Consistency4/5
The vast majority of tools follow a get_<noun> pattern (e.g., get_system_overview, get_transaction_detail). Two tools deviate: diagnose_performance and lookup_text. This is a minor inconsistency, but the overall naming is predictable and readable.
Tool Count4/5
25 tools is on the heavier side, but the server covers a broad APM domain: transactions, services, SQL, errors, alerts, configuration, and raw data access. Each tool addresses a legitimate need, so the count feels justified rather than bloated.
Completeness5/5
The tool surface is remarkably complete for a performance monitoring server. It covers system overview, automated diagnosis, counter trends, transaction search and detail, distributed tracing, service analysis, SQL analysis, error analysis, visitor statistics, alerts, configuration reading, host/agent info, thread dumps, and raw data access. There are no obvious dead ends or missing core operations.
Average 4.2/5 across 25 of 25 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context on the realtime/daily/hourly modes, which clarifies the kind of data returned. However, it does not mention the 'group' mode, creating a slight inconsistency with the schema enum, though it does not contradict annotations.
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 two sentences, front-loading the primary purpose and then listing supported modes and use case. There is no fluff or redundancy, making it highly concise.
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?
The tool has moderate complexity with 4 modes and 7 params, but the schema and annotations cover much of the behavior. The description explains three of the four modes, notably missing 'group'. Without an output schema, a note on the response format for each mode would have been valuable, but the schema's parameter descriptions mitigate this gap.
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?
The schema covers all 7 parameters with 100% description coverage, so the description need not repeat parameter details. The mention of modes aligns with the 'mode' parameter but adds no extra syntax or constraints beyond the schema. Baseline 3 applies.
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 clearly identifies the tool as retrieving unique visitor statistics and enumerates the supported modes (realtime, daily, hourly). This distinguishes it from sibling tools that focus on IPs, user agents, or counters. However, it omits the 'group' mode present in the schema, so it is not fully exhaustive.
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 description offers a general use case ('useful for understanding traffic patterns and user activity'), which implicitly suggests when to use the tool. It does not name any alternatives or explicitly exclude other tools, so guidance is minimal but present.
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?
Annotations already provide readOnlyHint/idempotentHint/destructiveHint, so the bar is lower. The description adds the scope (across services, multiple via txids) but no additional behavioral details like rate limits or response shape. Consistent with annotations.
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?
Two sentences, front-loaded with the core purpose, and every word is informative. No filler.
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 read-only, well-annotated tool with full schema coverage, the description covers the core use cases and prerequisite flow. It doesn't explain return format, but given annotations and schema richness, it's sufficiently complete. Slightly less comprehensive than the TDQS 4.3 example.
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 baseline is 3. The description does not add parameter-level details beyond the schema; it merely mentions GXID and txid list, which are already documented. No additional semantic value.
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 traces distributed transactions across services via GXID or fetches multiple by txid list. It uses an active verb and specifies the resource (distributed trace), distinguishing it from sibling tools like get_transaction_detail.
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?
Explicit context is given: 'Essential for MSA environments' and 'Use after finding a GXID in get_transaction_detail' provides a clear when-to-use and a related tool. It lacks explicit exclusions or when-not-to-use, so it falls short of a 5.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context by explaining the output contents (ranked errors, stack traces, sample transaction IDs, per-service rates) and the time-range analysis behavior. No contradictions with annotations.
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 two sentences, front-loaded with the primary purpose, and every sentence adds value. It concisely conveys what the tool does and what it returns without unnecessary filler.
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?
With no output schema, the description carries the burden of explaining return values, and it does so well (error types, messages, stack traces, sample transaction IDs, per-service rates). It does not describe limitations or aggregation specifics, but given the tool's scope and strong annotations, it is sufficiently complete.
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 the baseline is 3. The description references the time range (start_time/end_time) but adds no additional semantic detail beyond what the schema already provides for parameters like obj_hash and obj_type. The schema descriptions are sufficient.
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: 'Analyze errors within a time range' and details what it returns (ranked error types, stack traces, sample transaction IDs, per-service error rates). This distinguishes it from sibling tools like get_system_overview or diagnose_performance by focusing specifically on error analysis with drill-down data.
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 context is implied (use for error analysis within a time range), but the description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The sibling list includes several diagnostic tools, so explicit guidance would improve clarity.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds behavioral context by specifying the two ways to target a host (obj_hash or obj_type) and the types of information returned (top processes, disk usage). It does not mention return format, pagination, or potential errors, so value beyond annotations is moderate.
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 two sentences long and front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, and the second explains requirements and provides a pointer to a sibling tool. No redundant or vague phrasing.
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 simple read-only tool with full parameter schema coverage and strong annotations, the description is adequate. It explains the main usage modes (obj_hash vs obj_type) and what data is returned (top processes, disk usage). There is no output schema, so the description does not need to explain return values in detail, and the content described is sufficient for an agent to select and invoke the tool.
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?
The input schema provides 100% coverage with descriptions for all four parameters. The description adds minimal semantic value by tying include_top to 'top processes' and include_disk to 'disk usage', but this is already implied by the schema. No new syntax or format details are provided, so the description does not substantially enhance 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?
The description clearly states the tool's purpose: 'Get host-level system information: top processes (by CPU/memory) and disk usage.' It uses a specific verb ('Get') and resource ('host-level system information'), and the detail about top processes and disk usage distinguishes it from sibling tools like get_system_overview or get_server_info.
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 explains when to use the tool (to retrieve host info) and provides a prerequisite: either provide an obj_hash or specify obj_type. It explicitly references get_system_overview for finding host agent hashes, which is useful guidance. However, it lacks explicit when-not-to-use conditions or comparisons to alternative tools for the same type of data.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds some behavioral context about aggregation (shows top traffic generators), but it does not disclose details like return format, pagination, or any operational side effects. No contradiction with annotations.
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, only three sentences, with the main action front-loaded. Each sentence adds value: the function, the output, and the use case. No redundancy or fluff.
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 parameters are fully documented in the schema and annotations cover safety, the description adequately covers purpose and use cases. However, with no output schema, it could be slightly more explicit about the exact return structure (e.g., counts, sorting), though 'Shows which IPs generate the most traffic' gives a reasonable hint. Overall a minor gap.
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 the input schema already documents all 5 parameters. The description does not add parameter-specific meaning beyond the core dimension of 'client IP address'. Thus the baseline of 3 applies.
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 function with a specific verb ('Analyze') and resource ('request distribution by client IP address'). It also specifies what it shows ('which IPs generate the most traffic'), which distinguishes it from sibling tools like get_user_agent_summary or get_service_summary.
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 provides clear context for when to use the tool ('Useful for identifying heavy users, bots, or potential DDoS sources'), but it does not explicitly mention when not to use it or provide alternative tool names. This fits 'clear context, no exclusions' rather than the full 5-point guideline.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the tool is for analysis and detection, but does not disclose additional behavioral traits such as pagination, aggregation details, or any potential performance implications. It does not contradict annotations.
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 three sentences long, front-loaded with the core function, and every sentence adds value. No fluff or redundancy.
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's low complexity (5 optional params, no output schema, no nested objects), the description adequately explains the tool's purpose and output. It does not explicitly detail the return format, but the description implies aggregated client counts, which is enough for an agent. Sibling context further clarifies its niche.
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?
All five parameters are fully described in the input schema, achieving 100% schema description coverage. The description does not add extra parameter-level semantics beyond the schema, but the schema itself is sufficient. 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?
The description clearly states the tool analyzes request distribution by browser/user-agent, distinguishing it from siblings like get_ip_summary. It specifies the resource (user agents) and the action (analyze distribution), with concrete output examples (which clients generate traffic).
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?
Provides clear use cases: understanding client demographics and detecting crawlers. This implies when to use the tool, though it does not explicitly mention alternatives or exclusions. The context is sufficient for an agent to decide between this and sibling tools like get_visitor_stats.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds useful behavior context such as 'currently executing' and 'sorted by elapsed time descending', but does not go beyond that. No contradiction with annotations.
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 exactly two sentences, front-loaded with the core purpose and immediate usage guidance. Every word earns its place with no filler or redundancy.
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?
With no output schema, the description does state the return behavior: 'Returns active services sorted by elapsed time descending'. This covers the main return aspect. It lacks detail on return fields or pagination, but for a simple read-only list tool with well-documented parameters, it is sufficiently complete.
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 all four parameters (obj_hash, obj_type, thread_id, min_elapsed_ms) having clear descriptions. The tool description does not add additional parameter-level meaning, but the baseline of 3 is appropriate since the schema carries the full burden.
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 what the tool does: 'Show all currently executing requests (in-flight transactions)' with a specific verb and resource. It also distinguishes itself from siblings by emphasizing 'currently executing' and 'sorted by elapsed time descending', which differentiates it from historical search or thread dump tools.
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?
Explicit guidance is provided: 'Use when investigating hangs, slow conditions, or asking "what is running right now"'. This gives clear context for when to use the tool. However, it does not mention alternatives or exclusions, so it falls short of a 5.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context that the tool maps integer hashes to original text, which is beyond the schema. It does not disclose any additional behavioral traits like rate limits or error handling, but for a simple lookup tool this is acceptable.
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?
Two sentences, front-loaded with the verb 'Resolve', and no unnecessary words. Every sentence adds value: first states the core function, second explains when to use it. Excellent conciseness.
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 simple read-only lookup with a well-covered schema and safety annotations, the description is complete enough. It explains the purpose, the mapping concept, and the usage context. It doesn't describe return values for unknown hashes, but there is no output schema requirement and the tool's simplicity makes this a minor gap.
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 the schema already documents each parameter. The description clarifies that hashes refer to comma-separated integer IDs and that the tool returns original text values, adding some meaning. However, it doesn't go beyond the schema's descriptions, so the 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?
The description uses a specific verb+resource ('Resolve hash IDs to their original text values') and clearly distinguishes this from sibling tools by explaining it converts hashes to text, which is not covered by the other getters. It also mentions that these hashes appear in other tool outputs, giving a clear purpose.
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 says to use this when you encounter a hash ID in other tool outputs ('Use this to get the actual text for a hash ID seen in other tool outputs'). It gives a clear context, though it does not explicitly name alternative tools or state exclusions. This is sufficient guidance for this read-only utility.
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?
Annotations already state readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context by noting the multi-step nature of the diagnosis and the specific data sources it inspects (e.g., slow SQL, service hotspots). It also explains the report structure (severity levels and suggested actions). This exceeds the baseline but doesn't disclose potential runtime or cost implications, keeping it at 4.
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 two sentences, front-loaded with the main action, then details and output. Every word earns its place — no redundancy or filler. It is succinct yet informative.
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?
The description provides a solid overview of inputs, actions, and outputs, but with no output schema, it does not detail the report structure beyond severity and suggested actions. It omits any clarification of what obj_type filters (e.g., specific object types) and any indication of the operation's cost. Given the tool's complexity, the description is reasonably complete but leaves some contextual gaps, justifying a 4.
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%: both parameters (obj_type and time_range_minutes) have descriptions. The tool description does not add parameter behavior beyond what the schema provides, so it relies on the schema baseline. The description neither enhances nor detracts from the parameter understanding, meriting a 3.
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 function with a specific verb and resource: "Perform automated multi-step performance diagnosis." It enumerates the checks (system counters, active services, error patterns, slow SQL, service hotspots) and the output (structured diagnostic report with severity ratings and suggested actions), distinguishing it from sibling tools that focus on individual metrics.
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 implies when to use it — for a comprehensive, multi-step diagnosis rather than a single metric — but it does not explicitly name alternatives or exclusions. The context is clear: it is a holistic diagnostic report tool, unlike the granular get_* sibling tools. However, there is no explicit 'when not to use' guidance, so it falls short of a 5.
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?
Annotations already declare the tool safe (read-only, idempotent, non-destructive). The description adds valuable context beyond annotations: it is 'real-time' and returns specific metrics. No contradictions with annotations. Lacks details like pagination or time-window semantics, but the addition of real-time behavior and output metrics earns a 4.
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?
Three concise sentences: the first states the action, the second details the output, and the third provides the use case. No wasted words or redundant information. Fully front-loaded and easy to scan.
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's simplicity (2 optional params, no output schema), the description covers the main purpose, data returned, and use case. It doesn't mention filtering behavior or alternative tools, but the schema handles filtering. It's adequate but not as exhaustive as the get_calls example, which explicitly noted scope limitations.
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 the baseline is 3. The description does not add any parameter-specific guidance beyond what the schema already provides; both obj_type and obj_hashes are clearly described in the schema. No extra semantic value from the description.
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 function with a specific verb and resource: 'Get real-time service-to-service call relationships.' It elaborates with the exact metrics shown (call counts, error counts, latency) and distinguishes itself from siblings like get_counter_trend or get_service_summary by focusing on relationship topology rather than individual counters or summaries.
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?
Provides clear context for when to use: 'Useful for understanding service dependencies and topology.' This implies a use case distinct from diagnostic or transaction-focused tools, but it doesn't explicitly mention alternatives or when not to use, so it falls short of a 5.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that it returns decoded XLog entries along with loop/index offsets for subsequent polling, clarifying the incremental and paginated nature of the data.
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 three concise sentences that front-load the purpose and provide essential usage details without extraneous information. Every sentence earns its place.
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 polling tool with no output schema, the description adequately explains the return format (decoded XLog entries with offsets) and the initial usage pattern. It could mention what happens when no data is available or how to terminate polling, but it is sufficiently complete for an agent to use the tool correctly.
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 the baseline is 3. The description reinforces the offset usage pattern ('Use offset 0/0 ... pass returned offsets') but adds little beyond what the schema already states about the offset parameters. It does not introduce new semantic details for obj_type or obj_hashes 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?
The description clearly states the action ('Get') and resource ('recent real-time transaction data (XLogs)') with a specific scope ('since given offsets'). It distinguishes itself from the sibling tool get_raw_xlog by specifying 'decoded' entries rather than raw, making its purpose unambiguous.
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?
It provides explicit usage guidance for the polling pattern: 'Use offset 0/0 for the first call, then pass returned offsets to get newer data.' However, it does not mention alternatives or when not to use this tool, so it stops short of a 5.
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?
Annotations already declare read-only, idempotent, and non-destructive, lowering the bar. The description adds context by detailing the types of statistics included (most-called services, error rates, resource usage) and the external API call summary, going beyond annotation-only information.
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?
Two sentences, about 25 words, efficiently convey the tool's purpose and key included data with no redundancy. Information is front-loaded and every word earns its place.
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 a rich schema and strong annotations, the description provides a high-level understanding of the returned data and core features. It does not describe output structure or time-range behavior, but the schema covers time defaults and max_count, so the description is adequately complete for a read-only summary tool.
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 descriptions cover 100% of parameters but are terse (e.g., 'Sort criteria' for sort_by). The description adds semantic meaning by explaining the metrics (count, error rate, elapsed) and the include_api_calls flag, which enhances understanding of parameter intent.
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 aggregated service-level performance statistics, lists the specific dimensions (call count, error rates, resource consumption), and mentions external API call summary. This differentiates it from error-specific or transaction-specific tools.
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 description implies usage for service-level performance analysis, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. While it conveys the purpose, it lacks clear guidance on tool selection among siblings.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations by specifying the output ranking, time-range scoping, and metrics returned. This is useful and not contradictory.
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 two sentences, front-loaded with the core function, followed by usage guidance. Every sentence earns its place with no redundancy or fluff.
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?
The tool has 6 optional parameters, no output schema, and good annotation coverage. The description explains the purpose, output content, and usage context. It does not describe all filter options (obj_hash, obj_type) but the schema covers them, so the description is sufficiently complete for a read-only list tool.
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 the schema fully documents each parameter. The description provides high-level context (time range, ranking, counts) that aligns with parameters like start_time, sort_by, and max_count, but it does not add detailed semantics beyond the 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?
The description clearly states the tool analyzes SQL performance within a time range and returns ranked SQL statements with execution counts, error counts, and average execution time. This specific verb+resource+scope distinguishes it from siblings like get_error_summary or get_counter_trend.
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 provides explicit context: 'Use when investigating database-related performance issues.' It does not name alternatives or exclusions, but the usage scenario is clear enough to guide tool selection among the sibling tools.
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?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds important behavioral nuance beyond annotations: 'Stack traces require HTTP mode; TCP mode returns thread states only.' This discloses a mode-dependent limitation that the agent must know. It also mentions optional heap histogram inclusion. Some context about output size or latency is missing, but the additional mode disclosure justifies a 4.
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?
Four short sentences, all substantive. The first sentence states the action, the second states use cases, the third explains the optional parameter, and the fourth reveals a critical mode dependency. No filler or redundant phrasing, and key information is front-loaded.
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 diagnostic tool with two well-documented parameters and no output schema, the description is fairly complete. It covers purpose, use cases, optional behavior, and a crucial mode limitation. The only gap is the lack of any mention of expected output format or structure, but since no output schema exists, the description would benefit from stating what sort of data is returned. Still, the essential context is present.
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% for both parameters, so the schema already explains obj_hash and include_heap_histogram. The tool description hints at the heap histogram purpose ('for memory analysis') and the agent-specific obj_hash, but adds no new semantic detail beyond what the schema provides. 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?
The description clearly states the tool captures a thread dump from a specific JVM agent, with optional heap histogram. It names specific use cases (deadlocks, thread contention, thread activity) which distinguish it from sibling diagnostic tools like get_system_overview or diagnose_performance. The verb+resource is concrete and unambiguous.
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?
Explicitly says 'Use for diagnosing deadlocks, thread contention, or understanding thread activity', giving clear when-to-use guidance. It does not explicitly name alternatives or exclude other tools, but the purpose statement makes the intended context evident. No when-not-to-use is provided, so it falls just short of a 5.
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?
Annotations already provide readOnly, idempotent, and non-destructive hints, so the safety profile is covered. The description adds context about the content returned (execution profile) but does not disclose additional behavioral traits such as pagination, size limits, or performance considerations beyond what the schema already covers. No contradiction with annotations.
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 two sentences: the first states the core purpose, the second gives usage context. It is concise, front-loaded, and contains no extraneous information.
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 lack of an output schema, the description compensates by stating that the tool returns an execution profile with specific components (SQL, API calls, method traces). The parameters are thoroughly documented in the schema, and the annotations cover safety. It could be slightly more explicit about the response format or error cases, but it is adequate for selection and invocation.
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?
The input schema has 100% coverage with each parameter (txid, date, max_steps) having a descriptive description. The tool description adds no further parameter-level meaning, so the baseline score of 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?
The description clearly states that the tool retrieves full details of a specific transaction, enumerating the execution profile components (SQL queries, API calls, method traces). This differentiates it from sibling tools like search_transactions and list_active_services, which are about discovery rather than detail.
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 explicitly directs the agent to use this tool after identifying a problematic transaction from search_transactions or list_active_services, naming the preceding tools. This provides clear workflow timing and implies when not to use it (i.e., not for discovery).
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by indicating the output is aggregated statistics and frequency-based, which goes beyond the annotations and helps set expectations.
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 two sentences, front-loaded with the core purpose, and every sentence contributes value. The mention of the sibling tool is brief but useful, and there is no redundant information.
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?
For a read-only aggregation tool with good annotations and full schema coverage, the description is sufficient. It explains what the tool returns (aggregated statistics and frequency), the time range scope, and how it relates to get_system_overview. No output schema exists, but the description gives a reasonable hint of the return type.
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 the baseline is 3. The description does not add any parameter-specific information beyond what the schema already provides. It mentions time range generically, but start_time and end_time are already well described in 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?
The description clearly states the tool's function: 'Get aggregated alert statistics within a time range' and 'Shows which alert types fired most frequently.' It uses a specific verb and resource, and distinguishes itself from the sibling tool get_system_overview by contrasting historical aggregated data with recent real-time alerts.
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 names get_system_overview as a complementary tool and explains the use case: 'Use alongside get_system_overview ... for historical alert pattern analysis.' This provides clear context for when to use it, though it does not explicitly state when not to use it or list exclusions.
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?
Annotations already disclose the tool is read-only, idempotent, and non-destructive. The description adds useful context about what the snapshot includes (real-time counters, agents, etc.), going beyond the structured annotations. It does not mention potential costs or rate limits, but for this tool the content disclosure is sufficient given 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action and content, and ends with actionable guidance. Every sentence earns its place with no redundancy or wasted words.
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?
For a tool with one optional parameter and no output schema, the description covers purpose, return content categories, and usage recommendation. The explicit list of what the snapshot includes compensates for the lack of an output schema, making the description functionally complete.
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?
The schema covers 100% of the parameter with a clear description of 'obj_type' (filter, auto-discovers if omitted). The tool description does not add any additional parameter semantics, so the baseline of 3 for high schema coverage applies.
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 provides a comprehensive snapshot of system status, listing specific content (agents, TPS/response time/heap/CPU counters, active service counts, recent alerts). The verb 'Get' and the resource are specific, and the starting-point positioning distinguishes it from the narrower sibling tools.
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 recommends using this tool as the starting point for any investigation, providing clear context for when to use it. However, it does not mention alternatives or when not to use it, so it stops short of a full 5.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context by noting that the thread list shows live states rather than stack traces, and by itemizing the returned data categories. This exceeds the baseline set by annotations without contradicting them.
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 two sentences, with the first sentence front-loading the primary action and content list, and the second adding a key distinction and usage context. Every word earns its place; no redundancy or filler.
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 read-only annotations, well-documented parameters, and the explicit contrast with thread dump, the description is largely complete. The only minor gap is that it does not describe the return format, but no output schema exists and the listed content categories sufficiently indicate what will be returned.
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?
The input schema provides complete descriptions for all four parameters (100% coverage), so the schema already documents their semantics. The description's mention of threads, environment, and sockets loosely maps to the include_* parameters but does not add deeper meaning beyond the schema. Baseline of 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?
The description uses a specific verb 'Get' with a clear resource ('detailed agent runtime information') and enumerates the exact contents: thread list with states, active services, environment variables, and socket connections. It also distinguishes the tool from the sibling 'get_thread_dump' by contrasting live thread states with stack traces.
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?
Provides explicit usage guidance by stating 'Use for deep agent-level investigation' and explicitly names an alternative ('unlike thread dump which captures stack traces'), giving a clear when-not-to-use condition. The parameter description also references 'get_system_overview' as a source for obj_hash, establishing a prerequisite flow.
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?
Annotations already indicate readOnly and idempotent, but the description adds the HTTP-mode-only limitation and clarifies the tool returns the current script, threshold rules, and configuration. This adds meaningful context beyond the structured annotations without any contradiction.
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?
Three sentences, each with a purpose: what it does, what it shows, and how to discover counter names. No redundant phrasing, and the core purpose is front-loaded.
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's simplicity and rich schema/annotations, the description is sufficient: it specifies the HTTP-only mode, output content, and a prerequisite discovery step. No output schema exists, but the description covers key behavior without needing to detail return formats.
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 covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The description adds a discovery hint for counter_name ('Use get_server_info with include_counter_model'), which goes beyond the schema's example values. This small extra guidance justifies 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?
Description states 'Read alert scripting configuration for a specific counter' with a specific verb and resource, and lists what it shows (current alert script, threshold rules, configuration). It distinguishes from sibling tools like get_alert_summary by targeting scripting config for a counter.
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 provides clear guidance: '[HTTP mode only]' is a usage constraint, and it explicitly directs to get_server_info with include_counter_model for discovering counter names. It does not explicitly mention when not to use this tool, but the alternative guidance is helpful.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable context beyond annotations: it restricts usage to HTTP mode and explains that the result differs based on obj_hash (server config vs. agent config). This enriches the agent's understanding without contradicting annotations.
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 two sentences of dense, directly relevant information. It front-loads the HTTP-mode restriction and read-only nature, then explains the two behavior paths. No filler or redundant elaboration.
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's simplicity (one optional parameter, no output schema), the description is adequately complete. It explains both invocation scenarios and points to the correct sibling tool for a prerequisite. It does not describe the returned config structure, but for a read-only configuration tool that is not a significant gap; the schema and mode explanation suffice.
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 already covers 100% of the parameter with a clear description. The tool description further adds meaning by describing the behavioral consequence of providing or omitting obj_hash, which goes beyond the schema's literal definition and helps the agent anticipate results.
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 uses a specific verb ('Read') and identifies the exact resource ('server or agent configuration'). It also distinguishes this tool from siblings by explicitly directing users to get_system_overview for finding agent hashes, making the purpose unmistakable.
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 clearly explains when to use the tool (to read configuration) and the two modes based on obj_hash. It provides an explicit pointer to get_system_overview for a prerequisite action, though it does not list explicit exclusions or alternative tools for non-configuration reads.
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?
Annotations already declare readOnlyHint and idempotentHint, and the description adds behavioral details about auto-selecting precision and sampling large datasets. This gives agents insight into how data volume is handled, which is not present in the annotations. No contradiction.
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?
Three sentences, each informative: purpose, supported counters, parameter strategy, and auto-behavior. No redundant wording.
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?
The tool has 6 params and no output schema; description covers the key usage patterns and data handling. It lacks an explicit return-format description, but the purpose and sampling behavior give adequate context for the expected use case.
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 explaining the tradeoff between latest_sec and start_time/end_time, and describes the auto-precision behavior tied to time ranges. This goes beyond raw schema definitions.
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 it retrieves historical counter values for trend analysis, listing supported counters. This distinguishes it from sibling tools like get_system_overview or get_realtime_xlogs, which focus on different data. The verb 'get' plus resource 'historical counter values' makes the purpose unambiguous.
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 provides clear parameter guidance, noting when to use latest_sec vs start_time/end_time, and explains precision selection based on time range. It does not explicitly name alternative tools or exclusions, but the context is sufficient for typical use.
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?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond annotations—that output is raw Step objects with hash IDs, requiring lookup_text for resolution—which is valuable for setting expectations.
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?
Three sentences efficiently convey purpose, differentiation, and follow-up usage. The most critical information is front-loaded, and every sentence adds value without redundancy.
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?
Despite lacking an output schema, the description explains what the return value looks like (raw Step objects with hash IDs) and how to interpret it (via lookup_text). Combined with clear sibling alternates and full parameter documentation, it provides complete context for a read-only retrieval tool.
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 both 'date' and 'txid' having descriptive text. The description does not add any parameter-level detail beyond what the schema already provides, so the baseline score of 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?
The description clearly states the tool retrieves raw, non-decoded profile steps for a transaction, using a specific verb and resource. It explicitly distinguishes itself from get_transaction_detail by contrasting raw vs decoded data, making its purpose unambiguous.
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 explicitly names the alternative tool (get_transaction_detail) and explains when this raw variant is preferable. It also directs users to lookup_text for resolving hash IDs, providing clear usage context and next steps.
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?
With strong annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already covering the safety profile, the description adds valuable behavioral context: results are sorted by elapsed time descending and include summary statistics. It does not disclose any potential edge cases (e.g., default time windows) but the annotations reduce the burden.
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 three sentences with no filler. It front-loads the core action and resource, then adds filter options and output behavior, and ends with a clear positioning statement. Every sentence earns its place.
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 the tool's complexity (8 optional parameters, no output schema), the description conveys the essential context: what it searches, what filters are available, how results are ordered, and the primary use case. The absence of an output schema is compensated by explicitly stating the return characteristics. It is complete for a search tool with well-documented schema parameters.
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 the baseline is 3. The description adds meaning beyond the schema by framing parameters in terms of use cases (slow transactions, error transactions, service/IP/login filters), which helps the agent understand which parameters matter for typical investigations. It stops short of detailing format constraints, but it complements the schema well.
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 uses a specific verb ('Search') with a clear resource ('transactions (XLogs)') and details the filtering dimensions (slow, error, service/IP/login). It also mentions the result format (sorted by elapsed time descending with summary statistics), which clearly distinguishes it from more generic search tools and aligns with the stated primary use case for 'why is it slow?' investigations.
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 labels itself as the 'Primary tool for why is it slow? investigations', providing a clear when-to-use indicator. It implies a time-range search context but does not explicitly mention when to prefer sibling tools like get_transaction_detail or get_realtime_xlogs, so it lacks explicit exclusions.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds behavioral context by noting the output is 'raw' with 'hash IDs' and that one mode is 'real-time streaming', giving useful expectation beyond annotations. The bar is lower due to annotations, and this description adds meaningful detail without contradiction.
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?
Three sentences, front-loaded with the core action, and no filler. Each sentence earns its place: what it does, how it differs, and a useful pointer to a sibling tool.
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 (18 params, 5 modes) and lack of output schema, the description provides a solid high-level overview, including return type hint ('raw XLog objects with hash IDs') and mode categories. It doesn't dive into streaming/pagination details, but the schema descriptions cover those, making it adequate.
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% (18 params fully described), so baseline is 3. The description enhances parameter understanding by grouping modes and explicitly linking hash ID parameters to lookup_text ('Use lookup_text to resolve hash IDs'), which goes beyond the schema's per-field descriptions.
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 uses a specific verb ('Get') and resource ('raw (non-decoded) XLog transaction data'), clearly differentiating from search_transactions. It also lists the five distinct modes, making the scope unmistakable and distinguishing it from sibling tools.
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 'Unlike search_transactions which returns decoded data' as a direct when-not/alternative. Also directs users to lookup_text for resolving hash IDs, providing a concrete next-step. This meets the explicit when/when-not/alternatives criterion.
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?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint. The description adds specific fields returned (version, ID, connection status) and the HTTP mode requirement for counter model, providing context beyond annotations. No contradictions.
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?
Three sentences, all informative: main purpose, optional parameter, usage guidance, and constraint. No filler.
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?
For a read-only metadata tool with one optional param and no output schema, the description is complete. It explains what is returned, when to use it, and the prerequisite. The large sibling list doesn't create confusion because the tool's niche is clearly stated.
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 description covers the include_counter_model parameter thoroughly (100% coverage), and the tool description reinforces its purpose by connecting it to counter discovery workflow. This adds slight value beyond schema, justifying 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 uses a specific verb ('Get') and resource ('Scouter collector server metadata'), and explicitly mentions the optional counter model. It differentiates from siblings by positioning the counter model as a prerequisite for get_counter_trend.
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 explicitly states when to use this tool ('Use this to discover what counters exist before querying get_counter_trend') and provides a clear constraint ('Counter model requires HTTP mode'). This is direct guidance for alternative selection.
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:

[![scouter-mcp-server MCP server](https://glama.ai/mcp/servers/miningyu/scouter-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/miningyu/scouter-mcp-server)

Score Badge

Copy to your README.md:

[![scouter-mcp-server MCP server](https://glama.ai/mcp/servers/miningyu/scouter-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/miningyu/scouter-mcp-server)

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/miningyu/scouter-mcp-server'

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