Server Quality Checklist

Tool Scores

• save_content_ideaC
  2.7/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the full burden of disclosing behavior. 'Save' implies a write/persist operation, but the description does not mention whether the operation inserts a new record, updates an existing one, handles duplicates, requires any permissions, or what the response contains.

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

  Conciseness4/5

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

  The description is a single, readable sentence with no wasted words, and the core action and resource are front-loaded. It loses a point because it is so sparse that it leaves important context for other dimensions unaddressed.

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

  Completeness2/5

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

  Given 11 parameters, 6 required fields, no annotations, and a sibling set with overlapping content-save actions, this description is too minimal to fully orient an agent. The output schema exists, so return-value documentation is not strictly required, but usage context and behavioral caveats are still missing.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description adds no meaning about the fields beyond saying the idea is 'structured.' While the schema property names and enums are reasonably self-descriptive, the description itself does not compensate for the complete lack of parameter-level guidance.

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

  Purpose4/5

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

  The description uses a specific verb ('Save') and identifies a distinct resource ('structured content idea'), making the core purpose clear. It does not explicitly contrast with sibling tools like save_content_asset or save_interview_answer, so it misses the extra differentiation that would earn a 5.

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

  Usage Guidelines2/5

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

  The phrase 'for later development' implies an intended workflow stage, but there is no explicit guidance on when to use this tool versus alternatives such as save_content_asset, save_interview_answer, or add_article. No when-to-use or when-not-to-use conditions are provided.

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

• manage_sourceC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries the full disclosure burden, but it only lists action names. It does not explain side effects of 'enable'/'disable', whether actions are idempotent or reversible, what data 'list' returns, or any prerequisites such as authentication or required source ids.

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

  Conciseness4/5

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

  The description is a single front-loaded sentence with no filler: it opens with the action verbs and names the resource. It is efficient, though slightly too terse to fully support the multi-action behavior of the tool.

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

  Completeness2/5

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

  For a four-parameter, four-action tool with no annotations and zero schema description coverage, this description is incomplete: it omits per-action parameter requirements, behavioral caveats, and sibling routing. The presence of an output schema lessens the need to document return values, but the remaining gaps are material.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only supplies the domain ('RSS research sources'). It does not explain how url, name, and source_id map to each action (e.g., which are required to add versus enable/disable), leaving the agent to infer parameter relationships from names alone.

  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 names a concrete resource ('RSS research sources') and enumerates the exact operations ('Add, list, enable, or disable'), making it clear what the tool does despite the generic name 'manage_source'. It doesn't explicitly contrast with siblings such as add_article or refresh_sources, so it stops short of full differentiation.

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

  Usage Guidelines3/5

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

  The description implies usage: agents should call it when they need to manage RSS research sources. However, it never states when not to use it or which sibling tool (e.g., refresh_sources for refreshing, add_article for adding content) should be preferred in related situations.

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

• update_content_statusC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must carry behavioral disclosure, but it only hints that transitions are constrained by an 'allowed... workflow'. It does not explain validation of transitions, side effects, permissions, or error behavior, leaving the agent with significant uncertainty for a state-changing operation.

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

  Conciseness4/5

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

  The description is a single direct sentence with no filler, and it front-loads the action and object. It is efficient, though it could use additional structure to convey transition constraints.

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

  Completeness2/5

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

  The tool is simple and has an output schema, but the critical contextual detail - the exact status workflow and allowed transitions - is not provided. An agent cannot confidently predict whether a transition like idea -> published is allowed, making the definition incomplete for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It maps 'content idea' to idea_id and 'status' to new_status only indirectly, and does not explain that new_status must be a valid transition target for the current idea. The enum in the schema is the only real parameter guidance.

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

  Purpose4/5

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

  The description states a specific action ('Move') and resource ('a content idea') plus the domain concept 'allowed status workflow', which clearly identifies this as the status-transition tool. It does not explicitly distinguish it from siblings like save_content_idea, but the workflow wording makes the purpose clear.

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

  Usage Guidelines3/5

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

  The phrase 'through the allowed status workflow' implies this tool is for status changes, which gives the agent a basic trigger condition. However, it offers no exclusions, prerequisites, or comparison with alternatives such as save_content_idea, so the guidance is only implicit.

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

