@neuraldraft/mcp

Server Quality Checklist

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

Latest release: v0.3.4
Disambiguation5/5
Each tool targets a distinct resource-action pair (e.g., list_galleries, get_gallery, create_gallery, update_gallery, delete_gallery). Even closely related tools like register_image and replace_image have clearly separated responsibilities. No two tools appear to do the same thing.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (create_, get_, list_, update_, delete_, generate_, register_, etc.). The resource name is always a clear object, making the action predictable from the tool name alone.
Tool Count2/5
With 38 tools, this server is well beyond the typical well-scoped range of 3-15 tools. Even accounting for the broad feature set, the sheer number creates a heavy surface that could overwhelm agents and increase misselection risk.
Completeness3/5
The core resources have strong CRUD coverage: galleries, pages, and images are well-supported. However, there are notable gaps: components lack an update tool, blog posts have no delete, and translation keys have no update_content. These missing lifecycle operations force workarounds like delete-and-recreate.
Average 4.3/5 across 38 of 38 tools scored. Lowest: 3.7/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 is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It adds that the tool is free and doesn't consume credits, but omits other important traits such as whether existing pages are overwritten, required permissions, or what the API returns.
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 purpose, then usage, then cost. Every clause adds value and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is thorough for all 12 parameters, but the description lacks return value information and side-effect warnings (e.g., is_homepage demoting a previous homepage). It provides useful usage context but is not fully complete for a creation tool with no annotations and no output schema.
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 mentions 'slug + title + per-page SEO meta' as a high-level summary, but does not add details beyond the schema's own parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a page with slug, title, and per-page SEO meta. This specific verb+resource combination distinguishes it from siblings like update_page, delete_page, and register_component.
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?
It explicitly directs use for multi-page sites, tells to call once per page, and names register_component as the next step. While it lacks an explicit when-not-to-use clause, the guidance is clear and references an alternative tool.
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 behavioral disclosure burden. It discloses partial-update behavior and that the operation is free and consumes no credits. However, it omits other relevant behaviors such as return value, authentication requirements, rate limits, or conflict handling (e.g., slug 409 collision is left to the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each earning its place: purpose, partial update behavior, target use case, and cost. It is front-loaded with the main verb and resource and has no wasted words.
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 13-parameter mutation tool with no annotations and no output schema, yet the description does not mention return values, error behavior, or prerequisites beyond the use case. It is too minimal for the tool's complexity, leaving the agent without critical details for correct invocation.
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 only 46%, so the description must compensate. It only groups parameters into 'fields and/or SEO meta' without explaining individual parameter semantics, null-passing behavior, or the homepage demotion side effect beyond what the schema already states. This is insufficient for the many undocumented 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 states it patches a page's fields and/or SEO meta, using the specific verb 'patch' and resource 'page'. It distinguishes from sibling tools by noting the use case of backfilling meta_* on pages auto-created by register_component, which separates it from update_blog_post or create_page.
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?
It provides an explicit when-to-use scenario ('Use this to backfill meta_* on a page that was auto-created by register_component') and clarifies partial update semantics ('Only the fields you pass are touched'). However, it doesn't explicitly mention when not to use it or name alternative tools for creation/deletion.
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?
No annotations are provided, so the description carries the burden. It explicitly states 'Read-only; doesn't consume credits,' which is valuable behavioral and cost information beyond the schema. It does not mention pagination behavior or response format, but the core transparency about side effects is present.
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: 'List the project's pages (slug, title, type, is_homepage, is_active). Read-only; doesn't consume credits.' Every word adds value; no 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?
This is a simple listing tool with four optional filter/pagination params, all documented in the schema. The description covers the resource, return fields, and read-only nature. It could mention that results are paginated or filtered, but the schema already covers that, and the description suffices for basic 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?
Schema description coverage is 100% for all four parameters (page, type, is_active, page_size), and each parameter already has descriptive text. The tool description adds no additional meaning 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 uses the specific verb 'List' with a clear resource ('the project's pages') and enumerates the returned fields (slug, title, type, is_homepage, is_active). This distinguishes it from sibling tools like get_page (single page) and create_page/update_page/delete_page (mutations).
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 offers no guidance on when to use this tool versus alternatives. It does not mention get_page for individual pages or how it differs from list_blog_posts/list_content. The read-only note is behavioral, not usage direction.
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 transparency burden. It adds useful behavior context by stating the tool is free and explains how language_code affects text fields. However, it omits other important behaviors such as how omitted fields are handled, permissions, or whether it's a partial update (though 'Patch' implies this).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource. No redundancy, every word contributes value.
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 12 parameters, no output schema, and no annotations, yet the description only summarizes a subset of fields and cost. It doesn't explain the response format, error conditions, or how to handle parameters not mentioned, making it incomplete for reliable use.
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 only 42%, so the description needs to compensate. It adds meaning by grouping fields (title/body/SEO meta/status) and explaining language_code's role. But several parameters (slug, excerpt, category_id, featured_image) are not mentioned, and their schema descriptions are missing, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Patch' plus a clear resource ('blog post') and lists the key fields (title, body, SEO meta, status). This clearly distinguishes it from sibling tools like get_blog_post, list_blog_posts, and generate_blog_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use: updating an existing blog post's fields. It also adds practical guidance on using language_code for translations and notes the tool is free, but it doesn't explicitly mention when to use alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses merge semantics and that the operation is free (doesn't consume credits). However, it does not mention permissions, persistence guarantees, error behavior, or the response shape, which are important 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 two sentences with no filler. It front-loads the action and resource, states merge behavior, and adds a valuable cost note. Every sentence earns its place.
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 an 11-parameter tool with no output schema and sparse schema descriptions, the description covers core usage (patch, merge, free) and names major fields. It is enough to select the tool, but not fully sufficient to understand nested structures, language codes, or all field semantics without additional schema inspection.
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?
Input schema coverage is only 9%, so the description must compensate, but it only lists field categories rather than explaining the 11 parameters. It also loosely maps 'tone' to content_tone, 'logo' to logo_url, and 'languages' to target_languages/default_language, which may require inference. Merge semantics helps, but individual parameter details remain undocumented.
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 ('Patch') and clearly identifies the resource ('the project's brand') while enumerating the affected fields (voice, audience, tone, colors, fonts, logo, languages). This distinguishes it from sibling tools like get_brand and other brand/content operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys that this tool is for partial updates with merge semantics ('Only the fields you pass are updated; others are preserved'), which is strong usage context. However, it does not explicitly name alternatives or state when to avoid using this tool, so it lacks exclusions.
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 adds meaningful context: the two modes, the free nature, and the fact that embedding is a separate step. However, it does not describe the return value, required permissions, idempotency, or side effects—leaving notable gaps for an agent assessing the tool's 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 compact and well-structured: a one-sentence purpose, a concise bulleted list of two modes, and a short note about embedding. Every sentence adds value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, no output schema), the description adequately explains the core mode decision and directs the user to setup_booking_widget for embedding. However, it does not disclose what the tool returns (e.g., created service ID) or any post-creation workflow. While the schema fills many gaps, the absence of return-value info leaves an important completeness gap for an agent chaining calls.
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 covers 76% of parameters with descriptive text, including mode-specific notes like '[time_slot] Slot length in minutes. Default 60.' The tool description reinforces the mode–parameter association (duration_minutes for time_slot, min_nights/max_nights for date_range) but adds little beyond what the schema property descriptions already provide. The less-documented parameters (e.g., sort_order, buffer_*) are not elaborated in 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 clearly states the primary action: 'Create a service that customers can book.' It also differentiates the tool's two modes (time_slot vs date_range) and points to setup_booking_widget for embedding, distinguishing it from related flows. This is specific, action-oriented, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the two booking modes and their typical use cases (meetings/appointments vs apartment/rental stays). It also states that embedding is handled by setup_booking_widget, implicitly guiding the agent on what not to expect here. However, it does not explicitly name alternative create tools or include 'when not to use' statements, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses return behavior: 'Returns lists of newly-created and already-existing keys,' which implies idempotent-like handling. However, it does not specify how already-existing keys are handled (ignored vs. overwritten), nor does it mention permissions or side effects. Some transparency, but significant 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?
Two sentences, front-loaded with the primary purpose, and no redundant information. Each clause contributes to understanding when and how to use the tool, and what to expect as output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested object param, no output schema, no annotations), the description provides core purpose, usage context, and return summary, but omits important behavioral details like conflict resolution for existing keys and the structure of the returned lists. It is minimally complete but leaves 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% for both parameters, with detailed descriptions in the schema (key map, dot-namespaced, language default). The description adds minimal semantic value beyond the schema, only reinforcing 'default values' and 'outside registered components' context. Baseline 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 the tool's function: 'Create multiple translation keys with default values in one call.' It specifies the verb (create), resource (translation keys), and scope (multiple, bulk operation), effectively distinguishing itself from the sibling tools, which handle other entities like galleries or blog posts.
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 context on when to use the tool: 'Use this for keys you reference outside of registered components (nav labels, error strings, etc.)'. This implies a distinction from registered components, though it doesn't name an explicit alternative tool. Clear usage guidance, but no detailed exclusion or alternative tool reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses 'Read-only' and 'doesn't consume credits', which are meaningful safety and cost traits. It does not mention error handling or authentication, but for a simple read operation, this is adequate.
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 only two sentences, front-loaded with the action and object. It contains no redundant or filler wording, and every word contributes meaning.
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 one-parameter, read-only fetch tool with no output schema or annotations, the description provides sufficient context: what it fetches, how to identify the page, and behavioral notes (read-only, no credits). A more complete description might mention not-found behavior, but this is not essential for selecting and invoking the tool 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 100% coverage with a clear description of the id_or_slug parameter. The description's 'by id or slug' reiterates the schema rather than adding new semantic detail, so it adds no extra 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 uses a specific verb ('Fetch') and a clear resource ('a single page'), and specifies the selection method ('by id or slug'). It also lists the returned fields ('slug, title, type, SEO meta'), making it easy to distinguish from sibling tools like get_gallery or get_blog_post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when retrieving a single page by identifier, but it does not explicitly state when not to use it or name alternative tools such as list_pages for listing or update_page for modifications. Usage context is present but no exclusions or alternatives are given.
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?
No annotations are provided, so the description carries the burden. It explicitly states 'Read-only; does not consume credits,' adding key behavioral context. It doesn't disclose error handling or rate limits, but for a read-only resolve operation this is adequate.
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: first states the action, second gives a direct usage instruction. Front-loaded and free of unnecessary detail.
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?
With low complexity (1 param, no output schema) and no annotations, the description covers purpose, usage, and safety (read-only). It lacks explicit prerequisites or failure modes, but those are not essential for a retrieve-embedding 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% and the schema fully documents service_id. The description only refers to 'a bookable service' without adding additional parameter meaning 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?
Description uses specific verb 'Resolve' and identifies the resource (embed HTML + script URL for a bookable service). It clearly distinguishes from sibling tools that manage other entities by focusing on the widget embed.
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?
Provides usage context ('Drop the returned embed_html into the page where the booking flow should appear') but doesn't explicitly compare to alternatives or state when not to use. The read-only note implies a retrieval use case, but sibling differentiation is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important behaviors beyond the schema: 'Hits the CENTRAL host... not the per-tenant API,' 'Always 200, even for unknown emails (anti-enumeration),' and 'Free; doesn't consume credits.' These details are not inferable from the schema alone.
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 four sentences long, front-loaded with the core action and then providing use case and technical details. Every sentence adds value without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with 2 params and no output schema, the description covers purpose, usage, host routing, anti-enumeration behavior, and cost. It does not describe the return format or authentication requirements, but these are arguably not essential given the tool's simplicity.
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 mentions the email lookup context and central host behavior, but it does not add specific param-level semantics beyond what the schema already provides for 'email' and 'central_url'.
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: 'List the Neural Draft workspaces (tenants) an email is registered against.' It uses a specific verb ('List') and resource ('workspaces'), and the context of 'an email' distinguishes it from other tools like get_gallery or list_pages.
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?
It provides a concrete use case: 'Useful for multi-workspace login troubleshooting — the user knows the email but forgot which workspace.' It also explains that it 'Hits the CENTRAL host... not the per-tenant API,' which clarifies when this tool is appropriate, though it does not explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'Read-only; does not consume credits,' which are important behavioral traits beyond the schema. It does not cover error behavior, but for a simple retrieval tool this is sufficient.
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 with no wasted words. Key information (what it does, read-only, credit-free, when to use) is front-loaded and directly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool, the description plus schema covers the purpose, usage context, and safety/cost profile. There is no output schema, but the return value (a product) is reasonably inferable from the tool name and description.
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 100% parameter coverage, including that 'id' can be a numeric ID or string slug. The description adds no additional parameter-level meaning beyond what the schema states, meriting the baseline score for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('a single product by id'), clearly distinguishing this from sibling tools like list_products or get_gallery. The addition of 'Read-only' further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use when scaffolding a /products/[slug] page.' This gives clear context for when to invoke the tool, though it does not explicitly name alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only; doesn't consume credits,' which communicates the safety profile and side-effect-free nature. It also lists the returned fields, adding transparency about the output. It doesn't mention pagination behavior, but the schema covers page/page_size parameters.
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 and front-loaded with the core purpose, followed by read-only/credit disclosure and search usage. Every sentence serves a distinct informative purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema and optional parameters, the description covers the essential behavioral and return information (fields list, read-only, credit usage, search behavior). It doesn't describe the response format in detail, but the enumerated fields give a strong hint, and the schema handles parameter validation.
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 each parameter having a clear description. The tool description adds minimal value beyond the schema—it repeats the search substring-matching details in different wording but doesn't introduce new semantics for page or page_size. 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 uses a specific verb 'List' and identifies the exact resource ('contact-form submissions') along with the fields returned (id, email, subject, message, data). This clearly distinguishes it from sibling list tools like list_galleries or list_blog_posts.
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?
It provides clear context by stating this lists the project's captured contact-form submissions and gives specific usage for the search parameter ('Use search= to substring-match against email, subject, or message'). However, it doesn't explicitly state when not to use this tool or mention alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It explicitly states 'Read-only; doesn't consume credits,' which addresses the two most important behavioral concerns: no mutation and no resource cost. It does not mention pagination behavior or sorting, but schema parameters cover page/page_size, and for a simple list this is adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and resource, then follows with a useful filtering example and a critical safety note. Every sentence earns its place with no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple list tool: it states what is returned (key, url, updated_at), the scope (current project), and a filter mechanism. It does not have an output schema, but the return fields are explicit in the description. It lacks details on sorting or full pagination behavior, but given the simplicity and schema coverage, the description provides enough context 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?
Schema description coverage is 100%, so the baseline is 3. The description adds a slightly richer example for `prefix`, showing that 'hero.' returns keys like hero.background and hero.foreground, but this is incremental over the schema. The other parameters (page, page_size) are already fully described in the schema and not re-explained in 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 clearly states the tool's purpose: 'List image keys registered for the current project (key, url, updated_at).' It uses a specific verb ('List') and resource ('image keys') with an explicit scope ('current project') and return fields. It is easily distinguished from sibling tools like register_image, replace_image, and delete_image, which imply mutation or singular access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is read-only, does not consume credits, and supports an optional `prefix` filter with a concrete example ('hero.' returns hero.background, hero.foreground). While it does not explicitly name alternative tools for single-image retrieval or list other scopes, the context is sufficient for an agent to know when listing images is appropriate and that it is safe to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses key behavioral traits: 'Read-only; does not consume credits' and 'paginated'. This goes beyond simple listing by indicating safety and cost implications, though it does not detail response format or rate limits.
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 concise sentences with front-loaded action: the primary function 'List' comes first, followed by pagination, read-only, no credits, and a use case. No wasted words; every clause 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?
The tool is a simple list operation with 3 optional params and no output schema. The description adequately covers purpose, usage scenario, and safety. It lacks detail on return fields, but that is not explicitly required given the straightforward nature of listing products and the absence of an output schema.
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% for all three parameters (page, status, page_size). The description adds minimal extra meaning, only mentioning pagination which is already covered by the schema. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List the project's products' with pagination clearly indicated. It distinguishes from sibling tools like get_product (single product) and other list_* tools by explicitly mentioning 'products' and 'paginated'.
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 when-to-use guidance: 'Use before scaffolding a storefront so you generate cards for real items.' It implies this is a safe, non-consuming operation, though it does not explicitly mention alternatives or exclusions beyond the implied contrast with other tools.
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?
No annotations are provided, but the description carries the burden: it states read-only behavior, no credit consumption, and the return shape (name + ordered items array). This is sufficient for a simple retrieval tool, though it omits error cases or authorization details.
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?
Three sentences, front-loaded with purpose, then return type, then usage guidance. No filler or redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, return format, read-only behavior, and when to use an alternative. This is complete for an agent to select and invoke 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?
Schema coverage is 100% for the single slug parameter, so the baseline is 3. The description only repeats 'by slug' without additional semantic detail beyond the schema's example, so it doesn't elevate the 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 states a specific verb+resource: 'Fetch a gallery by slug.' It also distinguishes from siblings by mentioning 'list_galleries' and implies a single-item retrieval, differentiating from create/update/delete operations.
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?
It provides explicit advice: 'Use list_galleries first if you don't know the slug.' This gives clear context for when to use this tool versus an alternative, though it does not enumerate all sibling exclusions (e.g., when to use create/update/delete).
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?
No annotations are provided, so the description carries the transparency burden. It discloses the core behavior and explicitly notes the 404 error for unregistered keys. The read-only nature is implied by 'get' and 'resolve,' though not explicitly stated.
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, front-loaded with the action and result. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup without an output schema, the description fully covers both the successful resolution and the 404 failure case. 'Resolve the registered URL' directly implies the return value, making it complete for this 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 already covers the sole parameter with a description and example ('hero.background'), so the baseline is 3. The description adds the context that the key maps to a registered URL, but no additional syntax or formatting details 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 ('Resolve') and identifies the exact resource ('registered URL for an image key'). This clearly distinguishes it from sibling tools like list_images (enumeration), register_image (creation), and generate_image (generation).
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 text clearly implies this tool is for looking up a single image by key, which is evident from 'for an image key.' However, it does not explicitly name alternatives or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the most important behaviors: read-only, no credit consumption, and the returned fields. It does not mention pagination or ordering, but the schema covers those mechanics.
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 concise sentences, front-loaded with the verb and resource, followed by essential caveats and a filter example. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description explains the purpose, return fields, read-only nature, credit implication, and a filtering example. Pagination and page size are documented in the schema, so the description is complete without duplicating that information.
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 describes all four parameters with 100% coverage, so the baseline applies. The description adds only a minor usage hint about app_lead, which does not materially enhance the parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states a specific action (List) on a specific resource (newsletter subscribers), includes the fields returned, and is distinct for this project. It is unambiguous and immediately distinguishes the tool from siblings.
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 notes that it is read-only and does not consume credits, which is a key usage consideration. It also gives a concrete filtering example for app_lead. Since no sibling tool lists newsletter subscribers, explicit alternative guidance is not needed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses slug auto-derivation, conflict resolution with -2/-3 appending, max item limit of 200, and item shape {url, alt?}. It does not clarify behavior for explicitly provided conflicting slugs, leaving a minor gap, but the overall transparency is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. Each sentence provides essential information: definition, slug behavior, item optionality, and limits. There is no fluff or redundancy, making it compact and highly readable.
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?
With 3 parameters, full schema coverage, no output schema, and no annotations, the description covers the most important aspects: creation, slug derivation, uniqueness conflicts, item limits, and item structure. It does not mention return values, but for a create tool with no output schema, this is a minor omission. It is nearly complete for the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema by explaining the slug conflict resolution behavior (-2, -3 appended) when the derived slug exists, which is not present in the schema's slug description. It also clarifies that items are optional and can be added later, reinforcing the schema's optional nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a new gallery', followed by a clear definition ('named, ordered collection of image URLs'). It distinguishes from sibling tools by explicitly referencing update_gallery for adding items later, clarifying that this tool is for creation, not modification.
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 explicit usage guidance: 'Items are optional at create time — start empty and add via update_gallery.' This tells the agent when to use create_gallery vs update_gallery. It also explains slug auto-derivation when omitted, but does not cover exclusions for other sibling tools (e.g., delete_gallery, list_galleries).
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 transparency burden. It discloses the asynchronous job pattern (returns Job ID, poll until completed), automatic brand styling, and a credit cost (~40 credits). This goes beyond typical descriptions, though it doesn't mention failure handling or rate limits.
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?
Three sentences, no fluff. Front-loaded with the core purpose, then the critical usage pattern (poll get_job, use key) and cost. Every sentence 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?
The tool is async and has no output schema, so the description's explanation of the Job ID and polling flow is essential and provided. It also covers key usage and cost. Minor gaps (failure behavior, style/aspect ratio examples) are not critical, given schema coverage and the concise guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the `key` parameter, explaining how it makes the image addressable later via GET /v1/images/{key} and recommends it. Other parameters are not elaborated, but the schema already handles them.
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 action: 'Generate a brand-consistent image' and adds specificity by noting it automatically uses the project's color palette and visual tone. It distinguishes from sibling tools like get_image (fetch) and generate_video/generate_blog_post (other content types).
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 usage context: returns a Job ID to poll with get_job, and recommends passing `key` for later addressability. While it doesn't explicitly say when not to use (e.g., for existing images), naming get_job as a companion tool gives actionable how-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing key behaviors. It discloses async Job return, credit costs, plan restrictions, and the need to poll until completion. However, it omits details about how 'brand-aware' generation works and potential side effects, leaving minor 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?
The description is compact and front-loaded: a single purpose sentence followed by dense operational details. Every sentence adds value without redundancy, making it easy to scan.
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?
Covers the full lifecycle (start, poll, receive), costs, plan limits, and defaults. Lacks explanation of the 'brand-aware' behavior and exact content of the returned Job, which would be useful given no output schema. Slightly incomplete but not severely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful detail beyond schema: credit costs per tier (40 vs 300), the specific models used, and social-media context for aspect ratios. This enriches the parameter definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Kick off a video generation and return a Job' clearly states the verb and resource. It distinguishes this tool from get_job (polling) and generate_image (image generation) by specifying 'video generation' and 'return a Job'.
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 operational context: tier-specific credits and plan requirements, explicit polling instruction with get_job, and aspect ratio defaults for social platforms. It doesn't explicitly compare to alternatives like generate_image, but the context strongly implies when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the job status lifecycle (pending → running → completed | failed | cancelled), which is essential for understanding how to interpret polling. It does not mention error handling or idempotency, but the read-only nature is implicit in 'poll'.
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 with the core purpose front-loaded. Every piece of information is useful, and the status flow is presented compactly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers purpose, usage timing, and job lifecycle for a simple one-parameter polling tool. It lacks details about the response format or error cases, but no output schema exists and the tool is straightforward; the provided context is sufficient for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for the 'id' parameter. The tool description adds value beyond the schema by explaining that the ID is returned by generate_blog_post, generate_image, etc., helping the agent know where to obtain the required value.
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: 'Poll the status of an async Neural Draft job' with a specific verb and resource. It also distinguishes it from siblings by referencing the generator tools that return the job ID, making its role unambiguous.
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 the tool: after calling an async generation function like generate_blog_post or generate_image. It does not explicitly mention when not to use it or alternative tools, but the context is clear and adequate for this specific polling use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly states 'Read-only; doesn't consume credits,' which is valuable safety information. It also mentions pagination and that the language value is returned 'alongside the all_locales map,' giving a hint about output structure. This is a strong disclosure for a read-only list 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 and every clause earns its place. It front-loads the core purpose, then packs parameter guidance and a read-only note into a compact, scannable format. No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 5 optional parameters and no output schema, the description covers the essential aspects: what it lists, pagination, filtering options, read-only behavior, and a hint at the return structure (resolved value + all_locales map). It stops short of describing exact response layout, but for a list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value by giving a concrete example for search ('e.g. 'hero.' returns hero.headline, hero.cta, …') and clarifying how scope and lang interact with the returned data. This goes beyond the schema's dry property listings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the project's translation keys (paginated).' This clearly states the tool's function and distinguishes it from sibling list tools like list_galleries and list_pages, which handle different resource types. The pagination detail further sets expectations.
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 how to use the tool by explaining the search, scope, and lang parameters ('Use `search` for substring match... `scope` to narrow... `lang` to pick...'). It doesn't explicitly mention when not to use this tool, but the parameter guidance gives enough contextual clarity for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses key behaviors: the tool creates editable components, returns component_id and translation keys, and imposes a conventions requirement on the HTML. It does not cover all possible behavioral aspects (e.g., idempotency, error conditions), but the return value disclosure and prerequisite are valuable beyond basic mutation semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with each serving a distinct purpose: purpose (sentence 1), usage frequency (sentence 2), and return value/conventions requirement (sentence 3). It is front-loaded with the verb and resource, and every sentence contributes actionable information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides a solid overall context: it explains the purpose, when to call, prerequisite reading, and return values. It also includes a specific preservation instruction for component_id. It omits some details (e.g., handling of optional params, error scenarios), but it is adequately complete for the tool's complexity and relatively small parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context for the html parameter by linking to editable-HTML conventions, which is not in the schema. It also implies that the HTML should contain data-translate attributes (since translation keys are created). This goes beyond the schema's generic descriptions, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Register an HTML section as an editable component in the customer's Neural Draft admin.' It uses a specific verb (register) and resource (HTML section as editable component), and distinguishes from siblings like create_page or delete_component. The phrase 'for EVERY section you generate' further clarifies scope, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use: 'Call this for EVERY section you generate (hero, features, pricing, footer, etc.)' and provides a prerequisite ('read conventions://editable-html first'). It does not explicitly mention when not to use or alternative tools, but the strong 'when' directive and context make usage clear. It slightly misses the 5 threshold due to lack of exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that URL swap is synchronous with 0 credits, while regeneration is async, costs ~40 credits, and returns a Job. This is valuable context. However, it does not mention that the replacement is irreversible or what happens to the original image, which would be important for an agent to know.
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 tightly written: two sentences with a clear bulleted list. Every clause serves a purpose—mode, cost, sync/async, job polling, and the exclusivity constraint. There is no redundant or filler content, and it is front-loaded with the primary action.
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 two modes, six parameters, and no output schema, the description covers most essentials: mode selection, costs, async behavior, and job polling. It lacks a mention of the return value for the synchronous URL swap path and does not explicitly state that the replacement overwrites the existing image. These gaps prevent a perfect score.
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 already describes all six parameters (100% coverage), so the baseline is 3. The description adds semantic value by clarifying that url and regenerate are mutually exclusive, that regenerate requires a prompt, and that style and aspect_ratio are tied to AI regeneration. It also explains the credit implications, which the schema does not.
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 replaces an image at a given key, listing two specific modes: URL swap and AI regeneration. It distinguishes itself from sibling tools like register_image and delete_image by focusing on replacement behavior. The verb 'replace' is specific and matches the tool name.
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 explicit usage context by detailing the two modes, their prerequisites, credit costs, and the need to poll get_job for async regeneration. It states 'Exactly one mode must be supplied,' which is a clear constraint. However, it does not explicitly contrast with sibling tools like generate_image or register_image, so the differentiation is 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states 'Permanently remove,' 'Destructive — no undo,' and 'Returns 404 if the component doesn't exist,' fully exposing the destructive nature and error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each with dense information: the first defines the action and resource; the second covers the use case, error behavior, and destructive warning. No filler or redundancy that detracts from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no annotations and no output schema, the description covers purpose, usage, permanence, and error behavior. It even explains what a 'component' is and how to find the id. This is fully sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a detailed description for the id parameter ('Returned by register_component and listed under a page's components'), achieving 100% schema coverage. The tool description does not add additional parameter semantics, so the 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 uses the verb 'Permanently remove' with the specific resource 'registered component (editable HTML chunk) from the project,' clearly distinguishing it from sibling delete tools like delete_content or delete_page. The parenthetical clarifies what a component is, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use when retiring a section that's no longer on the page.' It does not explicitly mention alternatives or exclusions, which prevents a 5, but the context is strong enough to guide correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses that the operation is permanent ('Permanently remove'), irreversible ('no undo'), destructive, and returns 404 if the key doesn't exist. It also clarifies the deletion scope ('all its locale values'). This is excellent transparency for a destructive 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 three sentences, each earning its place: action and scope, usage context, and error behavior. It is front-loaded with the action and contains zero filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers all relevant aspects: what is deleted, when to use, what happens on missing key, and the destructive nature. Nothing essential is missing.
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%, with the schema providing a clear description and example for the 'key' parameter. The description text adds no additional parameter semantics, so the 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 the verb 'remove' and the resource 'content / translation key', with the precise scope 'all its locale values'. This distinguishes it from sibling delete tools like delete_component and delete_page, which target different kinds of resources.
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 gives an explicit usage context: 'Use when retiring copy that's no longer rendered anywhere on the site.' It does not mention specific alternatives or exclusions, but the context is clear and actionable, which matches a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and excels: it explicitly states the operation is destructive, has no undo, only removes the gallery record, and clarifies what it does NOT delete. This is exemplary 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?
Two concise sentences front-load the destructive warning and then specify scope and exclusions. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and no output schema, the description fully covers purpose, side effects, and non-side effects. It is sufficiently complete for an agent to invoke correctly, especially given the sibling context.
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 the parameter 'slug' already described with an example. The description adds no additional parameter semantics beyond restating 'by slug', so it meets the baseline but doesn't 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 a specific verb 'delete' and identifies the resource 'gallery' plus the method 'by slug'. It clearly distinguishes from sibling deletion tools like delete_component or delete_image by stating it only removes the gallery record.
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 warns 'Destructive — no undo' and clarifies that it does not delete underlying images, which helps prevent misuse. However, it does not explicitly mention alternative tools or when not to use this tool, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly states the precise effect (removes key→URL binding), what it does NOT do (delete CDN bytes), and the return behavior (404 if key not registered), giving agents complete transparency into side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each providing essential information: the action, the negative scope, and the error return. No redundant words or repetition of schema details, making it exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool with no annotations or output schema, the description is complete. It covers the operation's effect, its limitation, and error behavior, leaving no ambiguity about what the tool does or its consequences.
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 documents the 'key' parameter with a description and example, achieving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove an image key registration' and explains the effect on the URL resolution via GET /v1/images/{key}. It distinguishes itself from sibling delete tools by clarifying that it only removes the key→URL binding, not the underlying CDN bytes.
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 implicitly indicates when to use this tool (when an image key needs to be unregistered) and provides a key exclusion: it does NOT delete CDN bytes, helping agents choose it over sibling delete tools for this specific purpose. However, it does not explicitly name alternatives or state 'when not to use' in direct terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals three key behaviors: asynchronous execution (returns a Job ID immediately), credit cost (~400 credits per post), and the side effect of fanning out translations at 5 credits per language. This is substantial context for an AI agent to anticipate the tool's operational characteristics and plan accordingly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and follows a logical progression: what it does, how to track it, and key cost/translation options. No filler or redundant content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, asynchronous pipeline, no output schema), the description covers the essential workflow: it specifies that a Job ID is returned and how to poll for results, mentions the cost implications, and explains the translation fan-out behavior. This is sufficient for an agent to use the tool correctly without needing to inspect the schema for workflow details.
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 provides 100% description coverage for all 11 parameters, so the baseline is 3. The description adds minimal parameter semantics beyond the schema; it mentions translate_to_all and its cost, but this is more behavioral than semantic. The schema already explains each parameter's purpose and defaults, so the description does not need to compensate.
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: 'Kick off the AI blog generation pipeline' with an explicit series of stages (research → draft → image → SEO). This distinguishes it from sibling tools like get_blog_post or generate_image by focusing on the end-to-end generation workflow rather than retrieving or editing an existing post.
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 practical guidance for post-invocation behavior: polling with get_job until completion. It also gives an explicit alternative for translation control ('For per-language control use translate_blog_post on the resulting post id'), helping the agent choose between this tool's fan-out feature and a more granular tool. However, it does not explicitly state when to use this tool versus other blog-related siblings (e.g., update_blog_post), though the purpose is largely implied by the name and pipeline description.
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?
No annotations are provided, so the description carries the full burden. It explicitly states 'Read-only; doesn't consume credits,' which is valuable behavioral disclosure beyond the schema. It does not detail response shape on not-found or error cases, but for a simple read operation this is sufficient.
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 with no wasted words. It front-loads the action and resource, then adds necessary detail about translations and safety. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 2-parameter tool with no output schema and no annotations, the description covers the essential behavior, included fields, translation behavior, and safety profile. It is complete enough for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented. The description adds extra semantic value by explaining that lang picks a non-default translation and id_or_slug accepts either a numeric ID or slug. This goes beyond the schema by clarifying the relationship between 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 states the tool fetches a single blog post by id or slug, lists the included fields (title, body, excerpt, SEO meta, translations), and is distinct from sibling tools like list_blog_posts or get_page. The verb 'fetch' and resource 'blog post' make 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to retrieve one blog post by id or slug. It does not explicitly name alternatives or exclusions (e.g., 'use list_blog_posts to find posts'), but the context is sufficiently clear for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states read-only semantics and that it doesn't consume credits, and adds the resource-equivalence context. It doesn't describe return format, but for a simple getter this is sufficient.
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 compact three sentences with no redundancy. Every sentence contributes useful information: what it reads, how it compares to the resource alternative, and its safety/usage characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple (no params, no output schema), and the description provides all needed context: the resource being read, key fields, safety profile, and why this tool exists. The absence of an output schema doesn't create ambiguity since the description lists the returned brand attributes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level meaning. The baseline of 4 applies, and the description appropriately focuses on what the tool returns rather than parameter handling.
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 ('Read') and identifies the resource ('project's brand'), while enumerating the contained fields (voice, audience, colors, fonts, logo, target topics). This clearly distinguishes it from siblings like update_brand and 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 explains that this tool is equivalent to the brand://current resource and is provided for clients that don't support resources, giving clear context for when to use it. It doesn't explicitly mention alternatives or exclusions, but no closer alternative exists among siblings (update_brand is the write counterpart).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only, does not consume credits, returns the value for the chosen locale plus every other written locale, and defaults to the project default language. These are important behavioral traits beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every sentence contributes meaningful information about behavior and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description adequately covers what it does, what it returns, and its safety profile. No significant gaps are evident.
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 repeats what `lang` does (defaults to project default) without adding new parameter-level meaning; the schema already provides the same context. It adds no extra detail about `key` beyond 'by name'.
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 'Fetch a single translation key by name' with a specific verb and resource, and distinguishes this tool from sibling getters by focusing on translation keys and locale behavior. It is immediately obvious 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use it to fetch a single translation key, with an optional `lang` parameter that defaults to the project language. It does not explicitly mention alternatives, but the resource type is distinct from sibling tools, making the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description explicitly discloses that the operation is read-only and doesn't consume credits, which is critical for an agent. It also defines galleries clearly, adding context about their purpose. This goes beyond the schema and annotations.
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. It front-loads the main action and resource, then provides necessary context and safety info without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has complete schema coverage for parameters, and the description explains purpose, scope, ordering, and resource context. It also discloses read-only/no-credit behavior. This is sufficient for agent decision-making without an output schema.
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 descriptions for both parameters (page and per_page), and the description adds no extra meaning about these parameters. Baseline of 3 is appropriate because schema coverage is 100%.
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 'List' and the resource 'galleries' with scope 'for the current project', and specifies the ordering by 'slug, name, items_count'. This distinguishes it from sibling tools like get_gallery, create_gallery, update_gallery, and delete_gallery.
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?
It provides clear context for when to use the tool (listing galleries for the current project) and describes the output order. However, it does not explicitly mention alternatives or exclusions, such as using get_gallery for a single gallery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses idempotency ('calling twice with the same key swaps the URL'), cost ('0 credits'), and update behavior. It could mention return expectations or error handling, but for a simple registration tool this is sufficient.
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 tightly written sentences, front-loaded with the core action. The example is compact and every clause (idempotent, cost, alternative) adds value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter registration tool with no output schema, the description adequately covers purpose, usage, behavioral traits, and alternatives. Nothing critical is missing for an agent 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 input schema already has 100% coverage with descriptions for both 'key' and 'url'. The description adds a concrete example of the key mapping, which reinforces but doesn't significantly extend the schema. 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 the action: 'Bind a direct image URL to a stable key' with a concrete example. It distinguishes from sibling generate_image by noting when to use that alternative. The title also reinforces 'Register or update an image URL'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool: for direct image URLs, and explicitly says 'For AI-generated images use generate_image instead.' Also notes idempotent behavior and zero cost, which helps decide if re-registration is safe.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only, doesn't consume credits, returns paginated results, and uses a default sort of '-created_at'. This goes beyond basic operations and covers key behavioral aspects, though it doesn't mention rate limits or return structure.
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 front-loads the core action and then packs additional relevant details (filters, sort, defaults, read-only) without any waste. Every clause provides actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no required params, no output schema) and the absence of annotations, the description covers all essential aspects: pagination, filtering, sorting, defaults, and cost/read-only status. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all 7 parameters. The description adds valuable semantics beyond that: it explains how filters combine (status, category, tag, language), the '-' prefix convention for descending sort, and the default sort order. This helps the agent form correct queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('blog posts'), and scope ('the project's'), and immediately clarifies it is paginated. It clearly differentiates itself from sibling tools like get_blog_post (singular) and list_galleries by focusing on the blog post collection.
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 this tool: to list blog posts with optional filters and sorting. It does not explicitly name alternatives or exclusions, but the context makes it obvious that this is for multiple posts, while get_blog_post handles single posts. Slight gap: no explicit 'use this when you need a list' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: default soft-retire (is_active=false), reversible nature, force option for irreversible hard delete, and the homepage restriction. This covers the key safety and side-effect concerns for a delete 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 two sentences with no wasted words. It front-loads the purpose, then provides essential conditional behavior and a critical exclusion in a compact, scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with only two parameters and no output schema, the description covers all relevant context: default behavior, hard delete option, reversibility, and edge case (homepage). Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes both parameters with defaults. The description adds extra meaning beyond the schema by explaining the soft-retire mechanic and the reversibility via update_page, which are not present in 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 starts with 'Remove a page,' which clearly specifies the verb and resource. It distinguishes from sibling delete tools by identifying the target as a page and further defines the behavior with soft vs hard delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (removing a page) and states a when-not (homepage cannot be deleted). It also mentions an alternative for reversal via update_page, but does not explicitly contrast it with other sibling delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only; doesn't consume credits,' which is crucial safety information. It also describes the returned data elements, giving a transparent view of 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 two sentences: the first states exactly what the tool does, the second provides use case and safety. Every word adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description is fully complete. It covers purpose, use case, returned data, and safety. No additional context is needed.
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. The description adds no parameter details because none are needed, but it implicitly confirms no inputs are required. This is appropriate for a no-parameter tool.
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 reads credit balance, monthly limit, reset date, and per-operation spend breakdown. This is a specific verb (read) with a clear resource (project credit usage) and distinct details that separate it from any sibling 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 description explicitly says 'Use this to decide whether a multi-step generation will fit the budget before kicking it off,' providing a clear when-to-use context. It does not mention when-not-to-use or alternatives, but no sibling tool serves a similar purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: discloses full-replace semantics, slug immutability, and max 200 items. Minor gap: does not explicitly state that omitting items preserves existing items, but the phrasing 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?
Three sentences, front-loaded purpose, no fluff. Each sentence earns its place: first states the action, second explains fields and full-replace, third covers constraints and workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (full-replace mutation, no annotations, no output schema), the description covers the key aspects: usage, constraints, and workflow. It could mention what the response contains (e.g., updated gallery), but the instruction says that's not required without an output schema, and the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial semantics beyond simple field docs: full-replace behavior for items, the fetch-mutate-send workflow, and slug immutability. This is exactly the kind of value-added explanation 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?
Description states 'Update a gallery by slug'—a specific verb and resource. It clearly distinguishes from siblings like get_gallery, create_gallery, and delete_gallery by focusing solely on the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'Items is a FULL REPLACE — to add or reorder, fetch the current list with get_gallery, mutate, then send the complete new array.' Names the alternative (get_gallery) and explains when to use it, along with the immutable slug constraint.
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:

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

Score Badge

Copy to your README.md:

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

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