Server Quality Checklist

Tool Scores

• postifys_cq_list_itemsB
  3/5.0
  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 adds useful context: this is the native (non-n8n) queue and requires a feature flag plus entitlement. However, it does not disclose error behavior when the feature is disabled, pagination or limit handling, or any response characteristics; read-only nature is only implied by 'List'.

  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?

  Three short sentences with no wasted words, each earning its place. However, the core purpose is placed last, after context and prerequisites, so the description is not front-loaded with the most important 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?

  The definition falls short for a tool with 3 parameters, no annotations, and no output schema. It covers prerequisites and the basic action, but leaves two of three parameters semantically opaque and does not distinguish the tool from the cluster of CQ listing and job tools, so an agent would struggle to invoke it correctly with confidence.

  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, but it barely does. 'Data table' loosely hints at tableId, while limit and status are left entirely unexplained — no valid values, no filtering semantics, no guidance on defaults or relationships.

  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 provides a clear verb and resource, 'List rows in a data table', and anchors it in the Content Queue context. It is not a tautology and the name maps well to the action. However, the purpose is somewhat diluted by the opening context phrase, and it does not clearly differentiate from sibling tools like postifys_cq_list_tables or postifys_cq_list_jobs.

  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 explicitly states prerequisites, 'Requires CONTENT_QUEUE_ENABLED on the server and publish entitlement', which implies when the tool is callable. But it gives no guidance on when to choose this tool over the many CQ siblings, nor any exclusions or alternative routing.

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

• postifys_cq_add_itemB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It usefully notes that path may be a Drive share URL resolved at publish time and mentions required entitlements, but it does not explain what happens on failure, whether the action is immediate, 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.

  Conciseness4/5

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

  The description is concise at roughly three sentences and avoids fluff. The key purpose appears after prerequisite context rather than being front-loaded, but every sentence contributes useful 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?

  For a 7-parameter tool with no output schema and no annotations, this description is incomplete. It covers prerequisites and path behavior, but omits explanation of most parameters, return values, and operational context such as how tableId relates to the content queue.

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

  Parameters2/5

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

  Schema description coverage is only 14%, so the description must add meaning for the many undocumented parameters. It adds value for path ('may be a Drive share URL') and implies status is pending, but it does not explain tableId, title, hashtags, postType, or description, leaving major semantic gaps.

  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, 'Add a pending row' to the Postifys Content Queue, which clearly conveys the core purpose. It distinguishes the native queue from n8n with 'scheduler without n8n', but it does not explicitly differentiate from the sibling tool postifys_cq_import_rows, which also adds rows.

  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 gives clear prerequisites ('Requires CONTENT_QUEUE_ENABLED on the server and publish entitlement') which imply when the tool is usable. It does not, however, provide explicit guidance on when to prefer this over alternatives like postifys_cq_import_rows or postifys_publish.

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

• postifys_pingB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It states that the tool tests the API key against the server, which implies a safe, read-only connectivity check. Yet it does not disclose what the response looks like, whether the call is idempotent, or any potential side effects, and most behavioral content in the description refers to publishing rather than to ping.

  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?

  Only the first sentence is directly relevant to the tool. The remaining sentences are a long block of unrelated publishing platform caveats, media URL guidance, and pricing information. This is over-specified for a ping tool and wastes the agent's attention.

  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 parameterless ping tool, the first sentence gives a usable baseline. But with no output schema and no annotations, the description doesn't explain what the agent should expect as a result, and the bulk of the description is context about other tools rather than this one. It is minimally complete but padded with irrelevant details.

  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 explain. The baseline for no-parameter tools is 4, and the description does not need to compensate for missing schema information.

  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 first sentence clearly states the tool's purpose: 'Test the Postifys API key against the configured server.' This is a specific verb and resource that distinguishes it from sibling tools like publish or media_upload. However, the rest of the description is filled with publishing caveats unrelated to ping, which somewhat muddies the focus.

  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 about when to use this tool instead of siblings such as postifys_get_post_status or postifys_media_upload. The description includes extensive publishing workflow guidance, but it does not say when the agent should call ping or what situations make it the right choice.

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