• save_interview_answerB
  3.3/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 behavioral disclosure burden. It only says 'Save' and does not explain whether this overwrites an existing answer, creates a new record, requires any confirmation workflow, or what persistence implications exist.

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

  Conciseness5/5

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

  The description is a single sentence with no wasted words. It front-loads the action and includes the most relevant contextual constraints: Ruslana, confirmed answer, one focused question, and content idea.

  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 three-string-parameter tool with an output schema, the description conveys the core use case adequately, but it leaves important context unstated, such as overwrite/upsert behavior and how this differs from saving raw content ideas. It is minimally viable but not fully self-sufficient.

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

  Parameters3/5

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

  Schema description coverage is 0%, but the description compensates by semantically mapping all three parameters: 'answer' maps to answer, 'focused interview question' maps to question, and 'content idea' maps to idea_id. However, it adds no detail about format, allowed values, or how idea_id should be sourced.

  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 names a concrete action and resource: saving Ruslana's confirmed interview answer, scoped to one focused question and a content idea. It is clear enough to distinguish from siblings like save_content_idea or add_article, though it does not explicitly call out those differences.

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

  Usage Guidelines3/5

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

  The phrase 'confirmed answer to one focused interview question for a content idea' implies when to use the tool, but no explicit when-not-to-use guidance or alternatives are mentioned. An agent can infer clear context, but must reason about sibling tool selection on its own.

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

• save_content_assetA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full behavioral burden, and 'versioned' usefully signals that saves create versions rather than blindly overwrite. However, it does not disclose whether a new version is always appended, what happens to prior versions, or whether saving an asset affects the idea's status. The behavioral disclosure is meaningful but thin.

  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: the verb 'Save' leads, and the asset-type enumeration is compact with no filler. Every element earns its place and the sentence is immediately scannable by an agent.

  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 3-parameter tool with all-required fields, an enum, and an output schema present, the description covers the core operation and does not need to explain return values. Notable gaps are the missing guidance on tool selection among sibling tools and prerequisites such as whether the referenced content idea must already be saved. Adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the schema offers only bare names — 'Content', 'Idea Id' — plus the AssetType enum. The description partially compensates by clarifying that 'content' is a Reel script, LinkedIn draft, caption, or tutorial outline and that the asset belongs to a 'content idea' (the role of idea_id). It adds the 'versioned' concept but does not document idea_id format or any content constraints, so coverage gaps remain.

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

  Purpose4/5

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

  The description uses a specific verb ('Save') with a defined resource — 'versioned Reel script, LinkedIn draft, caption, or tutorial outline' — scoped to a content idea. The enumerated asset types make the tool's domain unambiguous and distinguish it from siblings like save_content_idea and save_interview_answer, though it does not name those alternatives explicitly.

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

  Usage Guidelines3/5

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

  The description implies the usage context — the agent has finished draft content for an existing content idea and wants to persist it as a versioned asset. However, it provides no explicit when-to-use guidance, prerequisites (e.g., whether the idea must already exist), or exclusions versus sibling tools such as save_content_idea or update_content_status. Usage context is implied rather than stated.

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

• import_chat_historyA
  3.8/5.0
  Behavior2/5

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

  No annotations are present, so the description must fully disclose side effects. It states the import destination but does not reveal whether existing data is overwritten or merged, what validation occurs, or other mutation semantics. The 'local private' wording adds some safety context but not enough for a write operation.

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

  Conciseness5/5

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

  A single front-loaded sentence states exactly what is imported, from where, and to where. There is no filler or redundant restatement.

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

  Completeness4/5

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

  For a one-parameter import tool with an output schema, the description gives enough context to invoke correctly: input file and destination. It could mention overwrite/merge behavior, but the operation and scope are sufficiently clear.

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

  Parameters3/5

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

  The schema fully documents the single file_path parameter with coverage at 100%, so a baseline of 3 applies. The description paraphrases 'explicitly selected' but adds no additional parameter meaning beyond the schema already provides.

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

  Purpose5/5

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

  The description uses a specific verb ('Import'), a precise input ('ChatGPT conversations.json export'), and a target ('local private database'). It clearly distinguishes from all listed siblings, none of which handle chat history imports.

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

  Usage Guidelines4/5

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

  The phrase 'one explicitly selected' gives clear context that this tool is for a single user-chosen export file, not bulk discovery or multiple files. It does not state exclusions or explicitly name alternative tools, but no sibling is a plausible substitute.

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

• add_articleA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It discloses meaningful behaviors: it fetches, extracts, saves, and rejects private/local network targets. However, it does not mention side effects such as duplicate handling, idempotency, or whether the saved article can be overwritten.

  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 crisp sentences with no filler. The main verb phrase 'Fetch, extract, and save' is front-loaded, and the important security constraint is stated clearly and briefly.

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

  Completeness4/5

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

  For a single-parameter tool with an output schema, the description covers the core operation and the key constraint adequately. It misses explicit sibling routing and deeper side-effect details, but the presence of an output schema and the simple parameter model make the description largely complete.

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

  Parameters4/5

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

  Schema coverage is 100% and the URL parameter already has a helpful description. The tool description adds extra semantics by clarifying that the URL must be user-provided, public, and exactly one, and by stating that private and local network targets are rejected.

  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: fetch, extract, and save one user-provided public article URL. It distinguishes this tool from siblings like save_content_idea or save_content_asset by specifying the exact resource and the public-URL requirement.

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

  Usage Guidelines3/5

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

  The description implies usage: use this when the user provides a public article URL to save. It also gives an exclusion by rejecting private and local network targets, but it does not explicitly mention sibling tools or conditions for choosing an alternative.

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

