Server Quality Checklist

Tool Scores

• apipost_updateC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions that the tool modifies API documentation, it doesn't describe what happens on success/failure, whether changes are reversible, permission requirements, rate limits, or what the response looks like. The formatting rules provided are helpful but don't constitute comprehensive behavioral transparency for a mutation tool.

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

  Conciseness3/5

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

  The description is relatively concise but front-loads formatting rules rather than the core purpose. While the formatting guidance is important, it dominates the description at the expense of other critical information. The single paragraph structure could be improved with clearer separation between purpose, usage, and formatting requirements.

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

  Completeness2/5

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

  For a mutation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. It focuses heavily on formatting rules but neglects behavioral aspects like error handling, success responses, authentication requirements, and side effects. The description doesn't adequately compensate for the lack of structured metadata about this complex update operation.

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

  Parameters3/5

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

  With 100% schema description coverage, the schema already documents all 11 parameters thoroughly. The description adds some value by providing formatting examples and clarifying that certain parameters can be cleared with empty values, but doesn't significantly enhance understanding beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the verb ('修改' meaning 'modify') and resource ('API接口文档' meaning 'API interface documentation'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this update tool from potential siblings like 'apipost_detail' or 'apipost_smart_create', which might also involve API documentation operations.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It mentions '规则同创建' (rules same as creation), which implies a relationship with creation tools but doesn't specify when to choose update over creation or other siblings. There's no mention of prerequisites, error conditions, or typical use cases.

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

• apipost_create_folderC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It states the tool creates folders, implying a write/mutation operation, but fails to disclose critical behavioral traits: required permissions, whether creation is idempotent, error handling (e.g., duplicate names), rate limits, or what happens on success/failure. The description is basic and leaves the agent guessing about operational risks.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese that directly states the tool's purpose and key capability (parent directory support). It is front-loaded with the main action and wastes no words, making it easy for an AI agent to parse quickly.

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

  Completeness2/5

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

  Given the tool's complexity (a write operation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions or errors, output format, or usage context. For a mutation tool with no structured safety hints, this leaves significant gaps for an AI agent to operate safely and effectively.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear parameter descriptions in the schema itself. The description adds no additional semantic meaning beyond what the schema provides (e.g., no examples, format details, or constraints). With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the action ('创建API文档目录' - create API documentation directory) and resource (folder/directory), with the specific capability to create under a parent directory. It distinguishes from siblings like 'apipost_delete' (deletion) and 'apipost_list' (listing), though not explicitly named. It loses a point for not explicitly contrasting with 'apipost_smart_create' which might have overlapping functionality.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance: it mentions creating folders under a parent directory, but offers no explicit when-to-use advice, no prerequisites (e.g., authentication needs), no exclusions (e.g., when not to use it), and no alternatives (e.g., vs. 'apipost_smart_create'). Usage is implied by the action, but lacks actionable context for an AI agent.

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

• apipost_detailC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool views detailed configuration information, implying a read-only operation, but doesn't clarify if it requires authentication, has rate limits, returns structured data, or handles errors. The description lacks details on behavioral traits beyond the basic action, leaving gaps for an AI agent to understand how to invoke it correctly.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that directly states the tool's purpose and scope. It's front-loaded with the main action and includes specific details (request parameters, response format, authentication settings) without unnecessary elaboration. However, it could be slightly more structured by separating usage context, but it's appropriately sized with zero waste.

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

  Completeness3/5

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

  Given the tool's complexity (a read operation with 1 parameter), no annotations, and no output schema, the description is minimally adequate. It covers what the tool does but lacks behavioral context (e.g., authentication needs, error handling) and output details. It's complete enough for basic understanding but has clear gaps that could hinder an AI agent's ability to use it effectively without additional inference.

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

  Parameters3/5

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

  The input schema has 1 parameter with 100% description coverage ('要查看的接口ID' - the interface ID to view). The description adds no additional meaning beyond the schema, as it doesn't explain parameter usage, format, or examples. With high schema coverage, the baseline is 3, and the description doesn't compensate or add value, so it scores 3.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '查看API接口的详细配置信息' (view detailed configuration information of an API interface). It specifies the resource (API interface) and the action (view detailed configuration), which includes request parameters, response format, and authentication settings. However, it doesn't explicitly differentiate from sibling tools like 'apipost_list' (which might list interfaces without details) or 'apipost_test_connection' (which might test connectivity rather than show configuration).

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an interface ID), exclusions (e.g., not for creating or updating interfaces), or comparisons to siblings like 'apipost_list' (for listing) or 'apipost_update' (for modifying). Usage is implied only by the action 'view,' but no explicit context is given.

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

