Server Quality Checklist

Tool Scores

• read_prompt_fileC
  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 it is a read operation (implying no side effects) but does not mention any potential failure modes, return format, or constraints (e.g., file must exist, be on-disk as opposed to custom prompt). The description merely restates the tool name in a fuller sentence without adding behavioral depth.

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

  Conciseness4/5

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

  The description is extremely concise and front-loaded, with no filler words. It is appropriately sized for a simple read operation with one well-documented parameter. It could be slightly more expansive to cover usage, but for efficiency it earns a high score.

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

  Completeness2/5

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

  Given the tool's simplicity (1 param, no annotations) but having an output schema, the description does not explain what is returned or how errors are handled. It also does not clarify the relationship to list_prompt_files or custom prompts, which is a gap given the sibling context. The description is too brief to be fully useful on its own.

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

  Parameters3/5

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

  The schema already provides a clear description for the 'name' parameter ('Filename from `list_prompt_files`'), and coverage is 100%. The tool description adds a minimal amount ('on-disk' hints at the source) but does not enrich the meaning beyond what the schema offers. Baseline of 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description states a specific verb ('read') and resource ('one on-disk prompt file'), which clearly identifies the tool's action. It differentiates from siblings like list_prompt_files (which lists) and write_prompt_file (which writes) by the verb and 'on-disk' qualifier. However, it doesn't explicitly mention that it returns the file content, which is implied but not stated.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives. The description does not mention that it is for reading contents of files listed by list_prompt_files, nor does it contrast with custom prompt operations like get_custom_prompt. An agent would have to infer the usage context from the name and schema alone.

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

• search_conversationsC
  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 must carry the full behavioral burden, but it only states the basic action. It does not disclose pagination behavior, handling of no results, case sensitivity, or what fields are returned. Although an output schema exists, the description does not hint at any special behavior or side effects, leaving key behavioral aspects unspecified.

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

  Conciseness4/5

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

  A single sentence that is direct and efficient, with no redundant phrasing. The primary action and target are front-loaded. It is appropriately concise without being under-specified, though it could add one or two critical details without losing conciseness.

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

  Completeness3/5

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

  For a simple search tool with only two parameters and an output schema, this description is minimally adequate but leaves gaps. It does not mention the optional limit default or the fact that results are filtered, and it omits any note about ordering or result limits beyond the schema. Given no annotations, a more complete description would include at least a mention of the return structure or pagination.

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

  Parameters3/5

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

  Schema coverage is 100% for both parameters, so the baseline is 3. The description adds context that the query searches both title and message content, which goes beyond the generic 'Text to look for' in the schema, but it does not elaborate on limit's meaning beyond the schema's own description. It adds modest value but is not essential.

  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?

  States a clear verb 'search' with a specific resource 'conversations' and identifies the scope ('by title and message content'). This distinguishes it from list_conversations, which implies listing all, but it does not explicitly name alternatives. The purpose is clear and unambiguous.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives like list_conversations or get_conversation. There is no mention of typical use cases, filters, or when to prefer this over listing all conversations. The description is purely declarative with no usage context.

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

• list_custom_promptsB
  3.1/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 only states 'List' which implies a read operation, but it does not mention that the operation is non-mutating, nor does it disclose any side effects, ordering, pagination, or limits. For a simple list tool this may be acceptable, but it lacks explicit behavioral context such as 'does not modify any prompts' or 'returns only user-owned prompts'.

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

  Conciseness4/5

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

  The description is a single sentence with no filler. It is front-loaded with the core action and resource. It is appropriately sized for a simple list operation. It does not over-explain, but there is a slight lack of behavioral detail that could make it more informative without becoming verbose.

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

  Completeness4/5

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

  The tool has an output schema that defines return values, and the input schema fully documents the only parameter. The description clarifies the scope ('this user's') which is important. For a lightweight list operation, everything an agent needs to call it correctly is present. Missing details like ordering are minor and likely covered by the output schema.

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

  Parameters3/5

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

  Schema description coverage is 100% because the only parameter (include_content) has a clear description in the schema. The tool description itself does not elaborate on the parameter, but the schema covers its meaning and default behavior. Since the description adds no extra meaning beyond the schema, the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description 'List this user's custom prompt library.' is specific: it names the verb (list), the resource (custom prompt library), and the scope ('this user's'). It clearly distinguishes the operation from get_custom_prompt (which retrieves a single prompt) and from the file-based list_prompt_files by specifying 'custom prompt library' as a distinct concept. However, it does not explicitly mention sibling alternatives, so it stops short of a full 5.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives like get_custom_prompt or list_prompt_files. The description does not mention exclusions, prerequisites, or typical use cases. An agent must infer from the name and the sibling list, which is not explicitly supported by the description.

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

