Webflow MCP Server

Server Quality Checklist

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

Latest release: v0.7.0
Disambiguation4/5
Most tools are clearly grouped by resource (collections, components, pages, sites, scripts), but there is potential confusion between live vs draft item operations (create_item_live vs create_item) and between registered vs applied scripts. The descriptions help differentiate, but some tools like delete_all_site_scripts lack a description.
Naming Consistency3/5
The naming mostly follows a resource_verb_noun pattern, but there are inconsistencies: 'collection_fields' vs 'collections_items' (singular vs plural), redundant 'items' in 'collections_items_create_item_live', and script tools use a mix of 'site_' prefix and verb-first names like 'add_inline_site_script'.
Tool Count2/5
With 32 tools, this is above the typical threshold of 25, making it feel heavy for an agent to navigate. While each tool serves a specific Webflow API operation, the sheer number likely overwhelms agents, though it is justified by the platform's complexity.
Completeness3/5
The tool set covers most CRUD operations for collections, items, pages, and components, but lacks a dedicated get_item tool, field deletion, and script application (only registration and all-deletion). The ask_webflow_ai tool may help fill some gaps, but there are notable missing operations.
Average 3.4/5 across 32 of 32 tools scored. Lowest: 1/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
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It gives no details about response format, latency, side effects, or limitations. The description is a generic tagline with zero behavioral information.
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 short sentence, which is concise and front-loaded. However, it is so brief that it omits essential information, though there is no fluff or redundancy. As a concise statement it earns a moderate score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must fully explain what the tool does and returns. It only states 'ask about anything related to Webflow API,' which is insufficient for an agent to know what to expect. The description is not complete for a tool that serves as an AI assistant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'message' is a raw string with no schema description coverage. The description does not explain what to put in the message or whether it accepts plain language, API references, etc. It fails to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('ask') and target ('Webflow AI'), but it is extremely vague about the scope and capabilities. It doesn't distinguish this tool from the many specific CRUD siblings, making it unclear when to choose this over a targeted 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?
There is no guidance on when to use this tool versus the alternative sibling tools. The phrase 'anything related to Webflow API' is too broad to provide actionable selection criteria. No exclusions or prerequisites are mentioned.
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 full burden of disclosing behavioral traits. It only repeats the 2000-character limit, which is already present in the schema. It does not disclose whether registration is idempotent, whether duplicates are overwritten, or any permission requirements, leaving significant behavioral ambiguity for a mutation tool.
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 appropriately concise at two short sentences. However, the second sentence about character limits is redundant with the schema. Still, it is well-structured and front-loaded with the primary purpose, earning a slightly above-average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a rich schema but no annotations or output schema, the description should provide more context about side effects, return behavior, or how it fits into the broader script-management workflow. It only states the action and a constraint, which is insufficient for an agent to confidently assess the tool's full impact.
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, so the baseline is 3. The description adds no additional meaning to the parameters beyond what is already in the schema. The 2000-character limit is redundantly stated, and no parameter-specific usage nuances are provided.
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's action: 'Register an inline script for a site.' This is a specific verb+resource pairing that distinguishes it from sibling tools like 'site_registered_scripts_list' or 'delete_all_site_scripts'. However, it does not explicitly contrast with other add/modify tools, so it misses the full 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, such as listing or deleting scripts. The only constraint mentioned is the 2000-character limit, which is a limitation rather than usage context. There is no mention of prerequisites, exclusions, or typical scenarios.
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, the description carries the full burden of behavioral disclosure. It only says 'List items with optional filtering and sorting' but omits crucial behavior such as pagination (limit/offset), the max limit of 100, default sort order, and the response structure. It does not contradict anything but adds minimal value beyond the verb.
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, front-loaded sentence with no redundancy, making it highly concise. It could be more informative, but every word earns its place in stating the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters and no output schema or annotations, the description is too sparse. It does not explain pagination behavior, default limits, how filtering is actually performed, or what the response looks like. These are significant gaps for a read operation, leaving the agent to infer critical details from the schema alone.
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 every parameter (name, slug, limit, offset, sortBy, sortOrder, cmsLocaleId, collection_id) already has a description. The description's reference to 'filtering and sorting' loosely maps to sortBy/sortOrder but does not clarify how filtering works (since no filter parameter exists), and it adds no new parameter-level meaning.
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 action ('List items') and the resource ('CMS collection'), which separates it from sibling create/update/delete/publish tools. However, it mentions 'optional filtering' but the schema only includes sorting parameters, not explicit filter fields, so the capability is slightly overstated.
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 states the core usage scenario (listing items in a collection) but provides no explicit guidance on when to use this versus alternatives, nor does it mention exclusions. Since there is no other list-items sibling, the context is implied, but the description does not proactively differentiate or set expectations.
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 must carry the burden of explaining behavior. It merely says 'update properties' without disclosing whether the update is partial or full, whether missing properties are left unchanged, or any side effects. This is minimal transparency for a mutation tool.
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 front-loads the main purpose. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too sparse. It does not explain the semantics of the request object (e.g., partial update behavior), what happens if the field does not exist, or what response to expect. The tool has a nested parameter object, so more context is needed for correct invocation.
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 description coverage is 100%, so the baseline is 3. The description does not add parameter details, but the schema already fully documents collection_id, field_id, and the request object with its nested properties. No additional value is needed.
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 'Update' and the resource 'properties of an existing field in a CMS collection', which distinguishes it from sibling create tools. It is specific and unambiguous.
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 about when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or suggest create tools for new fields. The only hint is the word 'existing', but it's not explicit.
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?
There are no annotations, so the description carries the full burden. It does disclose a key behavioral trait—items are created as drafts, not published—which is useful context. However, it does not mention permissions, reversibility, validation requirements, or return behavior, leaving significant gaps for a mutation tool.
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, front-loaded sentence with no wasted words. It states the core action and the draft state clearly. It is concise, though perhaps too brief to cover necessary detail—but that lack is captured by other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested parameter schema and no output schema or annotations, the description is critically incomplete. It offers no explanation of required fields, item structure, or expected behavior beyond the draft status. A tool with this complexity needs far more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter guidance. It does not explain what collection_id refers to, nor the structure of request, items, or fieldData. The nested schema with required fields (name, slug) is completely unaddressed, failing to help the agent construct a valid request.
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: creating new items in a CMS collection, specifically as drafts. The verb 'create' is specific, the resource is identified ('items in a CMS collection'), and the draft qualifier distinguishes it from the sibling tool collections_items_create_item_live.
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 for draft creation via 'as drafts', but does not explicitly mention when to use this tool versus alternatives (e.g., collections_items_create_item_live). No exclusions or conditions are stated, leaving the distinction implicit rather than explicit.
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 merely says 'Update' without disclosing side effects, permissions, return values, or whether properties are replaced incrementally or wholesale. The localization context adds some meaning but lacks behavioral detail.
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, direct sentence that communicates the core purpose without any waste. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, this description is incomplete. It does not explain return behavior, update semantics, locale requirements, or any constraints. The schema covers parameters well, but the missing context makes it hard for an agent to anticipate results or side effects.
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 parameters are described in the schema (100% coverage), so the description adds little beyond the schema. It references localization and locales, but does not clarify parameter formats or relationships beyond what is already in 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 action ('Update') and resource ('component properties') with a specific purpose ('for localization'). It distinguishes from likely content updates, but does not explicitly contrast with sibling tools like components_update_content.
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 localization scenarios ('customize behavior in different languages') but provides no explicit when-to-use guidance, exclusions, or alternatives. Related sibling tools exist, so more explicit differentiation would improve this.
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 full burden of behavioral disclosure. It only states 'Update' without explaining that this is a mutation, whether it overwrites existing settings, whether all fields are required or partial updates are allowed, or any permission/versioning considerations. The description adds no operational context beyond the bare 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 concise sentence that immediately states the action and key targets. It is front-loaded and contains no filler, making it easy to parse and remember. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (nested body object, 3 parameters, no output schema, no annotations), the description is far too sparse. It does not explain return values, error behavior, whether the operation is idempotent, or how it integrates with related tools like pages_get_metadata. The short description leaves many critical operational gaps.
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 lists some fields (SEO, Open Graph, slug, publishing status) that map to properties in the body schema, adding modest semantic grouping. However, the schema itself already describes all parameters in detail, and the description does not clarify relationships like the duplication between top-level 'page_id' and body.id, or when the localeId parameter should be used. Its contribution is partial but not trivial.
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 a specific action ('Update') on a specific resource ('page settings') and enumerates concrete fields (SEO metadata, Open Graph data, slug, publishing status). This distinguishes it from sibling tools like 'pages_update_static_content' or read-only metadata tools, fulfilling the verb+resource+scope criterion.
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 does not mention that it should be used for settings changes rather than content edits, nor does it note any prerequisites like ensuring the page exists or whether the tool supports partial updates. The usage context is entirely unaddressed.
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 must disclose behavioral traits. It only says 'Create' with no details about permissions, idempotency, side effects, or response format. For a mutation tool, this is a significant gap.
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 no wasted words. The examples are inline and helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested request object with required subfields and an enum of types, yet the description offers no guidance on constructing the request, return values, or prerequisites. With no annotations or output schema, the description is insufficient for a tool of this 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?
Schema coverage is only 50% (the 'request' parameter lacks a top-level description). The description gives field type examples (text, number, date) that map to the 'type' enum, but it does not explain the required structure of the 'request' object (e.g., that it must include 'type' and 'displayName'). It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('a new static field in a CMS collection'), and gives examples of field types. This distinguishes it from sibling tools like collection_fields_create_option and collection_fields_create_reference, which handle non-static field types.
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?
No explicit when-to-use or alternative guidance is provided. The word 'static' implies use for static vs. other field types, but the description does not explicitly direct users to sibling tools for non-static cases. Usage is implied rather than stated.
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 says 'Create' and gives no information about side effects, uniqueness constraints, error conditions, or whether the operation is reversible. The mention of 'schema' is ambiguous and not backed by any schema field in the input.
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 sentence that is direct and front-loaded with the action. There is no unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a nested request object and no annotations or output schema. The description is too minimal to fully guide an agent on constructing a valid request or understanding what happens after creation. The word 'schema' could mislead an agent into looking for a schema parameter that doesn't exist.
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 description adds no meaningful explanation of parameters beyond what the schema already provides. It refers to 'name and schema', but the input schema has displayName, singularName, and slug; there is no 'schema' parameter. The request object itself lacks a description, and the description does not compensate for this gap.
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 action ('Create') and the resource ('a new CMS collection in a site'), which distinguishes it from sibling tools like collections_list or collections_get. The verb+resource combination is specific and unambiguous.
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 ('you use this when you want to create a collection') but provides no explicit guidance on when not to use it or how it compares to alternatives. No exclusion criteria are mentioned.
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 transparency burden. It clearly indicates a read-only operation and specifies the returned information, but it does not disclose error behavior, required permissions, or side effects (e.g., whether the collection must exist or if unpublished schemas are included).
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 wasted words. It efficiently states the action, resource, and scope of returned data.
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 get operation with one parameter, the description covers the core purpose and return content. However, the absence of an output schema and annotations means the agent gets no information about output structure, errors, or authorization constraints, leaving notable gaps.
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 100% and the single parameter collection_id is already described in the schema. The description adds no new parameter semantics beyond confirming that the tool targets a specific collection.
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 uses a specific verb ('Get') and identifies the resource ('a specific CMS collection') plus the return content ('schema and field definitions'). This clearly distinguishes it from sibling tools like collections_list, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not explain, for example, that collections_list should be used to find collection IDs, or that this tool is for retrieving full detail for one collection.
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 carries the full burden of behavioral disclosure. It states the core action but omits important details such as permission requirements, reversibility, idempotency, or response format. The phrase 'make them live' conveys the transition but little else.
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 sentence that communicates the action and result without unnecessary words. It is well-structured and front-loaded with the verb.
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 two-parameter mutation tool, the description covers the basic action, but it lacks usage guidance and behavioral context. Since there is no output schema and no annotations, the description could do more to explain expected outcomes, prerequisites, and edge cases. However, the schema fills in parameter details, so the description is minimally 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 already provides complete descriptions for both parameters (collection_id and itemIds), covering 100% of the parameters. The description adds no extra parameter-level syntax or constraints beyond what the schema provides, so it meets the baseline but does not exceed it.
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 'Publish' and clearly identifies both the resource ('draft items in a CMS collection') and the outcome ('make them live'). This distinguishes it from sibling tools like create_item_live or update_items_live, which operate on live items directly.
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 choose this tool over alternatives such as collections_items_create_item_live or sites_publish. It lacks any prerequisites, exclusions, or alternative tool names.
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 disclosure burden. It states 'update and publish existing items' but does not mention consequences like slug changes breaking links (only in schema), permission requirements, or reversibility. 'Directly to the live site' hints at permanence 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the action ('Update and publish') and includes the scope ('existing items... directly to the live site'), making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested request array, publish semantics, multiple sibling tools), the description is insufficient. It does not cover bulk update behavior, validation rules, return values, or the difference from draft-only updates. The schema provides some structure, but the description omits crucial operational context.
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 description adds no parameter-level meaning. It does not explain the 'request' structure, how to specify items to update, or the role of 'collection_id'. With schema description coverage at 50%, the description should compensate but fails to do so.
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 updates and publishes existing CMS items directly to the live site. It uses a specific verb and resource, distinguishing it from siblings like 'collections_items_update_items' (likely draft-only) and 'collections_items_publish_items' (publish without update).
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 phrase 'directly to the live site' implies immediate publication, but no explicit alternatives or when/when-not guidance is given. The description does not compare this tool to 'collections_items_update_items' or 'collections_items_publish_items', leaving the agent to infer the intended use case.
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 a create operation, but does not disclose any side effects, permissions, idempotency, or what happens with existing options. It also doesn't mention return value or error behavior. Minimal 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?
A single sentence with no redundant words. It is appropriately concise and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex nested schema and no output schema, the description is extremely brief. It does not explain the structure of 'request' or required fields, nor does it mention return values or usage context. The tool would be hard to invoke correctly from the description alone.
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 50% (the top-level 'request' property lacks a description), but the schema provides detailed descriptions for all nested fields. The description adds only the hint 'predefined choices,' which maps to metadata.options. This is helpful but does not significantly compensate for the missing request description.
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 action: create a new option field in a CMS collection with predefined choices. The verb 'create' is specific, and the resource 'option field' distinguishes it from sibling tools like collection_fields_create_static and collection_fields_create_reference.
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 the tool is for option fields with predefined choices, which gives some indication of when to use it, but it does not explicitly mention alternatives or corner cases. It lacks explicit guidance on when to choose this over create_static or create_reference.
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 for behavioral disclosure. It confirms a create mutation but says nothing about required prerequisites (e.g., both collections existing), validation rules, idempotency, permissions, or what response the caller should expect.
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 filler. Every phrase contributes meaning, and it is appropriately concise for the tool's role.
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 schema provides required field details and the description clarifies the field purpose, making invocation feasible. However, with no annotations, no output schema, and no behavioral caveats, the description is only minimally complete for a mutation tool with a nested request object.
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 coverage is low (50%) and the description adds only a high-level conceptual mapping (reference field = another collection) rather than clarifying the nested `request` object or the relationship between `type` and `metadata.collectionId`. Most parameter semantics must be inferred from the schema, not the description.
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 ('Create') and resource ('reference field in a CMS collection'), and explicitly states the linking purpose ('links to items in another collection'), which distinguishes it from sibling field-creation tools like create_static or create_option.
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 this tool is for creating relational/link fields between collections, but it does not provide explicit when-to-use guidance, exclusions, or name alternative tools for non-reference fields.
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, the description carries the full burden of behavioral disclosure. It only states that it 'gets properties' and includes default values/configuration, but does not explain pagination via limit/offset, locale handling, or whether results are a list or object. It also doesn't explicitly state it's a read-only operation, though 'Get' implies 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, focused sentence that leads with the verb and object, containing no redundant information. It is appropriately concise for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description is minimal. It doesn't explain the expected return structure, the significance of the limit/offset parameters, or the role of localeId in localization. The presence of multiple optional parameters suggests complexity that the single sentence does not address.
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, with descriptions for all five parameters including limit, offset, site_id, localeId, and component_id. The description adds no additional parameter semantics beyond saying the tool gets 'component properties including default values and configuration,' so it meets the baseline but does not exceed schema information.
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 ('Get') and resource ('component properties'), including scope ('for a specific component') and content ('default values and configuration'). This effectively distinguishes it from sibling tools like components_get_content and components_update_properties.
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 retrieving properties of a specific component but provides no explicit guidance on when to choose this over alternatives such as components_get_content or components_update_properties. No exclusions or alternative references are given, leaving the decision to inference.
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, the description carries the full burden for behavioral disclosure. It states that text nodes and property overrides are modified, but it does not say whether this is an overwrite/merge, whether it is destructive, what permissions are needed, or what happens to unspecified nodes. This is a significant gap for a mutation tool.
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 front-loads the verb and target resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating tool with no annotations, no output schema, and four required parameters. The description is too terse to be fully actionable; it omits side effects, return behavior, and usage context. While the schema covers parameter meanings, the overall description leaves significant gaps.
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 already describes most parameters (site_id, component_id, localeId) and the item structures, with 75% coverage. The description adds the 'secondary locales' context and the concept of text nodes vs property overrides, but does not significantly elaborate beyond the schema, so baseline 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 identifies the action ('Update content'), the target resource ('component in secondary locales'), and the method ('by modifying text nodes and property overrides'). This differentiates it from sibling tools like components_update_properties and page content update functions.
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 this is for updating localized component content, but it does not explicitly state when to use this tool versus alternatives such as components_update_properties or components_get_content. No exclusions or conditional guidance are provided.
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, the description carries the full burden of disclosing behavioral traits. It only states that it makes changes live, but does not mention side effects, reversibility, permission requirements, or what happens if no domains are specified. For a publish action with potentially significant consequences, this is insufficient.
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 short sentences that directly state the tool's purpose and effect. There is no redundant or irrelevant information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters and no output schema, so the description should explain return values and edge cases. It does not mention what the tool returns, how it handles missing customDomains, or the significance of publishToWebflowSubdomain. The brief description leaves significant gaps for an agent trying to invoke it correctly.
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 already provides descriptions for all three parameters (site_id, customDomains, publishToWebflowSubdomain), so the description does not need to add parameter-level detail. The description adds no extra semantics, but the high schema coverage justifies a baseline score of 3.
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 ('Publish') and resource ('site') with a clear scope ('to specified domains'), which clearly distinguishes it from sibling tools like sites_list and sites_get. It effectively communicates 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating that it makes the latest changes live, but it does not explicitly state when to use it versus alternatives or any exclusions. There are no sibling tools with similar publish functionality, so it is not misleading, but it lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait that updates are saved as drafts, but it omits other relevant details such as whether the published version remains unchanged, side effects of slug updates, or required permissions. It adds some value beyond the name but not enough.
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 sentence with a clear verb and resource, no filler, and front-loaded information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a moderate-complexity nested schema, no annotations, and no output schema, the description is too sparse. It fails to explain update semantics (e.g., partial vs. full replacement), behavior on non-existent items, or the full implications of 'as drafts.' An agent would need to rely heavily on the schema, which itself has coverage 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?
The description does not mention any parameter specifics. Schema coverage is only 50%, and the description fails to compensate for undocumented parameters like the structure of the request object. The nested schema provides some field descriptions, but the tool-level description adds nothing to help the agent understand the 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 clearly specifies the action (update), the target (existing items in a CMS collection), and the mode ('as drafts'), which distinguishes it from sibling tools like collections_items_update_items_live. This is a specific verb+resource+mode that leaves little ambiguity.
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 that this tool is for updating items without publishing (as drafts), but it does not explicitly state when to use it over alternatives like the live update tool. It provides context but no explicit exclusions or alternative directions.
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, the description carries the full burden. It implies a read operation but does not disclose pagination behavior (despite limit/offset parameters), the exact return structure, or any side effects. This is a significant gap for a content retrieval tool.
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 filler. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters including pagination controls, but no output schema or annotations. The description fails to explain the return format or how limit/offset work, leaving the agent to discover critical behavior through other means.
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 parameters are well-documented. The description adds minimal semantic value beyond mentioning text, images, and nested components, but does not clarify the role of limit/offset in pagination. Baseline 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 a specific verb ('Get') and resource ('content structure and data for a specific component'), and distinguishes it from sibling tools like components_list and components_update_content by focusing on the content retrieval aspect.
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—when you need the content of a component—but does not explicitly mention alternatives or exclusions. It's sufficient for most cases but lacks explicit '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.
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 does state that the tool returns metadata (not full content) and implies read-only behavior, which is useful. However, it does not mention pagination behavior, request limits, or permission requirements, relying on the schema to surface limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core action and return value. There is no fluff 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?
For a straightforward list tool with a complete schema, the description sufficiently communicates the resource and return fields. It lacks details on default limits or ordering, but these are not critical given the simple read-only nature and schema coverage.
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 no parameter-specific meaning beyond the schema; it only describes output fields, not how parameters affect the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('components in a site') and states the output contains metadata (IDs, names, versions). This clearly distinguishes it from sibling tools like components_get_content or components_update_content.
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 explain when to prefer components_list over components_get_properties or other listing tools, nor does it mention any prerequisites like existence of the site.
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 transparency burden. It indicates a read operation via 'Get' and describes the return as content structure and data, but it does not mention pagination, localization, or any limitations. The read-only nature is implied but not explicit, and response format details are 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 concise sentence of 17 words, front-loaded with the verb and resource. Every word contributes to the core purpose, with no fluff or redundancy, making it appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about response shape and pagination. It mentions 'all elements and their properties' but does not explain how limit/offset affect results or how localeId modifies behavior. This is a significant gap for a data-fetching 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?
Schema coverage is 100%, with descriptions for all four parameters. The description adds only a slight context that it applies to a 'specific page', which maps to page_id, but it does not enrich understanding of limit, offset, or localeId beyond what the schema already provides. Baseline 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 a specific verb ('Get') and resource ('content structure and data for a specific page'). It distinguishes from siblings like pages_get_metadata or pages_list by focusing on page content and elements, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving content of a specific page, but it does not explicitly discuss when to use this tool versus alternatives like components_get_content or pages_get_metadata. It provides clear context ('specific page') but no exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('List') and return fields, but does not disclose pagination behavior (limit/offset), localization, or any side effects. The phrase 'all pages' may be inaccurate if a default limit applies.
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, front-loaded with the action, and no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and return fields, but for a list tool with pagination and locale parameters, it leaves important behavior (paging, localization) unstated. No output schema exists, so more detail would be helpful.
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 100%, so each parameter is already described. The description adds no parameter-specific meaning beyond the schema; it only mentions return fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('pages within a site'), and specifies the return content (metadata including IDs, titles, and slugs). It clearly distinguishes from sibling tools like pages_get_metadata (single page) and collections_list (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 description implies usage for enumerating pages in a site but does not explicitly state when to prefer this over pages_get_metadata or how pagination works. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait: creating and publishing to the live site in one operation, which is a significant side effect. However, it does not mention permission requirements, reversibility, or what happens to the item's draft state, leaving some behavioral ambiguity.
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, focused sentence that is front-loaded with the action and resource. Every word earns its place—there is no padding or redundant information.
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 has two parameters, one nested array, and no output schema. The description conveys the core purpose but does not mention return values, prerequisites (e.g., valid collection_id), or edge cases like slug conflicts. Given the absence of annotations and output schema, more operational context would be needed for full 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 50%, with the 'request' object lacking a top-level description. The tool description does not add any detail about the request structure or how collection_id and request are used, failing to compensate for the coverage gap. The nested schema fields have some descriptions, but the main parameter semantics remain unclear.
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 specific verbs 'create and publish' and identifies the resource 'new items in a CMS collection' with the scope 'directly to the live site'. This clearly distinguishes it from the sibling tool collections_items_create_item (likely draft/pending) and other CMS item tools.
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 'directly to the live site' clearly implies this is for immediate publication, providing strong contextual usage. However, it does not explicitly mention when to use alternatives like collections_items_create_item (for drafts) or collections_items_publish_items (to publish existing items), so exclusions are missing.
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 of behavioral disclosure. It states that the tool returns metadata, which implies a safe read operation, but it does not mention side effects, auth requirements, pagination, or any constraints beyond the site_id parameter. This is adequate but minimal for a simple 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 one concise sentence that is front-loaded with the verb and resource, followed by a clear statement of return values. There is no waste 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?
For a simple list tool with one parameter and no output schema, the description adequately explains the return content (metadata including IDs, names, schemas). It lacks details on pagination or ordering, but these are not critical for a basic list operation. The description is sufficiently complete for the tool's complexity.
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 describes the single parameter 'site_id' with its type and description, achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline of 3 is appropriate as the schema already fully documents the parameter.
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 ('List'), resource ('CMS collections'), and scope ('in a site'). It also details the return content (IDs, names, schemas), which distinguishes it from sibling tools like collections_get that retrieve a single collection.
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—'List all CMS collections in a site'—but provides no explicit guidance on when to use this tool versus alternatives such as collections_get. It offers clear context but no exclusions or alternative recommendations, so it only partially fulfills the guidelines dimension.
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 burden. It discloses the return content (SEO, OG, status) but does not mention side effects, error behavior, or permission requirements. 'Get' implies a safe read, but the description does not explicitly state read-only 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 a single, compact sentence that front-loads the action and resource, with no redundant words 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 read-only metadata tool with well-documented parameters, the description covers the essential function. It could elaborate on the exact response structure, but the absence of an output schema and the straightforward nature keep this at a 4.
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 both page_id and localeId are already documented. The description does not add additional parameter semantics beyond what the schema provides, yielding a baseline score.
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 verb 'Get' with the resource 'metadata for a specific page' and lists specific inclusions (SEO settings, Open Graph data, page status), clearly distinguishing it from sibling tools like pages_get_content or pages_update_page_settings.
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 with a page_id to retrieve metadata) but does not explicitly discuss alternatives or when not to use it. Given the sibling context, the purpose is clear, but no explicit 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?
With no annotations, the description carries the burden. It discloses the update mechanism and scoping to secondary locales, but does not state whether updates are partial or full replacements, whether permissions are required, or how fallback behavior works. Some behavioral context is added, but gaps remain.
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 sentence that is direct and front-loaded with the action. No redundant words 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?
The tool has a nested anyOf array, and while the description is brief, it provides the essential intent and scoping. The schema covers parameter details. The only notable gap is the lack of behavioral details on update semantics, but the combined description and schema provide sufficient context for an AI agent.
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 67% (page_id and localeId described, but not nodes at top level). The description compensates by mentioning 'text nodes and property overrides', which maps to the two anyOf types in the schema. However, it does not explain the relationship between nodes and locale or formatting constraints beyond what the schema 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 uses a specific verb ('Update'), resource ('static page'), and scoping ('secondary locales') with the mechanism ('modifying text nodes and property overrides'). It clearly distinguishes this tool from siblings like pages_update_page_settings and pages_get_content.
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: it is for updating static page content in secondary locales, implying it is not for primary locales or for page settings. However, it does not explicitly mention alternatives or when not to use it.
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. It uses the verb 'Get' which implies a read-only operation, but it does not explicitly state that it makes no changes, nor does it mention return format, pagination, or any side effects. For a simple list tool, this is adequate but minimal—it adds no context beyond the primary 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 two sentences: the first is a clear, specific statement of the tool's purpose; the second provides valuable workflow context. There is no redundancy or wasted words, and the most important information is 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 tool with one parameter, no output schema, and no annotations, the description covers the essential purpose and workflow context. It could benefit from clarifying what 'scripts applied' includes (e.g., whether inline scripts are included) and explicitly distinguishing from site_registered_scripts_list, but the current description is sufficiently complete for a simple list operation.
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 already provides full coverage (100%) for the single parameter site_id, with a description 'Unique identifier for the site.' The tool description adds no additional parameter semantics. Per the calibration baseline for high schema coverage, a 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: 'Get all scripts applied to a site by the App.' This is a specific verb and resource, and it distinguishes from related tools like site_registered_scripts_list (which lists registered scripts) and add_inline_site_script (which adds). The additional workflow hint about registration and application clarifies the context without ambiguity.
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 a clear workflow: first register scripts via Register Script endpoints, then apply them via Site or Page endpoints. This implies the correct use case for the current tool (inspecting applied scripts) and distinguishes it from registration-related tools. However, it does not explicitly name alternative tools for listing registered scripts, so it lacks an explicit 'when not to use' statement.
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 must carry the full burden. The word 'List' implies a read-only operation, and 'all registered scripts' indicates comprehensive output. However, it does not disclose authentication requirements, rate limits, or return format, which are unaddressed but not critical for a simple retrieval tool.
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: the first states the primary purpose, the second provides workflow context. Every word is purposeful, and it is appropriately short for the tool's simplicity.
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 one parameter and no output schema, the description is complete enough. It covers the tool's role in the script lifecycle and clarifies the distinction between registered and applied scripts. It does not mention pagination or return structure, but these are not essential for a basic list operation.
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 100%—the only parameter site_id is fully described in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 applies. No compensation needed.
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 action: 'List all registered scripts for a site', using a specific verb and resource. It also distinguishes itself from the sibling tool 'site_applied_scripts_list' by focusing on registered scripts, and the workflow sentence clarifies the relationship between registered and applied scripts.
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 use by explaining the registration-to-application workflow: first register via Register Script endpoints, then apply via Site or Page endpoints. This implies when to use this tool (to see registered scripts before applying), though it does not explicitly name alternative tools or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses what information is returned (settings, domains, publishing status) but does not mention side effects, permissions, or potential errors. For a read-only get operation, this is adequate but not rich.
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 that conveys the purpose and key fields without any filler. It is 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 one-parameter get operation, the description provides enough context by listing the types of information returned. However, with no output schema, it could briefly mention the response format, though this is not critical for such a straightforward 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 schema already describes the single parameter 'site_id' with 100% coverage. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
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 a specific verb ('Get') and resource ('detailed information about a specific site'), distinguishing it from siblings like 'sites_list' (which lists sites) and 'sites_publish' (which publishes). The detail about settings, domains, and publishing status further clarifies 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 implies when to use this tool (when you need detailed info on one site) and clearly separates it from listing/publishing siblings, but it does not explicitly mention alternative tools or when not to use it. The context is clear but not fully explicit.
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 disclosure burden. It reveals an important behavioral trait: deletion only affects the primary locale unless a cmsLocaleId is provided. This is valuable context beyond the basic delete semantics, though it does not mention irreversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema or annotations, the description adequately covers the core purpose and the key locale nuance. It could be more complete with details about return values or error behavior, but for a simple delete operation it is largely sufficient.
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 already provides 100% description coverage for all parameters, so the baseline is 3. The description adds meaning by explaining the role of cmsLocaleId in targeting a specific locale, which is not fully captured by the schema's generic 'Unique identifier for the locale' text.
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 action ('Delete an item in a CMS collection') with a specific verb and resource. It is unambiguous and distinguishes itself from sibling tools that handle creation, updating, listing, or publishing items.
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 tool's purpose implies when to use it, but it does not explicitly describe when to choose it over alternatives or provide exclusions. The locale caveat adds usage context but does not reference 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?
No annotations are provided, so the description carries the transparency burden. It discloses the return structure (site ID, name, last published date) and implies read-only behavior via 'List'. However, it omits details like pagination, ordering, or authentication requirements beyond 'authenticated user', leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action verb 'List'. Every word contributes: scope ('accessible to the authenticated user') and return fields. No redundancy or fluff.
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 zero-parameter list tool with no output schema, the description is adequate: it names the operation, scope, and return fields. It doesn't mention pagination or counts, but these are not critical for a simple list operation. Overall, it provides enough context for an agent to invoke 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?
The input schema has zero parameters, so the baseline is 4 as per the rubric. The description adds no parameter syntax (none exist) but does clarify the return content, which is helpful. There is no missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all sites accessible to the authenticated user'—a specific verb and resource with explicit scope. This distinguishes it from sibling sites_get (which likely retrieves a single site) and sites_publish. The return fields are also listed, reinforcing 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: use this tool to enumerate all sites for the authenticated user. While it doesn't explicitly name alternatives or exclusions, the context is sufficiently clear given sibling tools like sites_get. No misleading guidance is present.
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:

[![webflow-mcp MCP server](https://glama.ai/mcp/servers/ampcome-mcps/webflow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ampcome-mcps/webflow-mcp)

Score Badge

Copy to your README.md:

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

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