• postifys_get_post_statusB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It does reveal that this is a polling operation with terminal states, which is meaningful. But it does not mention whether repeated calls are expected, what happens on timeout/error, or whether there are side effects, leaving notable behavioral gaps.

  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 filler, efficiently conveying the polling action and terminal condition. It could have added a brief clause about the platform parameter without much bloat, but it remains appropriately concise.

  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 polling tool this is minimally viable: it names the core identifier, the action, and the terminal states, and the schema supplies the platform enum. However, with no output schema and no annotations, it does not explain the response payload, polling behavior details, or failure semantics, 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.

  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 clarify the parameters. It explicitly explains that postId identifies the publish job, but it completely omits the optional platform parameter, including how platform affects the lookup. The enum values in the schema provide constraints, not semantic meaning.

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

  Purpose4/5

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

  The description identifies a clear verb ('Poll'), resource ('async publish status'), and key identifier ('postId'), and names the terminal states ('published/failed/partial'). It is specific enough that an agent can distinguish it from publishing tools, though it does not explicitly contrast it with the similar-sounding postifys_media_status.

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

  Usage Guidelines3/5

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

  The phrase 'Poll async publish status' implies this should be used after an asynchronous publish to check progress until a terminal state, which is useful contextual guidance. However, it does not explicitly state when not to use it or when a sibling tool like postifys_media_status 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.

• postifys_media_statusB
  3.3/5.0
  Behavior3/5

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

  The verb 'Poll' indicates a read-style status-checking behavior, which is useful because no annotations are provided. However, the description does not disclose what the response represents, whether the call blocks or can be repeated, or any errors/lifecycle caveats.

  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 tight sentence with no filler; the operation, resource, and parameter are stated up front. Nothing could be cut without losing 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 simple one-parameter poll tool, the description is minimally viable, but it lacks return-value, workflow, and sibling-relationship context that would help an agent decide when to call it and what to do with the result. No output schema exists to fill that 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 description explicitly relates mediaJobId to the job being polled, adding a minimal semantic role beyond the bare schema property. It does not explain how the ID is obtained or what format is expected, but the single self-descriptive parameter limits the 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?

  Identifies a specific operation (poll) and resource (a Postifys media job), and names the required identifier. It is clear, but it does not explicitly contrast with sibling tools like postifys_get_post_status, relying on the 'media' vs 'post' distinction in the resource 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?

  No guidance on when to use this tool versus alternatives such as postifys_media_upload or postifys_get_post_status. No prerequisites, such as a mediaJobId from a previous upload, or conditions under which polling should stop, are mentioned.

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

• postifys_cq_create_tableB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral transparency burden. It discloses two important preconditions: CONTENT_QUEUE_ENABLED and publish entitlement. However, it does not describe side effects such as persistence, what happens if the table name already exists, 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 brief and mostly efficient, with two sentences carrying domain context, prerequisites, and the core action. The parenthetical 'scheduler without n8n' adds context but is not strictly necessary, and the main action appears only at the end rather than being 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?

  The tool is simple with only one parameter and no output schema, and the description provides fundamental context and prerequisites. However, it lacks information about expected return values, error behavior on duplicate names, and whether the created table is immediately usable. This 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.

  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 undocumented 'name' parameter. It does not explicitly state that 'name' is the new table's name or explain naming conventions. The phrase 'data table for queue rows' only implicitly suggests the purpose of the parameter, which is insufficient given the complete lack of schema-level description.

  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 creates a data table for queue rows, which is a specific verb+resource combination. It is distinguishable from sibling tools like postifys_cq_list_tables and postifys_cq_add_item, though it does not explicitly name an alternative or contrast itself with 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 provides clear contextual usage guidance by stating that CONTENT_QUEUE_ENABLED must be set and publish entitlement is required, effectively telling the agent when not to use the tool. It does not explicitly discuss when to prefer this over a sibling, but the prerequisites and domain context are useful.

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