• apipost_listC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'enhanced directory hierarchy search and parent-child relationship positioning,' which hints at search and filtering capabilities, but fails to describe critical behaviors such as pagination (implied by 'limit' parameter), read-only nature (likely, but not stated), error handling, or response format. For a tool with 10 parameters and no annotations, this leaves significant gaps in understanding how the tool behaves in practice.

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

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('view project API list') and adds key features ('enhanced directory hierarchy search and parent-child relationship positioning'). There's no wasted verbiage, and it directly addresses the tool's functionality. However, it could be slightly more structured by explicitly separating purpose from features, but it remains appropriately concise for the tool's complexity.

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

  Completeness2/5

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

  Given the tool's complexity (10 parameters, no annotations, no output schema), the description is incomplete. It lacks information on behavioral traits (e.g., read-only vs. mutative, rate limits), response format, error conditions, and usage context relative to siblings. While the schema covers parameters well, the description fails to provide the broader context needed for an agent to use the tool effectively, especially without annotations or output schema to fill in gaps.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with each parameter well-documented in the schema itself (e.g., 'search' for keywords, 'parent_id' for directory filtering). The description adds no additional parameter semantics beyond what the schema provides—it doesn't explain interactions between parameters like 'recursive' and 'depth' or clarify default behaviors. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the tool's purpose as '查看项目API列表' (view project API list) with additional capabilities for '强化的目录层级搜索和父子关系定位' (enhanced directory hierarchy search and parent-child relationship positioning). It specifies the verb ('view') and resource ('project API list'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'apipost_detail' or 'apipost_workspace', which might offer overlapping or related functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It mentions enhanced search and hierarchy features but doesn't specify scenarios where this is preferred over other tools like 'apipost_detail' for detailed views or 'apipost_workspace' for workspace-level operations. Without explicit when-to-use or when-not-to-use instructions, the agent lacks clear direction for tool selection.

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

• apipost_workspaceC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It lists actions but doesn't explain what 'view current workspace' returns, how 'list teams/projects' is paginated or formatted, what 'switch workspace' actually changes in the session, or any authentication/permission requirements. For a multi-action tool with potential session state changes, this leaves significant 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 efficiently structured as a single Chinese sentence that lists the four available actions. It's appropriately sized and front-loaded with the tool's purpose. However, it could be slightly more structured by separating the general purpose from the specific actions.

  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 annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns for each action type, how the actions affect session state (particularly 'switch'), or provide any error handling context. The combination of multiple actions with different parameter requirements needs more contextual explanation than provided.

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

  Parameters3/5

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

  Schema description coverage is 100%, with all 7 parameters well-documented in the schema itself. The description doesn't add any parameter semantics beyond what's already in the schema - it doesn't explain parameter relationships (e.g., team_id required for certain actions) or provide usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '工作空间管理：查看当前工作空间、列出团队和项目、切换工作空间' (Workspace management: view current workspace, list teams and projects, switch workspace). It specifies the verb+resource combination and lists the four specific actions available. However, it doesn't explicitly differentiate this multi-action workspace management tool from its siblings like 'apipost_list' or 'apipost_detail', which might have overlapping functionality.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context for choosing between the four actions, or how this workspace management tool relates to sibling tools like 'apipost_list' or 'apipost_detail'. The user must infer usage from the action list alone.

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

• apipost_smart_createB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's input formatting rules and constraints (e.g., 'example 填真实值' - fill example with real values), which adds useful context beyond the schema. However, it doesn't disclose critical behavioral traits such as whether this creates new documentation (implied by '生成器' - generator), what permissions are required, whether it's idempotent, what happens on errors, or what the output looks like (no output schema). For a creation tool with 11 parameters, this leaves significant gaps.

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

  Conciseness3/5

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

  The description is appropriately sized but not optimally structured. It front-loads the purpose ('API接口文档生成器') but then dives into detailed formatting rules without clear separation. The example at the end is helpful but makes the text somewhat dense. While every sentence contributes information, the flow could be improved for better readability, such as by grouping rules separately from examples.

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

  Completeness2/5

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

  Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It covers formatting rules and provides an example, but lacks crucial context: what the tool actually produces (API documentation object?), how to handle errors, authentication requirements, or rate limits. For a tool that likely creates resources in a system, this omission is significant, especially without annotations to fill these gaps.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions and examples. The description adds some semantic context by explaining the overall field-list-driven approach and providing formatting examples (e.g., nested用 .，数组用 [] - nested use ., arrays use []). However, it doesn't add significant meaning beyond what's already in the parameter descriptions, maintaining the baseline score for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the tool's purpose as an 'API接口文档生成器（字段列表驱动）' (API documentation generator driven by field lists), which is a specific verb+resource combination. It distinguishes from siblings like apipost_create_folder (creates folders) or apipost_test_connection (tests connections) by focusing on API documentation generation. However, it doesn't explicitly contrast with apipost_update (which might update documentation) or apipost_detail (which might retrieve documentation details).

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

  Usage Guidelines3/5

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

  The description provides implied usage guidelines through rules like 'responses 只传 fields，不传 data' (responses only pass fields, not data) and formatting conventions for headers/query/body/cookies. It suggests when to use this specific format-driven approach. However, it lacks explicit guidance on when to choose this tool over alternatives like apipost_update for modifications or apipost_detail for retrieval, and doesn't mention prerequisites or exclusions.

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

