yokozuna-mcp

by mbe24

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation4/5
Most tools have clearly distinct purposes, e.g., sumo_create_search_job vs sumo_run_search, but the latter is a higher-level wrapper that combines create, wait, and delete, which could cause confusion. However, descriptions are clear enough to differentiate.
Naming Consistency5/5
All tools follow a consistent 'sumo_verb_noun' pattern. Verbs like create, delete, get, list, describe, export, facets, trend, error_digest, new_since, run_search are all well-structured and predictable.
Tool Count5/5
14 tools is appropriate for the server's purpose—covering search job lifecycle, data retrieval, analysis, monitoring, and alerts. The number is neither too few nor excessive.
Completeness4/5
The tool set covers core workflows: job management, data retrieval, schema analysis, triage, trends, facets, monitors, and alerts. Missing are tools for creating/updating monitors or managing saved searches, but these are not essential for typical agent interaction.
Average 4.6/5 across 14 of 14 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on July 6, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits: async creation, keepalive polling, and cleanup requirement. However, the annotations set readOnlyHint=true, contradicting the description's claim that it creates a job (a mutation). This is a serious inconsistency.
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 focused sentences covering action, behavior, lifecycle, and parameter constraints. No unnecessary words; 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?
Given 6 parameters, 1 required, no output schema, the description covers the job lifecycle (create, keepalive, page, delete), time range options, and notes on polling. It lacks explicit mention of the return format or error cases, but is otherwise thorough.
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?
With 100% schema coverage, baseline is 3, but the description adds value: explains `last` units (s/m/h/d), `from`/`to` formats (ISO-8601 or epoch ms), mutual exclusivity, and practical tips like `byReceiptTime` for recent windows. It enhances understanding beyond schema 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 clearly states the action: 'Creates a search job and returns its id WITHOUT waiting.' It distinguishes from siblings like sumo_get_messages, sumo_get_records, and sumo_delete_search_job by being the initiation step that returns immediately.
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 guidance: page with sumo_get_messages/sumo_get_records, delete with sumo_delete_search_job, and time range constraints (exactly one of `last` or both `from`/`to`). It lacks direct comparison with alternatives like sumo_run_search but still gives clear context.
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 indicate readOnlyHint=true. The description adds behavioral details: concurrent execution, auto-deletion of jobs, error tolerance (one failing dimension yields error line, not total failure), time range rules, and numeric matching behavior. This goes well beyond annotations, though rate limits or authentication are not mentioned.
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 well-structured: begins with core purpose, then details dimensions, numeric matching, and time range. It is dense but not wasteful. Slightly longer than minimal, but every sentence adds necessary context for correct usage.
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 8 parameters, 100% schema coverage, and no output schema, the description covers behavioral aspects well: error handling, dimension interpretation, time rules. It does not describe the return format (likely a list of facets), but the overall completeness is high for a faceted query 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 coverage is 100% (all parameters described). The description adds significant meaning: explains that dimensions starting with '_' are native fields, others are JSON paths; clarifies time range exclusivity; notes default and max for limit; and explains numeric matching quirks. This adds value 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: 'the fastest way to see the SHAPE of matching logs before reading any messages' and specifies it returns ranked top-N counts per dimension. It distinguishes from siblings like sumo_run_search (general search) and sumo_trend (time-series) by emphasizing speed and dimensionality.
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 gives clear context on when to use (fast overview before reading), what it does (concurrent jobs, auto-deleted), and how to interpret dimensions. It also suggests sumo_describe_schema for unknown fields. However, it does not explicitly state when not to use this tool versus alternatives, which would earn 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 indicate readOnlyHint=true, and the description is consistent. It details behavior like page size limit, partial result paging, token lever functionality, and provenance of summary data. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but somewhat lengthy and uses compact notation (pipes, colons). It front-loads the key point but could be better structured for readability.
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 9 parameters, no output schema, and multiple siblings, the description covers pagination, detail levels, dedupe, sorting, offset, limit, maxMessageChars, and partial result behavior. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value by explaining token levels in detail, dedupe behavior, and sort ordering scope. It enhances understanding beyond the schema 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 clearly states it pages messages for non-aggregate search jobs, distinguishing from sumo_get_records for aggregate jobs. The title and description both specify the resource and verb, and sibling differentiation is explicit.
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 sumo_get_records for aggregate jobs and notes partial results are pageable while job is gathering. It provides context for when to use this tool but does not exhaustively cover all alternatives.
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; description adds that non-aggregate jobs cause a 400 error and page size max 10000, going beyond 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, concise, front-loaded with key info. No wasted words.
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?
No output schema, but description explains tool purpose and error conditions adequately. Could mention output format but not critical.
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 has 100% coverage of parameter descriptions; description adds no additional semantic info beyond what schema provides.
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 pages records of aggregate search jobs, and distinguishes from non-aggregate jobs which require sumo_get_messages. Specific verb and resource.
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 this tool vs sumo_get_messages: aggregate jobs only; non-aggregate jobs will 400. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that deletion frees a slot and that deleting an already-gone job is not an error (idempotent). Annotations already indicate idempotentHint:true, but description adds vital context about the cap and cleanup practice.
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 efficient sentences with no wasted words. Purpose, usage guidance, and behavioral detail are all front-loaded.
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 simplicity (one parameter, no output schema), the description fully explains its effect, idempotency, and proper usage context.
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?
Only one parameter 'id' with schema description 'Search job id.' Schema coverage is 100%, and description adds no further meaning beyond that already 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 it deletes a search job and frees a slot against the 200-active-jobs cap. It distinguishes from siblings like sumo_create_search_job and sumo_get_search_job_status by being the delete operation.
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 advises to always delete jobs created via sumo_create_search_job or kept with keepJob:true. Provides context about the cap but does not explicitly mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: it resets the idle timer, defines all states with their implications (partial results available, truncated results, etc.), and aligns with annotations (readOnlyHint=true). 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?
Two sentences efficiently deliver purpose, side effect, and state definitions. No wasted words, front-loaded with key actions.
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 no output schema, the description adequately covers all states and their meanings, enabling the agent to understand when to proceed with result retrieval. Complex state machine is fully explained.
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 for the single parameter 'id' with a clear description. The description adds no additional meaning beyond 'polls a search job', so 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 it polls a search job's status and resets the idle timer. It lists all possible states, making the tool's purpose specific and distinct from sibling tools like sumo_get_messages or sumo_get_records.
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 implicitly guides usage by explaining states (e.g., GATHERING RESULTS means results are pageable) but does not explicitly state when to use this tool versus alternatives. However, the context of polling for job completion before retrieving results is clear from the list of states.
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?
The description adds significant behavioral context beyond the readOnlyHint annotation: it queries the System Event Index, creates an auto-deleted search job, and correlates separate events. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently packs all necessary information without redundancy. While not extremely concise, every sentence serves a purpose.
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 no output schema, the description describes the output format (fields like fired-at, resolved-at, join keys). All parameters are covered, and the tool's behavior is fully explained. No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter has a schema description, but the tool description provides additional semantics: explains the mutual exclusivity of `last` and `from`/`to`, gives examples for time formats, and clarifies status filtering behavior with `statusScope`. This adds value 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 it lists fired-alert history, explicitly distinguishes it from the sibling tool sumo_list_monitors by calling it the complement, and specifies the source index and correlation logic.
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 explains when to use this tool (historical alerts) and mentions Enterprise account requirement, time range constraints, and automatic search job deletion. It indirectly suggests alternatives by referencing sumo_list_monitors for definitions/current state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. Description adds that jobs are auto-deleted, timeslice/count operators are appended, and time range validation. No contradiction. Provides additional behavioral context beyond annotations.
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?
Single paragraph, relatively concise while covering purpose, usage, constraints. Front-loaded with key info. Could be slightly more structured but no 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?
With 10 parameters, 1 required, no output schema, description explains return format (sparkline + per-bucket counts per series) and internal behavior (auto-delete, operator appending). Covers the main use case and constraints comprehensively.
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% with descriptions. Description adds meaning: for `by`, explains default auto-detected severity field; for `interval`, default auto gives ≤40 buckets; for `filter`, references sibling tool's contract. Provides useful beyond 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 starts with 'Shows WHEN things happened' and details bucketing via | timeslice, counts per series, and sparkline rendering. It clearly distinguishes from sibling tools like sumo_get_messages or sumo_run_search by focusing on temporal aggregation and visualization.
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 states 'Use it to spot spikes and onsets before reading messages.' It also specifies constraints: query must be a plain scope (no | aggregation), time range must be exactly one of last or from/to. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly details behavior beyond the annotations: streaming to file, 100k cap, chronological ordering with caveats for partial results, aggregate query handling, and time range requirements. It also explains extraction mechanics and the interaction of maxMessages. This far exceeds the minimal behavioral disclosure from annotations (readOnlyHint=true).
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 a single well-structured paragraph that front-loads the core purpose ('Runs a search and streams ALL results...') before diving into details. It is slightly lengthy but every sentence adds value, and the information density 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.
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 parameters, nested objects, no output schema), the description covers all essential aspects: behavior, return value, ordering, aggregate vs. non-aggregate, extraction, time range options, cap, and receipt time. There are no obvious gaps; the description is sufficiently complete for an AI 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning: it clarifies that time range must be exactly one of `last` or both `from`/`to`, explains the extra `| sort by _messagetime asc` appended to non-aggregate queries, details the extraction alias format and chaining, and notes the default and cap for maxMessages. These insights go well beyond the schema 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 clearly states the tool's action: 'Runs a search and streams ALL results... to an NDJSON file on disk, returning the file path — NOT the content.' It uses a specific verb ('export') and resource ('results to a file'), and distinguishes from sibling tools by contrasting with 'large inline limits' and implying that other tools return content directly.
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 'Use this for bulk analysis... instead of large inline limits,' providing a clear when-to-use scenario. It also advises splitting time ranges if more than 100k messages match, which is a good usage constraint. However, it does not name specific sibling alternatives, so the guidance is slightly less explicit than ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds extensive behavioral context beyond annotations: 'PROPOSES, never decides', auto-deletion of jobs, stratified sampling strategy (not first-N), and honest caveats on output. Annotations only indicate readOnlyHint=true, which is consistent.
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 relatively long but well-structured with clear sections. Every sentence provides value, though it could be slightly more compact. The use of colons and lists aids readability.
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 (9 parameters, no output schema), the description is thorough: covers sampling, output format hints (ranked severity fragments), budget, and parameter relationships. No missing critical 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?
Schema coverage is 100% with descriptions for all 9 parameters. The description adds extra usage context like mutual exclusivity of time parameters and default auto-detection for stratifyBy, enhancing 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 is a 'thorough schema learner' and 'deep counterpart' to lite detection in siblings. It details stratified sampling and key enumeration, and distinguishes itself by being 'propose-only' and never deciding.
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?
Explicit usage guidance: 'Use when a digest disclosed no-signal/zero-match or on first contact with a new system.' Also specifies budget and time range constraints, implying when not to use (when a quick schema suffices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, the description discloses cost (2 search jobs, 3 for string-payload, 1 with filter), auto-deletion, and auto-detected severity disclosure in output. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but each sentence adds necessary information. It is front-loaded with the core purpose and efficiently covers cost, time range, and behavioral notes. Slight room for tighter wording, but overall well-structured.
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?
With no output schema, the description fully explains the return: count, first/last occurrence, sample request_id, _sourcecategory, and severity disclosure. Also covers edge cases (string-payload, filter behavior) and constraints (time range, scope query).
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?
All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining defaults (query, limit, maxScan), mutual exclusivity of time params, and filter's effect on cost. This extra context 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?
The description clearly states it provides a deduplicated error/warning digest with auto-detected severity, grouping by normalized signature, and top-N problems. It distinguishes itself from sibling tools like sumo_run_search and sumo_get_messages by emphasizing its triage purpose and aggregated output.
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?
Explicit usage guidance: use for triage, consider sumo_describe_schema for new scopes, specify time range exactly one of 'last' or 'from'/'to', and avoid hostname in scope query. Also explains when to use filter to skip auto-detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), description discloses forced byReceiptTime, 180s settle margin, ~180s staleness, and aggregate rejection. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured, front-loading core concept. A bit verbose in sections (e.g., detail enumeration), but every sentence adds value for a complex tool.
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 10 parameters and no output schema, the description covers window semantics, cursor use, detail levels, dedupe, field projection, and more. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds deep context: detail modes (summary/compact/full/raw) with exact contents, dedupe mechanism, lookback default, and maxMessageChars safety cap. Greatly enhances understanding.
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 is a 'stateless receipt-time monitor for polling loops' that returns messages that arrived since the last call plus a cursor. It explicitly distinguishes from siblings like sumo_run_search by rejecting aggregate queries.
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 guidance: first call omit 'since', how to pass cursor, window semantics, rejection of aggregate queries, and alternative tool (sumo_run_search). Clear when-to-use and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the full lifecycle (create, wait, fetch, delete), idle timeout for kept jobs (~10 minutes), side-aggregate for detail=summary with provenance disclosure, token levers for detail levels, and the fact that sort only orders the returned set. This is rich behavior context beyond the annotations. However, note that annotations claim readOnlyHint: true, but the description describes mutation (create/delete), creating a contradiction.
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 detailed and well-structured with paragraphs and bullet-like formatting. It is front-loaded with the main action. However, it is quite long (several sentences) and might be dense for an agent. Could be slightly more concise without losing critical information, but every sentence serves a purpose.
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 no output schema, the description explains return formats (summary/compact/full/raw) and behavior like dedupe grouping. It covers time range, scoping, and references sibling tools. With 15 parameters, it provides adequate context for using the tool effectively. The lifecycle, limits, and edge cases are well addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions, but the description adds significant meaning: explains time range options (mutual exclusivity), token levers for detail (summary/compact/full/raw with details), dedupe behavior, keepJob lifecycle, maxMessageChars as safety cap, fields as projection, extract as JSON extraction, sort limitations, etc. Provides context that schema alone does not.
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: 'creates a Sumo Logic search job, waits for completion, returns the first N results, and deletes the job.' It distinguishes itself from siblings by mentioning sumo_export_results for bulk and sumo_error_digest for auto-detection of severity. The title 'Run a Sumo Logic search (create → wait → fetch → delete)' is also very specific.
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 guidance: 'Inline limit max 5000 — use sumo_export_results for bulk (up to 100k to a file).' Also recommends using sumo_error_digest or sumo_describe_schema for severity detection and mentions the 'triage' MCP prompt for full workflow. Clear when to use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses authentication requirements (access key with 'View Monitors' capability, HTTP 403 without), query behavior (name-only substring matching), and status filtering mechanics (no OR support, multiple statuses trigger separate API calls unioned client-side).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then efficiently packs details including a footgun warning and cross-reference. Every sentence provides 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?
Given no output schema, the description explains return fields (name, folder path, type, status, triggers, notifications). It covers authentication, query limitations, and status filtering behavior. Complete and self-contained 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds substantial value: for 'query' it explains matching behavior and syntax, for 'status' it details the lack of OR support and client-side union, and for 'limit' it complements the schema. This goes well beyond the baseline for high coverage.
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 discovers native Sumo Logic Monitors with specific fields (name, folder path, type, status, triggers, notifications). It explicitly identifies itself as a read-only management API call, distinguishing it from sibling tools like sumo_list_alerts.
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 guidance on when to use this tool vs alternatives: fired-alert history is handled by sumo_list_alerts. Includes a 'FOOTGUN' warning about query matching limitations (name-only, case-insensitive substring) and explains the query syntax including monitorStatus.
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:

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

Score Badge

Copy to your README.md:

[![yokozuna-mcp MCP server](https://glama.ai/mcp/servers/mbe24/yokozuna-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mbe24/yokozuna-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/mbe24/yokozuna-mcp'

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