• create_custom_promptB
  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 must fully disclose behavioral traits. It states 'Add a prompt' which implies a mutating operation, but does not mention potential side effects like overwriting existing prompts, uniqueness constraints, or authentication requirements. The description is too minimal to give the agent confidence about the operation's full implications.

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

  Conciseness5/5

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

  The description is a single, concise sentence with no redundant words. It is appropriately front-loaded with the essential action ('Add a prompt') and scope ('to this user's library'). Every element earns its place, and there is no fluff.

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

  Completeness4/5

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

  For a simple create operation with only two parameters, both fully documented in the schema, and an output schema present (which removes the need to describe return values), the description is mostly complete. The only missing aspect is behavioral context (e.g., what happens on duplicate titles), but given the simplicity and the schema coverage, this is a minor 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 coverage is 100%, with both parameters (title and content) having clear descriptions. The tool description adds no additional semantic information about the parameters themselves; it only provides context about the destination ('this user's library'). Since the schema already documents both parameters meaningfully, the description does not need to compensate for gaps, so a baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description 'Add a prompt to this user's library' clearly states the verb (add), the resource (a prompt), and the scope (this user's library). It distinguishes itself from sibling tools like list_custom_prompts, update_custom_prompt, and delete_custom_prompt through the action, though it doesn't explicitly name alternatives. It is specific and unambiguous, but could be slightly more explicit about being a create operation (e.g., 'create' instead of 'add').

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as write_prompt_file or update_custom_prompt. It does not mention any context, prerequisites, or conditions that would indicate this is the appropriate choice. The agent is left to infer usage based on the name and schema alone.

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

• create_workspaceB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description must cover behavioral traits. It does disclose that unknown keys are rejected by the API, giving a clear constraint. However, it omits other key behaviors such as whether creation is idempotent, whether name uniqueness is enforced, or any permission requirements. It covers some ground but not enough for a fully transparent description.

  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 compact, with the one-sentence purpose at the front. The second sentence is dense but necessary, explaining the strictness constraint in one clause. It avoids redundant phrasing and is 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 create operation with a full input schema and an output schema, the description provides enough context to call it correctly. It could mention that this is the counterpart to update_workspace for modifications, but that is a minor omission. The warning about strict API rejection is a useful contextual clue.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is well-documented. The description adds a valuable note that selection fields are exactly what ATLAS restores when the workspace is applied, reinforcing the meaning of these parameters beyond simple names. This is a modest addition, so a baseline 3 is appropriate.

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

  Purpose4/5

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

  The opening 'Create a workspace.' clearly states a specific verb and resource, distinguishing it from delete_workspace and update_workspace by action. It doesn't explicitly name siblings, but the purpose is unambiguous. The added sentence about selection fields further clarifies what the tool does without confusion.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like update_workspace. The description implies creation but does not state 'use this to create a new workspace; use update_workspace to modify an existing one.' The only contextual hint is to use the provided arguments instead of a free-form blob, which is a usage fact, not a when-to-use directive.

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

• get_custom_promptA
  3.5/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 operation is a read, which implies non-destructive behavior, but it does not elaborate on any security requirements, rate limits, error behavior (e.g., what if the prompt doesn't exist), or the exact content returned (though the output schema covers the return structure). The minimal 'Read' leaves too much to inference for a tool with zero annotation support.

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

  Conciseness5/5

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

  A single, front-loaded sentence with zero wasted words. It immediately communicates the verb, resource, and qualifier. Perfectly concise for a simple get-by-id tool.

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

  Completeness3/5

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

  Given the tool's simplicity (one parameter, a defined output schema, and a clear action), the description is minimally sufficient. However, it does not explicitly mention any potential failure modes, auth requirements, or the relationship to list_custom_prompts beyond what the schema provides. For a read operation without annotations, a bit more context (e.g., 'returns the full prompt content including all fields') would make it more complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and the parameter description explicitly states the field is 'The prompt UUID, from `list_custom_prompts`' – this adds provenance and context beyond just the type. The tool description itself does not add further parameter detail, but the schema already does the heavy lifting, 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 states a clear verb ('Read'), a specific resource ('custom prompt'), and a precise scope ('in full, by id'). This distinguishes it from sibling tools like list_custom_prompts (which lists prompts) and the create/update/delete counterparts. An agent can immediately understand what this tool does without needing to inspect the schema.

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

  Usage Guidelines3/5

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

  The description implies usage by 'by id', suggesting the agent must have a prompt UUID, and the schema clarifies that the id comes from list_custom_prompts. However, there is no explicit guidance on when to prefer this over alternatives (e.g., when you need the full prompt vs. a summary, or when to use list_custom_prompts instead). The guidance is implied but not made explicit.

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

• get_mcp_configA
  3.6/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 of behavioral disclosure. It explicitly states 'Read', indicating a read-only operation without side effects. However, it does not elaborate on failure behavior (e.g., missing file) or permissions. The description adds the scope but nothing else beyond the core read action.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the verb and resource. It is efficient, with zero wasted words, and clearly conveys the two modes (full file or single entry).

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

  Completeness4/5

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

  Given the low complexity of this tool (two optional parameters, no nested objects) and the presence of an output schema, the description is quite complete. It explains what the tool does; the schema covers parameter details, and the output schema likely covers return format. The only gap is usage context relative to siblings, but that is minor for a simple read operation.

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

  Parameters3/5

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

  Schema description coverage is 100%, and both parameters have descriptive text in the schema. The description adds minimal value beyond that, merely restating the scope in terms of 'whole file, or one server entry,' which aligns with the 'server' parameter. Since the schema already explains the parameters, a baseline 3 is appropriate.

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

  Purpose5/5

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

  The description specifies the action 'Read', the exact resource 'config/mcp.json', and the scope 'the whole file, or one server entry.' This clearly identifies what the tool does and distinguishes it from sibling write tools like upsert_mcp_server or replace_mcp_config.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention that it is the read counterpart to write operations, nor does it state any exclusions or conditions. The scope detail ('whole file, or one server entry') hints at usage but stops short of explicit guidance.

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

• delete_mcp_serverA
  3.8/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 previous file is backed up, which is a valuable and non-obvious behavior. It does not mention potential error conditions, permission requirements, or other side effects, but the backup note adds useful transparency about reversibility.

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

  Conciseness5/5

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

  The description is a single sentence that efficiently states the action, resource, and backup behavior. It is front-loaded and contains no filler—every element is necessary.

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

  Completeness4/5

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

  For a simple deletion operation with one parameter and an output schema, the description covers the essential behavior: what it removes and the backup note. It omits error handling or edge-case behavior, but those are likely covered by the output schema. Overall, it is adequately complete for the tool's simplicity.

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

  Parameters3/5

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

  The input schema covers the sole parameter 'name' with the description 'Server key to remove,' which is self-explanatory. The tool description echoes the removal concept but does not add extra detail about the parameter's format or constraints. With 100% schema coverage, the description adds no additional semantic value beyond the schema.

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

  Purpose5/5

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

  The description clearly states the action 'Remove' and the resource 'server entry from config/mcp.json', and it additionally notes the backup behavior. This makes its purpose unambiguous and distinct from sibling tools like upsert_mcp_server and replace_mcp_config, which handle add/update and whole-file replacement respectively.

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

  Usage Guidelines3/5

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

  No explicit guidance is given about when to use this tool versus alternatives. However, the verb 'Remove' strongly implies its intended use for deletion, and the backup note suggests a safe removal. It does not discuss conditions that would favor other tools, but the intended use is evident from the name and action.

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

• delete_workspaceA
  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 full burden of behavioral disclosure. It explicitly states that deletion is not recoverable and instructs the agent to confirm with the user first, which is critical behavioral context for a destructive operation. It does not mention side effects on associated data or permission requirements, but the irreversibility warning is the most important behavior.

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

  Conciseness5/5

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

  The description is two short sentences with zero redundancy. The primary purpose is stated first, followed by the critical warning. Every word earns its place.

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

  Completeness4/5

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

  For a simple delete tool with one parameter and an output schema present, the description covers the core purpose and the most essential behavioral warning. It is sufficient for the agent to invoke correctly. It does not elaborate on return values, but the output schema likely handles that, so missing that detail is acceptable.

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

  Parameters3/5

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

  The input schema already provides full coverage (100%) of the single parameter (workspace_id) with a description ('The workspace UUID.'). The tool description adds no additional meaning beyond the schema, which is fine given the high coverage. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Delete') and resource ('a workspace'), which is unambiguous. It also distinguishes from sibling tools like update_workspace or list_workspaces by naming the exact operation. The warning about non-recoverability reinforces the purpose as a destructive action.

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

  Usage Guidelines3/5

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

  The description implies usage (delete a workspace) but does not explicitly contrast with alternatives such as update_workspace or list_workspaces. It provides no 'when to use this vs. that' guidance. The confirmation warning hints at cautious usage, but it is not framed as a routing criterion.

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

• list_conversationsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the result ordering, the exact fields returned, and the limitation that it only provides previews, not the full messages. This is substantial, though it does not explicitly state that the operation is side-effect-free, but the read-only nature is strongly implied.

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

  Conciseness5/5

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

  The description is three short sentences: the first states the primary purpose and ordering, the second lists return fields, and the third points to the sibling for more detail. Every sentence earns its place, and the most critical information is front-loaded. Zero 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?

  The tool is simple (3 optional params, no nested objects) and an output schema exists, so the description need not detail return structure. It covers the essential behavioral context: what is returned, order, and the boundary with get_conversation. Missing mention of search_conversations is a minor gap, but the description is otherwise complete for an agent to invoke this correctly.

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

  Parameters3/5

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

  All three parameters (tag, limit, offset) are fully described in the input schema, so the description adds no additional parameter semantics. Per the rubric, when schema coverage is high, a baseline score of 3 is appropriate; the description does not detract but also does not enrich.

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

  Purpose5/5

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

  The description opens with a clear verb-resource pair ('List saved conversations') and a key behavior ('newest first'). It explicitly distinguishes itself from the sibling get_conversation by stating it returns a list with previews rather than full messages, making it easy for an agent to choose between them.

  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 clearly directs the agent to use get_conversation when full messages are needed, providing a concrete alternative and when-not-to-use guidance. However, it does not mention the close sibling search_conversations, which could be relevant for filtering or query-based retrieval, so coverage of alternatives is incomplete.

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

• list_conversation_tagsA
  4.2/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. 'List' implies a read operation, and the description adds that it's scoped to 'this user'. However, it doesn't disclose any behavior such as whether results are paginated, sorted, or limited, nor does it mention error conditions or authentication requirements. For a simple list tool with an output schema, this is adequate but not rich.

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

  Conciseness5/5

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

  The description is a single, short sentence that fully conveys the purpose with zero waste. It is front-loaded with the action and resource. Perfectly concise.

  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 tool with no parameters and an existing output schema, the description is complete enough. It clarifies the scope ('this user') and the resource (tags applied to conversations). It doesn't need to explain return values because the output schema handles that. A minor gap: it doesn't specify whether this returns all tags across all conversations or only distinct tags, but the phrase 'tags this user has applied to conversations' is reasonably interpretable.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is 100% (since there are no properties). Baseline for 0 parameters is 4. The description does not add parameter-specific information because there are none to describe.

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

  Purpose5/5

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

  The description states a specific verb ('list') and a clear resource ('tags this user has applied to conversations'). It clearly distinguishes from sibling tools like list_conversations (which lists conversations, not tags) and get_conversation (single item). The scope ('this user') is explicit, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description implies when to use it: when you need the tags associated with the current user across conversations. It doesn't explicitly mention alternatives or exclusions, but the tool is so specific that the usage context is clear without further guidance. A minor deduction for not naming any sibling alternatives.

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

• update_workspaceA
  4.2/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 of behavioral disclosure. It does disclose that config replaces the whole selection snapshot and that invalid keys are 'rejected by ATLAS', which is genuinely useful. However, it omits details such as whether name and description can be set together with config, what happens on partial failure, or permission requirements — notable gaps for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is compact and front-loaded: purpose in the first line, the critical config-replacement caveat and required read-first step in the second, and the allowed keys in the third. Every sentence earns its place 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?

  Given an output schema exists, full parameter coverage, and no nested objects, the description covers the essential gotcha (config replacement semantics) and the rejection behavior. It is complete enough for an agent to call this correctly; the only minor gap is explicit wording on usage boundaries vs. create/delete, which is largely self-evident.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: it clarifies that config is a wholesale replacement of the snapshot rather than a merge, which the schema's terse 'Replacement selection snapshot, if changing' does not convey. The explicit allowed-keys list also helps an agent avoid rejected inputs.

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

  Purpose5/5

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

  The first line states a specific verb and resource ('Update a workspace's name, description, or selections'), making the purpose unambiguous. The scope is clearly delimited and easy to distinguish from siblings like create_workspace, delete_workspace, and list_workspaces without inspecting their schemas.

  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 explicit context for the trickiest case by instructing the agent to 'read the current one with list_workspaces first' before passing config, and enumerates the allowed config keys. It doesn't explicitly state when not to use this tool versus create/delete, but the update-vs-create/delete distinction is self-evident from the verb.

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

• write_prompt_fileA
  4.2/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 full burden of disclosure. It reveals that the operation is destructive in nature but backs up the previous version, affects all chats, and takes effect only on restart. It also mandates user confirmation for a specific file. This goes beyond the schema and gives the agent a solid understanding of side effects and prerequisites, though it omits details like error conditions or backup restore process.

  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 efficient: two sentences convey the core action, backup behavior, global side effects, restart timing, and a confirmation requirement. Every sentence earns its place, and the primary action is front-loaded. There is no redundant or superfluous text.

  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 mutation tool with no annotations but an output schema, the description provides sufficient context: what it does, the backup, the global impact, timing, and a confirmation caution. Minor gaps exist, such as behavior if the file does not exist or if backup creation fails, but these are edge cases that the agent can infer. Overall, the description covers the essential information needed to invoke the tool correctly.

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

  Parameters3/5

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

  The input schema already covers both parameters with descriptions (name: 'Filename ending in .md, inside the prompts directory'; content: 'Full replacement text'), achieving 100% schema description coverage. The tool-level description adds no parameter-specific guidance, so the baseline of 3 is appropriate; the schema adequately conveys semantics without needing further elaboration.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'Overwrite an on-disk prompt file, backing up the previous version.' This clearly distinguishes it from read-only siblings like read_prompt_file and list_prompt_files by stating the mutating action and the backup behavior. It also notes the scope ('affects every chat') and timing ('next ATLAS restart'), making the tool's role unambiguous.

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

  Usage Guidelines4/5

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

  The description provides concrete usage context: the global effect, the deferred application, and the explicit requirement to confirm before changing system_prompt.md. It implies this is for on-disk prompt files as opposed to custom prompts managed by siblings like create_custom_prompt/update_custom_prompt, though it does not explicitly name alternatives or state 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.

• get_conversationA
  4.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 full burden of behavioral disclosure. It explicitly reveals that long messages are clipped and explains how to override this (raise max_message_chars), which is a key behavioral trait. It implies a read-only operation but doesn't state side effects or permissions; however, the clipping detail adds valuable context beyond the schema.

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

  Conciseness5/5

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

  Two sentences with zero waste. The first sentence states the purpose immediately; the second adds a behavioral note and a direct actionable hint. The structure is front-loaded and every word earns its place.

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

  Completeness4/5

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

  The tool is simple and has an output schema (which presumably defines the return structure), so the description doesn't need to explain return values. It covers the core function and the clipping behavior, which is the main nuance. It lacks mention of error cases (e.g., nonexistent conversation) but that's not critical for a basic read operation given the schema covers inputs and outputs.

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

  Parameters4/5

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

  Schema coverage is 100%, so all three parameters are already described in the input schema. The description adds value by explaining the practical effect of max_message_chars ('Long messages are clipped... raise it when you need full text') and ties it to the parameter, going beyond the schema's simple 'Per-message clip length' definition.

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

  Purpose5/5

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

  The description uses a specific verb ('Read') with a precise resource ('one full conversation, including its messages'), making it clear this tool retrieves a single conversation by ID. It implicitly differentiates from siblings like list_conversations (which lists) and search_conversations (which searches) without confusion.

  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 establishes clear context: this is the tool for reading a specific conversation's messages. It doesn't explicitly contrast with alternatives or state when not to use it, but the parameter description (conversation_id from list_conversations) and the tool name imply the scenario well. It also provides guidance on adjusting max_message_chars for full text, which indicates a specific use case.

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

• list_prompt_filesA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the files are system-level defaults, that editing them has global effect, and that changes take effect only after restart—important context for an agent deciding whether to modify them. Though it doesn't explicitly say the tool is read-only, 'List' implies that, and the caution about editing is a meaningful behavioral signal.

  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 two sentences, front-loaded with the primary action. The second sentence provides necessary context about defaults and the impact of editing, which earns its place. It is slightly verbose for such a simple action but remains efficient and well-structured.

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

  Completeness5/5

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

  Given zero parameters and an output schema (not shown but flagged as present), the description need not explain return values. It fully covers what the tool does, the distinction from the per-user library, and the operational consequence of editing—making it complete for an agent to decide when and whether to invoke it.

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

  Parameters4/5

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

  The tool has zero parameters and the schema coverage is trivially 100% (empty properties object). The description correctly omits parameter details since none exist. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description adds nothing about parameters because there is nothing to add.

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

  Purpose5/5

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

  The description clearly states the action (List), the resource (markdown prompt files), and the specific scope (defaults ATLAS loads from disk). It explicitly distinguishes from the per-user library, aligning with sibling list_custom_prompts, so an agent can immediately tell them apart without inspecting schemas.

  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 says these are 'separate from the per-user library above', implying that list_custom_prompts is the alternative for user-specific prompts. It also warns that editing these files affects every chat and requires a restart, which informs usage context. However, it does not state explicit conditions like 'use this when you need system defaults' or 'do not use for user prompts', leaving some inference to the agent.

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

• update_custom_promptA
  4.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 bears the full burden of behavioral disclosure. It states that `content` replaces the whole text, which is a critical behavioral trait (full overwrite) that prevents accidental data loss. However, it does not clarify behavior for the `title` parameter (e.g., whether omitting it preserves the existing title) or whether the update is atomic. These gaps leave some uncertainty, so a mid-range score is appropriate.

  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 exceptionally concise—two sentences total. The first sentence states the core action and the second provides a critical usage guardrail. It is front-loaded and every word earns its place, with no filler or redundant explanation.

  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 straightforward update tool with 100% schema coverage and an output schema, the description covers the essential nuance (content replacement). It does not mention the optionality of parameters or specify the return value, but these are either visible in the schema or standard for update operations. The key behavioral edge case is addressed, making it complete enough for an agent to call accurately.

  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 describes each parameter (title as 'New title, if changing', content as 'New full text, if changing', prompt_id as UUID). The description adds significant semantic value for `content` by explaining it replaces the entire text and recommending a read-first workflow for amendments. This goes beyond the schema's static descriptions and helps the agent use the parameters correctly.

  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 clear action ('Edit') on a specific resource ('a custom prompt's title or content'). This unambiguously differentiates it from sibling tools like create_custom_prompt, delete_custom_prompt, and get_custom_prompt, which have distinct verbs and purposes. The subject is precise and leaves no confusion about the tool's role.

  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?

  It explicitly provides a when-to-use guideline: read with `get_custom_prompt` first when amending rather than rewriting the content. This directly instructs the agent on the correct workflow for partial edits, which is valuable and goes beyond the schema. No alternative tool is mentioned but the guidance is specific and actionable.

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

• delete_custom_promptA
  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 disclosing behavioral traits. It explicitly states that the action is irreversible ('Not recoverable') and requires user confirmation, which are critical safety-relevant behaviors for a delete operation.

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

  Conciseness5/5

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

  The description is extremely concise—two short sentences that front-load the action and then add the crucial warning. Every word earns its place with no redundancy.

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

  Completeness5/5

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

  For a simple deletion tool with one parameter and an output schema, the description covers all essential context: the operation, its permanence, and the required confirmation. Nothing critical is missing.

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

  Parameters3/5

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

  The input schema already documents the single parameter (prompt_id) with 100% coverage. The description adds no additional parameter-specific information, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states a specific action ('Delete') and a specific resource ('a custom prompt'), distinguishing it from sibling tools like update_custom_prompt or get_custom_prompt. It is unambiguous about what the tool does.

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

  Usage Guidelines4/5

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

  It provides an explicit usage constraint—'confirm with the user first'—which guides when the tool should be invoked. However, it does not compare against alternatives (e.g., when to use this vs. update_custom_prompt), so it lacks full differentiation guidance.

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

• list_workspacesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description must carry the full behavioral burden. The verb 'List' and the scope 'this user's' strongly imply a read-only operation with no side effects. The description also clarifies that it returns the user's own workspaces, which is a useful behavioral constraint. It does not explicitly state 'does not modify data' or mention pagination, but for such a simple read operation, the description is reasonably transparent.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that leads with the verb and resource, then adds a helpful parenthetical definition. There is no fluff or redundancy, and every word earns its place. It is concise and well-structured.

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

  Completeness5/5

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

  Given zero parameters and the presence of an output schema of the return format, the description is complete for an agent to correctly invoke this tool. It specifies the exact scope (user's own workspaces), defines the domain concept, and there are no hidden options or requirements. Nothing essential is missing.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline for this dimension is 4 per the rubric. The description does not need to explain any parameters because there are none, and the schema confirms this. The description adds context about the returned data (workspaces as bundles), which is sufficient.

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

  Purpose5/5

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

  The description uses the verb 'List' with a specific resource ('this user's workspaces') and clarifies what workspaces are ('saved bundles of prompt/tool/RAG selections'). This clearly distinguishes it from sibling tools like create_workspace, update_workspace, and delete_workspace, as well as other list tools (e.g., list_conversations) by focusing on workspaces.

  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 states exactly what the tool does, making its usage obvious. It does not explicitly mention when not to use it or name alternatives, but since no sibling tool provides the same listing capability for workspaces, the context is clear. The description effectively communicates when this tool is appropriate: whenever a list of the user's workspaces is needed.

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

• upsert_mcp_serverA
  4.6/5.0
  Behavior5/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 transparently states three key behaviors: the entry is replaced wholesale (not merged), the rest of the file is untouched, and the previous file is backed up. These are critical side-effect and safety details that go beyond a simple 'add or replace' statement. No annotation contradiction exists.

  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 structured effectively: a clear action sentence, followed by critical behavioral notes, a usage workflow, and an example block. All content is relevant and purposeful. While it is slightly longer than average, the example is justified because it illustrates the non-obvious structure for a stdio entry. No fluff or redundancy is present.

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

  Completeness5/5

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

  Given that an output schema exists (context signal indicates has output schema true), the description does not need to explain return values. Combined with clear parameter descriptions and an example, the description provides everything an agent needs to call the tool correctly: what it does, how to read first, what the entry structure looks like, and the side effects. The workflow is fully specified, making this highly complete for the tool's complexity.

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

  Parameters4/5

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

  Schema coverage is 100%, so both parameters have descriptions in the schema (name as a key string, config as a full entry object). The description adds meaningful value beyond the schema: it provides a concrete stdio entry example with structure, and explains that the entry is replaced wholesale, which clarifies what the `config` object is expected to contain and how it is handled. This extra context earns a score above the baseline of 3.

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

  Purpose5/5

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

  The description clearly states the exact action: "Add or replace one server entry in config/mcp.json." It specifies the target file and the scope (one entry), distinguishing it from sibling tools like `get_mcp_config` (read), `delete_mcp_server` (remove), and `replace_mcp_config` (likely whole-file replacement). The verb is specific and the resource is unambiguous.

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

  Usage Guidelines4/5

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

  The description gives explicit workflow guidance: "read the current entry with `get_mcp_config` first and send it back with your change applied." This tells the agent how to use the tool correctly. It also implies the alternative (read before write) and clearly states that the entry is replaced wholesale, not merged. However, it does not explicitly name sibling tools like `replace_mcp_config` for whole-file replacement, though the distinction is implied by "one server entry."

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

• atlas_statusA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full responsibility. It discloses that the tool checks availability and reports a target URL, and that it can differentiate failure modes. It does not explicitly state that it is read-only or side-effect-free, but for a status check this is implicitly understood. The behavior is well disclosed.

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

  Conciseness5/5

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

  Two sentences, zero wasted words. The main purpose is front-loaded, followed by the usage guideline. It is optimally concise and structured.

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

  Completeness5/5

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

  Given zero parameters and the presence of an output schema (not shown but indicated), the description provides all necessary context: what the tool does, when to use it, and what it distinguishes. No critical information is missing for an agent to call it correctly.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific detail (none are needed). It does not repeat schema information, which is consistent with a no-parameter tool.

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

  Purpose5/5

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

  The description clearly states the verb 'Check' and the resource 'ATLAS', and specifies that it reports 'what this server is pointed at'. This distinguishes it from sibling tools like get_conversation or search_conversations, which have different purposes.

  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?

  It explicitly says 'Start here when another tool fails', providing a clear usage context. It also outlines the three distinct outcomes (ATLAS down, feature disabled, wrong URL), which helps the agent decide when to use this tool versus troubleshooting alternatives.

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

• replace_mcp_configA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses a validation condition ('Rejected unless content parses as an object of objects') and a safety behavior ('the previous file is backed up either way'), which cover key behavioral traits. However, it doesn't mention any potential side effects beyond overwriting (e.g., losing entries not in the new content) or what happens on success, though the output schema likely covers return values. Slightly under-discloses for a destructive operation, but the backup note mitigates.

  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?

  Four short, purposeful sentences. The core action is front-loaded, followed by usage context, validation/backup behavior, and alternative routing. No filler or redundancy – every sentence earns its place.

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

  Completeness5/5

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

  For a simple one-parameter tool with an output schema, this description covers purpose, usage context, validation, backup behavior, and alternative selection. Nothing essential is missing; the output schema handles return values, so the description's omission of success details is acceptable.

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

  Parameters4/5

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

  Schema has 100% coverage for the single parameter, but the description adds meaningful extra semantics: 'complete JSON document' and 'object of objects', which clarify the expected structure beyond the schema's generic 'full replacement JSON text'. This helps the agent construct valid input without extra inference.

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

  Purpose5/5

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

  States a specific verb and resource ('Overwrite config/mcp.json') and clarifies it takes a complete JSON document. Differentiates from siblings by noting it's for 'restructuring several entries at once' and explicitly naming 'upsert_mcp_server' as the alternative for single-server changes, so the agent can distinguish tools without opening schemas.

  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?

  Explicitly states when to use this tool ('For restructuring several entries at once') and when not to ('Prefer upsert_mcp_server for a single-server change'), naming the specific alternative. This gives clear routing guidance with no ambiguity.

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