sifflet-mcp

Official

by siffletdata

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.6
Disambiguation4/5
Most tools have clearly distinct purposes (asset lookup vs incident search vs monitor details). However, incident tools use different identifiers ('by_id' vs 'by_issue_number') for what appears to be the same entity, which could confuse an agent. Asset tools by URN are distinct but share similar input patterns.
Naming Consistency3/5
Naming conventions are mixed: 'asset_by_urn' does not follow the verb-first pattern used by most others, and pluralization is inconsistent ('search_asset' vs 'search_incidents'). Incident tools also inconsistently use 'by_id' versus 'by_issue_number'.
Tool Count5/5
10 tools is well-scoped for a data observability platform, covering assets, monitors, and incidents without being overwhelming. Each tool serves a distinct function, and the count fits comfortably within the ideal range.
Completeness3/5
Core workflows like asset search/detail, incident management, and monitor code generation are covered. However, there is no tool to search or list monitors (only get by ID), no monitor creation/update, and only downstream asset lineage (no upstream). These are notable gaps for a monitoring-focused tool.
Average 3.7/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose any behavioral traits: 'open' implies a possible state change or side effect, but there is no mention of permissions, reversibility, or operational impact. This is a significant transparency gap.
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 extremely concise: two sentences, front-loaded with the core action, and no unnecessary words. It efficiently uses the available space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks complete context. There is no output schema, so the description should at least mention what the tool returns or any behavioral consequences. It also fails to differentiate from get_incident_by_issue_number, leaving the agent without enough context to decide when to use this 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 0%, so the description partially compensates by explaining that the id is the unique identifier and providing an example. However, it does not elaborate on where the id comes from or any format constraints beyond the example.
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?
Specific verb 'open' with resource 'incident' and identifier 'id', clearly distinguishes from sibling tools like close_incident_by_id and search_incidents. The action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of context. The description simply states what it does without explaining when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only states what the tool does, not details like whether it's read-only, what constitutes 'downstream' (immediate vs transitive), or if pagination or limits apply. The description adds an example of an urn but no behavioral traits beyond the core action.
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 with no fluff. The first states the core purpose, and the second adds necessary parameter context with an example. It's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the action and parameter well, but it lacks information about the return value or semantics of 'downstream'. It might be sufficient for a simple use case, but given no output schema, a hint about what the response contains would improve completeness.
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 0%, so the description must compensate. It explains what an Urn is, provides an example format, and tells how to obtain it ('It can be found when you search for an asset'). This adds meaningful context beyond the schema's bare 'string' type.
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 first sentence clearly states the verb and resource: 'Get all downstream assets of an asset.' This distinguishes it from sibling tools like asset_by_urn (single asset) and search_asset (search), as it focuses on downstream assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It does explain how to obtain the urn (by searching for an asset), but that's a prerequisite, not a usage context. There's no mention of 'use this to see dependencies' or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It explains parameter meanings but does not mention side effects, permissions, reversibility, or the outcome of closing an incident. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the primary action and then explaining the second parameter. There is no redundant or verbose language; every sentence contributes to understanding.
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?
Given it is a simple tool with two parameters and no output schema, the description explains the action and parameters adequately. However, it omits behavioral details such as idempotency, effects on the incident, or return values, leaving some uncertainty for an agent. It covers the basics but not the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description compensates by defining incident_id as a unique identifier with an example and explaining should_qualify_monitor as a boolean for monitor qualification. This covers both parameters, though it leaves some domain-specific details unstated.
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 'Close an incident by id' with an example, which is a specific verb+resource. This distinguishes it from sibling tools like open_incident_by_id, making 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., open_incident_by_id) or any exclusions. The intended use is inferable from the tool name and description, so it is not entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose the return format, error behavior, or whether any special permissions are needed. While 'get' implies a read operation, the description does not add behavioral depth beyond that.
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 short but redundant: 'monitor_id is the monitor UUID' and 'monitor_id is the unique identifier' convey the same information twice. A more streamlined version would be more concise while retaining all key details.
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 one-parameter read tool with no output schema, the description adequately covers purpose and parameter semantics. It lacks details about return structure or failure cases, but these are less critical given the tool's simplicity.
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?
The schema only specifies monitor_id as a string, but the description enriches it with the meaning (UUID), an example value, and guidance on how to find it. This fully compensates for the zero schema coverage for this single parameter.
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 states a clear verb+resource ('Get monitor details by id'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools, though the name itself is distinctive enough among the listed siblings.
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 clear context: the monitor_id is a UUID and can be found by searching for a monitor. This implies when to use it (when you have the id) but does not explicitly mention alternatives or when not to use it, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only restates the action. It does not mention side effects, error behavior, permissions, or return format. For a read operation, it doesn't confirm read-only status or handle edge cases, so it provides minimal behavioral insight.
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 short sentences, front-loaded with the action. No filler or redundant explanation, earning a perfect score for conciseness and structure.
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 one-parameter lookup, the description covers the essential purpose. It could mention what happens on not-found or the return structure, but given the simplicity, it is largely adequate. No output schema or annotations increase the burden slightly, so a 4 is appropriate.
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 description explains that issue number is a unique identifier and gives an example (1234), which adds meaning beyond the bare schema property name 'issue_nbr'. However, it does not provide additional detail such as format constraints or behavior when the number is invalid.
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 the tool's function: retrieving incident details using the issue number as identifier. The verb 'get' plus resource 'incident details' distinguishes it from sibling tools like get_incident_scope_by_issue_number or open_incident_by_id.
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 usage when the user has an issue number and wants full incident details, but it does not explicitly contrast with similar tools like get_incident_scope_by_issue_number or search_incidents. However, the context is reasonably clear, and mentioning the issue number as a unique identifier helps signal when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral characteristics, but it only defines the output concept. It does not state that the operation is read-only, how errors are handled for invalid or missing issue numbers, or whether the returned list can be empty. The description thus provides minimal transparency beyond the basic purpose.
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 short sentences: purpose, parameter clarification, and output definition. Every sentence adds value without redundancy, making it appropriately concise and easy to parse.
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 a single parameter and no output schema, the description covers the core function, parameter meaning, and output type (list of assets and monitors). It lacks details on error behavior or edge cases, but it is fairly complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that issue_number is the unique identifier of the incident and provides an example (1234), adding meaning beyond the schema's bare integer type. This is the only parameter, and the description compensates for the lack of schema descriptions, though it does not specify any value constraints.
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 the specific verb 'Get' with resource 'incident scope' and clarifies that scope means the list of assets and monitors. This makes the tool's function immediately understandable and distinguishes it from sibling tools like get_incident_by_issue_number that retrieve incident details rather than scope.
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 when the agent needs the assets and monitors tied to an incident using its unique issue number. However, it does not explicitly contrast this with alternatives such as get_incident_by_issue_number or mention when not to use this tool, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains parameter values but does not describe how filters combine, the response format, or any side effects. It only hints at behavior via parameter semantics (e.g., text_search targets name/description, page starts at 0), leaving significant behavioral aspects undisclosed.
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 a compact, front-loaded bullet list. It begins with the purpose and then lists each parameter concisely without repetition or unnecessary prose. Every line adds value.
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 description fully covers parameters but lacks information about the response structure (no output schema), filter combination logic, or sorting. With 7 required parameters and no output schema, the agent is not fully informed about what the tool returns or how to interpret results.
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?
The description adds rich meaning for all 7 parameters: enumerated values for asset_type and health_status, owners as emails, tags as a list, text_search scope, items_per_page meaning, and page base. The input schema has no descriptions, so this is the sole source of parameter semantics and is highly comprehensive.
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 verb 'Search' and the resource types (assets, tables, dashboards, pipelines). This distinguishes it from sibling tools like search_incidents and asset_by_urn, which target different resources or operations.
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 this tool is for searching assets and related entities, but it does not explicitly mention when to use alternative tools or provide exclusions. The enumerated asset types give implicit context, but there is no direct 'use this when...' guidance.
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?
With no annotations, the description carries the full behavioral burden. It discloses sorting defaults, filterable fields, allowed statuses, and pagination start, which is useful. However, it mentions a 'user' filter that is not present in the input schema, and it does not disclose output format or whether status accepts an array, leaving gaps.
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 reasonably concise, using short sentences and bullet-like lines. The sort explanation is slightly redundant ('By default sort is descending. But you can change it'), but overall every sentence carries useful information without excessive verbosity.
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 description covers sorting, filtering, statuses, and pagination but does not mention the return format or any side effects. The inconsistency around the 'user' filter and missing details on array semantics leave gaps for an agent trying to invoke 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 coverage is 0%, so the description must add meaning. It explains the sort parameter (default 'desc', change to 'asc'), enumerates status values, and notes pages start at 0. Yet it omits the array nature of status, fails to explain items_per_page, and introduces a non-existent 'user' parameter, reducing its 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 'Search incidents' with a specific verb and resource, and goes on to detail the searchable criteria (sort, filters, pagination). This distinguishes it from sibling tools like search_asset and the various get_incident_* tools that fetch specific assets or incidents.
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 conveys that this is the tool for searching incidents with filtering and sorting, providing clear context for when to use it. It does not explicitly name alternatives like get_incident_by_issue_number for single-record retrieval, but the verb and resource make the use case apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as what information is returned, whether it performs a read-only operation, and any potential errors. The description only says 'Get asset information' without elaborating on scope or response details, leaving significant behavioral ambiguity.
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 purpose, and contains no redundant phrases. It efficiently conveys the core idea and an illustrative example without waste.
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?
For a simple lookup tool with no output schema, the description covers the essential input and source of the urn, but it lacks details on what 'asset information' includes or what the response looks like. Given the simplicity of the tool, this is acceptable but not thorough, so it earns a middling score.
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 only defines asset_urn as a string with no description. The tool description adds meaningful detail by explaining that the urn is a unique identifier and providing an example format (dataset:...). This goes beyond the schema's minimal type definition, though it could still be more precise about accepted formats or variations.
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 verb and resource: 'Get asset information by urn.' It differentiates from siblings like search_asset by specifying the lookup mechanism (urn) and notes the urn is a unique identifier, which helps distinguish it from other asset-related 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 provides context that the urn can be found from a search, implying when to use this tool (when you have the urn) versus search_asset (when you don't). However, it does not explicitly mention alternatives or exclusions, so it earns a 4 rather than 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?
The description discloses the output format ('The result is a YAML string') and the required inputs, but it does not explicitly state whether the tool has side effects (e.g., whether it actually creates a monitor or only generates code). Without annotations, this leaves some ambiguity about the tool's safety profile and behavioral implications.
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 repetitive, redefining 'description' multiple times ('The input is a description...', 'The description should be...', 'The description is a string...'). While the content is useful, the redundancy adds unnecessary length and could be condensed without losing 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?
The description covers the tool's purpose, required inputs, a usage example, and the output format (YAML string). It adequately addresses the key aspects for a simple two-parameter tool, though it does not discuss error cases or edge cases. This is sufficient given the tool's simplicity and lack of additional schema/annotation 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?
Despite the schema having no descriptions, the tool description adds significant meaning to both parameters: it explains dataset_ids as a list to apply the monitor to and instructs to use search_asset for discovery, and it defines description with an example ('Create a monitor that checks if the number of rows in the table is greater than 1000'). This compensates well for the lack of 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 function: 'Returns a monitor configuration based on the input query' and elaborates that it converts a natural language description and dataset IDs into a YAML configuration. This distinguishes it from sibling tools like get_monitor_details_by_id (which retrieves existing monitor details) and search_asset (which finds datasets).
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 on inputs: it requires at least one dataset ID and directs users to 'find the id of the dataset using search_asset'. This gives clear context for when to use the tool and how to gather prerequisites, though it does not explicitly contrast with alternative tools.
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:

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

Score Badge

Copy to your README.md:

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

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