io.github.resuly/daleads-mcp

by resuly

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.0
Disambiguation4/5
Most tools have clear, distinct purposes. search_das and nearby_das both find DAs but by different criteria (filters vs. location), and property_intelligence is broader than nearby_das. The sample tools are clearly demos. Minor potential confusion between search_das and nearby_das when both are applicable, but descriptions mitigate.
Naming Consistency2/5
Naming is mixed: verb_noun (search_das, get_da, list_categories, list_councils, get_stats), descriptive (nearby_das, sql_query), and a property_* prefix group (property_intelligence, property_sample, property_flood_sample, property_sandbox_addresses). No consistent verb or noun pattern across the entire tool set.
Tool Count5/5
11 tools is well-scoped for a DA lookup and property intelligence server. Each tool contributes a distinct capability: search, get, nearby, metadata, stats, SQL access, and property intelligence samples. No redundant or excessive tools.
Completeness5/5
The tool surface covers the domain comprehensively: searching with many filters, retrieving full details, geospatial search, metadata lists, statistics, and raw query capability. Property intelligence adds a complementary feature set. No obvious gaps such as missing update/create, which are irrelevant for a read-only public data API.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 3.5/5.
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
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 behavioral disclosure burden. It does mention the returned fields and the limit parameter's maximum behavior, but it does not explicitly state read-only status, pagination, sorting, or access requirements. The 'List' verb implies read-only, but deeper behavioral context is missing.
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 with two sentences, the purpose front-loaded. There is no wasted wording, and the 'Args' section is minimal and directly relevant.
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 list tool with an output schema, the description covers the core purpose and parameter. It lacks usage guidance and explicit read-only confirmation, but the low complexity makes it minimally adequate. It does not need to explain return values because an output schema exists.
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%, but the description adds the semantic 'Max councils to return' to the limit parameter, which clarifies its purpose beyond the schema's 'Limit' title. However, it adds no format details or edge-case behavior, so it only partially compensates for the schema lack.
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 ('List') and resource ('councils'), and also states the returned fields (state, DA count, last activity date). This clearly distinguishes it from sibling tools that focus on DAs or categories.
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?
The description provides no guidance on when to use this tool versus alternatives like search_das or list_categories. It neither states explicit use cases nor exclusions, leaving the agent to infer 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 present, so the description carries the burden. It does disclose some behavioral traits, such as 'since' meaning 'lodged on or after this ISO date' and 'limit' having a max of 100. However, it does not describe the return format, pagination behavior, or any side effects/safety expectations beyond the parameter-level details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single purpose sentence followed by a clean 'Args:' list. Each parameter gets one line with a short explanation, no redundancy, and the most important filter types (state, council, category) lead the list. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no schema descriptions, the tool description covers all parameters thoroughly, including examples and defaults. An output schema exists, so return value details are not necessary. The main gap is lack of guidance on result scope (e.g., what happens with no filters) and error behavior, but overall the description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by documenting every parameter with concrete examples (e.g., council 'City of Melbourne', category 'Renovation / Extension'), allowed values (status_group enum, states), format requirements (ISO date), and constraints (limit max 100, page default). This is exemplary parameter documentation.
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 begins with 'Search development applications with filters,' which is a clear, specific verb+resource statement. It distinguishes from siblings like get_da (single record) and nearby_das (location-based) implicitly by focusing on filter-based search, though it does not explicitly name alternatives.
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 is provided on when to use this tool versus alternatives. There is no mention of 'use this for filtering by council/suburb' or 'for nearby DAs use nearby_das.' The description simply lists parameters, leaving the agent to infer usage context.
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 burden for behavioral disclosure. It adds useful constraints (radius max 50, limit max 100, ISO date format, normalized status values) but does not mention authentication, rate limits, error behavior, or explicitly confirm this is a read-only 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 concise and front-loaded with the purpose, followed by a clean labeled Args list. Every sentence earns its place and there is no redundant filler.
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 all parameters but lacks usage guidance relative to siblings, details about category values, and behavioral traits like error handling or auth. Given an output schema exists, return values are not needed, but the gaps in contextual guidance keep this from being fully complete.
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 description coverage is 0%, so the Args section compensates by explaining all eight parameters, including defaults, max values, and allowed status values. However, 'category' remains vague (no enumeration of trade categories), and required parameters are not highlighted.
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 finds development applications near a location, with a specific verb and resource. This distinguishes it from siblings like search_das and get_da, which likely operate on different query logic or 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 for location-based queries but does not explicitly state when to choose this tool over alternatives like search_das. No exclusions or alternative references are provided, leaving the agent to infer from the tool name and first sentence.
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 must communicate behavioral traits. The verb 'Get' makes the read-only nature clear, but the description does not disclose error handling, data freshness, or any additional constraints. Since an output schema exists, the return structure is externalized, but the description itself adds little beyond the basic retrieval behavior.
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 exceptionally concise, with a one-sentence purpose statement and a brief Args list. Every sentence contributes useful information, and the main description is front-loaded, making it easy to parse quickly.
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 ID lookup with a single parameter and an output schema, the description covers the essential purpose. It does not expand on when to use it relative to siblings, but the output schema handles return details, so the description is adequately complete for the tool's simplicity.
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's Args section carries the burden. It clarifies that 'da_id' refers to 'The DA record ID', adding semantic meaning beyond the schema's property title 'Da Id'. However, it does not explain the expected integer format or any constraints, leaving the explanation minimal.
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 'Get full details of a specific development application by ID.' It clearly identifies the resource (development application) and the action (get full details), and the 'by ID' scope distinguishes it from siblings like search_das or nearby_das that involve searching or proximity.
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 when you have a specific DA ID and need its full details. It provides clear context but does not explicitly mention alternatives or state when not to use it, so it lacks explicit exclusionary 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?
No annotations are provided, but the description discloses that the tool returns categories with record counts and provides examples. It doesn't mention ordering, filtering, or pagination, but for a simple list operation this is acceptable. The output schema likely covers return structure.
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 purpose ('List all trade categories with record counts'), and then illustrative examples. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description doesn't need to explain return values. It provides enough context for a trivial zero-parameter tool, though it could mention that categories are tied to development applications, but that's implied by the sibling 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 tool has zero parameters, and the input schema is empty. The baseline for 0 parameters is 4, and the description adds no parameter semantics because there are none to explain.
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 lists all trade categories with record counts, and gives concrete examples. It distinguishes itself from sibling tools like search_das or get_da, which are not about categories.
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 use case is implied: call this tool when you need the list of trade categories. There is no explicit guidance on when not to use it or alternatives, but given its simplicity, the implied usage is sufficient.
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 must disclose behavior itself, and it does explicitly: 'read-only', 'SELECT only', max rows, timeout, and Pro plan requirement. It also explains why description/summary columns are unavailable, adding valuable context. It lacks error-handling or rate-limit details but is quite transparent overall.
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 front-loaded with the purpose, then structured into schema, limits, and arguments. The column list is long but necessary for a SQL interface, and each sentence contributes useful info. It is not overly verbose, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description supplies the full schema, constraints, and argument semantics, which is essential for invoking SQL correctly. It even explains the absence of certain columns, providing operational depth. With an output schema present, this is sufficiently complete, though examples of query syntax are absent.
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 compensates for 0% schema coverage by explaining that the query must use table name 'das' and that params are for SQL %s placeholders. It enumerates all available columns, giving full meaning to the parameters beyond the bare schema types. This is valuable operational guidance.
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 begins with 'Run a read-only SQL query against DA records', which clearly states a specific verb and resource. It also lists the exact table and columns, distinguishing it from sibling tools like search_das or get_da that use different retrieval methods. The addition of 'Pro plan only' is a constraint, not a clouding of purpose.
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—any time SQL is needed against DA records—but does not explicitly contrast with sibling tools or state when not to use it. It provides clear operational constraints like row limits and timeout, but no alternative recommendations, so guidance is mostly implied.
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 transparency burden. It discloses the output dimensions (total records, by state, by category, date range), which is useful, but it does not explicitly state read-only behavior, caching, or possible limitations. The verb 'Get' implies a read operation, but the description could be more explicit.
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 that immediately identifies the tool's purpose and lists the key output dimensions. Every word contributes value, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema exists, the description is sufficient. It clearly communicates the aggregate scope and the data dimensions returned, which is complete for a zero-argument statistics 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?
This tool takes zero parameters, so there is no parameter semantics to clarify. The baseline for 0-parameter tools is 4, and the description does not introduce any confusion or extra parameter-related content.
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 a specific action ('Get') and resource ('DA statistics'), then enumerates the exact breakdowns provided ('total records, by state, by category, date range'). This clearly distinguishes it from sibling tools like search_das or get_da, which focus on individual records rather than aggregate statistics.
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 word 'overall' signals that this is the aggregate-level tool, distinct from the more specific sibling tools. It gives enough context for when to invoke it (when summary statistics are needed), even though it does not explicitly name alternatives or state when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool returns a production data block, lists its contents, and states that no API key is required. This makes the safe, read-only nature of the sample clear, though it does not explicitly state that it is non-mutating.
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 attribute ('no API key required'). Every word adds value, with no redundancy or irrelevant 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?
Given the tool's simplicity (no params, sample data) and the presence of an output schema, the description fully explains what the tool returns and its intended use. It does not need to cover return format (schema handles this) or complex side effects, making it complete for its scope.
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, so the baseline score is 4. There is no parameter information needed in the description, and the empty schema confirms this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns the production scores.flood block for a specific Rocklea QLD point, listing the exact data components (depth, overlay, terrain, provenance). The verb 'Returns' is specific and the resource is well-defined, distinguishing it from sibling tools like property_sample by focusing on flood scores.
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 for exploration or demos by labeling it an 'example' and noting 'no API key required,' which provides clear context for when to use it. It does not explicitly mention alternatives or exclusions, but the simplicity of the tool makes these unnecessary.
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 reveals that the response is 'canned' (a fixed sample), that no API key is required, and specifies the exact address and context (heritage terrace with DA activity). This adds valuable context about what to expect, though it could also mention that the response is static and not a live lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core promise ('Complete real Property Intelligence response, no API key required'). Each sentence adds relevant information—what the tool returns and why you would use it. There is no wasted or redundant text.
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, zero-parameter sample tool, the description is sufficiently complete. It explains the purpose, the use case, the sample address, and that an output schema can be inspected. The presence of an output schema means the return shape is already structured, so the description does not need to enumerate fields. It could slightly improve by explicitly linking to the property_intelligence tool, but the sibling list makes that connection implicit.
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 takes zero parameters, so the description does not need to explain any parameters. The input schema is empty, and the description appropriately focuses on the output. Per the rubric, a baseline of 4 is applied for tools with no 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?
The description explicitly states it returns a 'Complete real Property Intelligence response' for a specific address (163 Grattan St, Carlton VIC), making the tool's purpose unambiguous. It clearly distinguishes itself as a sample tool that does not require an API key, differentiating it from sibling tools like property_intelligence and property_flood_sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'so you can inspect the full response shape before requesting a key.' It implies the tool is for pre-API-key inspection, but it does not explicitly compare itself to other sample tools or state when not to use it. That said, the guidance is specific enough for an agent to select it appropriately.
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 present, but the description discloses key behavioral traits: lookups never count toward quota, there are twelve real addresses covering all eight states, and it works on any Property Intelligence key. This goes beyond a basic 'list' description and gives useful context about the free nature and scope.
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. The first sentence states the core purpose, and the second adds essential details about the addresses and how to use them, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema and no parameters, the description fully covers the tool's purpose, usage, and relevant caveats (free, quota-free, real addresses). It also correctly positions the tool relative to property_intelligence, making it complete for its scope.
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, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description provides sufficient context without needing to describe any inputs.
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 'List sandbox addresses whose lookups never count toward your quota,' which identifies the specific verb and resource. It distinguishes the tool from siblings by explaining that these addresses are for use with property_intelligence to evaluate live responses for free.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the user to use these addresses with property_intelligence for free testing, providing clear context for when to use this tool. It does not mention alternatives or exclusions, but the singular use case is well defined.
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. It discloses the API key requirement, monthly quota metering, and the exception for sandbox addresses. It also lists the response block categories. It does not mention error behavior or rate limits, but the disclosed authentication and quota context is valuable and beyond what the schema provides.
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 well-organized with a clear lead sentence, a requirements/quota paragraph, and a structured Args list. It is verbose enough to be complete, but each sentence earns its place and the structure makes it easy to scan. The parameter list is front-loaded with the most important lookup inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 4 optional parameters and an output schema, the description provides sufficient context: full input alternatives, output component blocks, authentication requirements, quota behavior, and a pointer to a keyless sample. It is complete enough for an agent to select and invoke the tool correctly, even without annotations.
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 input schema has an example-less structure with no descriptions, so the schema coverage is 0%. The description compensates fully with an Args section explaining each parameter: address with an example, lat/lng as an alternative to address, and components with syntax ('comma-separated subset') and an explicit list of valid blocks. This adds substantial meaning 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 uses a specific verb-resource pair: 'Full property intelligence profile for one Australian address (or lat/lng point)' and enumerates the specific domains covered (planning, hazards, environment, transport, DAs, points of interest, risk scores). This clearly distinguishes it from sibling tools like search_das or get_da, which are narrower in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (for a complete property profile) and provides an alternative: 'No key? Use property_sample for a complete keyless example first.' It also mentions property_sandbox_addresses as an exception to quota metering, guiding the user to a no-cost path. This is explicit usage guidance with named alternatives.
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:

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

Score Badge

Copy to your README.md:

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

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