mcp-resilland

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes (get vs list, overview vs summary, brief vs report translation). Minor overlap exists between analyze_area and get_parcel, both returning parcel and nursery proximity data, but descriptions clarify scope.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (get_*, list_*, analyze_*, generate_*, translate_*, create_*). No mixed conventions or vague verbs.
Tool Count4/5
16 tools is slightly above the typical 3–15 well-scoped range, but the server covers multiple subdomains (parcels, nurseries, reports, stats, translation, AI analysis), so each tool earns its place.
Completeness4/5
The surface provides solid coverage for the forestry analysis workflow: list/detail for parcels and nurseries, report lifecycle (list, get, generate, translate, share, PDF), and stats. Minor gaps like no update/delete for reports or parcels are not critical for the domain.
Average 3.9/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/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 disclosing behavior. It only says 'List', without stating whether the operation is read-only, whether there are pagination limits, or whether filters like bbox or tuman are applied automatically. It also doesn't mention any potential side effects or access requirements, making it insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It is appropriately short for a simple list operation, but it could arguably include more contextual detail without becoming verbose. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 5 parameters, output schema, and sibling tools, the description is minimal but minimally viable. It doesn't explain when to use this tool or how it differs from siblings, and it lacks behavioral notes. The output schema covers return values, so that aspect is handled, but the overall context is incomplete for an agent to fully understand the tool's role.
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?
All five parameters have descriptions in the input schema, covering 100% of the parameter semantics. The description itself adds no additional detail about parameters, but the schema already provides the necessary meaning, so the baseline of 3 applies.
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 clearly states the verb 'List' and the resource 'cadastral forest parcels', which is specific and unambiguous. However, it doesn't explicitly distinguish this from sibling tools like get_parcel or list_nurseries, though the plural 'parcels' and the action 'list' imply a collection operation. Thus it is clear but lacks explicit sibling differentiation.
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. It doesn't mention that get_parcel is for individual parcels or that list_nurseries is for nurseries. There is no context about typical use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
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 burden. It adds useful behavioral details ('Sonnet 4.6' model and 'markdown-preserving'), but does not disclose other behaviors like character limits, error handling, or whether source_lang is auto-detected. The markdown-preserving note is valuable but partial.
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?
A single, front-loaded sentence with a parenthetical for additional traits. Every word earns its place; no redundancy.
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 low complexity and presence of an output schema, the description is fairly complete. It covers language count, domain, and a key behavioral trait (markdown-preserving). However, it misses an explicit distinction from translate_report, which would improve 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?
Schema description coverage is 100%, so the baseline is 3. The description adds semantic value by framing the task as forestry/policy text and confirming markdown preservation, which aligns with the preserve_markdown parameter, but it does not detail parameter usage beyond the schema.
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 clearly identifies the tool as translating forestry/policy text, with a specific verb ('Translate') and resource. It distinguishes from siblings by mentioning markdown preservation and domain focus, but does not explicitly contrast with the similar translate_report tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus translate_report or others. The name suggests a 'brief' variant, but the description provides no usage context, exclusions, or alternative recommendations.
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 full burden for behavioral disclosure. It mentions the production DB source and lists return contents, implying a read-only operation, but it does not explicitly state safety aspects, potential performance impact, or access requirements. It adds some context beyond a minimal description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a short opening sentence followed by a detailed but organized enumeration of return fields. The final sentence about the dashboard payload is slightly redundant with the opening 'Live platform KPIs' but doesn't waste much space. It earns a 4, not 5, due to minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and the description thoroughly enumerates all return sections (counters, data-sources panel, country coverage, activity feed), it is contextually complete. The description leaves no ambiguity about what the tool returns, and the output schema covers return values. A 5 is justified for this no-param 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 tool has zero parameters, so the baseline score is 4 according to the rubric. The description adds no parameter details because none are needed; the schema's additionalProperties: false confirms there are no inputs. Thus a score of 4 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 clearly states the tool returns live platform KPIs and enumerates specific counters and panels, making the purpose obvious. However, it does not explicitly differentiate from the sibling tool get_stats_summary, which likely serves a similar function. A 5 would require explicit sibling differentiation.
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 gives no explicit guidance on when to use this tool versus get_stats_summary or other siblings. The phrase 'straight from the production DB' implies a live read but offers no exclusions, prerequisites, or alternative recommendations. This is a clear gap for a tool with a closely named sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation but doesn't disclose authentication requirements, error behavior, or what 'full detail' includes. This is minimal for a read 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?
One sentence, no filler, front-loaded with verb and object. It is perfectly concise and well-structured.
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 single-fetch tool with one parameter and an output schema, the description is sufficient. The output schema covers return values. It could mention behavior on not-found, but the description is adequate for a basic get-by-ID.
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 clarifies that nursery_id is a UUID, adding meaning beyond the schema's plain string type. However, it doesn't specify UUID format or other constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' with a clear resource 'full detail for a single nursery' and a identifying method 'by UUID'. It clearly distinguishes from siblings like list_nurseries (which lists multiple) and get_parcel (different resource).
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 is implied: call this when you have a UUID and need full detail for a single nursery. No explicit when-to-use or alternatives are mentioned, but the singular 'single nursery' makes its purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states 'List', which inherently suggests a read-only operation, but it does not disclose any additional behavioral traits such as pagination, ordering, potential large response sizes, or any side effects. This adds minimal value 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, brief sentence that directly states the tool's purpose with no extraneous or repetitive content. It is optimally concise and 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 simple list tool with two optional, well-documented parameters and an output schema, the description is largely sufficient. It could mention that filtering is possible, but the schema already conveys that. Given the low complexity and available structured information, the description is adequately 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?
The input schema provides 100% coverage of parameter descriptions (country: ISO-3166 alpha-3; category: list of allowed values). The description adds no parameter-level meaning beyond the schema, so the baseline score 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 'List forestry nurseries across the RESILAND region' clearly states a specific verb ('List'), the resource ('forestry nurseries'), and the geographic scope ('RESILAND region'). This distinguishes it well from sibling tools like get_nursery, which presumably retrieves a single nursery, and other list tools like list_parcels.
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 use when a list of nurseries is needed, but it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The sibling tool names hint at distinctions, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'List available...' with no additional behavioral context such as whether this is read-only, whether it requires authentication, whether it returns all models at once, or any side effects. The description is too minimal to reveal behavioral traits beyond the obvious list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is front-loaded with the verb and immediately lists the specific items covered. Every word earns its place; there is no redundancy or filler.
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 zero parameters and an output schema present, the description is largely sufficient. It names the two categories of returned data (LLM + embedding models, supported locales/countries). Slightly more context about the return style (e.g., full list vs. paginated) would improve completeness, but the low complexity and schema mitigate this gap.
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 is 4. There are no parameters to document, and the description correctly mentions the scope (models and locales/countries) without needing to explain any input semantics. The schema confirms no properties, so no conflict.
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 the specific verb 'List' and clearly identifies the resource: 'available LLM + embedding models and supported locales/countries.' This precisely states what the tool does and distinguishes it from sibling tools like list_parcels or list_reports, which focus on different domains.
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: call this tool when you need to see available models or supported locales/countries. However, it does not provide explicit when-to-use vs. alternatives or any exclusion criteria. Sibling tools are unrelated, so no direct confusion, but the guideline is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds ownership scoping ('owned by this API key's user'), which is useful behavioral context. However, with no annotations provided, it does not disclose the default report_status filtering (final only), pagination behavior, or other side effects. Some details exist in the schema, but the description carries the burden and only partially fulfills it.
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 irrelevant details. It communicates the core purpose efficiently.
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 list tool with a rich schema and output schema, the description covers the essential ownership constraint. It could mention the default status filter or explicitly reference sibling tools, but the tool is relatively simple and the description is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the baseline is 3. The description adds no parameter-specific meaning 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 states the specific action 'List' and the resource 'feasibility reports', with an ownership qualifier. This clearly distinguishes it from siblings like get_report (single report) and generate_feasibility_report (creation).
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 as a listing endpoint for the current user's reports, but does not explicitly mention when to use it over alternatives like get_report or list_parcels. No exclusions or when-not-to-use guidance is provided.
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 available, so the description carries full responsibility. It indicates a read-only operation ('Return') and specifies that it operates on the current API key, which is useful context. However, it does not disclose any additional behavioral details such as authentication requirements or rate limit implications.
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, compact sentence that front-loads the operation and its target. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently covers the purpose and scope. It specifies what the response contains (quota state, totals, scopes) and requires no additional context for a simple balance lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% vacuously. The description adds context that the balance is tied to the current API key, which is useful for the agent to understand the implicit context. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and clearly identifies the resource: the current API key's quota state, totals, and scopes. None of the sibling tools deal with balance or quota, so it is well-differentiated.
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 compared to alternatives. There are no sibling tools for balance, but the description does not explicitly state when it should be invoked (e.g., before making API calls).
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 burden of behavioral disclosure. It adds context by mentioning 'cached' OSM infrastructure proximity and enumerating returned data, but it does not disclose permission requirements, error behavior, or potential performance implications. It is a read-only fetch by nature, but this isn't 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, compact sentence with the primary purpose front-loaded and details following with a colon. Every clause adds information, 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.
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 (one parameter, no annotations) and existence of an output schema, the description already enumerates the key return components and notes the cached nature of some data. It doesn't address error cases (e.g., nonexistent id), but for a straightforward fetch this would be handled by the output schema, so the description is largely 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?
The schema provides only a required integer parcel_id with no description (coverage 0%). The tool description compensates by clarifying that the parameter refers to the 'integer id' of the parcel, adding meaning beyond the bare schema. It doesn't give examples or range, but for a single simple parameter this is adequate.
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 ('Fetch'), identifies the resource ('full detail for a single parcel'), and specifies the lookup by integer id. It also enumerates the included attributes (cadastral attributes, geometry, centroid, etc.), which clearly distinguishes it from sibling tools like list_parcels or get_nursery.
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 clearly implies its use case ('full detail for a single parcel'), which contrasts with listing tools, but it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria. Guidance is implied rather than spelled out.
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 full burden. It discloses return values (markdown, citations, token usage, cost), output length, section structure, the mandatory one-of parameter rule, and locale options. This is substantial behavioral context beyond the schema, though it does not mention error behavior or side effects (e.g., cost implications or long runtime).
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 and front-loaded with the purpose, then lists return components and constraints. All sentences contribute value; no redundant phrasing. It could benefit from structured formatting (e.g., bullet list of sections) but is acceptably concise.
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 the existence of an output schema, the description covers the key outputs, typical length, section list, and the input requirement. It lacks information on failure modes, prerequisites like balance, or interaction with other tools, but for a report generator it provides a solid operational picture.
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 description must compensate. It explains that exactly one area-reference parameter (geojson, parcel_id, nursery_id, cadastral_number) is required, and enumerates locale values with pipe-separated options. However, it does not describe each parameter individually, leaving some ambiguity about formats (e.g., what geojson should look like).
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: 'Generate a full Phase 4-style feasibility report with Opus 4.7,' which clearly distinguishes it from sibling tools like analyze_area or translate_brief. It enumerates the report's contents (markdown body, citations, token usage, cost) and section list, leaving no ambiguity about what the tool produces.
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 does not name alternatives or provide explicit when-to-use guidance, but the phrase 'full Phase 4-style feasibility report' implies this is the primary generation tool. The required-parameter constraint is a usage rule, not a tool-selection guideline. Without comparisons to siblings like analyze_area or get_report, the agent may not know when to choose this over a lighter analysis.
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 disclosure. It reveals key behaviors: the link is public, auth-free, expires in 7 days, and returns specific fields. It does not mention permissions to create the link, but the core safety and expiration semantics are covered.
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, directly states the action and key details, and lists the return fields. There is no fluff or redundant repetition of the schema.
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 (one parameter), the description sufficiently covers purpose, key behavior, and return values. It also explicitly lists the output fields, which is useful even though an output schema exists. Minor missing context like prerequisites or side-effect details, but overall complete for the use case.
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 only parameter, report_id, is not explicitly described in the description beyond 'for a report'. Since schema coverage is 0%, the description provides minimal compensation, but the parameter name is self-explanatory and the tool is simple. This is adequate but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Mint' and clearly states the resource: a 7-day public share link for a report. It is distinct from sibling tools like get_report and get_report_pdf_url, which retrieve or provide PDFs, not create share links.
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 clearly indicates this tool is for sharing reports via a public, auth-free link, suitable for pasting into Slack, email, or chat. It does not explicitly contrast with alternatives like get_report_pdf_url, but the use case is well implied.
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. It discloses key behavioral traits: the operation creates a sibling, is asynchronous (returns in <1s), and the sibling starts as 'draft' then changes to 'final' after ~30–90s. This goes beyond the simple verb 'translate' and provides useful expectations for the agent. It doesn't mention failure modes or permissions, but the async behavior is well covered.
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: the first sentence states the purpose, and the second explains the crucial background behavior and gives actionable polling instructions. Every sentence adds value, with no fluff or redundancy.
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 is moderately complex due to its asynchronous nature, but the description covers the essential workflow (background task, immediate return, polling). Since an output schema exists, the description is not required to detail return values. It could mention permission requirements or error handling, but for a translation tool, the provided context is sufficient.
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 each parameter (report_id, target_language, model) already has descriptions. The tool description does not add additional parameter-level details beyond what the schema provides, which is acceptable per the baseline rule. The information about 'another language' aligns with target_language but adds no new semantics.
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 'Translate' and the resource 'an existing report', while also distinguishing the tool from siblings by explaining it creates a sibling report in the same analysis_group and runs as a background task. This is specific and contrasts with tools like translate_brief or get_report.
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 guidance: it explains the tool returns immediately and instructs the agent to poll get_report(sibling_id) until the status flips to 'final'. It also gives a timing estimate. However, it does not explicitly mention when not to use this tool or discuss alternatives like translate_brief, leaving a slight gap.
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 adds valuable details beyond the schema: the URL is public, expires after 7 days, and returns a plain URL rather than binary streaming. However, it does not mention authentication requirements, potential errors, or what happens if the report doesn't exist, which would be useful for full transparency.
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: two sentences, with the primary purpose stated first, then equivalence and MCP-friendliness. Every sentence adds value and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this simplicity, the description is complete: it explains the 7-day expiry, the URL return format, and how it relates to a sibling tool. An output schema exists, so the return value is already defined. No significant gaps remain for the target use case.
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 schema already documents both parameters (report_id and lang) with descriptions. The description does not add significant meaning beyond the schema, only reinforcing the URL behavior. Therefore, the baseline score 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's function: generating a 7-day public URL for a report as PDF. It uses a specific verb ('generate') and resource ('report PDF URL'), and distinguishes itself from sibling tool create_report_share_link by noting it packages the equivalent into one call.
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 this tool: when a plain, fetchable URL is needed without binary streaming, positioning it as an MCP-friendly alternative. It references create_report_share_link as the equivalent but does not explicitly state when not to use it or name other alternatives, so slightly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does: it enumerates response fields and even notes a version-dependent behavior (extra_metadata only on reports after 2026-04-24, older fall back). It doesn't describe auth, rate limits, or error cases, but for a read-only get-by-ID, the key behavior is 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 front-loaded with the core purpose and then uses a clean bulleted list for the response fields. Every line adds specific detail; no filler or repetition. Efficient and well-structured.
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 is simple (single parameter, read-only), and the description covers the main return structure and a notable behavioral nuance. Since an output schema exists, the description doesn't need to fully document every field, but it provides a strong overview and the temporal caveat. Missing only minor edge-case info that would be over-specification for such a 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 only parameter, report_id, is described as a 'UUID' in the first line, adding meaning beyond the bare string type in the schema. Given schema description coverage is 0%, this is valuable, though it doesn't elaborate on how to obtain the UUID or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Full report detail by UUID', which clearly identifies the tool as a retrieval-by-ID operation for reports. It lists specific fields (body_markdown, sections, siblings, shares) and distinguishes it from siblings like list_reports (listing) and translate_report (translation).
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 phrase 'Full report detail' gives clear context for when to use this tool. However, it does not explicitly mention when to use alternatives (e.g., get_report_pdf_url for PDFs or list_reports to find UUIDs), so it lacks explicit 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 burden. It discloses important behavioral traits: the tool is a 'filtered read', it can return either viewport-scoped or global totals depending on parameters, and the bbox coordinate system is EPSG:4326. This adds value beyond the name and schema, though it does not explicitly state read-only semantics or potential side effects.
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 core purpose. Each sentence earns its place: first states the function, second explains parameter modes, third clarifies the coordinate system. No filler or redundant content.
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 moderate complexity, the description covers the essential aspects: purpose, parameter behavior, and coordinate system. The output schema exists, so return values are not required in the description. It could have more explicitly differentiated from get_stats_overview, but overall it is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description compensates by explaining that the 4 parameters form a bbox, must be passed together for a filtered read, and that omitting them yields global totals. The tuple order [west, south, east, north] maps clearly to the min/max lat/lng parameters, providing semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('counts parcels, total area, distinct viloyats (provinces) and nurseries inside a bbox') and distinguishes it from the sibling get_stats_overview by emphasizing the viewport/bbox scope. The 'Viewport-scoped stats' prefix immediately conveys the resource and scope.
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?
Provides clear context for when to use the tool: when you need stats within a bbox. It also explains two usage modes (pass all 4 bbox params for filtered read, or none for global totals). However, it does not explicitly mention alternatives or when-not-to-use relative to sibling tools like get_stats_overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this thoroughly by listing what the tool returns (including the conditional 'if cached' for NDVI history), the input constraints, the meaning of depth, and supported locales. It also communicates the tool's analytical, read-oriented nature without explicitly saying 'read-only'.
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?
Despite the tool's complexity, the description is tightly structured: a lead sentence, a bulleted list of return fields, and a compact parameter usage section. Every sentence adds value and avoids redundancy, making it easy to scan for key facts.
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 high complexity (7 parameters, rich output schema), the description is remarkably complete. It covers the output structure, input constraints, parameter semantics, and even edge cases like 'if cached'. The existence of an output schema further reduces the burden, but the description already provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema gives no descriptions (0% schema description coverage), so the description compensates fully by explaining each parameter. It defines the exclusive-OR requirement for the four identifier parameters, gives an example for query, enumerates depth options, and lists valid locale values. This goes beyond the schema's raw type definitions.
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 ('Build a structured spatial context for this area') and enumerates the contents of the returned JSON payload, making the tool's purpose unmistakable. It clearly distinguishes this from sibling tools like get_parcel or get_nursery, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool and explicitly encodes a critical usage rule ('Exactly one of parcel_id | cadastral_number | nursery_id | geojson must be provided'). It also explains the role of query and depth parameters. However, it does not explicitly mention alternatives or exclusion cases relative to sibling tools, so it stops short of full when-to-use vs. when-not-to-use 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:

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

Score Badge

Copy to your README.md:

[![mcp-resilland MCP server](https://glama.ai/mcp/servers/ilhankilic/mcp-resilland/badges/score.svg)](https://glama.ai/mcp/servers/ilhankilic/mcp-resilland)

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/ilhankilic/mcp-resilland'

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