• postifys_cq_overviewB
  3.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns aggregated tables/jobs/hints, requires an environment flag and entitlement, and includes platform caveats (TikTok, LinkedIn, Pinterest). It does not explicitly state 'read-only/no side effects,' but the overview nature plus 'Returns' makes this adequately transparent.

  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 definition is front-loaded but bloated: pricing details, upload workflow, and raw URL warnings are unrelated to an overview call and should live on publish/media tools. Roughly half the sentences earn their place; the rest dilute the description.

  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, no-output-schema overview tool, the description is sufficiently complete: it names the returned information, prerequisites, and relevant platform constraints. A short 'does not modify data' statement would make it fully complete, but the behavior is inferable from 'Returns.'

  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 has 100% schema coverage by virtue of an empty schema, so the baseline of 4 applies. There are no parameters for the description to clarify.

  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 identifies a specific resource ('Native Postifys Content Queue') and a high-level result ('Returns tables, jobs, and next-run hints'), and contrasts it with 'scheduler without n8n.' It is clear, but it does not explicitly differentiate this aggregate overview from sibling list tools such as cq_list_tables or cq_list_jobs.

  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 prerequisites ('Requires CONTENT_QUEUE_ENABLED on the server and publish entitlement') but never states when to choose this tool over the sibling CQ listing tools, nor does it name any alternatives. The publishing workflow guidance belongs to other tools and does not help select cq_overview.

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

• postifys_cq_import_rowsA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose server configuration and entitlement prerequisites and clarifies the JSON body format. However, it does not state whether the import overwrites existing rows, whether duplicates are allowed, what response to expect, or how imported row status is determined beyond 'pending'.

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

  Conciseness5/5

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

  Two sentences contain all essential information, with the key operational constraints (native queue, requirements, bulk JSON import) front-loaded. No filler or repetition of the schema.

  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 bulk import tool with no output schema or annotations, it covers prerequisites, payload format, and the destination concept. It could be more complete by describing typical success/error outcomes or post-import verification, but the existing description is sufficient for an agent to decide 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 0%, so the description must compensate. It explains that rows are supplied as JSON rather than multipart CSV and refers to pending rows, which adds meaning to the rows parameter. It does not explain tableId or the optional fields (status, hashtags, postType, description), leaving much to 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 names a specific operation — bulk-importing rows into a Postifys Content Queue table — and distinguishes it from alternatives by clarifying it is the native scheduler (not n8n) and expects JSON rather than multipart CSV. This makes the tool's purpose unambiguous even among many sibling cq_* tools.

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

  Usage Guidelines4/5

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

  It provides clear context: use when interacting with Postifys' native Content Queue and when importing many rows as JSON. It states requirements (CONTENT_QUEUE_ENABLED and publish entitlement) and excludes CSV input, but it does not explicitly name sibling alternatives such as postifys_cq_add_item for single-row inserts.

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

• postifys_cq_run_job_nowA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It does disclose the environment requirement and publish entitlement, and it scopes the action to the next eligible pending row. However, it does not describe side effects, idempotency, whether the run blocks, or what happens if no eligible row exists.

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

  Conciseness5/5

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

  Two sentences contain all essential information with no filler. The most important qualifiers (native scheduler, requirements, immediate trigger) are front-loaded, making the tool easy to scan and understand.

  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 trigger tool with no output schema, the description covers the main operational requirements and the action's scope. It could add error or response expectations, but the prerequisites and immediate behavior are sufficient for an agent to make a reasonable invocation decision.

  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 0%, so the description must compensate. It ties jobId to the job whose next pending row is triggered, but it does not explain where to obtain jobId, whether it comes from postifys_cq_list_jobs, or any additional constraints beyond the schema's minLength.

  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 ('Trigger') and a precise resource ('the next eligible pending row for a job'), making the tool's action unmistakable. It also distinguishes this from sibling CQ tools by framing it as the immediate execution action rather than listing, creating, or importing jobs.

  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 sets prerequisites: CONTENT_QUEUE_ENABLED must be enabled and the caller needs publish entitlement. It does not explicitly list alternatives or when-not-to-use, but the context of 'run now' versus the rest of the CQ toolset makes the usage scenario clear enough.

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

