cart-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
The tools are largely distinct, but rate_aoi and rate_aois are essentially the same operation for one vs. multiple areas, and get_concern_details includes rating domain information that overlaps with get_rating_domain. Still, the descriptions make the intended use clear.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with clear prefixes (list_, get_, rate_, validate_). Pluralization and compound nouns are used predictably.
Tool Count5/5
With 10 tools, the set is well-scoped for the CART/AOI analysis domain. Each tool serves a clear purpose without redundancy.
Completeness4/5
The server covers listing concerns, retrieving details and ratings, generating soil and risk maps, and validating the pipeline. A minor gap is that risk maps only support cointerp-backed concerns, but rate_aoi covers custom concerns, so the overall workflow is complete.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.9/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
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It names the returned content categories but says nothing about read-only safety, required permissions, error conditions, or how the concern identifier is resolved. The tool name 'get' implies a read, but explicit transparency is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the essential purpose and key content areas. There is no filler, repetition, or unnecessary detail.
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 read tool with an output schema, the description is fairly complete, but it omits crucial context about how to acquire the concern value and how this tool relates to siblings. The output schema likely covers return structure, but missing usage and parameter guidance reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter is an undocumented 'concern' string. The description adds only 'one concern,' which does little to clarify the expected identifier format, its source, or how to obtain valid values. This fails to compensate for the schema's lack of detail.
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 resource ('one concern') and its contents ('domain, practices, regulatory references'), making it evident this returns a detailed profile. It differentiates from sibling tools like list_concerns (which lists concerns) and list_practices_for_concern (which focuses on practices alone), though it lacks an explicit verb like 'retrieves'.
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. It does not mention that the 'concern' parameter should come from list_concerns, nor does it note that list_practices_for_concern exists for a narrower practice-specific view. Usage context is entirely 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?
With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by specifying the ordering ('worst to best'), but it does not mention error conditions, return behavior for invalid concerns, or whether it is explicitly read-only. The lack of annotation makes the description the sole source, and it only partially addresses this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key information. Every word contributes to the purpose, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema that likely describes the return structure, so the description needn't explain return values. However, it lacks context about when to use this tool versus siblings and how the 'concern' is specified. It is minimally sufficient but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 mentions 'concern' as the parameter, but this only restates the schema's property name. It does not explain what constitutes a concern (e.g., ID vs. name), allowed values, or format. The description adds minimal semantic value 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 states the tool returns ordered rating classes for a concern, which is specific and distinguishes it from sibling tools like list_concerns or get_concern_details. It uses an implied verb ('get' from the name) and specifies the scope ('for a concern'), though it could be more explicit about the action.
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 vs. alternatives. The description only states what the tool does, with no mention of use cases, prerequisites, or situations where other tools should be preferred.
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 and does a good job: it discloses the output format, the clipping behavior, the feature properties, and the explicit absence of ratings. It does not cover auth, rate limits, or error cases, but for a read-only map retrieval this is reasonable context.
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, front-loads the essential output format, and every sentence adds value. No redundant or vague wording.
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 output schema exists, so return-value detail is not needed, but the description leaves gaps around parameter semantics and usage prerequisites. It is adequate for basic tool selection but not fully complete for an agent that needs to construct a valid request without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 no parameter-level meaning. It references 'AOI' but never explains that 'wkt' should be Well-Known Text or what 'landunit' represents. The agent must rely on the parameter names alone.
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's purpose: producing a GeoJSON FeatureCollection soil map for an AOI. It distinguishes itself from rating tools by stating 'no ratings are computed,' though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a soil polygon map rendered as GeoJSON) and explicitly notes it does not compute ratings, which excludes it from rating use cases. However, it does not name alternatives like get_aoi_soil_summary or list specific conditions that would make this tool the preferred choice.
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 bears the full burden. It discloses the tool's read-like behavior via 'Returns' and enumerates the exact fields, and it adds the key qualifier 'no ratings.' However, it omits any mention of side effects, permissions, rate limits, or edge-case behavior, offering only moderate 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, with two sentences covering purpose, output fields, and usage context. It is front-loaded with the primary action and contains no filler, making every sentence valuable.
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 successfully conveys the tool's purpose, outputs, and use cases, and an output schema exists to document return values. However, it lacks parameter-level details and explicit guidance on when to prefer this tool over siblings, leaving notable gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain 'wkt' or 'landunit.' While the parameter names are somewhat self-explanatory, the description fails to specify formats, coordinate systems, or how landunit is used, leaving a significant gap in compensating for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns map units and major components intersecting an AOI, and conspicuously notes 'no ratings,' distinguishing it from sibling rating tools. It also lists specific output fields, removing ambiguity about the tool's 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 by naming two use cases (transparency E4, leaching/water-table screening W4). It also implies a non-rating exclusion with 'no ratings,' but it does not explicitly reference alternative tools or provide comprehensive when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the data source (public NRCS CART spreadsheet, 'Assoc Ag Land' points), the listed fields (code, name, points), and the advisory, non-formal nature. It lacks mention of permissions or side effects, but these are unlikely for a read-only list 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, front-loaded with the primary purpose, and uses every sentence to add value: source, output fields, and advisory caveat. No unnecessary words 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?
The description provides essential context for a simple lookup tool: purpose, data provenance, output fields, and the advisory nature. While it doesn't detail parameter handling or point interpretation, the presence of an output schema covers return values, making this sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'concern' parameter is not explicitly described; only the tool name and description imply it specifies the concern to query. With 0% schema coverage, the description adds no format, allowed values, or context for this parameter, leaving the agent to guess its exact 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 tool lists NRCS conservation practices associated with a concern, with specific verb 'list' and resource 'practices for concern'. It also distinguishes itself from sibling tools like list_concerns and get_concern_details by focusing on practices rather than concerns themselves.
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 advisory discussions and notes it is not a formal practice plan, but it does not explicitly state when to choose this over alternatives. It offers context but no direct exclusions or comparisons to sibling tools.
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 adds useful input constraints (landunit length, EPSG:4326 for wkt) and the batching behavior ('one pipeline run'), but does not disclose whether the operation is read-only, what the output format is (though an output schema exists), or any side effects or prerequisites.
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, immediately states the core action, and provides a concrete example. Every sentence adds value with no redundancy or unnecessary detail.
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 presence of an output schema, the description covers the main use case and the critical 'aois' parameter, but the unexplained 'concerns' parameter and lack of explicit safety/prerequisite info leave notable gaps for a multi-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema coverage by explaining the structure and constraints of the required 'aois' parameter, but it completely omits any explanation of the 'concerns' parameter, leaving its semantics ambiguous.
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 ('Rate') and resource ('multiple landunits') and distinguishes it from the sibling 'rate_aoi' by emphasizing 'in one pipeline run' for multiple items. The use case example also reinforces purpose.
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 ('Ideal for comparing fields/parcels') and implies it is the batch version of rate_aoi. However, it does not explicitly name alternatives or state when not to use it, leaving some room for inference from sibling names.
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 carry the full burden. It states the tool returns all concerns and lists included fields, which is useful. However, it gives no details on read-only status, pagination, ordering, or access requirements. Minimal but not misleading.
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 sentence that is front-loaded with the core function ('All CART resource concerns') and immediately lists the key attributes. No filler or redundant 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 tool has no parameters and an output schema is present, the description fully explains what the tool returns. The only missing context is whether any authentication or special access is needed, but for a read-only listing tool this is often not required. It is adequate for the tool's simplicity.
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?
No parameters exist, so the baseline is 4. The description adds context about what each returned item includes (pipeline type, data source, etc.), which complements the empty 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 lists all CART resource concerns and enumerates the attributes (pipeline type, data source, computability, docs). This distinguishes it from siblings like get_concern_details (single concern) and list_practices_for_concern (practices for a concern).
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 use when needing an overview of all concerns with their attributes. It doesn't explicitly name alternatives or exclusions, but the 'All' scope and the sibling tool names make the intended usage clear. For a simple list-all tool, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool submits to an external public web service (Soil Data Access), returns specific rating fields, and that results are advisory, not official. This goes beyond a simple 'rate' statement, though it does not mention side effects, rate limits, or error 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 three sentences, front-loaded with the core action, and every sentence adds value: action/input, execution/output detail, and a caveat about advisability. No redundant or filler 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 presence of an output schema (which descriptions needn't duplicate) and the complexity of the tool, the description covers the main aspects: what it does, the inputs, the output fields, and a key caveat. It doesn't mention relationship to sibling tools like rate_aois, but this is not essential when the tool list is available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning for 'wkt' by specifying the format (WKT, EPSG:4326) and for 'concerns' as a subset of concerns. However, the 'landunit' parameter is only referenced indirectly via 'landunit rating', which may be ambiguous; the default value 'AOI 1' is not explained.
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 ('Rate') and resource ('area of interest'), and includes the input format (WKT, EPSG:4326) and domain (CART soil resource concerns). It clearly distinguishes itself from the sibling tool rate_aois by focusing on a single AOI, and the mention of returning landunit ratings for ratable concerns adds further specificity.
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 implies usage for rating a single area of interest and for CART soil concerns. It does not explicitly name alternatives or exclusion scenarios, but the context is clear enough that an agent can infer when to use this tool versus the plural rate_aois. The 'advisory' note also sets expectations about applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that network access is required and that golden values are tied to specific snapshots, which helps set expectations. It also warns about potential false mismatches, offering useful context beyond the basic function.
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, consisting of two short sentences that immediately state the action and the key caveat. Every sentence adds value, with no filler or 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 key contextual facts: network dependency, golden value provenance, and a likely cause of mismatches. It is complete for a zero-parameter validation 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 is 4 per the rubric. The description does not need to explain parameter semantics since there are none, and the schema fully captures the lack of 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 uses a specific verb ('Re-run') and identifies an exact resource ('pipeline on the T9981 Fld3/Fld4 test fields') with a clear action ('diff against golden values'). This clearly distinguishes it from sibling tools like rate_aoi or list_concerns, which serve 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 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 (for validating the pipeline against golden values) and includes a caveat about legitimate mismatches due to republished survey areas. It does not explicitly name alternatives, but the sibling tools are obviously unrelated, making the intended use evident.
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 full burden and does so admirably. It discloses the output structure (GeoJSON FeatureCollection with rating_value and rating_class), the rating logic (dominant major soil component), special handling for Order 5 map units ('Not rated'), and error behavior for unsupported concerns. This is rich behavioral context beyond the schema.
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 compact and well-structured. It leads with the primary purpose, then provides essential details about output and limitations in a dense, readable format. Every sentence adds meaningful information without 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's complexity (output schema exists, 3 params, 9 siblings), the description is remarkably complete. It explains the output format, data content, rating logic, edge cases, and error conditions. The existence of an output schema means return values need not be elaborated further, and the description fills the remaining context thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It implicitly explains 'concern' (the concern to rate) and suggests 'wkt' is the AOI geometry via 'clipped to the AOI', but it never explicitly documents the parameters, and 'landunit' is completely unaddressed. The description adds some semantic value but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a risk map for one cointerp-backed concern as GeoJSON. It specifies the resource (soil polygons clipped to AOI) and distinguishes from siblings by limiting to cointerp-backed concerns and excluding SOC/custom concerns, which is a clear differentiation.
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 (cointerp-backed concerns like SOH, Hydric, etc.) and when not to (SOC and custom concerns raise an error). This provides clear usage context and exclusions, though it doesn't name alternative tools, the prohibitive guidance is sufficient.
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:

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

Score Badge

Copy to your README.md:

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

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