Official Duck Framework MCP server for AI-assisted development and project scaffolding.
Scored across 13 tools
Most tools have distinct purposes: docs discovery (list_doc_categories, search_docs), guide retrieval (get_ai_guides, fetch_ai_guide), structure lookups, and scaffolding are clearly separated. The three structural tools (get_blueprint_locations, get_blueprint_structure, get_project_structure) and the get_ai_guides/fetch_ai_guide pair could momentarily be confused, but descriptions clarify the boundaries.
All names are snake_case verb_noun (get_*, list_*, scaffold_*, lint_*, plan_*, search_*, reindex_*), which is highly readable and predictable. The minor inconsistency is the get_ai_guides/fetch_ai_guide pair mixing the verbs get and fetch for a complementary list/retrieve flow.
13 tools is well within the appropriate range and each earns its place across the documentation, structure, scaffolding, and validation lifecycle. No obvious redundant or filler tools.
The surface covers discovery, search, guide fetching, structural reference, scaffolding, linting, and feature planning—a strong end-to-end flow for a framework coding assistant. Minor gap: there is no explicit tool to fetch the full content of a specific documentation page surfaced by search_docs or list_doc_categories, which could be a dead end when guides don't cover a topic.
Fetch an official Duck Framework AI guide. Use this after get_ai_guides() to retrieve the full guide content for AI-assisted Duck Framework development. Always read the relevant guide before generating code instead of relying on memory.
| Name | Required | Description | Default |
|---|---|---|---|
| guide | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral load. 'Fetch'/'retrieve the full guide content' signals a non-mutating read and that the response is the guide body, but nothing is said about error behavior for an unknown guide name, content size, or whether the content is truncated or paginated.
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?
Four short lines, purpose front-loaded, then workflow, then a usage injunction. Every line carries information; only the 'instead of relying on memory' clause is slightly redundant with the preceding sentence.
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?
Simple one-parameter tool with no output schema, and the description tells the agent what the return is (full guide content) plus the workflow that precedes it. The remaining gap is the accepted form of the guide identifier, which is the one thing an agent must get right.
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?
There is one required parameter, `guide`, at 0% schema description coverage, so the description must compensate. It implies the value comes from get_ai_guides() but never states the identifier format (title, slug, id) or that an unrecognized value fails, leaving the central input under-specified.
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?
Specific verb + resource: 'Fetch an official Duck Framework AI guide' and 'retrieve the full guide content'. It also names the sibling get_ai_guides(), making the list-vs-fetch split clear. Slightly short of a 5 because it never explicitly frames what a 'guide' is beyond being a pre-existing item from that listing tool.
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?
Explicit sequencing: 'Use this after get_ai_guides()' and a directive to read the guide before generating code rather than relying on memory. This is clear positive guidance; no exclusion case (e.g., when not to bother fetching) is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Duck Framework AI guides. Use this to discover available guides before fetching one with fetch_ai_guide(). Returns guide identifiers and their descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose the return content ('guide identifiers and their descriptions') plus the two-step discovery pattern. It omits side details such as ordering or whether the list is large enough to paginate, but for a zero-parameter read-only listing this is solid coverage.
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?
Three short sentences, front-loaded with the purpose and immediately followed by the when-to-use cue and the return shape. No filler sentences.
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?
There is no output schema, and the description compensates by stating what comes back (identifiers and descriptions). Combined with the named follow-up tool and empty parameter set, an agent has everything needed to call it and act on the result.
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 takes no parameters and the schema is empty, so there is nothing to disambiguate; the baseline for zero-parameter tools applies.
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?
States a specific verb and resource ('List available Duck Framework AI guides') and scopes it clearly enough that an agent can separate it from fetch_ai_guide, which retrieves a single guide.
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?
Gives an explicit workflow rule: use this to discover guides before fetching one with fetch_ai_guide(). It names the alternative tool and the condition that selects it, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain where Duck Framework blueprints can be located. Describes the supported blueprint layouts and when each organization approach is appropriate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but 'Explain'/'Describes' does imply a read-only, informational result with no side effects, which is the key safety signal. It does not say what the response looks like (free text vs. structured list of paths), leaving a meaningful gap for a tool with zero structured metadata.
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 short sentences, with the core purpose front-loaded. There is mild redundancy between 'where blueprints can be located' and 'supported blueprint layouts', but nothing that wastes real space.
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?
For a zero-parameter documentation lookup with no output schema and no annotations, the description covers what topic is answered but not the shape of the answer or how it relates to sibling doc tools. Adequate but with clear gaps given the crowded sibling set.
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 takes no parameters at all, so there is nothing for the description to disambiguate and the schema is effectively complete. Baseline 4 applies.
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 uses a clear informational verb (explain/describe) and names the resource precisely: where Duck Framework blueprints can be located, plus the supported layouts. It does not, however, distinguish this from the very similar sibling get_blueprint_structure, which an agent could easily confuse with this tool.
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 phrase 'when each organization approach is appropriate' describes the content returned, not when an agent should call this tool. There is no guidance on when to pick this over get_blueprint_structure, search_docs, or fetch_ai_guide, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the standard internal structure of a Duck Framework blueprint. Use this before generating a new blueprint or adding files to an existing one to understand where components, pages, templates, automations, and views belong.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden. 'Return' implies a safe read operation and the description identifies the kinds of components included, but it says nothing about output format, whether the structure is static or generated dynamically, or any operational constraints.
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 two tight sentences, front-loaded with what the tool returns and followed by when to use it. Every sentence earns its place and there is no filler.
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?
For a zero-parameter, annotation-free informational tool, the description is nearly complete: it explains the resource, the domain, and the calling context. It could say slightly more about what the returned structure contains beyond the category list, but no output schema exists to carry that burden.
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 takes zero parameters, so there are no parameter semantics to explain. Per the baseline for parameterless tools, a 4 is appropriate because there is nothing the description could meaningfully add about inputs.
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 states a specific verb and resource: it returns the standard internal structure of a Duck Framework blueprint. That clearly distinguishes it from generic project scaffolding, but it does not explicitly contrast itself with the closest sibling, get_project_structure.
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?
It gives a clear usage context: call this before generating a new blueprint or adding files to an existing one. It does not name an alternative tool or say when not to use it, so it falls short of the explicit when/when-not standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a built-in Duck Framework component API. Returns the confirmed import path, container type, and supported keyword arguments for a component without requiring the full HTML components guide to be loaded. Use this before using any component that has not already been confirmed. Returns close-name suggestions when the component does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| component_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it discloses the return payload fields and the failure behavior (close-name suggestions when the component doesn't exist). What it omits is whether this is strictly a read-only lookup or whether it touches a live index/network, which would matter for a tool with zero annotation coverage.
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?
Four short sentences with the capability stated first and the usage rule second; nothing is padding. Slight redundancy between 'without requiring the full HTML components guide' and the following usage sentence keeps it from a 5.
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?
There is no output schema, so the description correctly spells out the return shape (import path, container type, keyword args) and the miss behavior, which is what an agent needs to consume results. The remaining gap is the accepted format of the component name input.
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 single parameter `component_name` has 0% schema description coverage, so the description must compensate. It hints at exact-name semantics by warning that close-name suggestions appear on miss, but it never states formatting rules such as exact spelling, casing, or whether category prefixes are accepted.
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?
States a specific verb and resource ('look up a built-in Duck Framework component API') and enumerates exactly what comes back: import path, container type, and supported keyword arguments. This clearly separates it from doc-search siblings like search_docs or fetch_ai_guide, which retrieve prose rather than a confirmed API record.
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?
'Use this before using any component that has not already been confirmed' is an explicit when-to-use rule, and the second sentence implies the alternative (loading the full HTML components guide) is heavier. No explicit when-not or named sibling alternative, so it stops 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.
Return the standard Duck Framework project directory structure. Use this before creating or modifying projects to understand where files and directories belong.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. 'Return' signals a read-only, side-effect-free lookup, which is the key behavioral fact. However, it does not describe cost, caching, or the shape of what comes back (tree, list of paths, descriptions), leaving some gaps for a no-annotation tool.
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 short sentences, zero filler, and the core action is front-loaded before the usage note. Every sentence earns its place.
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?
There is no output schema, so the description is the only source of information about the return value. It conveys the general content (standard project directory layout) but not its form or granularity, which matters for an agent that needs to parse it. Adequate but with a clear gap.
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 takes zero parameters, so the baseline is 4. Nothing in the description misrepresents or omits parameter behavior, and there is nothing for the description to compensate for.
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?
States a specific verb and resource: it returns the Duck Framework project directory structure. It is clearly distinct from scaffold_project and get_blueprint_structure by name, though it never explicitly contrasts itself with get_blueprint_structure, which returns something structurally similar.
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?
Gives clear timing guidance: 'Use this before creating or modifying projects.' That implies the alternative (scaffold_project) and the precondition for calling this one. No explicit exclusions or ordering relative to get_blueprint_structure are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Duck Framework component or page code for common mistakes. Detects known patterns such as incorrect component imports, invalid page imports, incorrect Heading usage, leading-underscore method names, and separator comments. This is a pattern check for known issues, not a complete correctness validator. An empty result only means no known issues were detected. Run this on generated component code before presenting it as final.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the false-negative risk ('empty result only means no known issues were detected') and that the check is pattern-based rather than semantic. It does not describe the shape of a non-empty result (issue list, severities, line references), which is the remaining gap.
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?
Purpose is front-loaded in the first sentence, followed by the detection list, then the limitation caveat, then the call to action. Every sentence serves a purpose; the pattern enumeration is slightly long but earns its place by setting expectations.
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?
For a one-parameter, no-output-schema lint tool, the definition covers what it does, its limits, and when to call it. Only the result format for a non-empty response is unstated, which is a minor omission given no output schema exists.
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?
Schema coverage is 0% for the single 'code' parameter, so the description must compensate. It implies the input is component or page source, but does not say whether a full file (with imports/export) or a fragment is expected, nor whether page vs component code changes behavior.
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?
States a specific verb+resource (check Duck Framework component or page code) and enumerates the concrete mistake classes it detects (bad component/page imports, Heading usage, leading-underscore methods, separator comments). No sibling tool performs code linting, so an agent can route here unambiguously.
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?
Gives an explicit trigger: 'Run this on generated component code before presenting it as final.' It also sets a negative boundary by saying it is not a complete correctness validator. It does not name an alternative tool for deeper validation, but no sibling offers one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Duck Framework documentation categories and their pages. Use this when browsing available documentation without a specific search query.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It discloses that this enumerates ALL categories (a complete, non-paginated-looking listing) but says nothing about whether it is read-only, how version selection alters results, or the shape and size of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero filler, with the action front-loaded and the usage cue following. Nothing is redundant.
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?
For a simple single-parameter listing tool the description is adequate on purpose and usage, but leaves the only parameter unexplained and provides no output schema, so the agent must call it blind on version semantics.
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?
There is one parameter, version, with 0% schema description coverage, and the description never mentions it. An agent cannot tell whether version scopes the categories to a specific documentation release or whether omitting it defaults to latest.
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?
States a specific verb and resource: listing Duck Framework documentation categories together with their pages. The 'without a specific search query' clause implicitly separates it from search_docs without naming it, so the distinction is clear in substance but not explicit.
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?
Gives a concrete usage condition: browse when you have no specific query. The alternative (search_docs) is only implied rather than named, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a Duck Framework feature request and create an implementation plan. Returns relevant documentation to read and a suggested order of operations before writing code. Use this before implementing non-trivial Duck Framework features.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | ||
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the shape of the result (documentation list plus suggested order of operations) and implies it is a pre-implementation, non-mutating analysis step, but never explicitly states that it writes nothing, requires no auth, or how it treats the version parameter.
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?
Three short sentences, front-loaded with the core action and followed by the return shape and the usage trigger. No filler; only the missing parameter guidance counts against it.
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?
No output schema and no annotations, so the description does a fair job explaining what comes back, but gaps remain on parameter meaning (notably version) and on side effects or prerequisites. Adequate but not complete for a planning tool with two undocumented parameters.
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?
Schema coverage is 0%, so the description must compensate, and it barely does. The meaning of "request" can be inferred, but "version" is completely unexplained (Duck Framework version? target version?), leaving a real ambiguity for the caller.
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?
States a specific verb+resource: analyzes a Duck Framework feature request and produces an implementation plan, including docs to read and ordering of work. This clearly separates it from the doc-retrieval and scaffolding siblings, though it doesn't explicitly name them.
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?
"Use this before implementing non-trivial Duck Framework features" gives a clear trigger and an implicit exclusion (trivial features). It doesn't call out alternatives or what to do after the plan, but the timing guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild the Duck Framework documentation index. Crawls the live documentation sitemap for a given version and merges the result in: curated tags/summary/category are preserved, new pages are added, and pages no longer in the sitemap are removed. Requires the admin scope.
| Name | Required | Description | Default |
|---|---|---|---|
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the merge policy (curated tags/summary/category preserved, new pages added, stale pages removed) and the admin-scope requirement. It still omits cost/duration, whether the crawl is rate-limited or can fail partway, and whether removals are reversible.
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?
Four short sentences, front-loaded with the action, then mechanism, then merge semantics, then the auth prerequisite. Every sentence adds information an agent needs; nothing repeats structured fields.
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?
For a single-parameter, no-output-schema mutation tool, the description covers purpose, side effects, and authorization. The remaining gap is the optional version parameter's default and what the tool returns or reports on failure — relevant because there is no output schema to fall back on.
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?
Schema coverage is 0% and there is one optional parameter, so the description must compensate. 'For a given version' gives partial meaning, but does not state the expected format, valid values, or what happens when version is omitted (required list is empty), leaving the default behavior undocumented.
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?
States a specific verb and resource ('Rebuild the Duck Framework documentation index') and immediately explains the mechanism (crawl live sitemap for a version, merge in). This is clearly distinguishable from read-only siblings like search_docs and list_doc_categories, which only consume the index this tool builds.
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?
Usage is only implied — an agent can infer this is the refresh operation for a docs index, but the description never says when to call it versus search_docs or list_doc_categories, nor when not to (e.g. avoid running concurrently with other index consumers). No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a new Duck Framework blueprint. Generates a blueprint structure containing blueprint.py, views.py, and optional UI, template, and static directories following the documented Duck blueprint conventions. Returns generated file contents and the settings configuration needed to register the blueprint. This tool does not write files.
| Name | Required | Description | Default |
|---|---|---|---|
| urlpatterns | No | ||
| blueprint_name | Yes | ||
| enable_static_dir | No | ||
| enable_template_dir | No | ||
| prepend_name_to_urls | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the single most important trait: "This tool does not write files" — it returns generated file contents plus the settings configuration to register the blueprint. That prevents a false assumption that scaffolding mutates the project on disk. It stops short of stating overwrite/idempotency behavior or error conditions, which is why it is not a 5.
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?
Four short sentences, front-loaded with the action and followed by concrete output artifacts. The final sentence about not writing files is high-value and earns its place; there is minor redundancy between "Generates a blueprint structure" and the file list.
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?
It covers the return shape well enough that the absence of an output schema is tolerable (file contents plus settings config), and the no-write disclosure is important. But with 5 parameters, 0% schema documentation, and no annotations, the definition leaves too much of the invocation surface unexplained to be complete.
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?
Schema description coverage is 0% and all five parameter names are bare, so the description must compensate — and it effectively does not. It never mentions urlpatterns, prepend_name_to_urls, or that enable_static_dir/enable_template_dir are (oddly) typed as strings rather than booleans; the only weak linkage is "optional UI, template, and static directories." An agent cannot determine value formats from this text.
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 gives a specific verb and resource ("Scaffold a new Duck Framework blueprint") and enumerates the concrete artifacts produced (blueprint.py, views.py, optional UI/template/static dirs), so the purpose is unambiguous. It does not explicitly position itself against near siblings such as scaffold_project or get_blueprint_structure, which keeps it at 4 rather than 5.
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?
Usage is only implied: the name and the phrase "new ... blueprint" suggest it is for creating fresh blueprint scaffolding, and naming conventions imply the get_* siblings are for inspecting existing ones. There is no explicit when-to-use/when-not-to-use statement or named alternative, so an agent must infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a new Duck Framework project. Returns the required CLI commands and generated file contents for supported features with confirmed APIs. Unsupported features return documentation guidance instead of generated code to avoid guessing framework APIs. This tool does not write files. It only returns generated content for the calling client to add to the user's project directory.
| Name | Required | Description | Default |
|---|---|---|---|
| features | No | ||
| project_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: it explicitly says the tool does NOT write files, that output is content for the client to place, and that unsupported features degrade to documentation guidance instead of guessed APIs. This pre-empts the most likely misuse of a 'scaffold' tool.
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?
Four short sentences, front-loaded with purpose, then fallback behavior, then the non-writing constraint. Each sentence adds information an agent needs and none restate the title or name.
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?
No output schema exists, and the description partially compensates by describing the return shape (CLI commands + file contents). However, for a tool whose `features` parameter gates which APIs are supported, the absence of any list or pointer to the supported feature set leaves a real gap.
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?
Schema coverage is 0%, so the description must define both parameters, and it only gestures at `features` ("supported features with confirmed APIs") without saying what values are valid or that it is a free-form string. `project_name` is never addressed at all, leaving naming constraints undocumented.
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?
States a specific verb and resource ("Scaffold a new Duck Framework project") and immediately clarifies what is returned: CLI commands plus generated file contents. That distinguishes it from read-only siblings like get_project_structure, though it never contrasts itself with the closely named scaffold_blueprint.
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?
Usage is implied by the domain (start a new project), and the guidance that unsupported features yield documentation rather than code tells the agent what happens in the edge case. But no explicit when-to-use/when-not, and no routing to alternatives such as scaffold_blueprint or plan_feature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-search the Duck Framework documentation. Use this whenever the correct documentation page for a feature is unknown. Returns ranked matches containing title, URL, category, summary, and relevance score.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No | ||
| version | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden; it does disclose fuzzy ranked matching and the return fields (title, URL, category, summary, relevance score), which is real value. It says nothing about indexing freshness/reindex interaction, ranking behavior details, or whether results are version-scoped.
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?
Three short sentences: purpose first, usage condition second, return shape third. Nothing redundant, nothing buried.
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?
The return-value gap is covered since no output schema exists, and usage is framed well. However, for a tool with four undocumented parameters and no annotations, omitting any parameter guidance leaves an agent guessing on filtering and result-count semantics.
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?
Schema description coverage is 0% across four parameters, so the description must compensate and does not: it never mentions query, top_k, version, or category. Notably top_k is typed as a string, and the description offers no clarification on its acceptable values, nor on what version/category restrict.
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?
States a specific verb and resource ("Fuzzy-search the Duck Framework documentation") and even specifies the matching mode (fuzzy, ranked). It implies a contrast with direct-lookup siblings like get_component_api but never names one, so differentiation is inferred rather than stated.
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?
"Use this whenever the correct documentation page for a feature is unknown" is a genuine when-to-use condition that routes discovery-style queries here. No explicit when-not or named alternative (e.g., list_doc_categories for browsing) is given.
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.
fetch_ai_guideget_ai_guidesget_blueprint_locationsget_blueprint_structureget_component_apiget_project_structurelint_component_codelist_doc_categoriesplan_featurereindex_docsscaffold_blueprintscaffold_projectsearch_docsOfficial MCP server for Lovable, the AI-powered full-stack app builder.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
An MCP server that gives your AI access to the source code and docs of all public github repos
Add one secure layer between your agents and this server.