• postifys_list_pinterest_boardsA
  4/5.0
  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 disclosure burden. The word 'list' indicates a read-only operation, and 'connected Pinterest account' signals a prerequisite. However, it does not describe output behavior, pagination, rate limits, or whether the result includes board metadata such as names and IDs beyond the implied mention of boardId.

  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 with no wasted words. The primary action is front-loaded, and the second sentence adds relevant context about why boardId matters. It 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.

  Completeness4/5

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

  For a one-parameter, read-only listing tool, the description is nearly complete. It explains what the tool does, identifies the required account context, and hints that boardId is the key value returned. It does not explicitly describe the return shape, but given the simplicity and the implied boardId output, this is a minor gap rather than a serious 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%, with pinterestUserId described as 'Pinterest account id from postifys_list_connections.' This is sufficient, so the description does not need to add much. The description's boardId remark is about a downstream requirement, not the input parameter, so it adds little to 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 states a specific verb and resource: 'List Pinterest boards for a connected Pinterest account.' It clearly distinguishes itself from sibling tools like postifys_list_connections, which lists accounts rather than boards. The additional note about boardId being required for publishing reinforces why this tool exists.

  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 useful context: the boards belong to a connected Pinterest account, and boardId is needed when publishing image Pins. This implies when an agent needs board IDs for publishing, it should call this tool first. It does not explicitly name alternative tools or exclusion conditions, but no sibling tool directly competes with this listing function.

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

• postifys_tiktok_creator_infoA
  4/5.0
  Behavior3/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 'Fetch' strongly implies a read-only operation, and the parenthetical gives a sense of the response content. However, it doesn't mention potential errors, authentication requirements, or what happens if the account is invalid, leaving some typical gaps.

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

  Conciseness5/5

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

  Two short sentences deliver the core purpose and the critical usage timing. The first sentence is front-loaded with the action and resource, and the second sentence provides actionable guidance 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 single-parameter tool with no output schema, the description is suitably complete: it states what data is fetched, points to the source of the input parameter, and specifies when to call it. The only minor omission is the exact response format, but the described content types partially fill that 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?

  Schema description coverage is 100%, and the only parameter tiktokAccountId is fully documented as coming from postifys_list_connections. The description adds no new parameter-level meaning, 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 identifies the verb 'Fetch' and the resource 'TikTok creator publish options', and specifies the content as 'privacy levels, interactions'. This goes well beyond the tool name and distinguishes it from siblings like postifys_publish and postifys_list_connections.

  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 instruction 'Call before Direct Post' provides an explicit temporal usage context and implies a prerequisite relationship with the publish tool. It tells the agent when to invoke this tool, though it doesn't explicitly name 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.

• postifys_cq_create_or_update_jobA
  4.2/5.0
  Behavior4/5

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

  Because there are no annotations, the description carries the full burden of behavioral disclosure. It discloses a server-side feature flag, a publish entitlement requirement, the create/update mutation behavior, and a critical caveat to keep schedule.enabled false until destinations are ready. It does not describe response shape or overwrite semantics, but the practical guidance is valuable.

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

  Conciseness5/5

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

  The description is four short sentences with no filler. Purpose and prerequisites are front-loaded, and each sentence adds meaningful guidance. It is easy to scan and leaves no obvious waste.

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

  Completeness4/5

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

  For a 7-parameter create/update tool with no annotations and no output schema, this description covers the most important operational constraints and branches. The warning about schedule.enabled is exactly the type of insight that prevents real errors. It could be slightly more complete on required fields (e.g., dataTableId on create) and return behavior, but the schema and sibling context fill some of that 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?

  Schema description coverage is only 29%, so the description must compensate. It does clarify jobId semantics (create vs update) and reinforces the interval minimum and the schedule.enabled caveat. However, it leaves most nested parameters (defaults, timezone, destinations, schedule subfields) unexplained beyond the raw schema, so compensation is partial.

  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 explicitly names the resource ('Postifys Content Queue') and the dual operation ('Create a job (omit jobId) or update (pass jobId)'), making it unmistakable what this tool does and how it differs from sibling tools like list_jobs or run_job_now. The parenthetical ('scheduler without n8n') adds helpful context for orientation.

  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 gives direct conditional usage: omit jobId to create, pass jobId to update. It also states prerequisites (CONTENT_QUEUE_ENABLED, publish entitlement) and a strong scheduling constraint (interval ≥ 15 minutes). It does not explicitly name alternatives, but the create/update distinction is enough to route an agent correctly.

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

