postiz-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description fully carries the burden. It discloses the verification behavior and its implication for other tools. However, it does not specify what 'ok' means (e.g., return value or status), which is a minor gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences with no wasted words. Every sentence provides essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description covers purpose and usage well but lacks specifics on the response format (e.g., what constitutes 'ok'). Still fairly complete for a simple health check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters (100% coverage by default). The description adds context about the tool's purpose, which is sufficient for a parameterless tool. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: verifying API key validity and baseUrl reachability. It also distinguishes itself from siblings by positioning it as a first-call health check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using this tool first, before others, and explains the condition for continued authentication. This is excellent guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosure. It explains that the tool returns a URL and does not run a callback server, but it does not disclose potential side effects, such as whether a pending integration is created, or what happens if the URL is used multiple times. This is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that convey the core purpose, the return type, a key behavioral note, and a requirement. No extraneous information is included, and the most critical points are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two simple parameters and no output schema, the description covers the essential aspects: what the tool does, what it returns, a notable limitation (no callback server), and a permission requirement. It lacks details on the expected response structure beyond the url, but this is minor given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers both parameters with descriptions, achieving 100% coverage. The description adds minimal extra value by mentioning the default for 'refresh' (false) and the meaning of 'provider' (slug). Since the schema already provides the parameter semantics, the description does not significantly enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates an OAuth authorization URL for connecting a new social channel, using the verb 'Generate' and resource 'OAuth authorization URL'. It distinguishes itself from sibling tools like 'postiz_check_integration' and 'postiz_list_integrations' by specifying its unique role in initiating the OAuth flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that the tool requires enableWrite and that it does not run a callback server, providing implicit guidance on when to use it. However, it does not explicitly compare to alternative tools or state when not to use it, leaving some room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description fully discloses the public side effect for 'now' and near-term schedule, the dependency on provider settings schema, and the 'enableWrite' permission requirement. This is comprehensive for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences exactly: action, side-effect warning, prerequisite. Every sentence adds value; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, yet description does not mention expected return value (e.g., post ID) or pagination. For a creation tool, this gap may hinder the agent from handling the response. Purpose and side effects are clear, but return details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60% (type, date, posts described in schema). Description adds the side-effect warning for type and the prerequisite for settings, but does not explain shortLink or tags parameters, which remain undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool creates, schedules, or publishes posts, specifying the HTTP endpoint and the public side effect for 'now' or near-term schedule. This distinctly separates it from siblings like delete or update tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description advises using postiz_get_provider_settings_schema first to construct valid settings and mentions the 'enableWrite' requirement. It implies caution with type='now' but lacks explicit 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses cascading side effects, required permissions, and error behavior (ok:false / not_found). Missing explicit mention of irreversibility, but cascading implies destructiveness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then critical requirements and return behavior. No wasted words; each sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and partial param descriptions, the tool description covers main behavioral aspects: side effects, auth, error handling. Minor gaps, e.g., exact format of ok:false response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50% (only confirm has a description). The description adds context for both params, especially confirm's requirement and the return status. More detail on integrationId format would improve clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Disconnect a connected social channel.' It also notes the cascading deletion of scheduled posts, distinguishing it from siblings like postiz_connect_integration (add) and postiz_list_integrations (read).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description specifies prerequisites: 'Requires enableWrite + enableDelete + confirm=true.' It also describes a return condition for 404. While it does not explicitly state when to avoid use, the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses cascading deletion of the entire group, that published platform posts remain live, and the required permissions. This is excellent transparency for a delete operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero wasted words. It front-loads the core action and immediately follows with critical behavioral details, making it highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers prerequisites, cascading, and side effects. It could optionally note the success response, but for a delete tool, the information provided is sufficient for agent understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 50% (confirm has a description, postId does not). The description compensates by explaining that confirm=true causes cascading to the whole group, adding meaning beyond the schema. For 2 parameters, this is strong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete a Postiz post by id'), specifies cascading behavior, and distinguishes from sibling tools like postiz_delete_post_group. 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly mentions the required flags (enableWrite, enableDelete, confirm=true), providing clear prerequisites. While it doesn't explicitly state when not to use the tool or list alternatives, the cascading warning effectively guides usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses key behaviors: the HTTP method, the API path, required permissions (enableWrite, enableDelete), and the mandatory confirm=true for deletion. This adequately informs the agent of the tool's safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences cover purpose, usage, permissions, and requirements. No unnecessary words. Key information is front-loaded in the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a delete endpoint with no output schema, the description covers all essential aspects: what it does, when to use it, required permissions, and the mandatory confirm flag. It lacks mention of response format or error handling, which is acceptable for a simple deletion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 50% (only confirm has a description). The description adds context for 'group' as a cross-post unit, but does not elaborate on its format or how to obtain it. The confirm parameter is already well-documented in the schema, so the description adds minimal value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Delete every post in a group (cross-post unit)'. It specifies the HTTP method and endpoint, and distinguishes from sibling tool postiz_delete_post by emphasizing it deletes a whole cross-post group.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use: 'Use when you want to retract a whole cross-post in one call.' It does not explicitly state when not to use, but the sibling list provides an alternative for single posts, so the guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It clearly indicates a read-only operation (returns a time slot) and respects the schedule. However, it does not disclose potential error conditions (e.g., no available slot) or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous information. First sentence states the core function, second provides usage guidance. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description adequately covers purpose and usage. It could mention the return type (e.g., timestamp), but the current text is sufficient for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers the sole parameter (integrationId) with a description. The description does not add extra meaning beyond that, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the next available posting time for a given integration, and explicitly links it to usage in postiz_create_post. This distinguishes it from siblings like postiz_create_post or postiz_list_integrations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: when you don't have a specific time in mind, and to use the result as `date` in postiz_create_post. It also mentions that the slot respects the org's posting schedule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses cost implications and the need for write permission. It does not mention asynchronous behavior, rate limits, or success/error responses, leaving gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences covering purpose, cost, permissions, and body shape. Every sentence provides essential information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the minimal input schema and lack of output schema, the description covers cost and permission but omits output format, synchronous/asynchronous behavior, and error handling. External documentation is referenced but the description itself is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'body' is described in the schema as 'Free-form payload as expected by Postiz video integrations'. The description reinforces this as provider-specific and points to external docs, but adds little new semantic value beyond the schema's description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Generate an AI video via POST /api/video/generate', specifying the verb (generate) and resource (AI video). This distinguishes it from sibling tools like postiz_create_post (social post) and postiz_upload_file (file upload).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions cost implication and permission requirement (enableWrite), and advises consulting Postiz docs for provider-specific body shape. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but 'fetch' implies read-only. Description adds temporal context ('recent') but doesn't detail response format or confirm no side effects. Adequate for a simple fetch tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with purpose, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given single parameter, no output schema, and clear purpose, description is complete. Provides enough context for correct usage and pairing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers parameter with description. Tool description adds workflow context (why fetch due to missing releaseId). Adds value beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Fetch', resource 'platform-side content', and condition 'whose releaseId is marked missing'. Differentiates from sibling by mentioning pairing with postiz_update_post_release_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use (post with missing releaseId) and provides pairing guidance with postiz_update_post_release_id. No exclusions needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 GET request implying read-only behavior, but does not disclose other traits such as authentication requirements, rate limits, error conditions, or data freshness. The description is minimally adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, no wasted words, and front-loads the core purpose. Every sentence provides necessary information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks details about the return format, pagination, or error scenarios. Given the absence of an output schema, the description should compensate by describing the response structure, but it does not. It is adequate for a simple analytics retrieval but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds context that the 'integrationId' refers to a connected channel and that 'date' is a lookback in days with a default. It also explains that metric availability depends on the platform, adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves follower/impression/engagement analytics for a connected channel via a specific HTTP endpoint. It uses a specific verb ('Get') and resource ('follower/impression/engagement analytics'), distinguishing it from sibling tools like get_post_analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes that available metrics depend on the platform, implying limitations, but does not explicitly state when to use this tool versus alternatives or when not to use it. No comparison to 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.

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 return shape varies by provider, which is important for handling responses. However, it does not mention read-only behavior, auth requirements, rate limits, or error conditions, leaving gaps in behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and includes essential nuance about variable output. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description adequately covers purpose and output variability. It could be improved by noting errors or examples, but it is sufficiently complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with 'postId' described as 'Post id.' The description does not add further context about the parameter beyond the endpoint path, so it adds minimal value over 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves per-post engagement metrics (likes, comments, shares) and specifies the API endpoint. It differentiates from sibling tools like postiz_get_platform_analytics (which is platform-level) and postiz_list_posts (listing posts) by focusing on individual post analytics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for per-post analytics but lacks explicit guidance on when to use this tool versus alternatives (e.g., postiz_get_platform_analytics). No exclusions or prerequisites are mentioned, leaving decision-making to the agent without comparative context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description discloses the return structure (default-settings template, __type, markdown reference) and implies read-only behavior via 'look up'. It adds value but could explicitly state that no side effects occur.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The first states purpose and source; the second summarizes returns and usage. Every word earns its place, and the information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only 2 parameters and no output schema, the description adequately covers purpose, usage hint, and return structure. It lacks detail on the format of the settings block, but the reference to a 'template' and markdown is sufficient for an AI to understand the tool's function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes both parameters (provider string, includeMarkdown boolean). The description adds context by specifying the allowed provider values ('slug or __type') and the default behavior of includeMarkdown (true). This enhances understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('look up') and clearly identifies the resource ('settings block schema for a Postiz provider'). It also states the bundled source and outlines the return values, making the purpose unambiguous and distinct from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises calling this before postiz_create_post when provider-specific fields are needed. This provides clear usage context, though it does not specify when not to use it or mention any alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the return fields and purpose, but does not discuss authentication requirements, rate limits, or any side effects. Since it's a read-only listing, this is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each adding essential information: what the tool does and how it fits into a larger task. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with no parameters and no output schema, the description covers the necessary information: purpose, returned fields, and integration point. Could be improved by mentioning error cases or auth context, but it's sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With no parameters, the baseline is 4. The description adds value by explaining what the tool returns and its role in the workflow, which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists connected social-media channels, returns specific fields, and provides a use case (before postiz_create_post). It distinguishes from siblings by giving a workflow hint, though it doesn't explicitly differentiate from postiz_check_integration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using this tool before postiz_create_post to obtain the integration ID. However, it does not mention when not to use it or alternatives like postiz_check_integration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It mentions sorting but does not disclose pagination behavior (page parameter implies pagination but is not described). The example notification types give some context, but more detail on what the response contains would improve transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. All information is front-loaded and relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter and no output schema, the description is reasonably complete. It covers purpose, sorting, and usage examples. Could potentially mention that it fetches paginated results, but current context is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (page parameter). The description adds no additional meaning beyond what the schema already provides (only 'default 1'). Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and resource 'notifications' with sorting order 'most-recent first'. It is distinct from sibling tools like postiz_list_integrations and postiz_list_posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete use cases: 'surfacing posting failures, OAuth re-auth prompts, and new-feature notices'. This helps the agent know when to invoke it, though it does not explicitly mention when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavior. It identifies the HTTP method (GET) and return content, but omits details like pagination, rate limits, or potential side effects. This is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous words. Every part adds value: the action, endpoint, post types, and key response attributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema and annotations, the description covers the main response fields and post types. However, it lacks guidance on the interplay between startDate/endDate and the display parameter, and does not mention sorting or pagination.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameters are fully described in the schema, so the baseline is 3. The description adds little beyond stating the date range focus; no additional semantics or usage nuances are provided for startDate, endDate, display, or customer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List posts'), the resource ('via GET /api/posts'), and the scope ('in a date range'). It also enumerates the types of posts returned and key response fields, distinguishing it from sibling tools like create_post or delete_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies its use for retrieving posts within a date range. However, it does not explicitly state when to avoid using it or mention alternatives, such as the sibling tool for missing content. The context is clear but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 it is a GET request and returns a catalog, but lacks details on pagination, authentication, or other behavioral traits beyond the basic 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the API endpoint and purpose, with no wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description implies a return catalog with voice ids, which is adequate for a simple list tool. It could explicitly describe the return structure but is sufficient for the agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single optional parameter. The description adds minimal extra meaning beyond the schema definition, only restating the parameter's purpose indirectly. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists available AI voices for video generation via a specific endpoint, distinguishing it from sibling tools like postiz_generate_video by positioning it as a prerequisite.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states this is 'Required input for postiz_generate_video' and instructs the agent to pick a voice id, providing clear context for when to use it, though it does not mention 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the HTTP method and the 'enableWrite' requirement, but lacks detail on side effects, idempotency, or error responses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first states action with endpoint, second gives use case and requirement. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the use case but lacks information about return values or error handling. Given the simple update nature and no output schema, it is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds that releaseURL is optional, but does not explain formats or postId semantics. Baseline compensation is partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it updates the releaseId and optionally releaseURL of a Postiz post, with a specific endpoint given. This distinguishes it from sibling update tools like postiz_update_post_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a specific use case: reconciling a post after a missing-content event. However, it does not explicitly mention when not to use it or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the HTTP method (PATCH), effect of state change (re-enters schedule), and a requirement ('Requires enableWrite'). However, lacks details on idempotency, error cases, or what happens if the post is already in the target state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and method, then key behavioral detail. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given lack of output schema and simple parameters, the description covers the main action and effect. Missing edge cases like preconditions or error handling, but largely complete for a straightforward status transition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should compensate, but it only mentions 'postId' implicitly via '{id}' and 'state' via enum values. No added meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'Transition', the resource 'Postiz post', and the specific states 'DRAFT and QUEUE'. Distinguishes from sibling tools like postiz_create_post or postiz_delete_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for status transitions only, but no explicit guidance on when not to use or alternatives. The note about DRAFT→QUEUE re-entering schedule provides some context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It mentions that the tool requires 'enableWrite' and returns an object with id and path. However, it does not disclose potential side effects, rate limits, file size constraints, or destructive behavior. The description adds some behavioral context but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that express the main action, return value, and integration with another tool. Every sentence adds unique value without redundancy. It is front-loaded with the primary purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (4 parameters, no output schema, no annotations), the description covers the essential purpose, return format, and workflow integration. It lacks details on parameter combinations or error handling, but the ties to postiz_create_post provide useful context. It is fairly complete for a straightforward upload tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (filePath, base64, fileName, mimeType) have descriptions in the schema. The tool description does not add any additional meaning or usage context for the parameters beyond what the schema provides, meeting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Upload a media file (image, video) to Postiz storage'. It specifies the HTTP method and endpoint, and explains the return value and how to use it with postiz_create_post. This effectively distinguishes it from sibling tools like postiz_upload_from_url by focusing on file/Base64 upload versus URL upload.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives like postiz_upload_from_url. It mentions a prerequisite ('Requires enableWrite') but lacks context on when this tool is preferred or when to avoid it. No exclusion criteria or alternative references are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description discloses the HTTP method, endpoint, server-side fetch nature, return format, and a prerequisite, which is transparent for a simple upload tool. Lacks error or rate limit info.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each adding value. Front-loaded with the core action and endpoint. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description fully covers purpose, mechanism, return value, and prerequisite, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes the only parameter (url) as 'Public URL Postiz should fetch.' The description adds minimal context about reachability, but schema coverage is 100%, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it uploads a media file from a public URL, explains the server-side fetch, and specifies the return format and usage in another tool, distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides implicit guidance by noting 'works for sources the MCP host can't reach' and mentions 'Requires enableWrite', but does not explicitly state when not to use or contrast with alternatives like postiz_upload_file.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.