Author and validate Calaf workspace seeds against the app's real importer. No account needed.
Scored across 2 tools
Each tool has a clearly distinct purpose: one provides the format specification, the other validates a draft against that format. There is no overlap in functionality—an agent can unambiguously select the right tool for obtaining the spec versus checking a draft.
Both tools follow a verb_noun pattern ('get_seed_format', 'validate_seed'), with 'seed' as a shared domain term. The slight inconsistency is that one uses 'seed_format' and the other just 'seed', but the pattern is clear and predictable.
With only 2 tools, the surface is thin but appropriate for a narrowly scoped server focused on seed authoring and validation. It covers the essential workflow without bloat, though it could be argued a create/edit tool might be expected.
The tools cover the core loop of referencing the format and validating drafts, which is the stated purpose. Minor gaps exist—no explicit tool for creating or editing seeds—but agents can use external editors and the validation loop is complete.
Returns the complete specification (markdown) for calaf_seed: 1 JSON documents — the format to follow when a user asks for a Calaf seed. Read it before authoring; then check your draft with validate_seed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| uri | Yes | Where the same document lives as a resource. |
| markdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not restate safety. The description adds value by revealing the response is markdown and that it serves as the canonical format reference for authoring, plus the workflow of consulting before validate_seed. This goes beyond what the annotation provides, though it doesn't cover every possible behavioral edge (e.g., idempotency), which is acceptable given read-only and no params.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first packs the core return value and format, the second gives the recommended usage order. No filler, front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, a readOnlyHint annotation, and an output schema present, the description covers all an agent needs: what it returns, in what format, and when to call it relative to its sibling. No missing invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add to the schema. The schema coverage is 100% (vacuously) and the description correctly focuses on purpose rather than inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Returns'), a concrete resource ('complete specification for calaf_seed'), and the output format (markdown). It also distinguishes itself from sibling validate_seed by framing this as the spec to read before authoring. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use this tool ('Read it before authoring') and names the alternative for the next step ('then check your draft with validate_seed'). It provides a clear sequence and excludes misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Runs a draft seed document through the exact parser the Calaf app imports with. Pass the entire JSON document as a string. Returns per-section counts and the precise issue list (path, severity, message): severity "error" means nothing imports; "dropped" means that row or field is discarded and the rest lands. Fix the issues and validate again until clean before delivering the file to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | The complete seed JSON document — as text, or as the JSON object itself. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| counts | Yes | |
| issues | Yes | |
| hasVocab | Yes | |
| hasPlanner | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint:true indicates no side effects, and the description does not contradict that. It explains the return format (per-section counts and issue list), the meaning of severity levels 'error' and 'dropped', and the iterative validation process, providing full transparency about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough, covering purpose, usage, return details, and the validation workflow in a few well-structured sentences. It does not waste words and focuses on essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is quite complete. It mentions the return counts and issues, explains severity, and advises iterating until clean. It does not need to detail the seed format itself since that is covered by the sibling get_seed_format, but it could explicitly mention that the tool is read-only; however, the annotation covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description and schema both clarify the single parameter 'seed' as the complete seed JSON document, either as a string or an object. This fully explains what is expected, with 100% schema description coverage and no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it runs a draft seed document through the exact parser used by the Calaf app, which is a validation operation. It is distinct from the sibling tool get_seed_format, which presumably provides the format, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: after drafting a seed file, validate it and fix issues until clean before delivering. It gives clear instructions to pass the entire JSON document and implies it is the validation step, though it does not explicitly mention the alternative get_seed_format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_seed_format1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "markdown": {
+ "type": "string"
+ },
+ "uri": {
+ "description": "Where the same document lives as a resource.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "uri",
+ "markdown"
+ ],
+ "type": "object"
+}get_seed_formatvalidate_seedSimulate farms, validate GardenScript and compare policies with Rust. No outbound LLM calls.
Run AI agent evaluations on your own model keys, and publish runs others can review and re-run.
Verify PyPI and npm packages, symbols, and version diffs against real artifacts. Free, no account.
Stamp content with permanent, verifiable provenance. Hash locally, verify free forever.
Add one secure layer between your agents and this server.