• postifys_cq_list_jobsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It adds useful context about native Postifys Content Queue, the required feature flag, publish entitlement, and the one-job-per-table constraint. However, it does not mention return format, pagination, or whether the operation is read-only, though listing implies it.

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

  Conciseness5/5

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

  The description is compact, front-loaded, and every sentence earns its place. It conveys functionality, prerequisites, and a key behavioral constraint in two short sentences with no 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 zero-parameter list tool with no output schema, the description covers the essential invocation context: what the tool lists, the prerequisite flag and entitlement, and the one-job-per-table model. It could be slightly more complete by noting whether the list is ordered or paginated, but the low complexity makes this 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 and schema description coverage is 100%, so the schema already conveys the complete absence of parameters. The description does not need to explain parameters, and mentioning the 'one job per table' behavior adds useful semantic context beyond 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 clearly states the tool's purpose: 'List publishing jobs (one job per table).' It uses a specific verb and resource and naturally distinguishes itself from sibling tools like cq_list_tables and cq_list_items by targeting 'jobs' at the table level.

  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 actionable prerequisites: 'Requires CONTENT_QUEUE_ENABLED on the server and publish entitlement.' It gives clear context that this is the native Content Queue feature without n8n, but it does not explicitly name alternatives or state when to choose this over cq_list_tables or cq_overview.

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

• postifys_cq_list_tablesA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses important prerequisites (server flag and entitlement) and implicitly signals a read-only listing operation. It could be more explicit about output format or error behavior, but for a zero-parameter 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.

  Conciseness4/5

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

  The description is concise and uses three short sentences without fluff. The main verb phrase 'List data tables' is placed last and could be front-loaded, but the overall structure is efficient and easy to scan.

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

  Completeness4/5

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

  For a simple zero-parameter list operation, the description provides the key context: what the tool belongs to, what prerequisites exist, and what action it performs. It does not describe return values, but given no output schema and the simplicity of the operation, the coverage is adequate.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema already covers everything. The baseline of 4 applies because there are no parameters and no parameter documentation gap to compensate for.

  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 names the resource (Postifys Content Queue) and the action ('List data tables'). It distinguishes this tool from sibling tools like list_jobs and list_items by focusing specifically on tables.

  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: this is for the native Postifys scheduler, not n8n, and requires CONTENT_QUEUE_ENABLED plus publish entitlement. It does not explicitly call out alternative tools or when-not-to-use conditions, 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.

• postifys_publishA
  4.3/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral disclosure. It covers async behavior, guaranteed postId return, TikTok Direct Post requirements (privacy, consent, music confirmation), LinkedIn member-profile limitation, Pinterest image-Pin-only restriction with required boardId, and account entitlement/pricing. This is thorough for a publish 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 long but dense, with no fluff. It front-loads the core behavior and return contract, then layers platform caveats, workflow, and pricing. It could be better structured with bullet points, but every sentence contributes useful 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?

  Given the tool's complexity (31 params, no output schema, no annotations), the description covers the most critical context: return polling contract, platform-specific constraints, account entitlement, and media workflow. It does not explain all parameter combinations or error scenarios, but an agent gets enough to invoke the tool correctly for most platforms.

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

  Parameters3/5

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

  Schema description coverage is only 29%, so the description must compensate. It does add meaning for key parameters: boardId is required for Pinterest, privacy/consent/musicUsageConfirmed for TikTok Direct Post, and mediaUrls should use serve_url values. However, with 31 parameters, many remain unexplained (e.g., isAigc, brandContentToggle, categoryId, collaborators), leaving a significant gap.

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

  Purpose5/5

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

  The description opens with 'Publish asynchronously to one platform', which is a clear verb+resource statement. It also distinguishes itself from the postifys_get_post_status sibling by stating it returns a postId to poll, and from postifys_media_upload by describing the publish workflow.

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

  Usage Guidelines4/5

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

  It provides explicit workflow guidance ('Prefer Media upload → serve_url → Publish') and warns against passing raw Drive/Dropbox URLs. It also names postifys_get_post_status for polling, but it doesn't explicitly state when not to use this tool in favor of specific alternatives.

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

