Doorzo Deal Monitor

by TESTYEE-09

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct function: monitor lifecycle (add/remove/list/check), search, trends, and exchange rate. There is no overlap or ambiguity between them.
Naming Consistency4/5
All tools share the 'doorzo_' prefix, but the verb_noun pattern is inconsistent: 'monitor_add' and 'monitor_remove' place noun first, while 'check_monitors' puts verb first, and 'search'/'exchange_rate' are not verb_noun at all. Still readable and predictable.
Tool Count5/5
Seven tools is well-scoped for a deal monitor service, covering management, execution, and auxiliary queries without bloat.
Completeness4/5
Core monitor lifecycle is complete (add, remove, list, check), and search/rate tools support the workflow. Missing an update/price change operation is a minor gap that agents can work around by removing and re-adding.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'notify and log matches,' which are important side effects, but leaves specifics vague (e.g., how notification occurs, what logging entails, persistence, external side effects). With no annotations, this is minimally adequate but lacks depth.
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 single, front-loaded sentence with no redundant words. It efficiently conveys the core action and outcome ('Check monitors for NEW deals; notify and log matches'), making it easy to parse and ideal for quick agent scanning.
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 low complexity, complete parameter schemas, and an output schema, which reduces the need for extensive description. However, key behavioral aspects are ambiguous: what counts as 'NEW deals,' how notification is performed, and the exact logging behavior are unspecified. These gaps matter for an agent deciding whether this tool fits the user's request.
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 both parameters (monitor_id and watch_minutes) clearly described in the schema. The description itself adds no parameter-specific detail, which is acceptable since the schema already provides full semantics. Baseline of 3 is appropriate.
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 uses a specific verb ('Check') and resource ('monitors for NEW deals'), clearly indicating the tool's core function. It distinguishes from sibling tools like doorzo_monitor_list (which lists monitors) and doorzo_search (which searches deals) by focusing on checking monitors for new matches, though it does not explicitly name these alternatives.
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 when to use the tool (when you want to check monitors for new deals) but provides no explicit guidance on when not to use it or how it compares to alternatives. There are no exclusions or alternative tool references, leaving the decision partially to the agent's inference.
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 provided, the description carries the burden of disclosing behavior. It reveals the core alerting behavior (matching keyword and price) but omits important side effects such as notification delivery, persistence of the monitor, or behavior when existing monitors share the same name. The schema descriptions fill some gaps, but the main description itself is thin.
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 single, focused sentence that is front-loaded with the primary action. Every word contributes meaning, and there is no fluff or repetition.
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 6 parameters and an output schema, but the description is quite brief. While the schema covers parameter details, the description does not explain the overall workflow (e.g., that the monitor will immediately start watching, that notifications only work on macOS, or how monitors are managed after creation). It provides the core idea but lacks sufficient context for a user to fully understand the tool's place in the broader system.
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 adds minimal context by linking 'keyword' and 'at/below price' to the corresponding parameters, but it does not elaborate on parameter meanings beyond what the schema already 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?
The description clearly states the tool's function: 'Add a deal monitor: alert when items match keyword at/below price.' The verb 'Add' specifies the action, and the resource and condition ('deal monitor', 'keyword at/below price') are unambiguous. It also distinguishes from sibling tools like remove, list, and search by focusing on creation and alerting.
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 usage context is implied: it is used to create a new deal monitor, whereas siblings cover removal, listing, and checking. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It states the core behavior (search across Japanese shops) but does not reveal potential nuances like filtering, sorting defaults, or that the keyword can be translated. The schema covers parameters, but the description adds little beyond the basic operation.
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 single sentence that is direct and front-loaded. It avoids unnecessary words and clearly communicates the tool's essence, 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?
While the schema and output schema provide extensive detail, the description lacks contextual guidance such as when to use the tool, what types of results to expect, or any limitations. Given the tool's moderate complexity and absence of annotations, a slightly more informative description would improve completeness. However, the rich schema compensates partially.
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 only mentions 'a keyword', which duplicates the schema's 'keyword' parameter without adding new meaning. All parameters are adequately documented in the schema, so the description adds no extra 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 uses a specific verb ('search') and resource ('doorzo.com across Japanese shops') and clearly states the input ('a keyword'). This distinguishes it from sibling tools like doorzo_monitor_add and doorzo_hot_searches, which are about monitoring and trends.
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 searching across Japanese shops, but does not explicitly state when to use it versus alternatives (e.g., monitoring tools). No exclusions or alternative tool references are mentioned, so guidance is limited to the general purpose.
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 of behavioral disclosure. It only says 'Return' which implies a read operation, but it does not explain rate freshness, unsupported currency behavior, or error handling. This is a significant gap for a tool with zero annotation coverage.
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 single, focused sentence that front-loads the action and resource. It is concise, with no wasted words, making it 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 one parameter and an output schema, the description covers the core operation sufficiently. However, it omits details about how the rate is determined or any restrictions, which slightly reduces completeness.
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 already fully documents the 'currency' parameter with ISO 4217 code examples and a default value. The description adds no additional meaning beyond the schema, so the baseline of 3 applies here.
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 'Return' and the resource 'the JPY -> currency exchange rate doorzo uses', making the purpose specific and unambiguous. It distinguishes itself from sibling tools which focus on monitors and search, so there is no confusion.
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 the tool is used to retrieve Doorzo's JPY conversion rate for a given currency. Since there are no sibling tools for exchange rates, the context is clear, but no explicit alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List' which implies a read-only operation, but it does not explicitly disclose safety, auth needs, or side effects. It does add transparency about output fields.
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 single sentence, front-loaded with the verb, and includes essential detail without any fluff. 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?
For a simple parameterless list tool with an output schema, the description is largely complete. It covers the main purpose and fields, but does not mention ordering, pagination, or authentication requirements, which could be relevant.
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?
There are no parameters, so the baseline is 4. The description adds value by listing output fields, but since there are no params, it does not need to compensate for schema gaps.
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 'List' and the resource 'monitors', and specifies the exact fields returned (id, keyword, price ceiling, last check stats). This distinguishes it from sibling tools like add, remove, and check.
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 is implied: you use this to see all monitors. However, it does not explicitly mention when not to use it or suggest alternatives among the sibling tools, such as doorzo_check_monitors for checking statuses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'Return' implies a read-only operation, but no specifics about caching, data freshness, rate limits, or return structure are mentioned. The description adds minimal behavioral context beyond the tool name.
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 single, concise sentence that is front-loaded with the action and resource. There is no redundant information or fluff.
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 (no parameters, no nested objects), the description is complete. An output schema exists to document the return format, so the description does not need to explain it further. The minimal description suffices for a tool of this complexity.
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 tool has zero parameters, and schema coverage is 100% (vacuously). The description does not need to add parameter meaning since there are none, matching the baseline of 4 for zero-parameter tools.
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 ('Return') and resource ('doorzo's current hot/trending search keywords'). It distinguishes itself from sibling tools like doorzo_search and doorzo_monitor_list, which serve different purposes.
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 retrieving trending keywords but does not explicitly state when to use it versus alternatives or provide exclusions. Context is clear but guidance is minimal.
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 no annotations provided, the description carries the full burden of behavioral disclosure. It voluntarily surfaces a non-obvious side effect: 'also drops its seen-item state.' This goes beyond a generic 'removes item' statement and warns the agent about state loss, which is valuable.
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 single, tightly packed sentence that includes both the core action and a key side effect. There is no fluff or repetition, making it an excellent example of parsimonious documentation.
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 remove tool with one parameter and an output schema, the description covers the essential behavior and an important side effect. It does not explain error handling or edge cases, but the tool's low complexity means this is an acceptable level of completeness.
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 provides no description for monitor_id and overall coverage is 0%. The description confirms that the parameter is the monitor's identifier ('Remove a monitor by id'), but it does not provide format, source, or examples. The property name itself is self-explanatory, but the description adds minimal extra meaning.
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 'Remove a monitor by id' uses a specific verb ('Remove') and resource ('monitor'), clearly distinguishing it from sibling tools like doorzo_monitor_add and doorzo_monitor_list. The additional note about dropping seen-item state further clarifies the scope of the 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?
The context is unambiguous: this tool is for removing a monitor, and the 'by id' phrasing implies that one must first obtain the id from a list or search. There is no explicit when-not-to-use or alternative suggestion, but the simplicity of the tool makes the usage clear.
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:

[![DoorzoMCP MCP server](https://glama.ai/mcp/servers/TESTYEE-09/DoorzoMCP/badges/card.svg)](https://glama.ai/mcp/servers/TESTYEE-09/DoorzoMCP)

Score Badge

Copy to your README.md:

[![DoorzoMCP MCP server](https://glama.ai/mcp/servers/TESTYEE-09/DoorzoMCP/badges/score.svg)](https://glama.ai/mcp/servers/TESTYEE-09/DoorzoMCP)

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/TESTYEE-09/DoorzoMCP'

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