• refresh_sourcesA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It does disclose that the tool ingests unseen articles and returns only counts and metadata, not bodies. However, it does not explain side effects like whether ingestion creates permanent records, whether duplicates are handled, or whether any authentication or rate-limit considerations apply.

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

  Conciseness5/5

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

  The description is two short sentences with no filler. It front-loads the core action and follows with the output boundary, which is exactly the information an agent needs to select and invoke the tool correctly.

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

  Completeness4/5

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

  For a zero-parameter tool with an output schema present, the description is largely complete: it says what action is taken, what is returned, and what is not returned. The main gaps are behavioral details around side effects and explicit when-to-use guidance, but these are relatively minor given the tool's simplicity.

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

  Parameters4/5

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

  The tool has zero parameters, so parameter semantics are largely non-applicable; the baseline of 4 applies. The only implied input is the global state of 'enabled RSS sources', which does not require parameter documentation.

  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 ('Refresh'), a precise resource ('enabled RSS sources'), and the intended outcome ('ingest unseen articles'). It also clarifies the output scope by saying it returns counts and article metadata, not bodies, which distinguishes it from content-search or article-management siblings.

  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 intended use case is implied: call this when you want to pull in new articles from enabled RSS sources. However, the description gives no explicit guidance about when not to use it or how it compares to alternatives like manage_source or add_article.

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

• search_personal_contextA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It usefully scopes behavior (only imported conversations and notes, only personal-experience evidence), and 'search' reasonably implies a non-destructive read. But it does not disclose relevance-ranking behavior, matching semantics, or whether full text or snippets are returned, so some behavior remains unstated.

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

  Conciseness5/5

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

  A single sentence with the verb front-loaded and zero filler. Every phrase earns its place: 'imported' scopes the corpus, 'conversations and notes' names the sources, and 'evidence of relevant personal experience' states the retrieval intent.

  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 2-parameter tool with an output schema present, the description covers what is searched, from where, and for what, and the output schema handles return-value structure. The only gap is behavioral nuance like ranking or snippet behavior, which is minor for tool selection.

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

  Parameters3/5

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

  Schema description coverage is 100%: both 'query' ('Topic or experience to search for') and 'limit' ('Maximum number of matches') are already documented in the schema. The tool description mirrors the query semantics but adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Search'), a concrete resource ('imported conversations and notes'), and a clear intent ('evidence of relevant personal experience'). This differentiates it sharply from every sibling, which are all save/update/import/add/manage/refresh/list operations — this is the only retrieval tool in the set.

  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 word 'imported' signals clear usage context: this tool is used after content has been brought in (e.g., via import_chat_history), and it is the dedicated retrieval path for personal-experience evidence. No sibling competes for this job since all others are mutation or listing tools. However, it doesn't explicitly name alternatives or state when not to use it.

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

• list_topic_candidatesA
  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 behavioral disclosure. It states that the tool 'Returns deterministic metadata and short excerpts,' which reveals the return style and stability of results. While it does not explicitly say it is read-only or describe ordering/pagination, the verb 'List' and the return disclosure are sufficient for a low-risk listing tool.

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

  Conciseness5/5

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

  Two sentences, no filler. The primary action and resource are front-loaded in the first sentence, and the second adds useful return information. Every phrase 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 single-parameter list tool with an output schema present, the description covers the core purpose, the target resource, and the nature of the returned data. Minor gaps like the precise meaning of 'recent' or the ordering of results are not material enough to make the tool hard to call correctly.

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

  Parameters3/5

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

  The schema already fully documents the only parameter (limit) with type, default, minimum, maximum, and a clear description ('Maximum number of candidate articles'). The description adds no additional parameter meaning, so the baseline of 3 is appropriate given 100% schema description coverage.

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

  Purpose5/5

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

  The description starts with a specific verb ('List') and a specific resource ('recent unreviewed research articles'), and adds the intended purpose ('for content-idea evaluation'). This clearly distinguishes it from sibling tools like add_article, save_content_idea, and search_personal_context without ambiguity.

  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 a clear use context ('for content-idea evaluation') that implies when an agent should call this tool rather than the saving or searching siblings. It does not explicitly name alternatives or state when not to use it, but the purpose and resource scoping provide enough guidance for a straightforward read-only list tool.

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