• postifys_list_connectionsA
  4.5/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does this extensively: TikTok creator-inbox vs Direct Post requirements, LinkedIn member-profile-only limitation, Pinterest image-Pin-only plus required boardId, Video Pins not claimed, and entitlement/pricing constraints. This is far more than a generic 'list' statement.

  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 purpose is front-loaded in the first sentence, followed by ID usage, platform caveats, and workflow guidance. The paragraph is dense and fairly long for a single-parameter list tool, but every sentence conveys a distinct constraint or workflow tip. The pricing detail could arguably live elsewhere, which keeps it from a 5.

  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?

  There is no output schema, so the description partially compensates by mentioning returned ID fields like pageId, instagramAccountId, and channelId. It also covers platform-specific limitations and the recommended media upload flow. It does not describe the exact response shape, pagination, or the sibling postifys_list_pinterest_boards tool for retrieving required boardId values, but overall it is sufficient for correct 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 schema already documents the only parameter (platform) with an enum and a one-line description. The tool description adds per-platform behavioral semantics—TikTok Direct Post nuances, LinkedIn member profiles, Pinterest boardId requirements—giving each enum value practical meaning the schema alone lacks. Since schema coverage is already 100%, this is above the baseline but not exceptional.

  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?

  Opens with a specific verb and resource: 'List connected social accounts for publishing.' It immediately tells the agent what the tool returns and how to use the results (returned id fields as account targets), which also distinguishes it from the more specific sibling postifys_list_pinterest_boards.

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

  Usage Guidelines4/5

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

  Provides clear context on when to use: call before publishing to obtain target IDs, and filter the results with the optional platform parameter. It includes workflow advice like 'Prefer Media upload → serve_url → Publish' and warns against passing raw Drive/Dropbox URLs. However, it does not explicitly name alternative sibling tools or say when not to use this tool.

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

• postifys_media_uploadA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, and it delivers. It reveals async queue-and-poll behavior, the public serve_url outcome, platform-specific posting limitations, consent/music requirements, and entitlement/pricing constraints. It also explicitly notes limitations like 'Video Pins are not claimed.'

  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 main action and recommended flow are front-loaded, and every caveat carries actionable information. The description is dense rather than wasteful, though some pricing and platform details could arguably live in sibling tool descriptions without losing essential guidance.

  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 4 parameters, no output schema, and multiple platform-specific behaviors, the description covers the core workflow, preconditions, and limitations well. It identifies the key result (serve_url) but does not specify the exact response shape or failure/timeout behavior, which 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%, so the schema already documents all four parameters, including 'Drive share links OK' for url. The tool description adds workflow and platform context, but it does not add significant per-parameter meaning beyond what the schema already provides, making baseline 3 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?

  Description opens with a specific verb and resource: queue a source URL for download/proxy on Postifys and poll until a public serve_url is ready. It also situates the tool within the larger workflow ('Use this before publish') and clearly differentiates it from publish tools. No ambiguity about what this 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 Guidelines5/5

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

  The description gives explicit when-to-use guidance: before publish for Google Drive, Dropbox, or any non-CDN URL, and names the preferred flow 'Media upload → serve_url → Publish.' It also documents platform-specific conditions (TikTok Direct Post, LinkedIn member profiles only, Pinterest boardId required) and warns against passing raw URLs directly to publish tools.

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