• apipost_test_connectionB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states the tool tests connection status and verifies service availability, it doesn't describe what happens during execution (e.g., whether it makes network calls, what authentication is required, what happens on failure, or what the response looks like). For a tool with zero annotation coverage, this is a significant gap in behavioral context.

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

  Conciseness5/5

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

  The description is extremely concise - a single sentence in Chinese that efficiently communicates the core purpose. It's front-loaded with the essential information (testing connection status and configuration, verifying availability) with zero wasted words. Every part of the sentence earns its place.

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

  Completeness3/5

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

  Given this is a simple connection testing tool with 1 dummy parameter and no output schema, the description is minimally complete. It tells what the tool does but lacks details about what '验证服务可用性' (verify service availability) actually means in practice - what constitutes success/failure, what information is returned, or how it differs from other status-checking tools. The absence of annotations and output schema means more behavioral context would be helpful.

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

  Parameters4/5

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

  The input schema has 100% description coverage, with the single parameter 'random_string' documented as 'Dummy parameter for no-parameter tools'. The description doesn't add any parameter information beyond what the schema provides, but since this is essentially a no-parameter tool (the parameter is a dummy), the baseline for 0 meaningful parameters would be 4. The description appropriately doesn't waste space on parameter details.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '测试ApiPost MCP连接状态和配置信息，验证服务可用性' (Test ApiPost MCP connection status and configuration information, verify service availability). It specifies the verb ('测试' - test/verify) and resource ('连接状态和配置信息' - connection status and configuration information). However, it doesn't explicitly differentiate from sibling tools like 'apipost_list' or 'apipost_detail' which might also provide status information.

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

  Usage Guidelines2/5

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

  The description provides minimal usage guidance. It implies this tool should be used to verify service availability, but doesn't specify when to use it versus alternatives like 'apipost_list' (which might list resources) or 'apipost_detail' (which might provide detailed information). No explicit when/when-not guidance or prerequisites are mentioned.

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

• apipost_deleteA
  3.7/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 burden. It discloses that the tool performs deletion ('删除'), which implies a destructive mutation, and mentions it supports batch operations ('批量删除', '支持单个或多个接口删除'). However, it lacks details on permissions required, whether deletions are reversible, error handling, or rate limits. For a destructive tool with zero annotation coverage, this is a moderate gap, but the description at least clarifies the batch nature.

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

  Conciseness5/5

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

  The description is highly concise and front-loaded: the first sentence states the core action and scope ('批量删除API接口文档，支持单个或多个接口删除'), and the second sentence provides essential usage guidance. Every sentence earns its place with no wasted words, making it efficient and easy to parse.

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

  Completeness3/5

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

  Given the tool's complexity (destructive mutation with batch support), no annotations, no output schema, and 100% schema coverage, the description is moderately complete. It covers the purpose, usage prerequisites, and parameter basics, but lacks behavioral details like side effects, permissions, or return values. For a deletion tool, this leaves gaps in understanding the full impact, though the core functionality is clear.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'api_ids' fully documented in the schema as an array of strings for API interface IDs. The description adds minimal value beyond the schema: it reiterates that IDs can be obtained from apipost_list and supports single or multiple IDs, which is already covered in the schema description. Since schema coverage is high, the baseline is 3, and the description doesn't significantly enhance parameter understanding.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '批量删除API接口文档' (batch delete API interface documents) with the specific action '删除' (delete) on the resource 'API接口文档' (API interface documents). It distinguishes from siblings like apipost_list (view) and apipost_update (modify), though it doesn't explicitly name alternatives. The purpose is specific but could be slightly more differentiated from other destructive operations.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: '删除前先用apipost_list查看接口列表获取ID' (before deleting, first use apipost_list to view the interface list and get IDs). This gives a prerequisite step and implicitly distinguishes from apipost_list (for viewing) and apipost_detail (for details). However, it doesn't explicitly state when NOT to use it or name all alternatives (e.g., vs. apipost_update for modifications).

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