Happy Endpoint MCP Server

Official

by happyendpointhq

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: location discovery, property listing search, off-plan search, transaction data, yield comparison, agent lookup, product search, hotel search, and API list. No two tools overlap in function; even similar property tools (search vs. off-plan vs. transactions) are separated by listing type and data source.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (find_locations, search_properties, get_transactions, compare_rental_yields, list_available_apis). The verbs vary semantically (find, search, get, compare, list) but are used appropriately, and there is no mixing of camelCase or irregular styles.
Tool Count5/5
With 10 tools, the server sits comfortably in the ideal 3-15 range. Each tool serves a distinct endpoint or computation, and the property-focused subset (7 tools) is thorough without being bloated. The additional product, hotel, and meta tools expand the server's reach without making the count unwieldy.
Completeness4/5
The UAE property domain is well-covered: location search, property listing search, detailed property records, off-plan projects, actual transactions, rental yield comparison, and agent lookup. Missing are update/delete operations, but this is a read-only data server. The product and hotel sections are minimal (only search), but they serve simple use cases. Overall, minor gaps exist in non-property areas, but core workflows are covered.
Average 4.2/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
- 4 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?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that yield is computed from 'live listings' using 'median asking prices' and that it is 'not available as a single API call,' offering useful caveats. However, it does not discuss potential accuracy limitations or the nature of the output.
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 compact with four sentences, each serving a purpose: defining what it does, explaining the metric, and giving usage caveats. The second sentence about the formula is useful context and not wasted. It is front-loaded with the core action.
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 computation tool with no output schema and no annotations, the description covers the essential points: what metric is computed, the formula, the data source, and a caveat. It does not explicitly state the return format (e.g., a list with yields), but given the tool's purpose, this is reasonably implied and not a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'locations' parameter with examples and 'bedrooms' with valid values. The description adds minimal meaning by mentioning 'several UAE areas at once,' but it does not elaborate on 'bedrooms' or 'propertyType' beyond the schema. With 67% schema coverage, the description provides no significant additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Calculate and compare gross rental yield for several UAE areas at once.' It uses a specific verb ('calculate and compare') and resource ('rental yield'), and it distinguishes itself from sibling tools that provide raw listing or transaction data by focusing on a computed metric.
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 for use: it is 'the headline metric for buy-to-let investors' and explicitly advises to 'treat it as a screening tool rather than a valuation.' While it does not name alternative tools, it implies when this tool is appropriate versus raw data sources.
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. It discloses the tool returns 'active' agents and includes agency and TruBroker badges, but lacks details on result limits, pagination, or authentication requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary function and followed by use cases. There is no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters, the description covers the core purpose and result contents. It lacks information on result format or pagination, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds context to the location parameter (UAE area) and the purpose parameter is self-explanatory via its enum values. However, it does not clarify whether purpose is required or how it affects results, leaving some 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 tool's function: finding real estate agents in a UAE area, including their agency and performance badges like TruBroker. This distinguishes it from sibling tools like search_properties, which focus on properties rather than agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: agent directories and identifying the most active agents in a community. While it doesn't explicitly name alternatives or when-not-to-use, the context is sufficient for an agent to infer appropriate usage.
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. It discloses live-data nature and cross-country comparison behavior, which is relevant. However, it does not describe return format, pagination, rate limits, or other side effects. For a simple search tool, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. Each sentence adds specific, non-redundant information about scope and capabilities. No wasted words.
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 the main search scopes and the optional countryCode behavior, which is critical for correct invocation. However, without an output schema, it does not clarify what fields are returned or pagination, leaving some ambiguity for the agent. Overall adequate for a straightforward search 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?
The description adds meaningful context to the retailer enum (explaining what each retailer covers) and countryCode (supporting cross-country price comparison), which goes beyond the schema's sparse enum and default. The query parameter already has an example 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 opens with a specific verb and resource ('Search live product data from a retailer'), then clarifies the two retailer domains (beauty, furniture/home goods). This clearly distinguishes it from sibling tools focused on real estate and locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (searching Sephora or IKEA products), including geographic coverage and countryCode usage for price comparisons. It does not explicitly name alternatives, but the retailer-specific coverage implies usage boundaries and differentiates from unrelated siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'get transactions' by explaining the nature of the data (actual recorded transactions, not asking prices) and the included details (price per sqm, first sale vs resale). It does not mention response format or pagination, but for a read-only tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and key data details, then followed by use cases and a distinguishing contrast. Every sentence contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 params and no output schema, the description adequately covers what the tool returns (transactions with price per sqm and sale type) and its intended use. It does not explain the 'page' parameter or anything about pagination, but the core functionality is sufficiently clear for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, covering location, purpose, and timePeriod, so per the rubric baseline is 3. The description adds little parameter-specific meaning; it mentions sale/rental and UAE area, but this mostly mirrors the schema. No additional guidance is provided for the 'page' param, which lacks a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns actual recorded sale and rental transactions with price per sqm and first-sale/resale status, using a specific verb (get) and resource (historical property transactions). It explicitly distinguishes itself from sibling search_properties by contrasting actual sales with asking prices.
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 use cases: 'Use this for valuation, market trends, and price-per-sqm questions.' It also names a sibling alternative (search_properties) and explains the key difference. However, it does not explicitly state when not to use this tool or mention other alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states that the tool lists data sources and subscription locations, implying a non-destructive, informational read operation. However, it does not disclose potential behavioral details such as whether the tool actively checks reachability, requires authentication, or has any side effects. The phrase 'can reach' is somewhat ambiguous and could imply network calls or simply configuration data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence front-loading the primary action and resource, and the second sentence providing usage guidance. Every word adds value; there is no redundancy, fluff, or unnecessary detail.
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 tool with zero parameters and no output schema, the description adequately explains what it does and when to use it. It states the tool lists data sources and subscription locations, giving a clear idea of the return content. It could be more explicit about the exact format or structure of the output, but for such a low-complexity tool, the coverage is sufficient.
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 the schema coverage is 100% (vacuously). The description adds no parameter-specific information, which is acceptable because there are no parameters to explain. The baseline for 0-parameter tools is 4, and no deduction is warranted.
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 a specific action ('List') and clearly identifies the resource ('data sources this server can reach') plus the additional detail of where to subscribe. This clearly distinguishes it from sibling tools that retrieve specific data (e.g., search_properties, get_property_details), as this tool is about discovering available endpoints rather than querying them.
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 second sentence provides explicit use cases: when a call fails due to a missing subscription or to see what data is available. This gives clear context for when to use the tool. It does not name alternative tools explicitly, but the context is sufficient to infer that this is for metainformation rather than actual data retrieval.
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 description carries the burden. It explains the domain and payment plan context, but does not disclose pagination behavior, return formats, or any limitations beyond the implied read-only nature of a search.
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 concise sentences, front-loaded with the main purpose, 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?
For a search tool with 4 params and no output schema, it covers the domain, use cases, and key terminology. Lacks detail on pagination but acceptable given sibling tools and schema.
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 75% and description adds context for maxPreHandoverPayment via 'pre-handover payment terms' and explains the domain. It doesn't fully explain page, but the schema provides descriptions for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches off-plan and under-construction property projects in the UAE, distinguishing it from general search_properties. The definition of 'off-plan' adds clarity.
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?
Mentions specific use cases ('new developments, launches, and pre-handover payment terms'), giving clear context for when to use, but does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It explains the output contents (areas, communities, buildings with listing counts) and the search nature, but does not mention any potential errors, rate limits, or exact response structure. Still, it discloses the key behavioral trait of being a read-only lookup, which is sufficient for a simple search 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 three sentences, each with a clear purpose: action, output, and usage guidance. It is front-loaded with the verb and resource, and there is no redundant or irrelevant 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?
For a simple tool with 2 parameters and no output schema, the description covers the core functionality, output, and usage. It does not include examples or error handling, but given the low complexity, it is near-complete. The guidance about other tools adds important context for when to invoke 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 coverage is 100% for both parameters, so the description does not need to explain their syntax. It slightly reinforces that 'query' is a place name ('by name') but otherwise adds no new meaning beyond the schema's descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for UAE property locations by name and returns matching areas, communities, and individual buildings with listing counts. It uses a specific verb (search) and distinct resource (locations), and distinguishes itself from sibling tools by noting that other property tools resolve place names automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use the tool ('when a place name is ambiguous, or to discover what areas exist') and when not to ('Other property tools accept place names directly and resolve them for you, so you usually do not need to call this first'). This clearly differentiates it from 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It openly warns that the endpoint is slow (often over 30 seconds) and notes the dependency on a prior search. While it doesn't mention error behavior or authorization, it covers the most significant behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what it returns, prerequisite, and performance guidance. No redundancy or fluff, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description gives a solid picture of the return content and performance characteristics. It slightly lacks details on potential failure modes or field restrictions, but overall it is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for propertyId, and the schema coverage is 100%. The main description re-states that the id comes from search_properties, adding marginal nuance but not new information 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 explicitly states the tool returns the full record for one property, listing content areas (specification, amenities, agency, location hierarchy). This clearly distinguishes it from the sibling search_properties tool, which is a list/search operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite (needs an id from search_properties) and provides guidance to prefer search_properties when its fields are sufficient due to slowness. This gives clear when-to-use and alternative 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?
With no annotations, the description carries the burden and does well by revealing that dates are automatically converted to the API's expected format and that the destination is resolved to an internal id. This adds context beyond the schema, though it doesn't describe output structure or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each informative and front-loaded. It states the core purpose, then provides two key behavioral details without redundancy. 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?
Given the schema covers all six parameters and the description addresses the main usage constraints (date format, destination resolution), this is complete enough for a search tool. No output schema exists, but the description's mention of 'prices and availability' gives a reasonable expectation of return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enriches this by explaining the date format handling and automatic destination resolution, which adds meaning not present in the schema alone.
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 states 'Search hotels by destination and dates, with prices and availability,' which is a specific verb+resource+scope. It clearly distinguishes this tool from siblings like search_properties or search_products by focusing on hotels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: search by destination and dates, plus guidance on date format ('YYYY-MM-DD') and destination resolution. It doesn't explicitly mention when to use this tool instead of alternatives, but the hotel-specific wording implies its scope.
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?
Without annotations, the description adds key behavioral context: prices are in AED, rental prices are annual, and asking prices are higher than actual sale prices. It doesn't cover pagination or defaults, but it discloses critical return-value behavior and unit semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear front-loading: first sentence states the main function, second clarifies input and units, third offers a caveat and alternative. No unnecessary 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?
The tool has no output schema and multiple parameters, but the description covers essential semantics (place name, AED, annual rent, asking vs sold). It could mention pagination or return fields, but the current level is sufficient for an agent to use it 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?
The description adds meaning beyond the schema by clarifying that location is a place name and that prices are AED (with annual rent for rentals). Since schema coverage is 71%, this extra context for price and location is valuable.
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 searches UAE property listings with specific filters (area, price, bedrooms, type) and distinguishes itself by noting it takes a place name rather than an ID, while also referencing get_transactions for sold prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use get_transactions instead (when actual sale prices are needed) and implies when to use this tool (for current listings). It also provides the input constraint 'not an ID', giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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