WordPress MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Many tools have clear domain prefixes, but there are several overlapping functionalities such as wp_list_users vs admin_list_users and wp_list_menus vs nav_list_menus, which could confuse an agent. The descriptions help, but the sheer number of similar tools across different plugins (e.g., forms, multilingual) creates ambiguity.
Naming Consistency4/5
The naming predominantly follows a consistent domain_prefix + action + target pattern using snake_case, which is readable and predictable. Minor deviations exist like auth_status, admin_site_health, and ml_duplicate_for_translation, but they are infrequent and do not significantly hinder consistency.
Tool Count1/5
With 192 tools, this server is extremely oversized for an MCP server. Even for WordPress's broad scope, this number is excessive and will likely overwhelm agents, leading to selection difficulties and performance overhead. The tool count far exceeds any reasonable threshold.
Completeness4/5
The server covers an impressively wide range of WordPress functionality including posts, pages, media, comments, users, revisions, SEO, ACF, Elementor, multilingual, forms, WooCommerce, and more. However, some areas are read-only (themes, plugins, widgets) and lack full CRUD operations, leaving minor gaps for management tasks.
Average 3.3/5 across 192 of 192 tools scored. Lowest: 1.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
- Last stable release on January 3, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It merely states 'counts comments by status' without specifying return format (e.g., a single number, an array of per-status counts), whether it operates on all comments or only, and lacks any details about filtering logic or response fields. This is insufficient for an agent to predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks essential details about what the count represents and the response structure. The brevity does not serve the agent's needs, making it more of a placeholder than a valuable specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, no output schema, and no annotations, the description should fully clarify the tool's purpose and return value. It does neither, leaving the agent to guess whether it returns a simple integer, a status-wise breakdown, or something else. The lack of clarity makes the tool effectively unusable without external documentation.
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 tool has zero parameters, so the baseline is 4. However, the description's mention of 'by status' implicitly references a status filter that is not exposed as a parameter, causing confusion about how the status is determined. Since the description adds no meaningful parameter information and actively introduces ambiguity, it is slightly below the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zählt Kommentare nach Status' (Counts comments by status) is vague and misaligned with the tool name and title, which specifically indicate counting pending comments. It does not clearly state that it returns a count of pending/unapproved comments, and the phrase 'by status' introduces ambiguity about grouping or filtering by multiple statuses. The verb and resource are present, but the scope is unclear and inconsistent with the intended purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like comment_list or comment_get. The description does not mention use cases, prerequisites, or exclusions. An agent has no basis to decide when to invoke this tool instead of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'updates' without revealing side effects, permission requirements, idempotency, overwrite behavior, or what happens when the formId is not found. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It repeats the tool name without adding value, failing to earn its place. A useful description would be longer or at least provide actionable details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 6 parameters, no annotations, and no output schema. The one-sentence description is completely inadequate for understanding update semantics, field optionality, or return behavior. Even the update target (formId) is only mentioned in the schema, not the 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 input schema has 100% parameter description coverage, so the baseline is 3 even without additional info in the tool description. The description itself adds no parameter semantics, but the schema already explains each field (form, title, formId, mailBody, etc.) adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualisiert ein CF7-Formular' is a tautology that simply restates the tool name and title. It provides no specific verb+resource distinction beyond the implicit 'update' action, and does not differentiate from sibling CF7 tools like cf7_list_forms or cf7_get_form.
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 gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or any scenario where cf7_update_form is preferred over other CF7 operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It merely restates the tool's title and does not mention that this is a mutation, whether it is partial or full update, permission requirements, or any side effects. The description adds no value beyond the name and title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than appropriately concise. It repeats the tool's name/title without adding structured information. In this context, minimalism is not conciseness; it fails to earn its place with useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what fields are updated, how updates are applied (partial vs. full), what the response is, or any side effects. A mutation tool with this complexity requires far more 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?
The schema has 100% parameter description coverage, so baseline is 3. The tool description adds no extra semantic information about parameters, but the schema already documents each field clearly (email, roles, names, etc.). The description does not compensate for any gaps because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualisiert einen WordPress-Benutzer' clearly states a specific action (update) and a resource (WordPress user), distinguishing it from sibling tools like admin_delete_user and admin_get_user. However, it lacks explicit differentiation in terms of scope or related alternatives, so it doesn't reach the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as admin_create_user or admin_delete_user. There are no prerequisites, exclusions, or contextual cues beyond the verb 'update'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'updates' without disclosing side effects, required permissions, reversibility, or what happens if the comment does not exist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose. It is concise and easy to read, though it may be slightly too terse for a tool with multiple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not mention what the tool returns (e.g., updated comment, success flag) or any error conditions. For a write operation, this leaves significant gaps in understanding the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all three parameters, so the schema itself explains the parameters. The description adds no additional meaning beyond what is already in the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualisiert einen bestehenden Kommentar' clearly states the action (updates) and resource (existing comment), which distinguishes it from create and delete operations. However, it does not explicitly name alternative sibling tools like comment_moderate_bulk or comment_create, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus comment_create, comment_reply, or comment_moderate_bulk. The description provides no context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it retrieves a list, omitting details about pagination defaults, response structure, potential performance implications, or any filtering behavior. This is minimal and insufficient for a tool with three optional parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff, which is concise. However, it is under-specified to the point of being unhelpful; each word earns its place but the place is too small. A slightly longer description could add valuable context without losing conciseness.
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 is a simple list operation, but the description lacks any mention of return format, filtering capabilities, pagination, or relation to sibling media tools. Given no annotations and 0% schema coverage, the description is the only source of context and it provides almost none. The output schema exists but is not enough to compensate for the missing narrative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The description fails to explain the meaning of 'search', 'per_page', or 'media_type', leaving the agent to guess from the parameter names. This is a critical gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Holt eine Liste' = 'Gets a list') on a clear resource ('aller Mediendateien' = 'all media files'), making the core purpose obvious. It does not explicitly differentiate from siblings like wp_get_media, but the singular/plural distinction plus the verb 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as wp_get_media, image_list_sizes, or image_find_unused. There is no mention of prerequisites, filter use cases, or when not to use it, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only restates the action 'Holt eine Liste' without detailing pagination, default status, filtering behavior, or whether it returns hierarchical structure, offering no transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise. However, it adds minimal information beyond the tool name, so it doesn't fully earn its place; it's short but under-specifies the tool's capabilities.
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?
Although an output schema exists, the tool has four parameters with low schema coverage and no usage guidance. The description does not address filtering, pagination, or default behavior, making it incomplete for a tool with this complexity and for distinguishing among many list tools in the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'parent' has a description), and the description itself adds no explanations for 'search', 'status', or 'per_page'. It fails to compensate for the low schema coverage, leaving three parameters semantically unexplained.
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 'Holt' (fetches) and resource 'Liste aller WordPress-Seiten' (list of all WordPress pages), directly matching the tool name and distinguishing it from sibling tools like wp_list_posts and wp_list_categories. The scope is explicit ('aller'), and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is specifically for pages, nor does it reference sibling tools like wp_list_posts, leaving the AI agent without contextual selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'creates a new page' without mentioning side effects, permissions, default status, or how content is handled. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence, which is concise and front-loaded. However, it is under-specified for the complexity of the tool, so the conciseness is not paired with adequate information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and only a single sentence, the description is not complete enough. It lacks usage context, behavioral caveats, and any guidance on required vs optional parameters. The presence of an output schema helps with return values but does not compensate for the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning beyond the input schema. While the schema covers 67% of parameters with descriptions, the remaining parameters (slug, status) lack descriptions, and the tool description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Erstellt eine neue WordPress-Seite' clearly states the verb (creates) and resource (WordPress page). It is specific enough to distinguish from related tools like wp_create_post, though it does not explicitly differentiate among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wp_create_post or wp_update_page. The description only states what the tool does, not the appropriate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description is a tautology—'updates an existing page'—and does not mention side effects, required permissions, partial update behavior, or the impact of omitting fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words, front-loaded with the core purpose. It is concise, though it sacrifices valuable context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely incomplete for a 7-parameter mutation tool. It lacks usage guidance, parameter semantics, and behavioral transparency, and does not leverage the existence of an output schema to clarify expectations. An agent would struggle to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, and the description adds no parameter details. It does not explain what `slug`, `title`, `parent`, `status`, `content`, or `template` mean or how they should be formatted, leaving the agent without essential information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that it updates an existing WordPress page, using the specific verb 'Aktualisiert' and resource 'bestehende WordPress-Seite'. It distinguishes itself from related sibling tools like wp_create_page (create) and wp_update_post (post vs page).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to alternatives like wp_update_post or wp_create_page. There are no stated conditions, prerequisites, or exclusions; the description only restates the core action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It only says 'prepares content for export' but does not disclose side effects, permissions, return format, or whether it is read-only. This is inadequate for a tool that likely has significant behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it lacks detail and uses vague 'etc.' It is not overly verbose, but it also does not earn its place by providing enough context to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what the tool returns or what 'preparing' entails. It does not mention output, side effects, or any operational behavior, leaving the tool incomplete for an agent to use 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning to the parameters, and the schema descriptions themselves are minimal but present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's verb ('vorbereitet') and resource ('WordPress-Content') with examples of content types (Posts, Pages). It is clear and distinct from siblings, though 'prepare' could be more specific about the actual export mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing side effects, permissions, or return behavior. It only states that a structure is generated, without clarifying whether this is a pure data transformation or a server-side side effect, nor what the output shape looks like. This ambiguity is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise, but it is under-specified rather than appropriately structured. It lacks necessary detail about parameters, output, or usage context, so it does not earn the highest score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a nested settings object, an output schema (as indicated by context), and many sibling tools, the description is too sparse. It does not explain the generated structure's format, content, or relationship to widget types, leaving an agent with insufficient information for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (widgetType with examples and settings), and the description adds no additional parameter details. With 100% schema coverage, the baseline of 3 applies; the description neither enhances nor contradicts the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Generiert' = generates) and resource ('Elementor Widget-Datenstruktur' = Elementor widget data structure), distinguishing it from retrieval/list siblings like elementor_get_widget or elementor_list_widgets. However, 'data structure' is somewhat vague and lacks specific scope, so it doesn't reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like elementor_generate_section or elementor_generate_container. The description provides no context for tool selection, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only states that it validates a token, but omits what happens with invalid tokens, whether it falls back to the current token when none is provided, or what the return format is. This is a significant transparency gap for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff, but it essentially restates the title 'JWT Token validieren'. While concise in length, it is under-specified and does not earn its place by adding new information, making it only average on this dimension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the presence of many sibling JWT tools, the description is incomplete. It fails to mention expected outputs, error behavior, or any contextual details that would help an agent use the tool correctly in different scenarios.
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 of the single parameter, including that it is optional and uses the current token if not provided. The description adds no further meaning, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Validiert' (validates) and the resource 'JWT Token', making the tool's basic purpose evident. However, it does not distinguish this tool from sibling JWT tools like jwt_authenticate or jwt_token_info, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other JWT-related tools. The description provides no contextual cues, alternative suggestions, or exclusions, leaving usage entirely implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the basic action. It does not mention pagination behavior, default return size, whether results are read-only, authentication needs, or any side effects. This lack of detail leaves important operational unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it largely restates the tool title 'WooCommerce Bestellungen auflisten', adding no new information. While succinct, it fails to earn its place by providing redundant rather than complementary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, and no output schema, a one-line description is insufficient. It does not explain what the response contains, how filtering parameters interact, or the safety profile of the operation, leaving substantial gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all six parameters (page, after, before, status, perPage, customer), so the baseline is 3. The tool description itself adds no parameter context, but the schema's brief descriptions like 'Seite' and 'Status' sufficiently convey basic parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Listet WooCommerce Bestellungen auf' clearly states the verb (list) and resource (WooCommerce orders), making the primary function obvious. However, it does not specify scope (e.g., all orders vs. filtered) or explicitly differentiate from sibling tools like woo_get_order, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as woo_get_order or woo_list_customers. The description simply states what it does, leaving the agent to infer usage context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states a read operation ('Ruft ab') without detailing what data is returned, whether results are paginated, if authentication or specific capabilities are needed, or any other operational nuances. This is insufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no superfluous words, but it lacks substance. It is minimally sized yet does not pack enough context to be highly useful; it is neither overly verbose nor richly informative, so a middle score is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and only a short generic purpose statement, the description is incomplete. It does not explain what 'registered string translations' means in the WPML context, how the optional parameters affect results, or what the agent should expect from the response. This creates ambiguity 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%, with both parameters (domain and language) having clear descriptions. The tool description adds no additional meaning beyond the schema, but since the schema fully documents each parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ruft registrierte String-Übersetzungen ab' clearly identifies the action (retrieve) and the resource (registered string translations), distinguishing it from sibling tools like wpml_get_post_translations. However, it does not explicitly contrast with alternatives, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other WPML tools, nor does it mention any prerequisites or contextual scenarios. There are no exclusions or alternative suggestions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses only the basic check action, without explaining the output format, read-only nature, or what constitutes 'accessibility' beyond alt texts. The scope is ambiguous: 'alle Bilder' suggests site-wide, while the postId parameter implies a single post, leaving the agent uncertain about the operational contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that communicates the core purpose efficiently. However, it sacrifices critical context, so while it is concise, it is under-specified rather than optimally balanced.
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?
With no output schema and no annotations, the description must compensate by explaining return values, side effects, and scope. It fails to clarify whether the check applies to all images in the post or site, what the tool returns (e.g., list of missing alts), and how it relates to the a11y_generate_report or image_find_missing_alt workflow.
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 fully describes the single parameter (postId - 'Post/Page ID') with 100% coverage. The description does not add any additional parameter semantics, such as whether postId is required for a specific scope or how it filters images, so it relies entirely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Prüft' - checks) applied to a specific resource ('alle Bilder' - all images) with a clear focus ('Alt-Texte und Accessibility'). However, it does not explicitly distinguish itself from close siblings like image_find_missing_alt or a11y_check_forms, making it less sharply differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives such as a11y_check_forms, image_find_missing_alt, or a11y_generate_report. There is no context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that it retrieves detailed information but does not disclose authentication requirements, response format, or potential error conditions, offering minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no superfluous words. It effectively communicates the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema and no annotations, the description is under-specified. It fails to clarify what 'detailed information' includes, how the user is identified, or any usage constraints, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter, which is already described as 'Benutzer-ID'. The description adds no additional meaning or context beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a user, with a specific verb and resource. It distinguishes from sibling tools like admin_delete_user and admin_list_users, though it could be more explicit about the single-user scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention admin_list_users or other user-related tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that a comment is created, with no mention of side effects, permission needs, default statuses, or whether the comment requires moderation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it largely duplicates the title and adds minimal value, so it is concise but not particularly informative.
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?
With 7 parameters, no annotations, and no output schema, this sparse description is insufficient for an agent to fully understand expected behavior, response format, or limitations. The schema covers parameter names but not operational 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?
All 7 parameters have schema descriptions, giving a schema description coverage of 100%. The description itself adds no parameter-level meaning, but with high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Erstellt einen neuen Kommentar' clearly states the action (creates a new comment) with a specific verb and resource. However, it does not differentiate from sibling tools like comment_reply, which may also create comments in a reply context, and largely rephrases the title without adding scope or constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as comment_reply or comment_update. There is no mention of prerequisites, requirements, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only says 'deletes a comment' without explaining that the 'force' parameter controls permanent deletion vs. trash, or what happens to the comment, permissions needed, or return behavior. The schema partially covers the force parameter, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is immediately understandable. It is front-loaded and contains no unnecessary words. However, it is arguably too terse, omitting valuable context that could be included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a potentially destructive operation, the description is incomplete. It fails to mention the trash vs. permanent-delete behavior (only in schema), the return value, or any caveats. For a delete tool, more context is needed for safe and correct usage.
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 parameters are already well-documented (commentId as number, force as a permanent-delete flag). The description adds no additional meaning beyond the schema, but since the schema is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Löscht einen Kommentar' clearly states the action (delete) and resource (a comment), matching the tool name. It is specific and unambiguous, but it does not explicitly differentiate from sibling tools like comment_moderate_bulk, which could also involve removal actions in a bulk context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or situations where another comment-related tool (e.g., comment_update, comment_moderate_bulk) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only restates the basic function. It doesn't disclose defaults (like status='approve'), pagination, return format, or any edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is well-sized for conveying the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, the description is too sparse. It doesn't mention return type, pagination, default filtering, or other operational context, leaving the agent under-informed about expected behavior.
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 schema fully documents all 7 parameters. The description adds no specific parameter meaning beyond the generic word 'filters', which doesn't compensate beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list') and resource ('comments'), and mentions filters. However, it doesn't explicitly differentiate from sibling comment tools like comment_get or comment_reply, though the name makes the purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It lacks context about use cases, exclusions, or distinguished behavior from other comment-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only says 'moderates' without mentioning potential destructive effects (e.g., delete or trash), whether permissions are required, or what the response contains. This is a significant gap for a tool that can modify or remove multiple comments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the key action and scope. It contains no fillers, but the extreme brevity means it sacrifices helpful context, making it slightly less than excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a simple schema, the tool is a bulk mutation operation with potentially significant side effects. The description omits return values, error handling, and warnings about permanent actions, leaving the agent under-informed. Output schema is absent, so the description should compensate but doesn't.
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?
Both parameters are documented in the schema with descriptions and one has an enum. The description adds no additional meaning about the parameters or their relationship, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Moderiert' (moderates) with resource 'Kommentare' (comments) and specifies 'mehrere ... auf einmal' (several at once), clearly indicating a bulk operation. This distinguishes it from single-comment tools like comment_update or comment_delete, though it doesn't enumerate the specific moderation actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to choose this tool over single-comment tools or other moderation functions. The description gives no context, prerequisites, or alternative references. The only hint is the 'bulk' aspect, but no direct instruction or exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'replies to an existing comment,' implying a write operation, but it does not mention permissions, whether the reply is immediately published, reversibility, error handling for non-existent comments, or any side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the action and target. It is front-loaded, contains no filler, and every word serves a purpose. It is appropriately sized for a simple tool, though it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no annotations and no output schema, the description gives the core purpose but lacks usage guidelines and behavioral transparency. While the low complexity and rich schema mitigate some gaps, the absence of when-to-use and effect information makes it only minimally adequate.
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 covers both parameters with high detail ('content' as 'Antwort-Inhalt' and 'commentId' as 'Kommentar-ID auf den geantwortet wird'), achieving 100% coverage. The description adds no additional parameter context beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Antwortet auf' (replies to) and identifies the resource 'bestehenden Kommentar' (existing comment), which clearly indicates the action and target. It implies a distinction from comment_create (which likely creates new top-level comments), though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like comment_create or comment_update. It does not mention prerequisites, exclusions, or typical scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, what the output format is, how the postId is used, or any potential side effects. The analysis scope is only vaguely described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that fronts the core action and resource. It contains zero wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple in parameter count but the analysis results are not described, and there is no output schema. The description fails to explain what the analysis returns or how the results relate to the layout aspects mentioned. For an analysis tool, this lack of expected output context is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (postId), which is described as 'Post/Page ID'. The description adds no additional meaning beyond that, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool analyzes the UI/UX layout of a page and names specific aspects (structure, hierarchy, spacing). This clearly identifies both the verb and the resource, but it does not explicitly differentiate from closely related sibling tools like elementor_analyze_structure or design_get_spacing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any exclusions. It merely states what the tool does, leaving usage context to be inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'exports' without stating whether this downloads files, returns a payload, triggers side effects, or requires special permissions. This leaves the operation's actual behavior completely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the verb upfront and no fluff. It is efficiently worded, though it omits mention of the default format (json) and result behavior, which would improve completeness without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the tool lacks an output schema and annotations, so the description should explain what the export returns (e.g., file download, JSON array, or URL). The current text leaves this ambiguous, making it incomplete for a tool that produces artifacts.
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 covers the single parameter with a description ('Export-Format') and an enum of four formats, giving 100% coverage. The tool description only repeats the idea of 'various formats' and adds no new meaning beyond the schema, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('exports') and specific resource ('all design tokens (colors, fonts, spacing)'), plus the available output formats. This distinguishes it from sibling tools that retrieve individual design values (e.g., design_get_typography) by emphasizing bulk export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The phrase 'alle Design Tokens' implies a bulk-export scenario, but there is no mention of exclusions, prerequisites, or comparisons to similar tools like design_generate_css_variables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It only says the tool 'shows' example configurations, implying read-only, but does not disclose output specifics, error behavior, or any side effects. The minimal detail limits 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 a single concise sentence that directly states the tool's purpose. It is well-structured and free of unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the existence of many sibling Elementor tools, the description is too sparse to provide complete operational context. It does not explain what an 'example configuration' consists of, how results are structured (though an output schema exists), or when to choose this over similar tools.
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 single parameter widgetType is thoroughly covered by the schema with an enum and description, achieving 100% coverage. The tool description adds a general context of 'common' widgets but does not further explain parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function with a specific verb ('Zeigt' = shows) and resource ('Beispielkonfigurationen für häufig verwendete Elementor Widgets'). It distinguishes from siblings by emphasizing 'common' configurations, though it could more explicitly contrast with tools like elementor_get_widget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no preferred scenarios, and no exclusions. It only states the basic function, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'generates', but does not disclose whether this modifies existing page content, requires permissions, or has any side effects. No details about what the output or side effects are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no fluff. It communicates the core purpose clearly, but is under-specified for more complex usage guidance. Still, it earns its place with zero waste.
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?
Although an output schema exists (so return values are covered), the description lacks broader context. It gives no prerequisites, use cases, or relationship to page data. For a tool generating a complex structure, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear German description. The tool description itself adds no parameter information beyond the schema, so the baseline of 3 applies. It does not clarify the enum meanings or widget array structure further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a complete Elementor section with columns and widgets, using a specific verb and resource. It distinguishes from sibling tools like elementor_generate_widget and elementor_generate_container by naming the section and its structure, though it doesn't explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or alternative tools like elementor_generate_container. The only implication is that it's for creating sections, but that is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply says 'retrieves statistics' without detailing what the statistics include, whether the operation is safe/read-only, or any side effects. This is a significant gap for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose efficiently. It is front-loaded with the verb and resource, and contains no unnecessary words, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is incomplete. It does not explain what statistics are returned, how to interpret them, or which plugins are covered beyond the schema. For a tool with three parameters, the description provides minimal 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?
The schema has 100% description coverage for all three parameters (formId, period, plugin), including enums and defaults. The description adds no additional meaning beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves statistics for form submissions, using a specific verb and resource. It is distinct from sibling tools like gf_get_entries or wpforms_get_entries, which return detailed entries rather than statistics, although it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to choose statistics over entry listing, nor any exclusions, making it difficult for an agent to know the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the analysis purpose. It does not state whether the tool is read-only, what kind of output to expect, or whether any side effects occur. This lack of transparency could mislead an agent into assuming it modifies images or returns a specific format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the verb 'Analysiert' and immediately communicates the tool's purpose. No structural improvements are needed for such a simple tool.
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 no output schema and only one parameter, but the description fails to mention what the analysis returns or how to interpret 'Optimierungspotential'. Without output schema or behavioral notes, an agent cannot anticipate the tool's response or what constitutes an optimization suggestion, making the description incomplete for practical 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?
The input schema fully describes the only parameter 'limit' with a clear description (Anzahl der zu analysierenden Bilder), giving 100% schema coverage. The tool description adds no extra meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analysiert Bilder auf Optimierungspotential' clearly states the action (analyzes), the resource (images), and the goal (optimization potential). It distinguishes itself from general image tools like image_get_details by focusing on optimization analysis, but it does not explicitly differentiate itself from similar analysis tools like perf_check_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions. The description simply states what the tool does, leaving the agent without context for selecting it among the many image-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only says 'retrieves', implying a read operation, but does not describe the return format, error behavior, or what specific details are included. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets to the point with no wasted words. It is appropriately sized for a simple tool, though it could benefit from additional details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what information is returned. It only vaguely says 'detailed information' without specifying fields, and it does not clarify how it differs from similar image/media tools. This under-specification makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with the mediaId parameter described as 'Media/Attachment ID'. The description adds no extra parameter semantics, but with full schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'retrieves' and the resource 'detailed information about an image', making the basic purpose clear. However, it does not distinguish this from sibling tools like wp_get_media or image_edit, which could also return image details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of preferred scenarios, prerequisites, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only adds that the token is set 'manually' and 'for the session', but does not state side effects, whether an existing token is overwritten, or if any validation occurs. This is insufficient for a session-affecting operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant content. It is concise and appropriately sized, though it adds only marginal information beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain the outcome of setting the token (e.g., success/failure, errors, return value). It does not, and the absence of usage context makes the tool under-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 100% description coverage ('JWT Token'), so the baseline is 3. The tool description adds no additional meaning beyond the schema; it simply repeats the parameter name without clarifying format, expiration, or origin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Setzt einen JWT Token manuell für die Session' (sets a JWT token manually for the session), which is a clear verb+resource+context. It adds the word 'manuell' (manually), which hints at the manual nature but does not explicitly differentiate from sibling tools like jwt_authenticate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as jwt_authenticate, jwt_validate, or jwt_refresh. It does not mention prerequisites, whether it should be used after authentication, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says information is shown. It does not clarify that this is a read-only operation, what information is returned, or how the optional token parameter interacts with the 'current' token. No side effects or failure modes are described.
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, short sentence with no filler words. It is front-loaded with the verb and clearly states the purpose, making it highly concise and well-structured.
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 no output schema and no annotations, so the description must explain what information is returned and how the optional token parameter affects behavior. It fails to do either, leaving significant gaps that prevent an agent from fully understanding the tool's output and usage.
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 fully documents the single optional 'token' parameter with a clear description ('Token zum Analysieren (optional)'), so the baseline is 3. The tool description adds no additional meaning beyond the schema, such as how the parameter modifies the 'current' token behavior, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Zeigt Informationen zum aktuellen JWT Token' clearly states the tool shows information about a JWT token, using a specific verb ('zeigt') and resource ('JWT Token'). It is concise and understandable, but it does not explicitly differentiate from sibling tools like jwt_validate, which may also examine tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as jwt_validate or jwt_set_token. The description does not mention exclusions, preferred scenarios, or how it relates to other JWT tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the tool is read-only, what it returns, whether it requires specific plugins (e.g., Yoast/RankMath), or any side effects. The description only lists analysis factors, leaving the agent without critical information about 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 a single sentence that is front-loaded with the action and includes relevant examples. Every word contributes to the purpose, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal for an agent to fully understand the tool's behavior, return value, or appropriate usage. It does not mention what the result looks like, whether it modifies anything, or how it fits with sibling SEO tools. More context is needed for a complex analysis 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 description coverage is 100%, and both parameters (postId, focusKeyword) are already described in the schema. The tool description adds some context by mentioning keyword density and readability, which relates to focusKeyword, but it does not meaningfully expand on parameter usage beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Analysiert Content auf SEO-Faktoren' (analyzes content for SEO factors) and lists examples like keyword density and readability. It is specific enough to distinguish from unrelated tools, though it does not explicitly differentiate from sibling SEO tools like seo_bulk_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without mentioning exclusions or comparing to related tools such as ux_analyze_readability or seo_get_post_meta. Given the large sibling list, the lack of context on when this tool is preferred is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'Generiert' (generates) but does not disclose whether this is a read-only transformation, what the output format is, or whether it modifies any post or settings. No side effects, permissions, or return behavior are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise and front-loaded with the core purpose. It avoids unnecessary verbosity, but the brevity sacrifices critical details (output, usage) and uses no structural elements like examples or conditions, so it earns a 4 rather than a 5.
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 moderate complexity (2 params, 1 enum) but no output schema and no annotations. The description fails to explain the return value (presumably JSON-LD markup), any prerequisites, or behavioral constraints. This leaves a significant gap for an agent to invoke the tool correctly, especially given the presence of related sibling tools.
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 describes both parameters: 'type' as a Schema.org type enum and 'data' as an object. The description adds no additional information about parameter usage, valid values, or relationships. With 100% schema coverage, the baseline score of 3 is appropriate since the description does not compensate for or enrich the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Generiert Schema.org Structured Data für verschiedene Typen' clearly states the action (generate) and resource (Schema.org structured data) with a scope (various types). However, it doesn't explicitly distinguish from the sibling 'seo_get_schema_from_post', which also deals with schema.org data, making the differentiation implied rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'seo_get_schema_from_post' (which retrieves existing schema) or 'seo_analyze_content'. No context, exclusions, or alternative tools are mentioned, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It indicates a read-only analysis ('analysiert') but does not disclose what the analysis returns, whether it modifies anything, or any side effects. The single sentence lacks behavioral detail beyond the implication of non-mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of unnecessary words. It efficiently conveys the core function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a one-sentence description, the tool lacks critical context about return values, scope of analysis, or criteria used. The low complexity of one parameter does not compensate for the absence of expected output information, making this insufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (postId as 'Post/Page ID') with 100% coverage. The description adds no parameter-specific meaning, but since the schema already covers it, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('analysiert') and resource ('Content') with a specific goal ('Mobile-Optimierung'). It distinguishes from sibling tools by focusing specifically on mobile-friendliness, though it could be more specific about what aspects of mobile optimization it checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like design_get_responsive_settings or ux_analyze_readability. There is no mention of exclusions or preferred contexts, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It merely states 'retrieves sales statistics' without indicating whether the operation is read-only, what the response structure looks like, or how date parameters influence the query. This is minimal and leaves the agent without important context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded and free of unnecessary text. It is concise but borders on being too terse, doing the minimum to convey the core purpose. Still, it earns points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should clarify what 'sales statistics' includes (e.g., revenue, order counts) and how the parameters interact (e.g., whether period overrides date range). It does neither, leaving the agent uncertain about the tool's behavior and return value.
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 full descriptions for all three parameters ('Zeitraum', 'End-Datum', 'Start-Datum'), giving 100% coverage. The tool description does not add any additional parameter semantics beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ruft Verkaufsstatistiken ab' clearly states the action (retrieve) and resource (sales statistics), giving a basic understanding of the tool's function. However, it does not differentiate this tool from sibling tools like woo_get_top_sellers, which also deals with sales-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether to use it for overall sales trends vs. top sellers, or when to use period vs. date range parameters. There are no context cues, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'lists with filters' and gives no information about pagination, default sort order, result limits, or any side effects. This is a significant gap for a tool with 13 parameters, leaving the agent unaware of response structure or operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It front-loads the core purpose and is easily scannable. However, it is arguably too brief to convey needed guidance, though that is a completeness issue, not a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 optional parameters, no output schema, no annotations), the description is woefully incomplete. It fails to explain pagination behavior, result limits, sorting defaults, or how filters interact. A one-sentence description cannot adequately cover this functionality.
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%, meaning every parameter already has a description (e.g., 'Tag-ID', 'Seite', 'Nur Sale Produkte'). The description adds little beyond the generic 'with filters', so it meets the baseline for schema-driven tools but provides no additional semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists WooCommerce products with filters, using the verb 'listet' and specifying the resource. While it doesn't explicitly name alternatives, the focus on products distinguishes it from sibling tools like woo_list_orders or woo_list_categories, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context about scenarios where listing products is appropriate, nor does it contrast with related list tools (e.g., woo_list_variations). This leaves the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'updates an existing product' and does not mention partial-update semantics, required permissions, side effects, or return value—critical omissions for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the action and resource. It is maximally concise while still conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the one-line description is insufficient. It does not clarify whether only provided fields are updated, the necessity of productId, or what the response looks like, making it incomplete 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?
Schema description coverage is 100%, with each parameter already documented in the JSON schema (e.g., 'Artikelnummer (SKU)', 'Produktname'). The tool description adds no parameter-level semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualisiert ein bestehendes WooCommerce Produkt' clearly states the action (updates) and the resource (existing WooCommerce product). 'Bestehendes' (existing) differentiates it from create or delete, but it does not explicitly name sibling alternatives, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like woo_create_product, woo_delete_product, or woo_get_product. The description only states the general update operation without context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action. It does not disclose pagination behavior, response format, or that entries are tied to a specific formId. The schema hints at pagination via page/perPage, but the description offers no behavioral detail beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, containing only the essential action. While it is not bloated, its brevity leaves out useful context that would make it more informative. It is appropriately sized for a simple tool but could be slightly richer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the sparse description, the agent cannot infer what a successful response looks like or how the parameters affect the results. The schema provides defaults, but the overall behavior and return structure remain unspecified, making this incomplete for a tool with this 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?
Schema description coverage is 100%, with all three parameters described (page, formId, perPage). The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ruft Formular-Einträge ab' clearly states a retrieval action targeting form entries, which is specific and unambiguous. However, it does not distinguish this tool from siblings like wpforms_list_forms or gf_get_entries, so an agent might not immediately know it is WPForms-specific and entry-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of how it relates to wpforms_list_forms (for listing forms) or other form plugins' entry tools, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only says 'creates a translation' without detailing side effects such as overwriting existing translations, requiring WPML configuration, or needing specific permissions. It does not mention what happens on failure or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's function. It is front-loaded and wastes no words. Although it might be too brief for the tool's complexity, it is not verbose, and every word earns its place. Similar single-sentence descriptions in the calibration examples scored 4.
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 mutation tool with no annotations, no output schema, and five parameters. The description provides only a minimal statement of intent, lacking essential context such as return values, behavior when a translation already exists, or relationship to WPML workflow. It does not address the complexity implied by the schema and sibling tools, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for parameter descriptions, so the baseline is 3. The tool description adds no parameter-specific information, but the schema already explains each field clearly (e.g., 'Übersetzter Titel', 'Original Post-ID', 'Zielsprache'). Thus, the description does not need to compensate, and a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: 'Erstellt eine Übersetzung für einen Post' (Creates a translation for a post). It identifies the verb (create) and resource (translation for a post), so purpose is clear. However, it does not differentiate from sibling tools like ml_duplicate_for_translation or wpml_get_post_translations, which also relate to translations, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without mentioning when it should be preferred over similar tools, such as wpml_get_post_translations for reading or ml_duplicate_for_translation for duplication. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. The description only says 'shows preview' with no mention of side effects, permissions, rate limits, return format, or whether the operation is read-only. This lack of context is a significant gap for a tool with no structured 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 a single, compact sentence that is front-loaded with the action. It contains no redundant words or filler, making it highly concise and easy to parse. Every word contributes to conveying the core function.
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 no output schema, so the description is responsible for explaining what the preview actually contains or returns. It merely states 'shows preview' without specifying whether the preview includes images, text, metadata, or how it is delivered. Given the low complexity (one parameter), some additional context about the return value is still necessary for an agent to understand the tool's behavior.
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% since the only parameter, postId, has a description ('Post/Page ID'). The tool description does not add any parameter-specific meaning, but according to the baseline for high schema coverage, a score of 3 is appropriate. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it shows a preview for social media shares on Facebook, Twitter, and LinkedIn. The verb 'zeigt' (shows) and resource 'Vorschau für Social Media Shares' are specific, and this distinguishes it from sibling SEO tools like seo_analyze_content or seo_get_post_meta, which focus on analysis or metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The only hint is the tool name and basic function, which is insufficient for an agent to decide when to prefer it over other SEO or preview-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Listet WooCommerce Kunden auf' (lists WooCommerce customers), offering no details on pagination, default role filtering, search behavior, or potential side effects. This is inadequate for a tool that appears to be a basic read 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 a single, straightforward sentence with no redundancy or unnecessary words. It is appropriately sized and front-loaded, delivering the key purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It does not explain return format, pagination defaults, or comparison with similar list tools, leaving gaps for an agent to make incorrect assumptions about behavior and output.
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 descriptions provide 100% coverage for all four parameters, but they are terse ('Seite', 'Rolle', etc.). The tool description adds no additional parameter meaning, so the baseline score of 3 applies, as the schema already 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 'Listet WooCommerce Kunden auf' uses a specific verb ('listet') and a clear resource ('WooCommerce Kunden'), distinguishing it from sibling tools like woo_list_orders or wp_list_users. It unambiguously states the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wp_list_users or admin_list_users. There are no mentions of prerequisites, exclusions, or specific scenarios, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only states what is retrieved, but does not disclose return format, error behavior, whether the fields are full definitions or just names, or any side effects. It implies read-only but doesn't confirm.
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, clear sentence with no redundant or filler content. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool, the description covers the basic purpose and scope. However, with no output schema and a large sibling set, it lacks guidance on what the 'details' include or how they are structured, and does not mention common usage contexts. It is minimally adequate.
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 describes the single parameter (groupId) as 'Field Group ID oder Key' with a type of number or string. The tool description adds no additional parameter meaning, so the schema's 100% coverage sets a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Ruft ab' = retrieves) on a specific resource ('Details einer Field Group') and mentions it includes all fields. This distinguishes it from list-type siblings like acf_list_field_groups, though it doesn't explicitly differentiate from other getter tools like acf_get_post_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many ACF-related siblings, the description provides no context such as 'use this to inspect a field group definition' or 'prefer this over acf_list_field_groups when you need a single group.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'updates' without disclosing whether fields are merged or replaced, whether it requires an existing user, what permissions are needed, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler. It is appropriately front-loaded with the action and resource, though it could be expanded without becoming verbose. Minimal size earns a high but not perfect score because it omits important behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too thin. It does not explain return values, merge semantics, error handling, or any caveats. The schema covers parameters, but the overall context is incomplete for an agent to use it safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (userId and fields as key-value object). The description adds no further meaning beyond the schema, which already explains the fields container and user ID. Baseline 3 is appropriate because the schema handles the parameter definitions adequately.
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 (Aktualisiert/updates) and a clear resource (ACF custom fields of a user), which distinguishes it from siblings like acf_update_post_fields and acf_get_user_fields. The title reinforces the user-specific target, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as acf_get_user_fields first to read fields or acf_update_post_fields for posts. There are no exclusions, prerequisites, or context hints, so the agent gets no help choosing among related ACF tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral traits itself. It only states the basic creation action and does not mention side effects, required permissions, duplicate handling, or return values, which are essential for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient, though it could be slightly expanded with usage context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the description provides only a one-line summary. It lacks essential contextual details such as what the tool returns, whether admin privileges are required, and how it interacts with the WordPress environment, making it incomplete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all 8 parameters are documented. The description adds no additional parameter semantics beyond what the schema already provides, matching the baseline for high schema 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 'Creates a new WordPress user' uses a specific verb and resource, clearly differentiating it from sibling tools like admin_update_user, admin_delete_user, and admin_get_user. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context about prerequisites, and no exclusions. It simply states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention side effects such as the site being inaccessible to visitors, the existence of the 'status' action, or any permission requirements. It is minimal and lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the core function. There is no redundant wording or unnecessary information, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with low complexity (2 parameters, one enum), the description is adequate but incomplete: it omits the 'status' action and does not explain the purpose of the 'message' parameter. The missing status action is a clear gap that affects overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema, but the schema itself adequately describes the parameters (action and message), so no further explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with specific verbs (activates/deactivates) and the resource (WordPress maintenance mode). However, it omits the 'status' action available in the schema, making the purpose slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or typical scenarios. It only states what it does, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of explaining behavior. It implies a read-only operation but doesn't disclose what specific information is returned, potential performance impact, or whether any permissions are required. This is insufficient for a system-info retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. Every word contributes meaning, with no filler or redundant repetition of the tool name.
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 is simple (no params, no output schema), but the description gives minimal context. It doesn't state what aspects of WordPress system information are included (e.g., version, php, server), nor how it differs from related tools like admin_site_health. This leaves the tool under-specified for an AI agent to select it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, and the schema coverage is 100% (vacuously). The description doesn't need to explain parameters, and the baseline for no-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Ruft ab' = retrieves) and identifies the resource ('WordPress System-Informationen'). It distinguishes the tool as a read-only info retrieval, but does not differentiate it from similar sibling tools like admin_site_health or wp_get_site_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description states only what it does, not the context or scenarios in which it should be preferred, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full disclosure burden. It only states the operation is a retrieval, implying read-only, but does not disclose what specific details are returned, error conditions, or any side effects. This is minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or verbose wording. It efficiently communicates the core purpose, though it lacks supplementary context. This is appropriately concise for a simple getter tool.
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?
There is no output schema, so the description should explain what kind of details are returned, but it does not. The vague term 'Details' leaves the response shape and content unspecified. More detail is needed for an AI agent to know what to expect.
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 single parameter formId with a clear description ('Formular-ID'). The description adds no additional semantic information about the parameter beyond the schema, so with 100% schema coverage, 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 tool retrieves details of a CF7 form. The verb 'Ruft ab' (retrieves) and resource 'Details eines CF7-Formulars' distinguish it from sibling tools like cf7_list_forms and cf7_update_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool instead of cf7_list_forms or how to obtain the formId. There are no alternatives, exclusions, or context to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state the output format, whether the operation is read-only or has side effects, or what the generated CSS looks like. The agent is left unaware of the return value, making the behavior opaque.
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 that communicates the core purpose without any wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return values and context. It fails to mention the output type or the effect of the three boolean parameters. Given the simplicity of the tool, a bit more detail would make it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. It does not mention includeColors, includeSpacing, or includeTypography at all. Though parameter names are somewhat self-explanatory, the description adds no semantic value beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Generiert CSS Custom Properties aus den Theme-Einstellungen' (generates CSS custom properties from theme settings). This distinguishes it from sibling getter tools like design_get_typography or design_get_customizer_settings, which retrieve settings rather than generate output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description only states what it does, not when to apply it or when to prefer design_export_tokens or other design tools. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Generates' implies a read-only operation, but the description does not disclose the output format (e.g., CSS string), whether it modifies any files or settings, or if it requires an active form plugin. This is minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it is under-specified, lacking useful detail that could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is inadequate. It does not explain what the generated CSS looks like, how the output is returned, or any side effects. The description is too minimal to fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for parameter descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond the schema; it does not explain how parameters like style, plugin, or primaryColor interact to produce the output.
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 'Generiert CSS-Vorlagen für Formular-Styling' clearly identifies the verb (generates), the resource (CSS templates), and the scope (form styling). It distinguishes the tool from siblings like design_generate_css_variables, which targets CSS variables rather than form templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., detecting a form plugin first), exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'retrieves details', which implies a read operation, but does not explain return format, error behavior, or authorization needs. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and communicates the core function efficiently, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 one parameter and no output schema, the description is minimally adequate. However, it lacks details about the response structure, possible errors, and how it relates to sibling forms tools, leaving gaps for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single parameter 'formId' as 'Formular-ID', achieving 100% description coverage. The description adds no additional parameter meaning, but the schema already provides the necessary information, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a Gravity Forms form, using a specific verb and resource. It distinguishes from sibling tools like gf_list_forms (which lists forms) and gf_get_entries (which retrieves entries) by focusing on a single form's details, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as gf_list_forms or gf_get_entries. It only states the action without context, prerequisites, or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description alone must disclose behavioral traits. It conveys that the tool performs mutations (updates) on multiple images, but it fails to mention important details such as whether the operation is reversible, whether partial failures are possible, or any permission requirements. The minimal wording 'Aktualisiert' leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly communicates the tool's purpose. There is no redundant content or unnecessary elaboration, making it highly efficient and front-loaded.
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 simplicity of the tool (one array parameter, no output schema), the description+schema provide adequate functional understanding for basic invocation. However, it lacks information about expected behavior, edge cases, or result handling, leaving room for more context around failed updates or bulk limitations.
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 is fully documented (100% coverage) with clear descriptions for the 'updates' parameter. The description adds minimal semantic value beyond the schema, merely confirming that multiple images are affected. Since the schema already defines the structure, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Aktualisiert Alt-Text für mehrere Bilder' clearly states the action (updates alt-text) and the resource scope (multiple images). It is unambiguous and distinct from sibling tools like image_update_meta or image_edit, though it does not explicitly name them as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as image_update_meta for single images or image_find_missing_alt for identifying images lacking alt text. There is no context about prerequisites, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says it detects the plugin without explaining whether it is read-only, what it returns, whether it caches results, or what side effects (if any) occur. For a detection tool this is likely safe, but the description does not explicitly say so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence ('Erkennt welches Multilingual-Plugin installiert ist') that is front-loaded and to the point. Every word earns its place with no padding or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what a successful detection returns (e.g., plugin slug, display name, or version). It also does not mention which multilingual plugins are covered (WPML, Polylang, TranslatePress). This leaves crucial information missing for an agent to understand the tool's full behavior.
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?
There are zero parameters, so the baseline is 4 per instructions. The description adds no parameter details because none exist. The schema is empty and the description's omission is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Erkennt' / detects) and a clear resource (which multilingual plugin is installed). It distinguishes from sibling multilingual tools like wpml_list_languages or polylang_list_languages by focusing on plugin detection rather than language operations. However, it remains somewhat vague about the output (e.g., plugin name vs. boolean), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention using it before wpml_* or polylang_* tools, nor does it exclude situations like 'when the plugin is unknown.' The context of use is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral transparency. It only describes the search scope and examples, but does not indicate whether the operation is read-only, how results are ordered or paginated, or any required permissions. This leaves the agent without critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the core action and scope, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with a fully described schema and an output schema, the description is minimally adequate but lacking in usage context and behavioral details. It does not explain the meaning of 'all WordPress content' beyond examples, nor does it address error cases or limitations.
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 descriptions for all four parameters with 100% coverage, including enums for 'type'. The description adds no additional parameter-level meaning beyond what the schema gives, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Durchsucht alle WordPress-Inhalte (Posts, Pages, Terms, etc.)', which clearly identifies a search action over WordPress content types. It is specific and understandable, though it doesn't explicitly contrast with sibling tools like rest_api_execute, relying instead on the verb 'search' for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It merely states what it does, without clarifying when it should be selected over other content-listing or REST API tools, nor does it mention any exclusions or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It simply says 'updates' which implies mutation but lacks detail on overwriting behavior, permissions required, or return values. No potential side effects or limitations are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded and easy to parse. However, it is so brief that it borders on under-specification, though this is more of a completeness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description is too sparse. It fails to mention that only provided fields are updated, that the Yoast plugin must be active, or what the tool returns. This leaves the agent without crucial operational 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?
The input schema has 100% description coverage, with each of the 12 parameters documented. The description itself adds no parameter information, but the baseline of 3 is appropriate since the schema already provides the necessary semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Aktualisiert' (updates) and the specific resource 'Yoast SEO Meta-Daten eines Posts' (Yoast SEO meta-data of a post). This differentiates it from sibling tools like seo_update_rankmath_meta and seo_get_post_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention compatibility requirements, when to avoid it, or contrast with seo_update_rankmath_meta. The only hint is the name, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description merely restates the tool name ('Ruft TranslatePress Konfiguration ab') without adding any behavioral details like read-only nature, error handling, or return format. It offers no information beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It front-loads the purpose. However, it is so brief that it borders on under-specification, providing no additional context beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the returned configuration looks like or mention any requirements. It does neither. While the tool is simple, an agent cannot infer the response structure or whether preliminary conditions (e.g., plugin installation) exist, leaving the description incomplete.
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?
With zero parameters, the schema fully covers all parameters (trivially). The description adds no extra semantics, but the baseline for 0 parameters is 4, as there is nothing to explain. The description is adequate in this dimension.
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: retrieving TranslatePress configuration. It uses a specific verb ('Ruft ab' = retrieves) and a specific resource (TranslatePress configuration), distinguishing it from sibling tools for WPML, Polylang, and other plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as whether TranslatePress must be active, or any context that would help an agent decide between this and similar tools like wpml_get_post_translations or polylang_list_languages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action ('updates the status') without revealing side effects, permission requirements, whether the note is appended or replaces existing notes, or any irreversible consequences. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is efficient and front-loaded, with no wasted words. It could be more informative, but conciseness is not about completeness; it earns a 4 for being appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and no annotations, the description is too sparse to provide adequate context. It does not mention the note parameter, expected response, or any behavioral details. A mutation tool with this complexity requires a more thorough description to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes descriptions for all parameters (100% coverage), so the baseline is 3. The description adds no extra semantic meaning beyond the schema, such as format hints or parameter relationships. It relies entirely on the schema for parameter understanding.
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 ('aktualisiert' = updates) and the resource ('Status einer Bestellung' = order status), making it unambiguous. It distinguishes itself from sibling tools like woo_get_order and woo_list_orders by specifying the update action on the status. The optional note capability isn't mentioned, but the core purpose is specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as woo_update_product or other order-related tools. There are no stated prerequisites, exclusions, or context for appropriate usage relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It only implies a read-only operation ('Holt') but does not specify what 'general information' includes, any side effects, or authentication requirements. This is too vague to be truly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. However, it essentially restates the title, so while concise, it adds limited informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero parameters) and has an output schema, which mitigates the lack of detail about return values. However, the description's vague 'general information' leaves the agent uncertain about the exact scope, making it minimally complete but with clear gaps.
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 schema already covers everything. The baseline for zero-parameter tools is 4, and the description adds no parameter-related meaning, which is acceptable given there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches general information about the WordPress installation, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like admin_system_info or admin_get_settings, which also return site-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool vs alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that appropriate permission is required, which is useful context. However, it does not describe any other behavioral traits such as whether the list is paginated, sorted, includes metadata, or whether it is strictly read-only. This is minimal disclosure for a tool that may expose sensitive user data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence and a parenthetical. Every word serves a purpose—the action and the permission requirement. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and no parameters, the description leaves out important context. It does not clarify how this differs from 'admin_list_users' or whether it returns the same result. It also lacks any mention of response format or scope limitations beyond 'all'. For a simple tool this may be acceptable, but the ambiguity with sibling tools makes it incomplete.
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 there is no parameter information to clarify. The description does not need to add parameter semantics. Baseline 4 is appropriate because the tool takes no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'Zeigt alle WordPress-Benutzer an' (shows all WordPress users). It uses a specific verb and resource, and adds scope ('all'). However, it does not differentiate from the sibling tool 'admin_list_users', which likely also lists users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'admin_list_users'. The only additional note is the permission requirement, which is a prerequisite, not a usage guideline. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It only says 'checks forms' without stating whether it modifies anything, requires permissions, or what the output format is. The read-only nature is implied but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key information: what is checked and on what resource. There is no unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., list of issues, score, etc.), but it does not. It also does not mention the postId parameter or any prerequisites. For a simple tool, this description is minimally adequate but leaves important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter postId, so the baseline is 3. The description adds no additional meaning about the parameter, but since the schema already documents it adequately, this is acceptable.
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 checks forms for labels, ARIA attributes, and accessibility. This is a specific verb+resource combination, and it distinguishes itself from sibling a11y tools by focusing specifically on forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning context, prerequisites, or exclusions. With many sibling a11y tools, a user might be unsure which one to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden, but it only states the action. It does not mention read-only behavior, error conditions, or what happens if ACF Pro is missing, though the parenthetical hints at a dependency.
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?
One short German sentence, front-loaded and free of fluff; every word is informative.
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 description is too sparse for a tool with no output schema. It doesn't describe the return format, whether it returns all fields or a subset, or the behavior when the options page doesn't exist. Minimal viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a clear description for optionsPage (ID/Slug) and a default. The tool description adds no extra semantic detail about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ACF Options Page fields, using a specific verb and resource. The explicit 'Options Page' distinguishes it from sibling ACF getter tools for posts/users/terms, and the ACF Pro note adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like acf_get_post_fields, nor any exclusions or prerequisites beyond the ACF Pro hint. The agent must infer usage from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic fetch operation and does not explain the return format, behavior on missing or non-repeater fields, or any other operational traits. Minimal disclosure beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler or redundancy. It directly and efficiently communicates the core purpose, with all words earning their place.
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 is simple, but without an output schema, the description should offer some indication of the returned structure or context (e.g., an array of rows). It also fails to position the tool among the many ACF-related siblings, leaving a completeness gap despite the simple nature.
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 full descriptions for both parameters (postId, fieldName) with 100% coverage. The description adds no additional parameter-level meaning, so a baseline of 3 is appropriate per the rubric.
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 ('ruft ab' - fetches) and clearly names the resource ('alle Zeilen eines Repeater-Feldes' - all rows of a repeater field). It distinguishes itself from sibling tools like acf_get_flexible_layouts or acf_get_post_fields by explicitly targeting repeater rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus other ACF getters. There is no mention of prerequisites, alternatives, or exclusion cases, leaving the agent to infer usage entirely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavior such as whether existing values are overwritten, if partial field updates are supported, or what the tool returns. The only extra detail is that it's an ACF Pro feature, which is minimal.
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, short sentence that immediately conveys the core purpose. It is front-loaded and free of unnecessary words, earning its place by succinctly naming the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation with no annotations and no output schema, the description is too sparse to be contextually complete. It omits usage context, behavior notes, and how it relates to sibling ACF update tools, leaving the agent to rely solely on the 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?
Both parameters are fully described in the schema (100% coverage), so the description adds little beyond the schema. The schema already explains 'fields' as a key-value object and 'optionsPage' with a default. The description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates ACF Options Page fields (ACF Pro feature). It uses a specific verb ('Aktualisiert') and resource ('ACF Options Page Felder'), and distinguishes from sibling tools like acf_update_post_fields and acf_update_user_fields by targeting options pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. Given the many sibling update tools (e.g., acf_update_post_fields, acf_update_user_fields), the description would benefit from explicitly stating it is for options pages only and not for other ACF field locations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action (creates) and the purpose (API access), but does not disclose side effects such as the password being shown only once, permission requirements, or whether it is irreversible. This is a significant gap for a credential-creating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that delivers the essential information without wasted words. It is appropriately concise for a simple creation operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and the schema covers parameters, there is no output schema and no annotations. The description omits crucial context such as what the function returns (e.g., the generated password or a success message) and any security implications. The agent would be left uncertain about the operational outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides (name, appId, userId). All parameters are adequately described in the schema itself.
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 'Erstellt ein neues Application Password für API-Zugriff' uses a specific verb (erstellt) and resource (Application Password), clearly distinguishing it from siblings like 'admin_list_app_passwords' and 'admin_delete_app_password'. It also adds the purpose 'für API-Zugriff', making the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or why one would choose this over listing or deleting app passwords. The context is minimal and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the delete action, without mentioning irreversibility, required permissions, or side effects (e.g., revoking existing tokens). The destructive nature is implicit but not elaborated.
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, complete sentence with no redundant words. It is maximally concise and front-loaded with the core action and object.
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?
As a destructive admin operation, the description lacks essential context: when to use it, post-deletion consequences, and the role of the optional userId. Without annotations or an output schema, the minimal text does not fully equip an agent to deploy 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 documents both parameters (uuid and userId) with descriptions, giving 100% coverage. The description adds no extra parameter meaning, so the baseline of 3 applies for high schema 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 clearly states the action ('Löscht ein Application Password' = 'Deletes an application password') with a specific verb and resource. It distinguishes from sibling tools like admin_create_app_password and admin_list_app_passwords by indicating the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus alternatives, such as when an application password is compromised or no longer needed. There are no prerequisites, exclusions, or references to related tools for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states that it checks health status, without disclosing whether this is read-only, what output format is returned, or any side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence in German that is front-loaded with the action and resource. No redundant 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?
For a zero-parameter tool, the description provides the basic purpose but lacks details on the return structure or what specific health checks are included beyond Security and Performance. No output schema exists, so more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is no parameter semantics to explain. The schema is trivially 100% covered. The description adds no param details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks WordPress Site Health Status, focusing on Security and Performance. It names a specific resource (WordPress Site Health) and a specific action (prüft/checks). It distinguishes from siblings like admin_system_info by specifying the health check focus, though it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus others. It simply states the function without indicating situations where it should be preferred over sibling tools like admin_system_info or wp_get_site_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool 'shows' status and method, but does not disclose what the response contains, whether authentication is required to call it, what methods are covered (cookie, JWT, etc.), or any error conditions. The description adds minimal value beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It contains no fluff or redundant information, making it easy to parse quickly.
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 has no parameters and no output schema, the description is minimally adequate. However, it lacks context about how the authentication status might be used (e.g., before performing authenticated actions) and what the output denotes, so the agent may not know what to expect from the call.
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, and the schema is empty. The description correctly does not attempt to explain parameters, and the baseline for a zero-parameter tool is 4 since nothing is needed to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('zeigt' / shows) and resource ('aktuellen Authentifizierungsstatus und -methode'), giving a specific purpose. It distinguishes from JWT-specific siblings by covering the general authentication status and method, but does not explicitly mention whether it refers to the current user or the site's auth configuration, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like jwt_validate or wp_get_current_user. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('gets') but does not disclose return format, permissions required, or potential side effects. The brief phrasing lacks meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. It contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and zero parameters, the description is adequate for basic comprehension. However, with no output schema, it does not clarify what the returned settings look like or how they might be structured, leaving some ambiguity.
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 schema coverage is effectively 100%. The description does not need to add parameter details; the baseline for zero parameters is 4, and the description does not introduce any confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Theme Customizer settings with specific examples (Site Identity, Colors). It uses a specific verb and resource, though it doesn't explicitly differentiate from sibling tools like design_get_theme_json or design_get_typography.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as design_get_theme_json or design_get_custom_css. The description provides no context for tool selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure but only states the core retrieval operation. It does not mention pagination behavior, default status filtering, or response format, leaving key behaviors undisclosed.
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 directly conveys the tool's purpose without superfluous words. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, and the description omits important contextual details such as pagination defaults, status enum nuances, and response structure. For a simple retrieval tool, it is minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with brief labels (e.g., 'Seite', 'Status'), so the baseline is 3. The description adds no additional 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?
The description clearly states the tool retrieves entries from a Gravity Forms form ('Ruft Einträge eines Gravity Forms Formulars ab'), specifying the verb and resource. It distinguishes from siblings like wpforms_get_entries by explicitly naming Gravity Forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as gf_list_forms or wpforms_get_entries. The description only states what it does, without mentioning selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation by saying 'Gets', but it does not disclose whether the result is a raw theme.json, merged with defaults, or any side effects. It also does not describe the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose without any filler. It is perfectly sized for a tool with no parameters and minimal complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter getter, the description is minimally viable but lacks detail. It does not mention what the output schema contains, nor does it compare with the presumably similar design_get_theme_json tool. Given the presence of an output schema, the description could have briefly specified what the response includes.
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 according to the criteria the baseline is 4. The description adds meaningful context by clarifying that 'global styles' refers to 'theme.json settings', which aids understanding even though there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Gets') and resource ('global styles (theme.json settings)'), making it understandable. However, it does not explicitly differentiate from the sibling tool design_get_theme_json, which likely serves a similar purpose, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Given the existence of design_get_theme_json and other design tools, the description should have mentioned when to prefer this tool, but it provides no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The verb 'Regeneriert' implies a mutating operation, but the description does not warn that existing thumbnail sizes will be overwritten, nor does it mention potential performance impact or whether originals are affected.
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, front-loaded with the verb and resource. It contains no filler, redundancy, or unnecessary detail.
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?
Although the schema covers both parameters, the overall description lacks behavioral context and usage guidance for a mutation tool. With no annotations and no output schema, the description is not fully complete for an agent to safely select and invoke the 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 description coverage is 100%, with both mediaIds and onlyMissing having clear descriptions. The tool description adds no parameter-specific meaning beyond the schema, 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 specific verb 'Regeneriert' (regenerates) and clearly identifies the resource 'alle Bildgrößen' (all image sizes) for one or more images. This clearly differentiates it from sibling tools like image_list_sizes or image_edit by focusing on the regeneration action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as image_edit or image_update_meta. It does not state prerequisites, exclusions, or situations where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It fails to state whether updating is partial (only provided fields are changed), whether empty strings clear fields, or what permissions are needed. It also does not mention side effects or response behavior. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. It contains no filler words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits the 'caption' field present in the schema, and does not explain partial update semantics or required permissions. Given no output schema and no annotations, the description should provide more context for safe invocation, but it is minimal and incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all five parameters (100% coverage), so the baseline is 3. The description merely lists three of the fields and does not add extra semantics like the requirement to provide at least one updatable field, partial update behavior, or how fields interact. It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Aktualisiert') and the resource ('eines Bildes'), listing the specific fields (Alt-Text, Titel, Beschreibung). This distinguishes it from sibling tools like image_edit (which likely edits the binary file) and image_bulk_update_alt (which performs bulk updates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For instance, it does not mention that image_bulk_update_alt is for bulk updates or that image_edit is for file editing. There are no exclusions or context for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, permissions, or workflow implications. It only says 'creates a copy' without explaining whether the original is modified, how the language linkage works, or what the response contains.
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, efficient sentence that front-loads the core action and purpose. No unnecessary 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?
Given the absence of annotations and output schema, the description is too sparse to fully understand the tool's behavior in the translation workflow. It doesn't explain how the duplicate is created, what status is used (though schema says default), or how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. However, the tool description doesn't add meaning beyond the schema; the parameter descriptions are minimal but present, so a 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 action ('Erstellt eine Kopie') and the resource ('eines Posts'), specifying the purpose ('als Übersetzungsvorlage'). This distinguishes it from related tools like wpml_create_translation or ml_translation_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as wpml_create_translation or polylang_link_translations. The description only states the function, without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral burden. It only states the basic function and omits what 'progress' means, how postType affects results, or any permissions/limitations. This is minimal transparency for a tool with no annotation support.
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, front-loaded, and contains no redundant or extraneous content.
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?
With no output schema and no annotations, the one-line description is insufficient. It does not explain what 'translation progress' includes, how postType filters the data, or what format the results take. Given the many related translation tools, this lacks the context needed for confident 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 coverage is 100% with the parameter clearly documented ('Post-Typ' with enum). The description adds no additional parameter meaning, so 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?
Description 'Zeigt Übersetzungsfortschritt für alle Sprachen' clearly states the tool shows translation progress for all languages, with a specific verb and scope. It distinguishes itself from siblings like ml_list_untranslated and wpml_get_post_translations by focusing on overall progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools like ml_list_untranslated or wpml_get_post_translations, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the high-level action without explaining whether existing translation links are overwritten, how the mapping is validated, or what response is returned. This leaves significant behavioral uncertainty for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded with the action and purpose, making it easy to parse quickly.
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?
Although the parameter is well-documented, the description lacks any behavioral side-effect information, and there is no output schema to clarify the return value. For a mutation tool with no annotations and many multilingual siblings, this leaves the context incomplete.
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 fully covers the single parameter 'translations' with a description of 'Objekt mit Sprach-Slug als Key und Post-ID als Value', so the baseline is 3. The tool description itself adds no parameter-level detail, so it does not exceed that baseline.
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 'Verknüpft Posts als Übersetzungen voneinander' clearly names the action (verknüpft) and resource (Posts), and specifies the purpose as creating translation links between posts. This distinguishes it from sibling tools like polylang_set_post_language, which sets a single post's language, and wpml_create_translation, which creates a translation content item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as requiring existing posts or language configuration, nor does it direct the agent to sibling tools like polylang_list_languages for language setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it deletes a revision, without highlighting irreversibility, permission requirements, or any constraints such as whether the latest revision can be deleted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that is front-loaded and contains no filler. It communicates the core action with maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the description lacks essential context about side effects, permission needs, and success/failure responses. It is minimally viable but leaves significant gaps for an agent deciding whether to invoke it.
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 all three parameters (postId, postType, revisionId) have descriptions in the schema. The tool description adds no parameter semantics, so the schema already carries the load, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Löscht') and target ('eine spezifische Revision'), clearly distinguishing it from sibling tools like revision_get, revision_restore, and revision_cleanup. It unambiguously states the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention bulk operations like revision_cleanup or restoration via revision_restore, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'full content' but does not disclose read-only nature, potential errors, authentication needs, or what exactly is returned. The description adds minimal context beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. It effectively communicates the core function. However, it is slightly under-specified for a tool with siblings, missing context that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description gives a basic understanding of the return value ('full content'). Yet it lacks details on the output structure or any side effects, which is a moderate gap given the absence of annotations and 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 covers all three parameters with descriptions, achieving 100% schema description coverage. The tool description adds no additional parameter information. Baseline of 3 is appropriate since 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 clearly states the tool retrieves the full content of a specific revision, using a specific verb ('Ruft...ab') and resource ('vollständiger Inhalt einer spezifischen Revision'). It distinguishes from sibling tools like revision_list or revision_compare by focusing on content retrieval for a single revision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer revision_get over revision_list or revision_compare, or any exclusion criteria. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only restates that the tool lists revisions, without adding context about safety (read-only nature), permissions, ordering, pagination, or return format. This is a minimal disclosure barely exceeding the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. There is no unnecessary verbiage, and it earns its place by stating the core purpose without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential return-value information. Since there is no output schema, the agent cannot infer what a successful response looks like (e.g., an array of revisions, revision IDs, or metadata). It also does not mention pagination or any limits, leaving a significant gap for an unannotated read 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%, so both postId and postType are already documented in the schema. The description adds no extra meaning about parameters, so the baseline of 3 applies. It does not explain how parameters affect the listing or how to use postType.
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 ('Listet alle Revisionen') and the specific resource ('eines Posts/einer Seite'). It distinguishes the tool from sibling revision tools like revision_compare, revision_restore, and revision_delete by focusing on the listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context such as 'use this to view revision history' or 'for comparing revisions, use revision_compare'. Usage is only implied by the tool's name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It only states that the tool analyzes posts for SEO issues, but does not clarify whether it is read-only, what kind of results it returns, or any side effects. This lack of behavioral disclosure forces the agent to assume the operation is non-mutating and purely diagnostic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without redundancy. It is front-loaded and efficiently worded, earning the highest score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is not sufficiently complete. It does not explain what the tool returns (e.g., a list of issues, a report, a score) or any operational details such as pagination or error behavior. This is a clear gap for an agent that needs to correctly invoke the tool and interpret its result.
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 all three parameters (limit, status, postType) with 100% coverage. The tool description adds no additional parameter semantics. The baseline score of 3 is appropriate given the schema's completeness.
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: 'Analysiert mehrere Posts auf SEO-Probleme' (analyzes multiple posts for SEO issues). It specifies a verb (analysiert), a resource (mehrere Posts), and a purpose (SEO-Probleme), making its role distinct from single-content SEO analysis tools like seo_analyze_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The word 'mehrere' implies bulk analysis, but there is no explicit differentiation from single-post analysis tools or any mention of when-not-to-use. The description offers no context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only restates the read action. It fails to disclose what specific sitemap information is returned, whether an external request is made, or any potential side effects beyond the implied 'retrieve'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately concise for a zero-parameter retrieval tool.
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?
With no output schema or annotations, the description should reveal what kind of sitemap information is returned (e.g., URL count, last modified, entries). The current text is adequate but lacks these specifics.
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 takes zero parameters, so the input schema is trivially complete. The description does not need to explain parameters, and the baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Ruft ab' / retrieves) and a specific resource ('XML-Sitemap'), making the tool's purpose understandable. It differentiates from sibling SEO tools by focusing on the sitemap, but it does not explicitly contrast with other 'seo_get_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, excluded use cases, or why an agent would choose this over sibling SEO analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of disclosing behavioral traits. It fails to mention whether updates are partial or full, whether existing meta fields are overwritten, any permission requirements, or error handling behavior. This leaves the agent without critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the tool's purpose with no fluff or redundancy. It is front-loaded and every word contributes to understanding the core function, making it highly efficient.
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?
With no output schema and no annotations, the description fails to explain what happens after the update (e.g., return value, success message, or updated post object). It also doesn't clarify partial update semantics or any validation behaviors, leaving the agent under-informed for a mutation tool with 10 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptive names and field-specific descriptions for all 10 parameters (title, description, robots, ogTitle, etc.). The description adds no additional semantic meaning beyond the schema, 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 'Aktualisiert RankMath SEO Meta-Daten eines Posts' uses a specific verb (updates) and identifies a clear resource (RankMath SEO meta data of a post). It distinguishes itself from the sibling tool seo_update_yoast_meta by explicitly naming RankMath, making its 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without offering context on when it should be selected over seo_update_yoast_meta or seo_get_post_meta.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it 'finds and analyzes' CTAs, without mentioning side effects, permissions, return format, or limitations. The read-only nature is implied but never explicit.
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 short sentence that gets straight to the point. It is appropriately concise with no redundant information, though it could have included more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description remains incomplete. It doesn't clarify what the analysis yields (e.g., a list, scores, categories) or what behavioral expectations exist, leaving the agent guessing about the result.
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 a description for postId ('Post/Page ID'), achieving 100% coverage. The tool description adds no additional meaning to the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Findet und analysiert CTAs auf einer Seite' (finds and analyzes CTAs on a page). It identifies a specific resource (CTAs) and scope (a page), distinguishing it from sibling tools like readability or layout analysis. A clear verb-resource pairing earns high marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any conditions, exclusions, or relationships to sibling tools, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a coupon is created, but does not mention side effects, permission requirements, behavior on duplicate codes, or whether changes are reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. It contains no filler or redundant information, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters and no output schema, the one-sentence description is inadequate. It does not explain expected return values, error conditions, or validation requirements. The description is minimal and relies entirely on the schema, which is not enough for a complex creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 13 parameters having descriptions. The tool description adds no parameter information beyond the schema, so the baseline score of 3 is appropriate. The description does not compensate for any gaps because there are none 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 clearly states the verb 'Erstellt' (creates) and the specific resource 'neuen WooCommerce Gutschein' (new WooCommerce coupon). This distinguishes it from sibling tools like woo_list_coupons and woo_create_product, which target different resources or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to use this tool versus alternatives, no prerequisites (e.g., WooCommerce being active), and no exclusions. The only implied usage from the verb 'creates' is not sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only says 'fetches' and does not mention whether the operation is read-only, how the period parameter affects results, whether there is a default limit, or what the return structure looks like. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no wasted words. It is front-loaded with a clear verb and resource, making it easy to parse at a glance. Given the simplicity, this level of conciseness is appropriate, though it sacrifices completeness.
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 is simple but the description is very thin. There is no output schema, so the description should explain what the response includes (e.g., product IDs, quantities, dates). Nor does it mention the 'period' parameter, which is the only input, or how this report differs from the sales report. The minimal context makes it hard for an agent to understand the exact scope and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single parameter 'period' and a description 'Zeitraum'. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies. It does not clarify how period values (week, month, last_month, year) influence the aggregation or if any other filtering exists.
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 'Ruft die meistverkauften Produkte ab' clearly states the action (fetch) and the resource (best-selling products). It distinguishes itself from sibling tools like woo_get_sales_report or woo_list_products by focusing specifically on top sellers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as woo_get_sales_report or woo_list_products. There are no exclusions or context hints to help an agent decide between similar WooCommerce reporting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention that the operation is read-only, that the parent parameter filters results contrary to the word 'alle' (all), or any details about permissions or return behavior. This is a significant gap for a 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 a single, focused sentence with no filler or redundancy. It is front-loaded with the action verb and is appropriately concise for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the tool, the description is incomplete. Without an output schema, it fails to describe the return value (e.g., fields like ID, name, slug). It also does not clarify the default behavior regarding parent/child categories, leaving ambiguity about what 'all' means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already explains both parameters. The description adds no extra meaning beyond the schema, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Listet alle Produktkategorien auf' clearly states a specific verb (list) and resource (product categories), distinguishing this tool from sibling tools like woo_list_products or wp_list_categories. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It simply states what it does without mentioning any exclusions or context, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says "lists all coupons" without detailing pagination behavior, response format, or any side effects. It doesn't mention that perPage defaults to 20 or that results may be limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is immediately understandable. It contains no filler and is appropriately front-loaded with the action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description should explain what the response looks like or how the list is returned. It lacks this detail, making it incomplete for an agent that needs to know the return structure. It also doesn't mention the optionality of parameters or default behavior.
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 each parameter has a description in the schema (page, search, perPage). The description adds no additional semantic information beyond what the schema already provides, 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 specific verb "Listet auf" (lists) with the resource "WooCommerce Gutscheine/Coupons", making the tool's purpose unambiguous. It clearly distinguishes itself from sibling tools like woo_list_products or woo_list_orders by specifying coupons.
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, nor any exclusions. It only states what the tool does without contextualizing its use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It only states the action (creates a post) and does not mention authentication requirements, side effects, default status, or what happens on success. The output schema exists but does not cover behavioral traits like permission needs or irreversible actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, directly stating the purpose. It is concise and front-loaded. Though it lacks additional context, it is not bloated or padded, so it earns a high score for conciseness.
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 output schema covers return values and the schema covers parameters, the description only needs to clarify purpose and usage. It does that minimally but lacks any context about when to use it, default behavior, or relationships to sibling tools. For a tool with 7 parameters and no annotations, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters with descriptions. The description itself adds no parameter-level information beyond what the schema already provides, which meets the baseline 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 'Erstellt einen neuen WordPress-Beitrag' uses a specific verb (erstellt) and resource (neuen WordPress-Beitrag), clearly distinguishing this from update/delete tools and from page/product creation. It is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wp_create_page or wp_update_post. There are no use cases, exclusions, or context that would help an agent decide between this and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that it retrieves translations, but does not mention read-only safety, required permissions, error behavior (e.g., no translations found), or what the response structure looks like. This is a minimal level of transparency for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without any wasted words or redundant information. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description fails to provide essential context such as the format of the returned translations, whether the original post is included, or how missing translations are handled. For a tool with one parameter, the description is minimal but does not fully cover what the agent needs to know about the response.
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% (postId is documented as 'Post-ID'). The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 applies per the rubric when schema coverage is high.
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: 'Ruft alle Übersetzungen eines Posts ab' (retrieves all translations of a post). This is a specific verb+resource combination that distinguishes it from sibling tools like wpml_get_string_translations or polylang_get_post_language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as wpml_create_translation or other translation-related tools. There is no mention of prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states that the tool updates a post, without mentioning that it may overwrite existing fields, whether unspecified fields remain unchanged, whether specific permissions are required, or what the response format is. This lack of detail is a significant gap for a mutating 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 a single, concise sentence that communicates the core function without any unnecessary words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks critical behavioral context for an update operation. It does not explain how partial updates work, whether setting fields to null is possible, or what the result indicates. The combination of no annotations and a minimal description makes this tool under-specified for reliable agent 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?
The input schema provides detailed descriptions for all 8 parameters (100% schema coverage), so the description doesn't need to add parameter-level details. The baseline of 3 is appropriate because the schema already covers parameter semantics effectively; the description adds no additional insight beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Aktualisiert einen bestehenden WordPress-Beitrag' (Updates an existing WordPress post). It specifies a concrete action (updates) and resource (existing WordPress post), distinguishing it from siblings like wp_create_post, wp_delete_post, and wp_update_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context such as 'use for modifying an already published post.' The only implicit information is from the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the analysis purpose; it does not mention that it's a read-only operation, describe what the output looks like, or address any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple check tool but lacks details about return format, scope, or usage context. Without an output schema or annotations, it should provide more context on what the user will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single optional parameter (postId), so the baseline is 3. The description adds no extra parameter context, but the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Analysiert') and resource ('Farben') tied to WCAG compliance, distinguishing it from sibling a11y checkers like a11y_check_forms or a11y_check_images.
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?
Provides no guidance on when to use this tool versus the other a11y checkers. It only states the purpose without any contextual usage instructions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details such as whether the report is read-only, what data it aggregates, how the report is returned, or if any side effects occur. The description only states the outcome, not the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to parse. However, it is under-specified, lacking important context, which prevents a 5.
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?
With no output schema and no annotations, the description should explain what the report contains and how it is delivered, but it does not. The tool appears to be a comprehensive report generator, yet the description gives no details about report content or processing behavior.
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 fully describes the only parameter postId as 'Post/Page ID' (100% coverage). The description adds no additional parameter semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a complete accessibility report for a page, using the specific verb 'Erstellt' and resource 'Accessibility-Report'. It distinguishes from sibling a11y_check_* tools that focus on individual aspects like forms, contrast, or images.
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 does not explicitly state when to use this tool versus the individual a11y_check_* tools. There is no mention of alternatives or conditions. The usage context is implied by the word 'vollständigen' but not explicitly clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info, but it only states the action (retrieves all layouts) without disclosing output format, empty result handling, or error behavior. It adds no behavioral context beyond the purpose itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word earns its place, making it highly concise and well-structured.
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?
This is a simple 2-parameter retrieval tool with no output schema or annotations. The description conveys the core function but omits return value details (e.g., array of layout objects) and any context on when it's appropriate, making it minimally complete but with clear 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 description coverage is 100% for both parameters (postId as 'Post/Page ID' and fieldName as 'Flexible Content Feldname'). The tool description adds no parameter-level meaning beyond the schema, 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 'Ruft alle Layouts eines Flexible Content Feldes ab' clearly states the tool retrieves all layouts of a flexible content field, with a specific verb and resource. It distinguishes from sibling ACF tools like acf_get_repeater_rows, which handle repeater fields, by explicitly targeting flexible content layouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention scenarios for flexible content fields or exclude repeater fields, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'abrufen' implies a read-only operation, but the description adds little beyond the title and name. It does not disclose error behavior, return format, or whether any side effects occur (e.g., caching).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly conveys the tool's purpose without filler. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers its primary purpose, but there are gaps. With no output schema, the description should ideally mention return behavior. It also omits that custom post types are supported (per the schema's customPostType parameter), and it lacks guidance on when to use this over related ACF tools.
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 covers all three parameters with descriptions (postId, postType, customPostType), so the schema carries the parameter semantics. The description does not add meaning beyond the schema, but that is acceptable given the high schema 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 states a specific verb ('Ruft ab' - retrieves), a clear resource ('alle ACF Custom Fields'), and the scope ('eines Posts/einer Seite' - of a post/page). This distinguishes it from sibling tools like acf_get_options or acf_get_user_fields, which target different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as acf_bulk_get_fields, acf_get_options, or acf_get_user_fields. It simply states the function without context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the basic action and resource, but does not disclose return format, default behavior, potential errors, or permission requirements. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in German that directly states the tool's purpose. It contains no unnecessary words or repetition, making it efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description covers the core function. However, there is no output schema and no annotations, so the description does not explain what the return value contains or any edge-case behavior. It is minimally viable but lacks richness that would make it fully complete in 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?
The input schema provides a clear description for the userId parameter ('User ID'), achieving 100% schema description coverage. The tool description adds no extra parameter semantics, but the baseline of 3 is appropriate since the schema already documents the parameter sufficiently.
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 'Ruft ab' (retrieves) and the resource 'ACF Custom Fields eines Benutzers' (ACF custom fields of a user). This is specific and distinguishes it from siblings like acf_get_post_fields and acf_get_term_fields, which target different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare with sibling getter tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions that the operation is conditional on REST availability, but does not warn that flushing cache is destructive to cached data or may temporarily impact performance. Also, the description's focus on 'Object Cache' conflicts with the parameter's broader 'all' and 'transients' options, adding confusion.
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, front-loaded with the action and resource, and contains no redundant phrasing. Every word earns its place.
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 description is too sparse for a tool with a parameter and no output schema. It omits behavior on success/failure, side effects, and the meaning of the three cache type options. The REST-availability caveat is helpful but insufficient for an agent to understand the full impact of invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the parameter with an enum and description, but the tool description does not elaborate on the differences between 'all', 'transients', and 'object'. In fact, it narrows the tool to 'Object Cache', potentially misleading an agent about what 'all' or 'transients' do. The description adds no value beyond the schema and may even contradict 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 clearly states the action ('Leert' = clears) and the target resource ('WordPress Object Cache'), with a conditional scope ('falls verfügbar via REST'). This is specific and distinguishes it from sibling admin tools, none of which flush cache.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are provided. The condition 'if available via REST' implies a prerequisite, but there's no 'when to use' or 'when not to use' direction. The context is merely implied by the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only gives a brief action without details such as read-only nature, auth requirements, error behavior, or return format. The term 'ruft Details ab' implies a safe read but does not explicitly state it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of filler. It immediately conveys the core purpose without unnecessary detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-comment fetch with one parameter, the description covers the basic purpose. However, it lacks guidance on expected output, error cases, or usage context, which would help an agent fully understand the tool's behavior. Given low complexity, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter 'commentId' described as 'Kommentar-ID'. The description adds no extra semantic meaning beyond the schema, so 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 'Ruft Details eines einzelnen Kommentars ab' clearly states the tool's function: retrieving details of a single comment. This is a specific verb+resource combination that distinguishes it from siblings like comment_list (lists comments) and comment_update (modifies comments). The resource is uniquely identified, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states the action without context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the retrieval action but does not disclose return format, potential empty results, or read-only nature, leaving the agent without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose without unnecessary words. However, it sacrifices informative detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what the tool returns (e.g., CSS string) but does not. For a simple getter, this is a notable gap.
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, and the schema is empty. The baseline for no parameters is 4; the description appropriately adds no parameter information since none exist.
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 'Holt das benutzerdefinierte CSS aus dem Customizer' clearly specifies the action (gets custom CSS) and resource (Customizer), distinguishing it from sibling tools like design_get_typography or design_get_customizer_settings.
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, nor does it mention any prerequisites or exclusions. It simply states the function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'generates' without disclosing whether the operation is destructive, how it integrates with the page, whether it returns a new ID, or any permissions/limitations. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loaded with the core action. However, it is quite minimal for a tool with 5 parameters and might benefit from a bit more detail, though it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 optional params, no annotations, and an output schema not shown in the description), the description offers insufficient context. It does not explain what an Elementor container is, when you'd create one, or how it relates to widgets/sections. The agent would have to rely on the schema and name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (gap, align, justify, widgets, direction) has a description. The tool description adds only 'Flexbox-based' context, which indirectly relates to the alignment/direction parameters, but does not provide deeper 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?
The description 'Generates a modern Elementor Container (Flexbox-based)' clearly states the verb (generate), the resource (container), and distinguishes it from sibling tools like elementor_generate_section and elementor_generate_widget. The Flexbox-based note adds specific value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a container is needed, but it does not explicitly mention when to use this tool over alternatives like generate_section or generate_widget. There is no when-not or exclusion guidance, only a basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states that it generates HTML. It does not mention whether it validates block types, handles errors, or is a pure function with no side effects. This lack of behavioral disclosure is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence in German, front-loading the core action and resource with no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple purpose and the presence of a full input schema and output schema, the description is minimally sufficient. However, it lacks usage context and does not mention the content parameter, making it less complete than ideal for an agent selecting among many Gutenberg tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema, so the baseline is 3. The tool description merely reiterates that generation is based on block type and attributes, adding no new detail about the content parameter or attribute formatting.
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 'Generiert' (generates) and identifies the resource as 'HTML-Code für einen Gutenberg Block' (HTML code for a Gutenberg block), clearly distinguishing it from sibling tools that list, parse, or manage blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like gutenberg_parse_blocks or gutenberg_list_block_types. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states only that the tool parses HTML and extracts block structure, but omits details such as input format expectations (raw HTML vs. serialized block comments), error behavior for invalid content, or whether it handles nested blocks in a specific way. The operation appears read-only, but that is 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 a single, compact sentence with the key action and object front-loaded. It contains no filler or repetition, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter parse tool, the description provides a basic 'what' and 'result' but lacks behavioral caveats and usage context. The presence of an output schema somewhat offloads return-value details, but no annotation coverage and minimal behavioral disclosure leave gaps. It is adequate but not comprehensive.
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% since the single parameter 'content' has a description ('Der HTML/Block-Content zum Parsen'). The tool description adds context by specifying this is post HTML content, but it does not materially expand on the parameter's meaning beyond the schema. The baseline of 3 is appropriate as the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Analysiert den HTML-Content eines Posts und extrahiert die Gutenberg Block-Struktur') and names the resource (HTML content) and outcome (Gutenberg block structure). It distinguishes itself from sibling tools like gutenberg_generate_block or gutenberg_list_block_types, which focus on creation or listing rather than parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It simply describes the function without mentioning preferred use cases, prerequisites, or in which contexts another tool would be more suitable. The lack of any comparative or conditional advice leaves the agent to infer the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not mention whether the operation is read-only, what the return format is, or any side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It conveys the core functionality efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the essential purpose, but it lacks details about the output format (e.g., list of image IDs or URLs) and does not mention the limit parameter context. Without an output schema, these gaps prevent a higher score.
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 covers the only parameter 'limit' with a description ('Maximale Anzahl'), so schema description coverage is 100%. The tool description does not add parameter information, but the schema already provides sufficient meaning, yielding the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Findet alle Bilder ohne Alt-Text' clearly states the verb (find), the resource (images), and the specific condition (missing alt text). This distinguishes it from sibling tools like image_find_unused or image_analyze_optimization, which target different image issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning when to prefer it over a11y_check_images or image_bulk_update_alt, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'renews the current JWT token' but does not explain side effects (e.g., whether the old token is invalidated), prerequisites (e.g., a valid refresh token), or what happens if no token is present. This is insufficient for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without any filler or repetition. It is front-loaded with the key action. However, it is almost too brief, lacking context that might be necessary, but for conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a security-related tool with no output schema and no annotations, the description is notably incomplete. It does not explain what the renewal entails, the return value, error conditions, or how it interacts with the authentication flow. Sibling tools like jwt_token_info and jwt_validate suggest there is more context, but this description fails to provide 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?
The tool takes no parameters, and the schema is empty. The description adds value by specifying that the operation acts on the 'current' JWT token, implicitly clarifying that no parameter is needed because it targets the existing session token. This meets the baseline for zero-parameter tools.
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: renewing the current JWT token. The verb 'erneuert' (renews) is specific and differentiates it from sibling tools like jwt_validate or jwt_set_token, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as jwt_authenticate, jwt_validate, or jwt_set_token. It does not mention whether it should be used after token expiration or before validation, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what is analyzed (size, format, lazy-loading) but does not disclose what the output looks like, whether it is read-only, how results are returned, or whether it checks a specific post's content or featured images. This is a significant transparency gap for a tool with no output 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 a single concise sentence that communicates the core functionality without any extraneous content. It is well-structured and front-loaded with the key action.
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 simplicity (one parameter, no output schema), the description is somewhat sufficient for basic selection, but it lacks critical context about the return value/format, what 'size, format, and lazy-loading' entails (e.g., thresholds, recommendations), and how it fits into an image performance audit workflow. More detail on the output would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'postId' parameter described as 'Post/Page ID'. The description does not add any further parameter semantics, but since the schema already fully documents the parameter, a baseline score of 3 is appropriate. The description indirectly implies the post scope but doesn't explicitly connect it to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analysiert Bilder auf Größe, Format und Lazy-Loading' (Analyzes images for size, format, and lazy-loading). It uses a specific verb (analysiert) and resource (Bilder/images), and the aspects analyzed (size, format, lazy-loading) make it distinct from sibling tools like a11y_check_images or image_analyze_optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, intended use cases, or mention any sibling tools. The tool name and title imply a performance check, but there is no explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions deleting old revisions, implying a destructive action, but does not state whether the operation is permanent, reversible, or requires specific permissions. No additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in German, front-loaded with the action and resource. It contains no unnecessary wording and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three parameters and no output schema, so the description is relatively minimal. However, as a destructive operation, it lacks details on return values, side effects, or idempotency. It partially meets the need but leaves gaps for an agent to invoke it without full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters, including descriptions and defaults. The description adds only indirect reference to keepCount (as 'N') and does not enrich or clarify the parameters beyond the schema. Baseline of 3 is appropriate given high schema 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 clearly states the tool's purpose: deleting old revisions while retaining the last N versions. This is a specific verb+resource combination that distinguishes it from sibling tools like revision_delete (which deletes individual revisions) and revision_restore.
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 gives no guidance on when to use this tool versus alternatives such as revision_delete or revision_restore. It implies use for bulk cleanup but does not provide exclusions or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the function (compare and show differences) without disclosing whether it's read-only, what output format to expect, how errors are handled, or any side effects. For a compare operation, it doesn't confirm that no changes are made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, immediately leading with the verb. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is minimal but covers the core action. However, it lacks guidance on expected return value and usage context. Given the simplicity of the operation and complete schema documentation, it is minimally viable but could benefit from more 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 description coverage is 100%, so all four parameters (postId, postType, revisionId1, revisionId2) are documented in the schema. The description adds no additional parameter meaning beyond what the schema already provides, but the schema itself is sufficient.
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 'vergleicht' (compares) and clearly identifies the action as comparing two revisions and showing differences. This distinguishes it from sibling tools like revision_list (listing), revision_get (retrieving), revision_restore, revision_delete, and revision_cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning prerequisites, exclusions, or when to prefer it over revision_list or revision_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'deletes' without mentioning whether it moves to trash, permanently deletes, or requires specific permissions. The schema's force parameter hints at permanent deletion, but the description does not surface this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loaded and easy to parse. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter delete operation, the description is minimal but not dangerously incomplete because the schema covers the force parameter. However, it lacks context about side effects or prerequisites, so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the parameters are fully documented in the schema, including the 'force' boolean's default and meaning. The description adds no additional parameter semantics, so 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 action with a specific verb ('Löscht' = deletes) and resource ('WooCommerce Produkt'), distinguishing it from sibling tools like woo_create_product and woo_update_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states the function without situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'full content' but does not disclose side effects, auth requirements, or potential costs. There is no indication whether this is a safe read-only operation or if it might trigger heavy processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without unnecessary words. It is well-structured and immediately understandable.
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 simplicity (1 parameter, output schema exists), the description is minimally adequate but lacks behavioral transparency and usage context. It does not explain what 'full content' includes or indicate any limitations, leaving gaps for an agent to fully assess.
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% (the only parameter 'id' is described). The description adds no additional meaning beyond the schema, so a 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 'Holt einen einzelnen Post mit vollständigem Inhalt' clearly states the action (get/retrieve) and the resource (a single post) with a specific detail (full content). It distinguishes from sibling tools like wp_list_posts (list) and wp_get_page (page).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions or prerequisites, such as needing the post to exist or how it differs from wp_get_page or wp_list_posts for retrieval tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to convey read-only or safe behavior. The description only states that it fetches categories, which implies a read operation, but it does not disclose potential side effects, performance considerations, or any behavioral details such as pagination or ordering. Given no annotations, the description carries the full burden and does not provide sufficient 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 a single, concise sentence in German: 'Holt alle WordPress-Kategorien'. It is front-loaded and contains no superfluous words. Every word contributes to the purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is reasonably complete, especially given that an output schema exists to describe the returned data. However, it lacks any mention of scope, ordering, or potential volume of results, which could matter for an agent deciding whether to call this tool. This gap prevents a perfect score, but the simplicity of the operation makes the description sufficient for most contexts.
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 0 parameters and the input schema is empty with 100% schema description coverage. With no parameters to explain, the description does not need to add parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Holt alle WordPress-Kategorien' clearly states the tool's function: retrieving all WordPress categories. It uses a specific verb (holt) and a specific resource (Kategorien), which makes the purpose distinct from general-purpose tools. However, it does not explicitly differentiate from sibling tools like wp_list_tags, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool instead of alternatives like wp_list_tags or wp_list_posts, nor does it specify any prerequisites, limitations, or exclusions. The agent receives no contextual guidance beyond the raw action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic listing action. It does not disclose whether the operation is read-only, whether any plugins are excluded (e.g., network-activated), or any potential performance implications. This leaves the behavioral profile under-specified.
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, immediately clear and without extraneous information. It earns a high score for efficiency.
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 zero-parameter schema and the presence of an output schema, the description is likely sufficient, but it omits any context about when this listing would be useful or whether it includes only active plugins. Still, for a trivial list operation, it is reasonably complete.
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 schema already covers everything. The description adds no parameter semantics, which is appropriate given there are nothing to describe. Baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Zeigt' and specifies the resource 'alle installierten WordPress-Plugins', making the tool's function clear. However, it doesn't explicitly differentiate from sibling tools like `ml_detect_plugin` or other list tools, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it shows, with no exclusions or context about plugin status or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that fields are retrieved, without mentioning read-only safety, return format, what happens if the term or fields do not exist, or any other behavioral characteristics. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It contains no filler words or redundant information, making it highly efficient.
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?
With no output schema and no annotations, the description should clarify what the return value looks like and provide more context about the operation. It only states the basic action (retrieving fields), leaving the agent without enough information about the response format or edge cases. This is insufficient for a tool that lacks structured output documentation.
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 complete descriptions for both parameters (termId and taxonomy) with examples for taxonomy, yielding 100% schema coverage. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves ACF custom fields for a taxonomy term (category, tag, etc.), using the specific verb 'abrufen' (retrieve) with a clear resource scope. This differentiates it from sibling tools like acf_get_post_fields or acf_get_user_fields, which target different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the target resource (terms), but it does not explicitly state when to choose this over alternatives or provide exclusions. The main clue is the term 'Term' in the name and description, which helps an agent infer the appropriate context, but there is no direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose return format, pagination, or any side effects. It only states that it lists field groups, which is minimal for a read 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 a single, direct sentence with no unnecessary words. It is efficiently front-loaded with the action and resource.
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?
There is no output schema, so the description should explain what the list contains (IDs, full objects, etc.), but it does not. It also lacks context on sorting or scope beyond 'all', making it incomplete for operational use.
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 accepts no parameters, and schema coverage is 100%. Since there are zero parameters, the description does not need to add parameter meaning, meeting the baseline.
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 'listet' (lists) and identifies the resource 'alle ACF Field Groups' (all ACF field groups), clearly distinguishing it from singular/specific ACF tools like acf_get_field_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as acf_bulk_get_fields or acf_get_field_group. It simply states what it does without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'updates fields' without explaining whether fields are merged or replaced, whether new fields can be created, permission requirements, or side effects. This is sparse for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant information. It earns its place and follows the principle of front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with a nested fields object and no output schema, the one-line description lacks crucial context about return values, effect on existing fields, and plugin requirements. The schema covers parameter names but not the tool's full operational 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?
The schema provides 100% coverage with descriptions for all three parameters. The description adds no additional parameter meaning, and the nested 'fields' object remains vaguely defined, but the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates ACF Custom Fields for posts/pages using a specific verb ('Aktualisiert') and resource. It distinguishes from sibling getter tools like acf_get_post_fields and other update tools like acf_update_options.
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?
Usage is implied by the name and description ('updates ACF fields'), but there is no explicit guidance on when to use this tool versus alternatives such as acf_update_options or acf_update_user_fields. No exclusions or alternative mentions are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only says 'retrieves the current permalink structure' — implying a read operation but providing no details on permissions, return format, caching, or side effects. This is minimal and does not add meaningful behavioral context beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and well-structured. However, it adds only the word 'current' beyond the title, so it does not significantly enrich the tool's documentation, though it remains appropriately sized for a zero-parameter getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description is simple but lacks contextual detail. It tells us the tool retrieves the permalink structure but does not describe the return value's format, structure, or any relevant caveats. This is a minimum viable description but leaves gaps for an agent needing to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameters, and the empty input schema aligns with this. No additional parameter-specific semantics are required or provided.
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 retrieves the current permalink structure, using a specific verb ('ruft ab' = retrieves) and a clear resource ('Permalink-Struktur'). It effectively distinguishes this tool from siblings like admin_get_settings or wp_get_site_info by referring specifically to permalink structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description simply states what the tool does without indicating when to use it versus alternatives, prerequisites, or any context about typical use cases. This is a 'no guidance' case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only notes that admin rights are required, but does not explain whether the option must exist, potential side effects, error behavior, or return value. For a mutating operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and a key constraint. It is front-loaded, has no unnecessary words, and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no annotations, and no output schema, so the description must compensate. It does not mention whether the option is updated or created, what response to expect, or any edge cases. The tool is part of a large sibling set but the description is too sparse for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters described in the schema (option name and new value). The description does not add additional detail beyond what the schema already provides, so a 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 tool updates a WordPress option, using a specific verb ('Aktualisiert') and resource ('WordPress Option'). This distinguishes it from siblings like admin_get_option (reading) and admin_list_settings (listing).
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 mentions a prerequisite (admin rights), which implies when the tool can be used, but it does not explicitly state when to prefer this over alternatives or when not to use it. No direct comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the core function without mentioning side effects, permissions, or whether it is a read-only operation. It adds no safety or performance context beyond the literal action, which is insufficient for a tool lacking annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource. It contains no redundant information and is appropriately concise for a one-parameter getter tool.
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 simple with one parameter and an output schema, so the description is mostly adequate. However, it lacks explicit usage differentiation from other Elementor tools, which slightly reduces completeness, though the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter, postId, as 'Post/Page ID', achieving 100% coverage. The description does not add additional meaning, such as constraints or relationships to Elementor-specific pages, so it stays at baseline.
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 retrieves the complete Elementor data structure of a page, including widgets and settings. This explicitly distinguishes it from sibling tools like elementor_get_global_settings or elementor_get_widget by scoping to page-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply defines what the tool does without mentioning use cases, prerequisites, or exclusions, leaving the agent to infer applicability from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral detail beyond the basic action. It does not disclose whether the operation is read-only, what output format to expect (e.g., plugin slug, name), or any limitations. With no annotations provided, the description carries the full burden and is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in German, efficiently stating the tool's purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief for a tool with no output schema. It does not specify what the tool returns (e.g., plugin slug/name) or which form plugins are detectable. This leaves a significant gap in understandability, especially given the lack of structured output documentation.
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, and the input schema is empty, providing 100% coverage. With no parameters to document, the description could add nothing further; the baseline score of 4 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 detects which form plugin is installed. It uses a specific verb ('Erkennt') and resource ('welches Formular-Plugin installiert ist'), which distinguishes it from sibling tools that operate on specific form plugins (e.g., gf_list_forms, wpforms_get_entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as ml_detect_plugin or form-plugin-specific tools. The use case is only implied by the tool name and description, with no explicit exclusions or instructions on how to proceed after detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry the full burden. It mentions using the WordPress Image Editor API but does not disclose side effects like overwriting original files, irreversibility, or impact on image sizes. The parameter 'applyToSizes' hints at behavior not covered in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose and the key capability (using the WordPress API). Every word adds value, and it is efficiently front-loaded for quick understanding.
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 is complex with 6 parameters and nested objects, yet the description provides only a high-level overview. No output schema or annotations exist, so the description should explain typical usage, how parameters interact, and expected outcomes. It does not, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already provides; it simply names the operations, which are already enumerated in the 'action' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool edits an image and lists the specific operations (crop, rotate, flip), distinguishing it from siblings like image_get_details or image_update_meta. The verb 'Bearbeitet' (edits) and resource 'Bild' (image) are specific, and the enumeration of supported actions adds further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for image editing operations but does not explicitly state when to use this tool over alternatives such as image_update_meta or image_regenerate_thumbnails. It provides no exclusions or contextual guidance about prerequisites or fallback scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions the prerequisite that the JWT plugin is required, but does not explain return values, side effects (e.g., token storage), failure behavior, or whether credentials are sent securely. This is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the action and a key prerequisite efficiently, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It states that a JWT token is obtained, but does not specify the response format, whether the token is automatically stored for subsequent requests, or how it interacts with related tools like jwt_set_token and auth_status. The description leaves important operational context unclear.
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 both username and password parameters documented as optional with env-variable fallback. The tool description does not add any additional parameter meaning, so the baseline of 3 applies because the schema already provides comprehensive parameter explanations.
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 authenticates with WordPress and obtains a JWT token, with a specific verb and resource. It also mentions the JWT plugin requirement, distinguishing it from sibling tools like jwt_validate, jwt_refresh, or jwt_token_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for initial authentication to get a JWT token, but does not explicitly state when to use it over alternatives like jwt_validate or jwt_refresh. No exclusion or alternative guidance is provided beyond the plugin requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits such as response format, error handling, permissions, or side effects. It does not indicate whether the operation is read-only or if any prerequisites apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loading the action and resource. It efficiently communicates the tool's purpose.
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 tool with no output schema, the description adequately covers the purpose and result (includes complete HTML). It lacks mention of error behavior when the pattern is not found, but given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for patternName is complete (100% coverage), explaining the expected value with an example. The tool description adds no additional parameter semantics beyond restating 'specific block pattern', 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 it retrieves a specific block pattern with its complete HTML, using a specific verb ('Holt') and resource ('spezifisches Block Pattern'). It distinguishes from sibling tools like pattern_list_block_patterns which list patterns.
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 gives no guidance on when to use this tool versus alternatives. It does not mention pattern_list_block_patterns or any exclusion criteria, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions supported methods (which are already in the schema) but fails to warn about side effects (e.g., DELETE or POST mutate data), authentication requirements, or error/return behavior. For an arbitrary API execution tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the tool's purpose, followed by a brief enumeration of supported methods. There is zero waste, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a generic, potentially destructive tool (supports DELETE, PUT, PATCH), the description is underpowered. It does not mention return format, authentication, prerequisites, or safety considerations. While the schema covers parameter semantics, the lack of annotations and output schema places full burden on the description, which it does not meet.
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 each parameter is already well-documented. The description adds no additional meaning about parameters—it only repeats the HTTP methods already present in the schema's enum. Baseline 3 is appropriate since the description neither enhances nor detracts from schema clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Führt eine beliebige WordPress REST API Funktion aus' (executes any WordPress REST API function), and lists the supported HTTP methods. This distinguishes it from sibling tools like rest_api_list_functions, rest_api_get_function_details, and rest_api_batch, which have different verbs and scopes.
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 general-purpose use ('beliebige') but does not provide explicit guidance on when to choose this tool over alternatives such as rest_api_batch or rest_api_search. It gives clear context for its functionality but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral transparency. It implies a read-only listing operation through 'Entdeckt' and 'Zeigt', but does not explicitly state that it makes no changes, requires no authentication, or what the output size might be. Lacking such details, the agent cannot fully anticipate side effects or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately stating the core purpose and what will be revealed. There is no redundant information or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool with optional filters and an output schema, the description covers the essential functionality. It could be more complete by mentioning that it lists custom endpoints as well or that the results might be large, but given the schema and output schema exist, the description is sufficient.
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?
Input schema has 100% description coverage for both parameters (method and namespace), including an enum for method. The description adds no extra parameter semantics, but the schema already provides the necessary details, so a 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 that the tool discovers all available WordPress REST API endpoints and shows namespaces, routes, and supported HTTP methods. This uses a specific verb ('Entdeckt') and resource (REST API endpoints), and distinguishes it from sibling tools like rest_api_get_function_details or rest_api_list_post_types.
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 explains what the tool does but provides no guidance on when to use it versus alternatives. There is no mention of scenarios like exploring before executing, or excluding cases where specific post types/taxonomies are needed. This leaves the agent to infer usage from the description alone.
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 convey behavior. Saying 'Berechnet' (calculates) implies a read-only analysis, and the mention of specific metrics adds some transparency. However, it does not explicitly state that no modifications occur, nor does it describe the output structure or any potential 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 a single, front-loaded sentence that efficiently communicates the core function. Every word contributes; there is no redundancy or irrelevant detail.
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?
With no output schema, the description should provide some indication of the return format or result structure. It mentions metrics but not whether they are returned as a score, a breakdown, or a single value. The lack of guidance on applicable post types or prerequisites makes it incomplete for an agent to fully anticipate the tool's behavior.
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 fully documents the only parameter (postId) as 'Post/Page ID' (100% coverage). The description adds no additional parameter meaning beyond that, 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 uses a specific verb 'Berechnet' (calculates) and clearly identifies the resource as readability metrics, naming concrete examples (Flesch, average sentence length). It distinguishes itself from sibling analysis tools by focusing on readability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus readability-related alternatives like seo_analyze_content or perf_analyze_content. The description simply states what it does without any contextual use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action and gives no information about side effects, permissions, required fields beyond the schema, or behavior on errors. For a mutation tool, this is minimal.
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, clear sentence with no wasted words. It is front-loaded with the key action and resource, making it easily scannable.
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?
With 16 parameters, nested objects, no annotations, and no output schema, the description is extremely brief. It does not explain what the tool returns, important defaults, or any constraints, leaving significant context missing for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in the input schema. The description adds no additional parameter semantics beyond what the schema provides, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Erstellt ein neues WooCommerce Produkt' clearly states the action (create) and resource (WooCommerce product), and distinguishes from sibling tools like woo_update_product and woo_delete_product by indicating a new product creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new product, but provides no explicit guidance on when to use this tool versus alternatives or any exclusions. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says the tool 'checks' the structure, without describing what it returns, whether it modifies anything, or any side effects. The read-only nature is implied by the action verb but not explicitly stated, and there is no mention of output format or errors.
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 that conveys the core purpose and the specific aspects checked (heading hierarchy, landmarks). It contains no unnecessary words and is appropriately concise for its simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, and the description explains its purpose. However, there is no output schema, so the description should ideally mention what the tool returns (e.g., a list of issues or a pass/fail report). The lack of any behavioral detail beyond 'checks' leaves the agent uncertain about the result, making the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (postId) with a clear description ('Post/Page ID'), giving 100% schema coverage. The tool description adds minimal context by referring to 'einer Seite' (a page), which connects the postId to the page whose structure is checked. This is sufficient, so a 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 tool's function: it checks the accessibility structure of a page, specifically heading hierarchy and landmarks. This distinguishes it from sibling tools like a11y_check_forms, a11y_check_color_contrast, and a11y_check_links, which target different accessibility aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to check a page's accessibility structure) but does not explicitly mention alternatives or state when not to use it. The purpose is clear enough to infer the use case, but there is no direct guidance or exclusion.
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?
The verb 'Ruft ab' implies a non-mutating read operation, and the examples clarify the scope. However, with no annotations, the description does not explicitly state that no changes are made or describe the output format or error behavior, leaving the agent to infer these 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?
The description is a single, front-loaded sentence with no filler. The examples in parentheses add valuable specificity without making the text bloated.
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 parameterless read-only tool with low complexity, the description gives a solid mental model by listing example settings. It lacks an explicit return structure, but this is not critical for such a simple operation.
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 there are no parameter semantics to clarify. The description's parenthetical examples provide useful information about what the returned settings cover, which is adequate given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Ruft ... ab' = retrieves) and the resource ('WordPress Site-Einstellungen') with representative examples. However, it does not explicitly distinguish itself from the sibling tool admin_list_settings, so it falls just short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like admin_list_settings or wp_get_site_info. No context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It indicates a read-only listing operation but does not describe return format, pagination behavior, or permission requirements. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description covers the core function, but it does not specify what 'Details' includes, and there is no output schema. It also does not clarify the relationship to the sibling wp_list_users 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?
All five parameters have descriptions in the schema, so the description does not need to repeat them. The description adds no additional meaning beyond the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all WordPress users with roles and details, using a specific verb (listet) and resource (WordPress-Benutzer). It distinguishes by scope ('alle') and detail level, but does not explicitly differentiate from the sibling wp_list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing users, but does not mention alternatives or exclusions. It lacks explicit guidance on when to choose this over wp_list_users or other admin user tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it merely restates the title without adding behavioral context such as return format, pagination, or any side effects. The tool is a simple read-only list operation, but the description offers no additional insight into what the output contains or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is effectively one line that communicates the core purpose, though it is so brief it borders on being a tautology. Still, it is appropriately sized for a simple listing tool.
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?
With no output schema, no annotations, and no behavioral details, the description fails to convey what the tool actually returns (e.g., form IDs, titles). For a tool with zero parameters and no structured output, the description should at least mention the kind of data returned, making the context incomplete.
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, which earns a baseline score of 4. The description adds no parameter details, but none are needed since the schema is empty and the operation requires no inputs.
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 'Listet alle Contact Form 7 Formulare auf' clearly states the action (list), the resource (Contact Form 7 forms), and the scope (all). It distinguishes itself from sibling tools like gf_list_forms and cf7_get_form by explicitly naming the plugin and the list-all behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a list of all CF7 forms, but it does not explicitly state when to use this over alternatives. There is no mention of singular-form retrieval via cf7_get_form or that other plugins have their own list tools, leaving usage to be inferred rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only extraction but does not disclose return format, error behavior, or whether it reads from the active theme's global styles or another source. This is minimal.
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, grammatically complete sentence with no unnecessary words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description conveys the core action adequately. However, with no output schema, it does not mention the return value shape (e.g., array of hex codes vs. CSS variable map), leaving the agent uncertain about the result format.
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 and the input schema is empty, so the description does not need to explain parameter details. The baseline of 4 applies because there is nothing for the description to add.
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 ('Extrahiert') and names the exact resource ('Theme-Farbpalette') and source ('Global Styles'), making it clear what the tool returns. This distinguishes it from sibling tools like design_get_typography and design_get_custom_css.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over related design tools (e.g., design_get_theme_json, elementor_get_global_colors) or any prerequisites or exclusions. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'gets' the spacing scale, which implies a read-only operation, but it does not explicitly confirm non-destructiveness, describe return format, or mention any potential side effects or error conditions. For a simple getter, this is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the core functionality. Every word contributes to the meaning, and there is no redundant or extraneous 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?
The tool is simple with no parameters and no output schema, so the description is minimally adequate. It tells the user what it does, but it does not add context about the structure of the spacing scale, how the result might be used, or any special considerations. Given the low complexity, this is acceptable but not comprehensive.
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 does not need to explain parameter semantics. The baseline for 0 parameters is 4, and the description satisfies this since no parameter-related information is required.
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 ('Holt' / gets) and the specific resource (the theme's Spacing/Abstands-Skala). It is specific enough to distinguish it from sibling tools like design_get_typography or design_get_custom_css, which target different design elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention specific use cases, prerequisites, or any exclusions. While the name implies 'when you need spacing settings,' there is no explicit context or comparison to other design_get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'get details' without clarifying read-only status, what details are included, error conditions, or any side effects. This is minimal for a tool with no safety annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise and front-loaded sentence in German. It communicates the action and resource without unnecessary words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with an output schema, so return values need not be described. However, the description omits the fact that postId is also required, which could mislead agents into thinking only widgetId is needed. Overall, it is minimally sufficient but lacks important contextual detail.
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 fully describes both parameters (postId and widgetId) with 100% coverage. The description adds little beyond 'by its ID', which aligns with widgetId but omits the required postId. Baseline 3 is appropriate when schema covers parameter meaning.
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 ('Hole' = get), the resource ('Details eines Elementor-Widgets'), and the identifier ('anhand seiner ID'). It is specific enough to distinguish from sibling tools like elementor_get_global_settings or elementor_list_widgets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (retrieve widget details by ID) but does not explicitly state when to use it over alternatives or any exclusions. There is no mention of alternative tools or prerequisites, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does clarify the scope by listing the template types, but it does not indicate whether the operation is read-only, what output format is returned, or any permissions or limitations. For a simple list tool, this is partially acceptable.
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, complete sentence with no fluff or repetition. It efficiently states what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema. The description covers the core purpose but omits the return format and does not reference the filter parameter in the description, though the schema covers it. Overall, it is functionally adequate but lacks some context about the expected output.
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 fully describes the templateType parameter with an enum and a German description (100% coverage). The tool description does not add any parameter semantics beyond the schema, so it earns the baseline 3 for schema 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 the specific verb 'Listet' (lists) and identifies the resource as 'Theme Builder Templates', enumerating the included types (Header, Footer, Single, Archive). This clearly distinguishes it from sibling tools like elementor_list_kits or elementor_list_global_widgets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the templateType parameter or any conditions for filtering, nor does it reference any sibling tools that might be better suited for other Elementor list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states the core function without revealing how 'unused' is determined, whether it is read-only, what the return format is, or whether it covers all content types or just posts/pages. This lack of detail leaves significant ambiguity for a tool with zero annotation support.
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 that directly states the tool's purpose without any filler or redundancy. Every word contributes to the meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description gives the essential purpose but omits useful context such as what the return value looks like (e.g., list of IDs), how usage is defined, and potential limitations. It is not incomplete enough to be unusable, but it leaves gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (limit) with a description ('Maximale Anzahl') and 100% schema coverage. The description itself adds no additional meaning about the parameter, but the schema already clearly documents its purpose. Baseline 3 is appropriate since the schema handles the burden.
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: 'Findet Bilder' (finds images) with a clear scope—images not used in any post/page. This distinguishes it from sibling tools like image_find_missing_alt (missing alt text) and image_delete_unused (deletion). The purpose is immediately clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for finding unused images) but provides no explicit guidance on when not to use it or how it compares to alternatives such as image_find_missing_alt or image_delete_unused. There is no mention of prerequisites or exclusions, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description carries the full burden of disclosure. It only restates the purpose without providing behavioral context such as read-only nature, return format, pagination, ordering, permissions, or whether draft/trashed forms are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary detail. It is highly concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is minimally viable: it states what it lists. However, it does not describe the structure of the returned forms (e.g., IDs, titles), nor does it explicitly confirm a safe read operation. Given the absence of annotations and an output schema, a bit more context would be useful.
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 semantics, but none are needed; 'alle' implies no filtering, which matches the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Listet' (lists) and explicitly names the resource 'Ninja Forms Formulare' (Ninja Forms forms), including the scope 'alle' (all). This clearly distinguishes it from sibling form-listing tools such as gf_list_forms and wpforms_list_forms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus other form listing tools, nor any exclusions or prerequisites. With many form-listing siblings, the agent gets no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that it analyzes content, which implies a read operation, but it does not disclose whether any modifications, side effects, permissions, or output formats are involved. Significant behavioral details are missing for a tool with no safety 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 a single, clear, front-loaded sentence with zero wasted words. It efficiently conveys the tool's core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the description gives a high-level overview with examples. However, there is no output schema and the description does not explain what kind of results are returned or the full scope of content checks, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter postId, which is fully described as 'Post/Page ID'. The description itself adds no additional parameter guidance, 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 tool analyzes content for performance problems (image sizes, embeds, etc.), using a specific verb ('analysiert') and resource ('Content'). It effectively distinguishes from sibling tools like seo_analyze_content and perf_check_images, which target SEO and images specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for content performance analysis, but it does not explicitly state when to use it versus alternatives like perf_check_images or perf_analyze_plugins. Clear context exists but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the operation without detailing side effects, error conditions (e.g., invalid language slug), whether existing translations are overwritten, or if the Polylang plugin must be active. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively low complexity (2 required params, no output schema), but the description lacks behavioral context such as prerequisites, consequences, or error handling. Given no annotations, more depth would be beneficial, but the current state is minimally viable for a simple setter.
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%—both postId and language have clear descriptions ('Post-ID' and 'Sprach-Slug (z.B. de, en, fr)'). The tool description adds no extra meaning beyond the schema, so the baseline score 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 'Setzt die Sprache eines Posts' clearly states the action (set) and resource (a post's language). It distinguishes this tool from siblings like polylang_get_post_language (which retrieves a language) and polylang_list_languages (which lists available languages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to set a post's language, use this tool. However, it does not explicitly state when to use this over alternatives (e.g., polylang_link_translations) or mention any exclusions or prerequisites. Guidance is minimal but inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the WordPress 5.6+ requirement, but does not explain how batch failures are handled, whether the operation is atomic, how responses are aggregated, or any rate limits. This is a significant omission for a tool that executes arbitrary requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and purpose. It contains no redundant information and every word 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?
The tool has only one parameter, which is fully described in the schema, and an output schema exists, so return values are likely covered. However, the description omits crucial operational context for a batch tool, such as error semantics, ordering guarantees, or whether partial success is possible. The version note is helpful but not sufficient for complex usage.
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 full descriptions for all parameters (e.g., 'REST API Pfad' for path, 'Array von Requests' for requests), so the schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already offers, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes multiple REST API requests in a batch operation, using the specific verb 'executes' and scoping to multiple requests. This distinguishes it from sibling tools like rest_api_execute, which presumably handle single requests. The mention of WordPress 5.6+ adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for executing several requests at once, but it does not explicitly state when to use it over alternatives like rest_api_execute or when not to use it. No exclusions or direct comparisons are provided, leaving the usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details beyond the basic action. It does not disclose side effects, required permissions, return format, or error behavior, which is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is appropriately sized for a simple getter tool, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks any additional context such as return values, error conditions, or use cases. Given no output schema and no annotations, the description is adequate but not comprehensive.
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 already fully describes the only parameter (orderId), so the description adds no extra meaning. Baseline of 3 applies due to high schema 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 clearly states the tool retrieves details of a single order, using a specific verb and resource, distinguishing it from list/update 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single order's details but provides no explicit guidance or alternatives. Context from sibling tools suggests when to use, but it is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does mention the trash/permanent distinction, which is valuable, but this information is already present in the 'force' parameter's schema description ('Endgültig löschen statt Papierkorb'). The description fails to disclose other important behaviors like irreversibility of permanent deletion, effects on related data such as comments or meta, or permission requirements. This is a significant gap 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 a single, concise sentence that immediately states the purpose and key modes. Every word contributes meaning, with no filler or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the core behavior (trash vs permanent) but omits context like whether the operation is reversible by default, what happens to associated data, or what the response contains. The output schema exists, which likely documents return values, so that gap is partially covered. However, given no annotations, a bit more context would be expected for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'force' clearly described in the input schema. The tool description adds no additional meaning beyond what the schema already provides—it merely restates the force behavior. Per the rubric, baseline is 3 when schema coverage is high, and no extra value is added here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and resource (WordPress post), with a parenthetical that distinguishes two deletion modes: moving to trash or permanent deletion. This is a specific verb+resource pair that aligns with the tool's name and separates it from tools targeting other entity types like products or users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to delete a WordPress post) but provides no explicit guidance about when not to use it or alternatives. It does not mention prerequisites, permission requirements, or compare with other deletion tools in the sibling list. Usage context is only inferred from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('shows information') but does not mention edge cases like unauthenticated requests, possible null returns, or authentication requirements. No additional context is provided beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action verb. It is concise, contains no fluff, and is easy to parse.
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 simplicity (no params, output schema present), the description is minimally viable. However, it lacks usage context and behavioral transparency (e.g., what happens when no user is logged in), leaving gaps that could confuse an AI agent. The output schema covers return values, so this dimension is not penalized for that.
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 per rubric baseline is 4. The description adds no parameter information, but none is needed since there are no parameters to document.
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: displaying information about the currently authenticated user. The 'current' qualifier distinguishes it from sibling user-listing tools like wp_list_users or admin_get_user, even though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs. alternatives. The description merely states the function and provides no context about when it's appropriate, exclusions, or how it relates to other user-related tools such as auth_status or admin_get_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It communicates the read-only nature ('displays') and the dependency on the Menus REST API Plugin, which is useful. However, it does not disclose failure behavior, pagination, or other potential 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 a single, front-loaded sentence that states the action and object directly. Every word earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema, the description is largely sufficient. The plugin requirement adds important context, but the lack of differentiation from sibling nav_list_menus is a minor completeness gap.
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 input schema is empty and there is nothing for the description to clarify. The baseline of 4 applies because no parameter explanations are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Zeigt ... an' / 'displays') and the resource ('alle WordPress-Navigationsmenüs' / 'all WordPress navigation menus'). However, it does not differentiate this tool from the sibling nav_list_menus, which likely serves the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives like nav_list_menus or nav_get_menu_items. It only mentions a plugin requirement, which is a prerequisite rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. It says 'Prüft' (checks), implying a read-only operation, but it does not explicitly state non-destructiveness, what it returns, whether it modifies content, or any permission requirements. The examples given (empty links, generic texts) add some insight but not enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the main purpose and immediately provides concrete examples of what it checks. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema and no output schema or annotations, so the description must explain what the tool returns and how to interpret results. It does not. It also lacks context about the scope (site-wide vs. per-post) and potential side effects, making it incomplete for an agent to use confidently.
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% (postId is described as 'Post/Page ID'), so the baseline is 3. The description does not elaborate on how postId scopes the link check, and 'alle Links' could be misconstrued as site-wide. It adds no extra semantic 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 'Prüft' (checks) with a clear resource 'alle Links' (all links) and scope 'auf Accessibility' (for accessibility), listing concrete examples ('leere Links, generische Texte'). This distinguishes it from sibling tools like a11y_check_forms and a11y_check_color_contrast, which target other accessibility aspects.
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 indicates the tool is for auditing link accessibility on a post/page (implied by postId). However, it does not explicitly mention alternatives or provide when-not-to-use guidance, stopping 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden for disclosing behavioral traits. It does not state that the deletion is permanent, that content will be reassigned, or mention any side effects or error conditions. The mention of 'reassign' hints at content transfer but does not elaborate on the destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action and a critical prerequisite without any extraneous words. It is efficient and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is too minimal. It omits important context such as permanence, effects on user content, expected response, and error scenarios, leaving the agent without sufficient information to understand the full impact of invoking this 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 description coverage is 100%, so the baseline is 3. The description's mention of reassign simply repeats a required parameter without adding new meaning. It does not clarify the roles of userId or force beyond the schema's existing 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 action ('Löscht' = deletes), the resource ('WordPress-Benutzer'), and a key requirement ('erfordert Reassign'). It unambiguously distinguishes this from sibling admin tools like admin_create_user or admin_update_user by indicating deletion.
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 includes a usage prerequisite: reassign is required. This provides clear context for when the tool is appropriate. It does not explicitly mention alternatives or exclusions, but the tool name and purpose make the primary use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Analysiert' implies a read-only operation and the 'Übersicht' indicates the return type, but it does not explicitly state that no changes are made, nor does it mention prerequisites like Elementor being active or behavior on non-Elementor posts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the purpose and output with no filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter analysis tool with an output schema, the description is largely complete. It could mention prerequisites or limitations, but overall it provides enough context 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?
Schema description coverage is 100% with postId described as 'Post/Page ID'. The description adds no further meaning about the parameter beyond the schema, 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 verb 'Analysiert' and the resource 'Elementor-Seitenstruktur', and specifies the output as an overview of containers, sections, and widgets. This distinguishes it from siblings like elementor_get_page_data (raw data) and design_analyze_page_layout (layout analysis).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as elementor_get_page_data, a11y_check_page_structure, or design_analyze_page_layout. The description implies usage for analyzing Elementor structure but does not state exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the retrieval action ('Holt') but does not disclose return format, potential errors, or any side effects. Since it is a getter, the read-only nature is implied, but no additional behavioral traits are revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and object. It is concise and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is largely sufficient. It could mention the response shape or confirm that all breakpoints are returned, but the operation is simple enough that this is a minor gap. The examples 'Mobile, Tablet, etc.' add useful 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?
The input schema has zero parameters, so baseline 4 applies. The description correctly does not introduce any parameter syntax or requirements, which is appropriate for a parameterless 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 uses a specific verb 'Holt' (gets) and identifies the exact resource 'Responsive Breakpoints (Mobile, Tablet, etc.)'. This clearly distinguishes it from sibling tools like elementor_get_global_settings or elementor_list_kits. Minor typo in title ('Hole') does not obscure the meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with other Elementor settings tools. The usage context is entirely implicit from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It includes a 'VORSICHT!' warning that signals destructive potential and specifies the condition 'nicht verwendet' (unused). However, it does not explain the force parameter, whether deletion is permanent by default, or potential side effects such as broken references, leaving notable 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 a single sentence that is front-loaded with the primary action and includes a critical caution flag. It contains no filler or redundant explanatory content beyond what is necessary for the warning.
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?
As a destructive tool with no annotations and no output schema, the description is too minimal. It lacks context about how 'unused' is determined, the effect of the force flag, recovery options, and safe invocation workflow (e.g., using image_find_unused first). This is a significant gap for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage, including descriptions for mediaIds and force. The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.
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 deletes unused images, matching the name and title. It specifies the verb (löscht), resource (Bilder), and condition (nicht verwendet), and distinguishes it from the sibling image_find_unused which only locates unused images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting images that are no longer used, but it does not explicitly state when to use it versus alternatives like image_find_unused. No prerequisites or exclusion scenarios are mentioned, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a write operation ('setzt') but does not disclose side effects, prerequisites (e.g., image existence), permission requirements, or whether the operation is destructive or reversible. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately communicates the tool's purpose. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a mutation with no output schema and no annotations. The description lacks details about return values, success/failure indicators, or behavioral consequences. While the schema is complete, the description leaves the agent uncertain about what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (mediaId, x, y) with percentage ranges. The description adds no additional parameter-level meaning beyond the schema, so a 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 tool's function: setting the focal point of an image for smart cropping. The verb 'setzen' (set) plus the resource 'Fokuspunkt eines Bildes' (focal point of an image) is specific and distinct from sibling tools like image_edit or image_update_meta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'für Smart Cropping' provides clear context on when to use this tool. However, it does not explicitly mention alternatives or cases where another tool might be more appropriate, leaving a small gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It conveys a read operation and notes 'complete content', which adds some behavioral context. However, it does not specify whether unpublished pages are included, required permissions, or other side effects, limiting 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 a single, concise sentence that is front-loaded with the action and the resource. It contains no redundant words or unnecessary 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?
For a simple getter with one parameter and an output schema present, the description is mostly sufficient. It states the purpose and the scope ('complete content'), though it could benefit from mentioning edge cases like non-existent pages, but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'id' parameter is described as 'Seiten ID'). The description adds no extra meaning beyond the schema, 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 tool retrieves a single page ('Holt eine einzelne Seite') with complete content ('mit vollständigem Inhalt'), using a specific verb and resource. It distinguishes from sibling tools like 'wp_list_pages' (list) and 'wp_get_post' (posts vs pages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, such as 'wp_get_post' for posts or 'wp_get_page' for pages. There are no explicit use cases, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a basic list retrieval with filters, but does not disclose pagination behavior, default result counts, or read-only nature. It adds minimal value beyond the tool name.
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?
Single, complete sentence with no wasted words; front-loads the core action and resource. It is appropriately sized for a simple list tool.
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 low complexity, rich schema, and existing output schema, the brief description suffices for basic understanding. It misses explicit guidance on defaults and edge cases like unfiltered queries, but output schema likely covers return 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 input schema covers all 6 parameters with descriptions (100% coverage), so the baseline is 3. The description's generic 'optionalen Filtern' adds no specific semantic value 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?
The description clearly states a specific action ('Holt eine Liste') and resource ('aller WordPress-Beitrage'), distinguishing it from sibling tools like wp_get_post (single post) and wp_list_pages (pages). It's a concise, unambiguous statement of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching lists of posts with filters, but does not explicitly compare with alternatives or state when not to use it. No exclusions or alternative tool names are mentioned, leaving guidance at an implied level.
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 convey behavioral traits. It indicates a read-only retrieval and specifies the returned font categories, which is helpful. However, it does not disclose potential error conditions, return format, or dependency on the Elementor plugin being active, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb and resource, with a parenthetical list of the specific font types. It is concise, structured, and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is very simple (no params, no output schema), and the description names the exact font categories returned. However, it omits contextual details like the return structure and prerequisites (e.g., Elementor must be active), leaving some edge cases unaddressed.
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?
This tool has zero parameters and an empty input schema, so the description doesn't need to add parameter details. The zero-parameter baseline is 4, and the description correctly ignores parameters, as there are none to describe.
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 'gets the global Elementor fonts' and lists the specific font roles (Primary, Secondary, Text, Accent). This distinguishes it from sibling tools like elementor_get_global_colors and elementor_get_global_settings, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other Elementor getters or list tools. It lacks any mention of prerequisites, scenarios, or alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It communicates a read-only existence check, but does not disclose the return format, whether 'installed' includes active/inactive plugins, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler; the action and object are front-loaded and every word 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 a 0-parameter tool this is mostly complete, but with no output schema the agent is left uncertain about the response format. It also does not mention any prerequisites or plugin-name variations.
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 and the schema is empty, so the 4 baseline applies. No parameter description is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Prüft' (checks) with a clearly scoped resource ('ob ein JWT Authentication Plugin installiert ist'), distinguishing it from sibling JWT tools that authenticate or refresh tokens and from other plugin detection tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. It does not state when to run this check before using JWT token operations, nor does it 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the core function without revealing behavioral details such as whether it is read-only, how it handles unpublished or draft posts, whether results are limited, or what the response structure looks like. For a listing tool, basic read-only behavior is implied, but nothing beyond that is disclosed, leaving significant 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 a single, concise sentence that front-loads the purpose ('Findet Posts/Seiten ohne Übersetzung') and qualifies the scope ('in einer bestimmten Sprache'). There is zero redundancy, and every word contributes to meaning. It is efficiently structured.
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 relative simplicity (4 parameters, no output schema, no annotations), the description provides a minimal but adequate context. However, it lacks clarification on what 'without translation' precisely includes (e.g., which content statuses are considered, how partial translations are treated) and does not hint at the response format. With many sibling tools, a bit more context would improve completeness, but the current description is not inadequate.
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 does not add additional meaning beyond the schema for parameters like sourceLanguage and targetLanguage, though it does clarify that the tool works on posts/pages, which aligns with the postType parameter. The interplay between language parameters is left to the schema, and the description adds no extra semantic insight.
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 'Findet' (finds) and clearly identifies the resource: posts/pages without translation in a specific language. This clearly distinguishes it from siblings like ml_translation_status (which likely reports overall translation status) and ml_duplicate_for_translation (which creates duplicates). The scope is precise: listing content lacking a translation into a given language.
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: to find posts/pages that lack a translation in a specific target language. It does not explicitly mention alternatives or exclusions, but the context is strong enough to infer appropriate usage. A score of 4 is warranted because there is no 'when not to use' guidance, but the core use case is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It states the core action (restoring an older revision as the current version), but does not mention potential side effects such as overwriting current content, irreversibility, permission requirements, or what the response will be. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately conveys the purpose. It is front-loaded and contains no wasted words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and all parameters documented, the description covers the basic purpose. However, it lacks information about return values, side effects, or the effect on the post's revision history, which would be useful for a restore operation. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters (postId, postType, revisionId). The description adds no parameter-specific meaning, but the schema already documents them thoroughly, 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 'Stellt eine ältere Revision als aktuelle Version wieder her' clearly states the tool's action: restoring an older revision as the current version. This specific verb+resource combination distinguishes it from sibling tools like revision_list, revision_get, revision_compare, revision_delete, and revision_cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to roll back to a previous version) but does not explicitly state use cases or exclude alternatives. It doesn't mention that revision_get or revision_compare are for viewing/analyzing rather than modifying, so guidance 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.
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 does disclose the supported plugin formats (Yoast, RankMath, Standard), which is useful behavioral context beyond a generic 'get meta' statement. However, it does not mention what happens when no meta exists, whether it returns raw values or a formatted object, or any side effects (though likely none). This is minimal but adequate for a simple getter.
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, well-structured German sentence that immediately states the action and object. It contains no filler or redundant information, and every word adds value by specifying the tool's scope and supported formats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), and the description covers its core purpose. However, it lacks details about the return format (e.g., an object with meta keys) and edge cases like missing meta or invalid postId. For a basic retrieval tool, this is acceptable but not thorough.
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 documents the only parameter postId with 'Post/Page ID', covering 100% of the parameters. The description adds no additional semantic detail about the parameter, such as accepted ranges or formats. Given the high schema coverage, this meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Ruft ab' (retrieves) and the resource ('SEO Meta-Tags eines Posts/einer Seite'), and scopes it to specific formats ('Yoast, RankMath, oder Standard'). This distinguishes it from sibling tools like seo_update_yoast_meta or seo_update_rankmath_meta, which perform updates rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading SEO meta tags but provides no explicit guidance on when to use it instead of alternatives such as seo_analyze_content or seo_get_schema_from_post. There are no exclusions or alternative tool mentions, so it falls short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description has full responsibility for behavioral disclosure. It only states that the tool 'retrieves details' without mentioning read-only nature, error handling (e.g., product not found), or response format. This is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is concise and directly states the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one fully documented parameter, the description is minimally viable. However, without an output schema, it would benefit from saying what 'details' include or how the response is structured, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter, productId, is documented as 'Produkt-ID'. The description adds no extra meaning beyond that, so the baseline score 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 a specific verb ('Ruft ab' – retrieves) and clearly identifies the resource ('Details eines einzelnen Produkts' – details of a single product). The word 'einzelnen' distinguishes it from listing tools like woo_list_products, 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 implies the usage context: use this tool when you need details of one specific product, as opposed to a list. It does not explicitly name alternatives or exclusion criteria, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. The verb 'zeigt' (shows) implies a read-only operation, and it mentions that responses include descriptions. However, it does not explicitly confirm no side effects, permissions, or the exact return structure, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently states the tool's purpose and key detail (inclusion of descriptions), achieving maximum conciseness.
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 simplicity (no parameters, no output schema), the description adequately communicates that it lists all available ACF field types with descriptions. However, it could be more explicit about the return format, though this is not a significant gap for such a basic list operation.
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 in the input schema, so the description correctly does not attempt to describe any. The baseline of 4 applies because there are no parameter semantics to clarify.
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 (Zeigt) and resource (ACF Feldtypen), and adds the detail 'mit Beschreibung' (with description). This clearly distinguishes it from sibling tools like acf_list_field_groups, which list field groups, by focusing on field types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as acf_list_field_groups or acf_get_post_fields. It only states the basic function without any context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly signals a read-only operation via 'Listet', but it does not disclose whether the output includes actual password values (vs. metadata), any permission requirements, or pagination behavior. For a simple list tool, this minimal transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and scope. No filler or redundant text; it earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the primary functionality adequately. Minor gap: it does not describe the return format (e.g., list of objects with fields), but for a simple listing tool this is not a major omission.
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 the single optional userId parameter, and the schema already explains that it defaults to the current user. The description adds no additional parameter detail, so the baseline score 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 'Listet' (lists) with a clear resource ('Application Passwords') and scope ('für einen Benutzer'). It unambiguously distinguishes this read-only listing tool from sibling create/delete tools like admin_create_app_password and admin_delete_app_password.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to list app passwords for a user) but does not explicitly state exclusions or direct alternatives. Given the sibling tools for creating/deleting app passwords, some guidance on when to choose listing over those would be helpful, but the purpose is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds a useful scope (available via REST API) and 'list' implies a non-mutating read operation, but it does not explicitly confirm safety, mention response format, or note potential volume/sensitivity of settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately communicates the function. No wasted words, and the structure is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter list tool, the description covers the core behavior and scope adequately. It omits any details about return format or potential caveats, but the low complexity and lack of output schema make the description nearly sufficient on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter information, and the empty schema is fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all WordPress settings available via REST API, with a specific verb (list), resource (settings), and scope (available via REST API). This distinguishes it from siblings like admin_get_settings (get vs list) and other list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as admin_get_settings or wp_get_site_info. There are no exclusions or context for choosing this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only indicates a read operation ('Holt'), but fails to disclose any behavioral nuances such as whether Elementor must be active, how settings are merged, or potential edge cases. This is minimal transparency beyond the obvious.
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 that efficiently conveys the action and scope. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a zero-parameter getter with no output schema, the description covers the core purpose adequately. Minor gaps remain: it does not mention the structure of the response or behavior if Elementor is missing, but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The schema already documents everything (100% coverage), and the description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Holt' = fetches) and a specific resource (all responsive/breakpoint settings from theme and Elementor). This differentiates it from siblings like elementor_get_breakpoints by explicitly covering both theme and Elementor sources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it retrieves, but it provides no explicit guidance on when to choose this tool over alternatives (e.g., elementor_get_breakpoints for Elementor-only settings) and no exclusions. The context is clear but guidance is absent.
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?
The verb 'Holt' implies a read-only operation, but the description does not explicitly state that there are no side effects or describe the return format. Since no annotations are provided, the description bears the full burden, yet it only covers the basic action and content, leaving safety and behavioral details unstated.
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, lean sentence that front-loads the action and resource. It enumerates the exact categories returned and wastes no words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is fairly complete: it states what settings are retrieved and itemizes the categories. However, it doesn't clarify whether these settings come from the active theme, customizer, or theme.json, which leaves a slight ambiguity given related sibling tools.
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 there are no semantics to clarify. The description correctly aligns with the empty schema. The baseline for zero-parameter tools is 4, and this description exposes nothing misleading, so the score 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 ('Holt' = gets) and the resource ('alle Typografie-Einstellungen'), then enumerates what's included (font families, sizes, weights). This distinguishes it from sibling tools like design_get_color_palette or design_get_spacing, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as design_get_customizer_settings, design_get_theme_json, or elementor_get_global_fonts. It lacks any context about selection criteria or exclusions, so the agent must infer based solely on the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It communicates a read-only listing behavior via 'Listet' and specifies the output content (IDs and settings), but it does not disclose potential pagination, response limits, or permission requirements, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and object, with no filler or redundancy. Every word contributes to understanding the tool's function.
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 an output schema exists and the parameter count is low, the description sufficiently explains what the tool lists. It lacks usage guidance and caveats, but those are already evaluated separately; for a straightforward listing tool with rich schema support, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear property descriptions for postId and widgetType, so the description adds no critical parameter details beyond the schema. It does not mention that widgetType is an optional filter, but the schema already conveys this, meeting the baseline 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 ('Listet') and resource ('alle Widgets einer Elementor-Seite mit ihren IDs und Einstellungen'), clearly defining a complete list operation rather than a single-item fetch. This distinguishes it from sibling tools like elementor_get_widget (single widget) and elementor_get_page_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for when an agent needs an overview of all widgets on an Elementor page, but it does not explicitly state when to prefer this over related elementor_* tools or mention prerequisites (e.g., page must use Elementor) and 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?
No annotations are provided, so the description carries full behavioral burden. It transparently indicates a read-only listing operation ('Listet... auf'). However, it does not disclose output structure, pagination, ordering, or any limitations beyond the fact that it lists all forms. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. There is no unnecessary verbiage, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description covers the core functionality. It lacks detail about the exact response format (e.g., whether it returns IDs, titles, full objects), but the operation is so straightforward that the description is nearly sufficient. The absence of an output schema slightly reduces completeness.
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 and schema coverage is 100% (vacuously). With no parameters to document, the description does not need to compensate. The baseline for 0 parameters is 4, and the description appropriately focuses on the operation.
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 'Listet alle Gravity Forms Formulare auf' clearly states the action (listing) and the resource (all Gravity Forms forms). It distinguishes itself from siblings like gf_get_form and gf_get_entries by specifying 'alle' (all) forms, not a single form or entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that gf_get_form retrieves a specific form or that gf_get_entries lists entries. There is no explicit context, exclusions, or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only listing operation by using 'zeigt an', but does not disclose whether it returns all registered block types including core/custom, or any response details. The scope 'alle verfügbaren' is helpful, but behavioral traits beyond that are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately front-loaded and every word contributes to conveying the tool's purpose.
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 low complexity (no parameters, output schema present), the description adequately explains the tool's purpose. However, it could be slightly more complete by explicitly mentioning that it returns a list/object of block types, though that may be covered by the output schema. The lack of usage guidance is a minor gap but not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% and there is no parameter information to add. Per the rubric, a baseline of 4 is appropriate when no parameters exist.
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 'Zeigt alle verfügbaren Gutenberg Block-Typen an' clearly states the verb (zeigt = shows) and resource (available Gutenberg block types), and distinguishes the tool from siblings like gutenberg_list_reusable_blocks and gutenberg_list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply states what it does without mentioning prerequisites, exclusions, or when to prefer another tool, leaving the agent to infer usage from the name alone.
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?
The description implies a read-only operation ('Zeigt an'), but does not disclose potential limitations such as pagination, ordering, or permission requirements. Since annotations are absent, the description is the only source but remains minimal.
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?
Single sentence, direct, and front-loaded with the action. Zero 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?
Adequate for a simple list tool with an output schema and no parameters. It lacks usage guidance but is otherwise complete for its scope.
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?
With zero parameters, the schema fully covers parameter semantics. The description appropriately avoids redundant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it displays all reusable Gutenberg blocks, using the verb 'Zeigt an' (displays). This distinguishes it from sibling tools like gutenberg_list_block_types or gutenberg_list_templates, which target different entities.
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?
Provides no guidance on when to select this tool over alternatives. No mention of scenarios or exclusions, though the name implies its use for reusable blocks only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a read-only listing operation ('Zeigt alle Template Parts an'), which implies safety. However, it does not specify whether the list includes all available parts from the active theme or any other scope, nor does it mention any limitations. For a zero-param tool, this is minimally sufficient but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that is front-loaded with the verb and resource, plus useful examples in parentheses. Every word earns its place, and the structure is immediately clear.
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 simplicity (0 params, output schema present), the description covers the core purpose. It could add context about which template parts are included (e.g., 'from the active theme'), but the output schema likely documents the return structure. Overall, it is adequately complete for its complexity.
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?
There are zero parameters, so the schema is trivially covered. The description says 'alle' (all), implying no filtering is possible, which aligns with the empty parameter list. With no params to document, the baseline of 4 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 clear verb 'Zeigt an' (shows) and explicitly names 'Template Parts' as the resource, with examples (Header, Footer, etc.). This distinguishes it from sibling tools like gutenberg_list_templates, which lists templates rather than template parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. It only states what it does, with no context about scenarios, prerequisites, or exclusions. Sibling tools with overlapping names (e.g., gutenberg_list_templates) are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It accurately implies a read-only listing behavior but does not disclose output format, ordering, or whether it includes built-in and custom sizes. It adds minimal context beyond the title.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is perfectly sized for the tool's simplicity. Every word contributes meaningfully.
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 zero-parameter, no-output-schema design, the description is largely complete. It could benefit from specifying the return format (e.g., an array of size identifiers), but the core purpose is adequately conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information, as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('lists') and resource ('all image sizes registered in WordPress'). It is distinct from sibling tools like image_get_details or image_update_meta, making its 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of alternatives or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It indicates a read operation ('Holt') and notes hierarchical output, but it does not disclose return fields, ordering, or whether all item statuses are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description sufficiently conveys the purpose and return shape (all items with hierarchy). It lacks minor details like output fields or error behavior, but is otherwise adequate.
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% since menuId has a description ('Menü ID'), so the schema fully documents the parameter. The description adds no extra parameter semantics, meriting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Holt'), the resource ('alle Items eines Navigationsmenüs'), and the specific scope ('mit Hierarchie'), distinguishing it from sibling tools like nav_list_menus which list menus rather than menu items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are provided. The description implies this tool is for retrieving hierarchical menu items, but it does not state when to prefer it over nav_list_menus or other navigation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of describing behavior. It communicates a read-only list operation and adds that positions are included, but it does not disclose output format, edge cases (e.g., empty menu list), or whether any data is modified. This is adequate but minimal, providing no significant behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise German sentence that is front-loaded with the action ('Listet') and resource ('alle WordPress Navigationsmenüs'). It is efficiently worded with no fluff, making it appropriately sized for the simplicity of the tool.
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 no-parameter, read-only list tool, the description provides essential information: it lists all menus and their positions. Although there is no output schema, the mention of positions gives a hint about returned data. It could be more explicit about the return structure, but given the low complexity, the description is largely complete.
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?
With zero parameters, the schema covers all inputs trivially, and the baseline for 0-parameter tools is 4. The description does not need to explain parameters, and it adds no parameter-related information, which is acceptable given there are no parameters to document.
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 'listet' (lists) with the resource 'WordPress Navigationsmenüs' and specifies scope 'alle' (all) plus additional detail 'mit ihren Positionen' (with their positions). This clearly states the tool's purpose and distinguishes it from sibling tool nav_get_menu_items, which likely retrieves items within a specific menu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as nav_get_menu_items or wp_list_menus. It only states what the tool does, without any context, exclusions, or mention of alternative tools, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden of behavioral disclosure. It clarifies what block patterns are ('vorgefertigte Layouts') but does not explicitly state that the operation is read-only, has no side effects, or requires special permissions. However, the name and verb 'Listet' strongly imply a non-mutating list operation, so a 3 is appropriate—it adds context but lacks explicit safety/behavioral 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?
The description is a single sentence that is concise, informative, and front-loaded with the action. It explains the resource in a parenthetical without unnecessary verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with one optional parameter and no output schema, the description adequately covers what the tool does. It doesn't describe the return format or pagination, but for a simple 'list all' operation, that's usually understood. It also doesn't mention the category filter, but that's in the schema. Slightly more detail on return structure would make it fully complete, hence 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'category' with a description ('Filter nach Kategorie'), providing 100% schema coverage. The tool description does not mention this filter, but since the schema already documents it, the description adds no extra semantic value. 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 'Listet alle verfügbaren Gutenberg Block Patterns (vorgefertigte Layouts)' clearly states a specific verb (list) and resource (Gutenberg block patterns), with an explanatory parenthetical. It distinguishes from sibling tools like 'pattern_get_pattern' (which likely retrieves a single pattern) by emphasizing 'alle verfügbaren' (all available).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need a list of all available block patterns. However, it provides no explicit comparison to alternatives like 'gutenberg_list_block_types' or 'pattern_get_pattern', nor any exclusions or when-not-to-use guidance. This is a standard list tool, so the implied usage is clear, but explicit differentiation would elevate it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It conveys the core behavior (showing active plugins with potential performance impact) and hints that the impact is an estimate via 'potentiellen', but it does not disclose whether the tool is read-only, how impact is calculated, or what the output format looks like. This is minimal beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly front-loaded sentence that states the action and the result. Every word earns its place, with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description adequately outlines the output (a list of active plugins with their potential performance impact). Since no output schema exists, the description serves that role well. It could be slightly more detailed about what 'performance impact' means empirically, but it is sufficient for a straightforward analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no inputs for the description to explain. Per the rubric, this yields a baseline of 4. The description correctly omits parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with the verb 'Zeigt' (shows) and specifies the resource (active plugins) and the scope (their potential performance impact). It distinguishes itself from sibling tools like perf_analyze_content and perf_check_images by focusing on plugin-level impact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose implies when to use it—when an overview of active plugins and their performance impact is needed. However, it does not explicitly mention alternatives such as wp_list_plugins or perf_analyze_content, nor does it provide any when-not guidance. The usage context is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the tool is a read operation ('ruft ab') and specifies the scope (language and translations), but it does not mention error handling, plugin dependencies, or return format. For a simple getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded with the action and immediately states the resource and expected output, making every word necessary.
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 low-complexity tool (one parameter, no output schema), the description states the input purpose and expected output (language and translations) but lacks details on the return structure, such as how translations are represented. It is sufficient for a simple getter but not exhaustive.
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 full coverage with the parameter 'postId' described as 'Post-ID'. The description adds no additional meaning beyond restating that the tool operates on a post. Thus, the baseline of 3 applies because 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 uses the specific verb 'Ruft ab' (retrieves) and clearly identifies the resource: the language of a post and its translations. This distinguishes it from sibling tools like polylang_set_post_language (write operation) and polylang_list_languages (list all languages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a post's language and translations, but it does not explicitly state when to use this tool over alternatives like wpml_get_post_translations or mention exclusions or prerequisites. The usage context is assumed rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Listet auf' implies a read-only operation, but the description does not explicitly state that it has no side effects, nor does it describe the return format. For a simple list tool, this is adequate but not detailed.
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, clear sentence with no unnecessary words. It is front-loaded and easy to parse, ideally concise for a simple list operation.
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 low complexity (zero parameters, no output schema), the description is nearly complete. It states the tool's purpose clearly, but does not specify the exact structure of the returned language list (e.g., codes, names, locales), which would be helpful for an agent to set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description's focus on the action and resource is consistent with the empty input schema, and no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Listet auf' (lists) and a specific resource 'alle konfigurierten Polylang-Sprachen' (all configured Polylang languages), which clearly distinguishes it from sibling tools like wpml_list_languages or polylang_get_post_language. The purpose is unambiguous and directly related to 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as wpml_list_languages or polylang_get_post_language. It does not mention use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Holt' indicates a read operation, but it does not disclose potential error behavior, authentication requirements, or assumptions about the route existing. Since the output schema exists, the return format is covered, but additional behavioral context is minimal.
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, well-structured sentence that is front-loaded with the core action. It contains no redundant information and earns its place entirely.
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 relatively simple with two parameters and an output schema. The description provides the essential purpose, while the schema and output schema fill in parameter details and return structure. It could benefit from explicit sibling differentiation or error behavior, but for this complexity level, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (route and method), including examples for route. The description only adds a high-level statement that all parameters and types are included, which matches the schema baseline. No additional semantic value beyond the schema is provided.
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: retrieving detailed metadata for a specific REST API endpoint, including all parameters and their types. The verb 'Holt' (retrieves) and resource 'spezifischen REST API Endpoint' are specific, and this distinguishes it from sibling tools like rest_api_list_functions or rest_api_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific endpoint rather than listing or executing, but it does not explicitly reference alternatives or exclusion criteria. It lacks a note like 'Use rest_api_list_functions to list all endpoints.' Thus, guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Listet alle konfigurierten' implies a read-only operation and adds scope ('alle konfigurierten' = all configured), which is useful context. However, it does not clarify whether the list includes only enabled gateways or all gateways with settings, nor does it describe pagination or return format.
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, straightforward sentence that front-loads the action and scope. It is concise and entirely relevant, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is adequately informative. It states the resource and scope, which is sufficient for a simple read operation. However, it does not describe the response structure or any filtering behavior, which could have been added for clarity.
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, and the schema is empty. With no parameters to explain, the baseline is 4. The description adds no parameter-specific semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Listet alle konfigurierten Zahlungsmethoden auf' (Lists all configured payment methods). The verb 'Listet' and resource 'Zahlungsmethoden' specify a list operation for payment gateways, distinguishing it from sibling tools like woo_list_orders or woo_list_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description merely states what it does, with no mention of conditions, prerequisites, or exclusions. For a simple list tool, the context is implied but not explicitly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it is a read operation listing all variations, but does not mention output format, pagination, or behavior when the product is not variable. Minimal but not misleading for a basic 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 a single, front-loaded sentence with no filler words. It directly states the action and target, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 required parameter, no nested objects, no output schema), the description plus parameter schema are sufficient for a basic list operation. However, the absence of annotations and any mention of return format means it is not fully complete, but adequate for the intended 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?
The input schema provides 100% coverage with a clear description for productId ('Produkt-ID des variablen Produkts'). The tool description adds no additional parameter semantics beyond what the schema already clarifies, 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 a specific verb ('Listet') and resource ('alle Varianten eines variablen Produkts'), clearly distinguishing this tool from sibling tools like woo_list_products, which list products rather than variations. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative tools are mentioned. However, the description implies its usage: when you need all variations of a specific variable product identified by productId. This is sufficient for a simple read tool but lacks formal exclusions or alternatives.
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. 'Listet' implies a read-only operation, but it does not disclose details such as whether all forms include trashed or draft forms, or what the return structure looks like. It provides basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is appropriately sized for a simple listing tool. It is front-loaded with the action and resource, containing no unnecessary words.
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 zero-parameter list tool, the description is adequate. However, it lacks context about the output format or whether any filtering options exist, which could be helpful given the absence of an output schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description accurately reflects the lack of parameters, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Listet alle WPForms Formulare auf' clearly states the action (list) and the resource (all WPForms forms), distinguishing it from sibling tools like gf_list_forms and nf_list_forms which target different form plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does without mentioning use cases, exclusions, or alternative tools like wpforms_get_entries for entries.
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?
The description implies a read-only operation by using 'Zeigt' (shows), but it does not mention authentication requirements, response details, or any side effects. Since annotations are absent, the description carries full burden, but it adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose without any wasted words. It is appropriately front-loaded and easy to parse.
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 simplicity of the tool, the presence of an output schema, and no parameters, the description is sufficiently complete for its complexity. It lacks extra context like multisite behavior, but this is a minor gap.
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 schema fully documents what is needed. The description correctly avoids parameter details, matching the baseline of 4 for no-parameter tools.
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 (shows/displays) and the resource (all installed WordPress themes). This distinguishes it from sibling tools like wp_list_plugins or wp_list_sidebars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no exclusions or explicit context, relying solely on the resource name for differentiation.
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 implies a read-only listing operation and clarifies scope ('configured' languages), but it does not disclose return format, behavior when WPML is inactive, or whether it includes inactive languages. This is acceptable for a simple list operation but not richly transparent.
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, short sentence that is front-loaded with the core action and object. Every word earns its place, and there is 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?
Given the tool's simplicity (zero params, no annotations, no output schema), the description is mostly complete. However, it does not specify what the output structure looks like (e.g., array of language codes/names), which an agent might need to know for downstream processing. Still, it's adequate for basic invocation.
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, and the schema has no properties, so the baseline is 4. The description does not need to explain parameters, and it adds no further semantic detail beyond the schema, which is already complete.
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: listing all configured WPML languages. It uses a specific verb ('Listet auf') and resource ('alle konfigurierten WPML-Sprachen'), which distinguishes it from sibling tools like polylang_list_languages or wpml_get_post_translations.
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 gives no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or alternative tools. It simply states what the tool does, leaving the agent to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only operation ('abrufen'), but offers no details on response format, error handling, or performance impact of bulk requests. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without extraneous detail, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and no output schema, the description provides the essential purpose but lacks information about the return structure (e.g., keyed by post ID). It is adequate but has clear 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%; both postIds and fields are fully described in the input schema. The description adds no additional semantic 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 clearly states the tool retrieves ACF fields for multiple posts, using a specific verb ('ruft ab') and resource ('ACF Felder'). This differentiates it from single-post tools like acf_get_post_fields.
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 context implies use for bulk retrieval of ACF fields across multiple posts, but it doesn't explicitly mention alternatives or when-not-to-use scenarios. Since the use case is clear without exclusions, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool only reads existing data ('vorhandene'), suggesting a non-destructive operation. However, it does not mention permissions, return format, or behavior when no schema is present, leaving some gaps for a tool with no annotation support.
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, succinct sentence front-loaded with the action ('Extrahiert') and object. No filler or redundancy, making it highly concise and scannable.
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 simplicity (one parameter, no output schema), the description covers the core action but omits details about the return value or edge cases like missing Schema.org data. It is minimally viable but not fully complete for an agent needing to handle responses confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'postId' with a clear description ('Post/Page ID'). 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 a specific verb ('Extrahiert') and clearly identifies the resource ('vorhandene Schema.org Daten') and the target ('aus einem Post'). It distinguishes this from sibling tools like 'seo_generate_schema' and 'seo_get_post_meta' by emphasizing existing data extraction.
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 context is clear: use this tool to retrieve existing Schema.org data from a post. Although alternatives are not explicitly named, the phrase 'vorhandene' (existing) implies a contrast with schema generation tools. No exclusions are stated, but the simple read-use-case is well implied.
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 must carry the transparency burden. 'Ruft ab' implies a read-only operation, but it does not explicitly mention side-effect-free behavior, return behavior for missing options, or any access requirements. This is a simple getter, so the gap is moderate but 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, well-formed sentence that directly states the core purpose with no filler. It is front-loaded with the action and resource, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is largely sufficient: it names the table and the retrieval action. However, it could be more complete by stating what is returned (e.g., the option value or null if not found), but the simplicity of the tool mitigates this omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for 'option' with 100% coverage, but the description adds concrete examples ('blogname, admin_email, etc.'), which clarify the expected format and typical values. This goes beyond the schema, adding practical semantic value for the agent.
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 specific action ('Ruft eine einzelne WordPress Option ... ab' = retrieves a single WordPress option) and the resource ('aus der wp_options Tabelle'). This distinguishes it from sibling tools like admin_list_settings (list) and admin_update_option (update). The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing a single option value, but it does not explicitly state when not to use it or provide alternatives like admin_get_settings or admin_list_settings. There is no exclusion guidance for scenarios such as fetching multiple options or checking for existence, leaving the agent to infer from the tool name.
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 behavioral disclosure. It specifies the tool returns the complete configuration with named design areas, but does not disclose return format, error conditions, or whether it is read-only (though the verb implies it). This adds some context but leaves the agent unaware of potential edge cases like non-block themes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the tool's purpose and scope.
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 no-parameter read tool, the description is mostly complete: it names the resource and main content categories. However, it lacks notes on return format or behavior when theme.json is absent or the theme is classic, which could leave the agent unsure about error handling. Since output schema is absent, a bit more detail might help, but the tool is simple enough.
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?
There are zero parameters, so the baseline is 4. The description adds no parameter details (not needed) but clarifies the tool's output scope, which is sufficient.
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 the complete theme.json configuration and enumerates key contents (colors, typography, spacing, layout), making it distinct from sibling tools like design_get_typography or design_get_color_palette that target specific subsets. The verb 'Holt' is specific and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the full theme.json is needed, but it does not explicitly contrast with more specific sibling tools or state when to prefer them. No prerequisites or context are provided, so the agent must infer the use case from the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns global colors and lists the expected color names, but it does not specify the return format (e.g., hex values), whether custom colors are included, or any edge cases. Basic read behavior is implied but not detailed.
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, efficient sentence that front-loads the action and resource. There is no redundant or filler content. The title is slightly awkward ('Hole' instead of a proper verb), but the description itself is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter getter, the description provides sufficient context by identifying the resource and the color slots included. However, since there is no output schema, it could more explicitly state the return value format (e.g., hex codes) to be fully complete. This is a minor gap for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with 100% coverage. The baseline for 0 params is 4. There is no parameter information to add, and the description does not need to explain anything beyond what the schema already shows.
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 retrieves global Elementor colors, listing the specific color slots (Primary, Secondary, Text, Accent). This unambiguous verb ('Holt') and resource distinguish it from sibling tools like elementor_get_global_fonts and elementor_get_global_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve Elementor global colors) but does not provide explicit when-to-use guidance or mention alternatives. Since this is a simple getter, the use case is fairly self-evident, but there is no exclusion guidance relative to similar Elementor getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states that the tool fetches (reads) global settings and lists the scope, implying a safe read-only operation. However, it does not disclose potential response structure, permission requirements, or whether the returned data is a superset of the listed categories, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in German, front-loaded with the action verb and immediately clarifying the content. Every word earns its place; there is 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 parameterless getter with no output schema, the description provides adequate context by naming the three key content areas (colors, fonts, breakpoints). It does not describe the exact return format, but given the low complexity and the clear scope, it sufficiently informs an agent about what to expect. A slightly more detailed mention of the response structure would elevate it further.
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, and the schema is an empty object, so the description is not required to explain parameter semantics. The baseline for 0 parameters is 4. The description adds negligible parameter information but is not deficient in this dimension.
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 ('Holt' / gets) and resource ('globalen Elementor-Einstellungen'), and explicitly enumerates the included categories (colors, fonts, breakpoints). This clearly distinguishes it from sibling tools that focus on individual global settings, such as elementor_get_global_colors or elementor_get_breakpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is the umbrella option for retrieving multiple global settings at once, but it does not explicitly state when to prefer it over the more specific sibling tools. There is no mention of exclusions, alternatives, or when to use the granular getters instead, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It accurately describes a read-only listing action, but it does not explicitly state that it is non-destructive, nor does it mention any potential side effects, authentication requirements, or output characteristics. The description is honest but minimal, providing only the basic action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in German that front-loads the verb and object. It contains no fluff, repeats nothing from the title unnecessarily, and every word contributes to the meaning. It is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description is sufficiently complete for an agent to understand what to expect. It clearly identifies the resource type (global/reusable widgets) and the action (list). It might benefit from noting that the output is an array or list of widget identifiers, but this is implied and not critical for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered (100% coverage vacuously). According to the rubric, a baseline of 4 is appropriate when there are no parameters, and the description does not need to add anything about parameters. It is a simple list operation with no input requirements.
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 ('Listet auf') and clearly specifies the resource ('alle globalen/wiederverwendbaren Elementor Widgets'), distinguishing it from sibling tools like elementor_list_widgets which likely lists non-global widgets. It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you need a list of global/reusable Elementor widgets. However, there is no explicit guidance on when not to use it or which alternative tools to consider (e.g., elementor_get_widget for details), so it only meets the 'implied usage' standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It implies a read-only operation through 'Holt' and adds useful context about returning all image sizes, but it does not explicitly state read-only semantics, auth requirements, or error behavior. This is adequate but not fully transparent.
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 that states the verb, object, and a key detail (all image sizes) with no wasted words. It is appropriately sized for a simple get-by-ID tool.
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 low-complexity tool with one fully documented parameter and an output schema, the description is nearly complete. It covers the operation's scope and the inclusion of image sizes, leaving little ambiguity for selecting and invoking the 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 only parameter 'id' is already described as 'Media ID'. The description's 'einzelnen Mediendatei' reinforces that the ID identifies a media file, but it does not add substantive 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?
The description uses a specific verb ('Holt Details') and a clear resource ('einer einzelnen Mediendatei'), and adds the key differentiator 'inklusive aller Bildgrößen'. This clearly distinguishes it from sibling tools like wp_list_media, which lists media files rather than fetching a single one.
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 indicates this is for retrieving a single media file by ID, implying use when detailed info on one item is needed versus listing with wp_list_media. It does not explicitly name alternatives or exclusion criteria, but the single-file focus provides clear usage context.
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 implies a read-only operation via 'zeigt' and states that it lists active widgets, but it does not disclose any additional behavioral traits such as return format, limitations, or side effects. Adequate but minimal.
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 short sentence that directly conveys the function without any filler. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema present, so return values are covered. The description fully captures the core purpose. It could be enhanced by noting alternatives or exclusions, but it is complete enough for the tool's complexity.
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, and the schema coverage is 100% vacuously. With no parameters to document, the description does not need to add parameter meaning, and the baseline for zero params is 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 tool displays all active widgets in sidebars, using a specific verb ('zeigt') and resource ('aktiven Widgets in den Sidebars'). It distinguishes from siblings like wp_list_sidebars and elementor_list_widgets by specifying 'active widgets in sidebars'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The usage is implied from the purpose but there are no exclusions or comparisons to sibling tools such as elementor_list_widgets.
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?
Since no annotations are provided, the description carries the full burden. The word 'zeigt' (shows) inherently implies a read-only operation, and the qualifier 'mit REST API Support' adds scope. However, it does not explicitly disclose absence of side effects, auth requirements, or pagination, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the action and resource. It contains no filler words and is appropriately sized for the simplicity of the tool.
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 zero-parameter input and the existence of an output schema, the description is complete for a simple listing tool. It specifies the exact scope ('all registered taxonomies with REST API support') without needing to explain return values, which are covered by the output schema.
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 there is nothing to explain. With an empty input schema, parameter semantics are trivially clear, and the description does not need to add any parameter information. The baseline for 0-parameter tools is 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 function with a specific verb ('Zeigt') and resource ('Taxonomien'), and adds a qualifier ('mit REST API Support') that distinguishes it from other listing tools like rest_api_list_post_types. It is unambiguous and directly addresses what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when needing to display taxonomies with REST API support, but it does not explicitly mention when to use it over alternatives or any exclusions. It provides a clear context of what it returns but lacks guidance on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states what the tool does ('Holt alle WordPress-Tags') and implies a read-only action, but does not disclose additional behavioral details such as pagination, ordering, or performance characteristics. It is adequate for a trivial list but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and directly communicates the full purpose. Every word earns its place, with no unnecessary filler or repetition.
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 zero-parameter, simple list tool with an output schema, the description is complete. It fully captures what the tool does without needing to explain return values (covered by output schema) or edge cases (none exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information, and the schema is trivially complete with 100% coverage. No further 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?
The description 'Holt alle WordPress-Tags' uses a specific verb ('holt') and a clear resource ('alle WordPress-Tags'), distinguishing it from sibling tools like wp_list_categories or wp_list_posts. It clearly states the operation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need all tags) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. For a simple list tool, this is acceptable but not thorough.
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. It clearly states the action 'Listet alle Elementor Kits' (lists all kits), which communicates a read-only, non-mutating behavior. No hidden behaviors (pagination, filtering) are claimed or omitted. This is sufficient transparency for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the verb and object, making it immediately scannable. Every word contributes to 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?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is almost complete. It states what is listed and the domain ('Elementor Kits'). A minor gap is the absence of return format details, but for a generic list operation, an agent can reasonably infer an array of kit objects.
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 there are no parameter semantics to clarify. Per the rubric, 0 params earns a baseline 4. The description adds nothing about parameters because none exist.
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 ('Listet' = lists) and names the resource ('Elementor Kits') with a clarifying parenthetical ('Design Presets'). It clearly distinguishes from sibling tools like elementor_list_theme_builder_templates or elementor_list_global_widgets, which target different Elementor asset types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives or when-not-to-use guidance is provided, but the verb 'Listet' implies the usage: when an agent needs a catalog of available Elementor design kits. Given the simplicity of the tool, this implied usage suffices, though a brief note about when to prefer other Elementor list tools would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clarifies the scope (all block templates for FSE) but does not explicitly state that the operation is read-only or disclose any permissions or prerequisites, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource, containing no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently covers the functionality for a straightforward listing task. It could optionally mention whether templates come from the active theme, but this is not critical for basic use.
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?
There are zero parameters, so the description does not need to explain parameter syntax or semantics. The baseline of 4 applies since no parameter information is required.
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 'Zeigt' (shows) and specifies 'alle Block-Templates' (all block templates) with the qualifier 'Full Site Editing', clearly differentiating from sibling tools like gutenberg_list_template_parts or gutenberg_list_block_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?
It provides clear context by mentioning 'Full Site Editing', which implies when this tool is relevant, but does not explicitly state exclusions or alternatives. For a simple no-parameter list operation, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'retrieves' implies a read-only operation, but the description adds no details about permissions, potential side effects, or the structure of returned data. It merely restates the purpose without deeper behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the action and object without superfluous information. It is front-loaded and every word contributes to the meaning, making it an model of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only getter with no output schema, the description adequately conveys the essential purpose. It does not specify the exact format of the returned settings, but the simplicity of the tool makes this acceptable. A note about what 'general shop settings' includes would be an improvement but is not essential.
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, and the input schema confirms an empty object with 100% coverage. Since there are no parameters, the description need not explain parameter semantics, and the baseline for 0 parameters is 4. No additional information is required.
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 'Ruft ab' (retrieves) and the resource 'allgemeine Shop-Einstellungen' (general shop settings), making the tool's function unambiguous. This differentiates it from sibling WooCommerce tools that target specific entities like products, orders, or customers.
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 the tool should be used when one needs to retrieve general WooCommerce shop settings, which is clear context. However, it does not explicitly mention alternatives or exclusions, but given the zero-parameter nature and the uniqueness of the resource, this is adequate.
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 for behavioral disclosure. It states that the tool returns all shipping zones and their methods, which is a clear behavioral trait. The word 'listet' implies a read-only operation, but it does not explicitly state that no modifications are made. However, for a parameterless list tool, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. There is no unnecessary information, making it highly efficient and easy to parse.
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 parameterless list tool, the description adequately covers the operation's scope: it lists all shipping zones and their methods. It does not detail the exact data structure or any sorting, but given the tool's simplicity and lack of parameters, it is nearly complete.
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 accepts zero parameters, and the schema description coverage is 100% by default. The description's use of 'alle' (all) clarifies that no filtering is possible, adding semantic value beyond the empty schema. This aligns with the baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all shipping zones and their methods, using the specific verb 'listet' (lists) and the resource 'Versandzonen und deren Methoden' (shipping zones and their methods). This distinguishes it from sibling tools by specifying the unique resource being listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve shipping zones, but it does not provide explicit when-to-use guidance or mention alternative tools. For a simple list operation, the context is implied rather than fully articulated.
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 fully discloses the operation's scope (all roles) and content (capabilities), and it implicitly signals a read-only, non-destructive behavior. For a simple list operation, no further behavioral disclosure is necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the verb and resource, and contains no unnecessary words or 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 zero-parameter tool with no output schema, the description fully covers what the agent needs to know: what is listed, the scope, and the content. No additional context is required.
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 and the schema is empty, so there is no parameter information to explain. The baseline of 4 applies because the description adds no parameter semantics but also does not need to.
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 'Listet' (lists) and clearly identifies the resource as 'alle WordPress-Benutzerrollen mit Capabilities' (all WordPress user roles with capabilities). This distinctly separates it from sibling tools like admin_list_users, which list users, not roles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all user roles with their capabilities, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Since no other sibling tool lists roles, the intended usage is reasonably clear, but guidance is not explicitly articulated.
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 behavioral disclosure. It clearly indicates a read-only operation ('Zeigt' = shows) and adds a useful filtering detail: only post types with REST API support are included. However, it does not describe the exact output structure or any pagination/ordering behavior, though an output schema exists to cover return values.
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 that directly states what the tool does without any filler. Every word adds value, and no unnecessary details distract from 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?
This is a simple listing tool with no parameters and an existing output schema. The description is sufficient for an agent to understand what the tool returns and when to invoke it. Given the low complexity and the presence of an output schema, the description is fully complete.
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 and the schema is empty, so there are no parameter semantics to clarify. The description correctly omits parameter details, and the baseline for zero-parameter tools is 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 uses a specific verb 'Zeigt' (shows) and clearly identifies the resource: all registered post types with REST API support. It distinguishes itself from sibling tools like rest_api_list_taxonomies and rest_api_list_functions by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to list post types enabled for REST API, but it provides no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. As a simple listing tool, the intended use is fairly obvious, but no explicit context or alternatives are mentioned.
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. The verb 'zeigt an' (displays) clearly indicates a read-only listing operation, providing adequate transparency. No side effects are mentioned, but none are expected for a simple 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 a single sentence that conveys all necessary information with no wasted words. It is appropriately sized and directly stated.
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 parameterless list tool with an output schema, the description is complete. It clearly states what is listed, and the output schema covers the return format, leaving no significant gaps.
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, and schema description coverage is 100%. The description correctly avoids inventing parameter details, aligning with the baseline for parameterless tools.
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 that the tool displays all registered widget areas (sidebars), using a specific verb ('zeigt an') and resource, distinguishing it from sibling tools like wp_list_widgets. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance or alternatives are provided. The description implies when to use the tool (e.g., when you need to list all sidebars) but does not offer exclusions or comparisons with other list tools.
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:

[![wp-mcp-server MCP server](https://glama.ai/mcp/servers/c-sakel/wp-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/c-sakel/wp-mcp-server)

Score Badge

Copy to your README.md:

[![wp-mcp-server MCP server](https://glama.ai/mcp/servers/c-sakel/wp-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/c-sakel/wp-mcp-server)

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/c-sakel/wp-mcp-server'

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