Server Quality Checklist

Tool Scores

• search_recordsC
  2.4/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 burden of behavioral disclosure. It only states the tool searches for matching text but does not disclose case sensitivity, exact vs. fuzzy matching, result ordering, pagination, or any side effects. The agent is left without critical runtime behavior information.

  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, concise sentence that is front-loaded with the core action and target. It is efficient in word count, but it omits essential details, so while it is concise, it is not comprehensive. It earns a 4 for brevity without waste, but lacks the structural depth expected for a tool with multiple parameters.

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

  Completeness1/5

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

  Given the tool has 5 parameters, no output schema, and no annotations, the description is grossly incomplete. It fails to explain how to form a query, what valid input types are, the semantics of date filters, or the response format. An agent would struggle to invoke this tool correctly without further information.

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

  Parameters1/5

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

  The schema has 0% description coverage, and the description does not explain any of the five parameters. It does not clarify what 'query' means, how 'from'/'to' are formatted, what 'limit' controls, or how 'types' restricts the search. The only loose hint is 'journal and input' which vaguely maps to the types enum, but this is not explicit.

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

  Purpose4/5

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

  The description clearly states the tool searches journal and input Markdown files for matching text, specifying both the action and the resource types. However, it does not differentiate from sibling tools like get_records_by_date_range, which could also involve searching or retrieving records, so it lacks distinguishing context.

  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. It does not mention any conditions, prerequisites, or scenarios where this search tool is preferred over capture or date-range retrieval tools. The agent receives no help in selecting the correct tool.

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

• capture_inputC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose side effects and expectations. It only says 'Save' without explaining write privileges, overwrite behavior, filing conventions, or response format. The saved note's storage details are entirely omitted, leaving an agent unaware of potential errors or constraints 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.

  Conciseness4/5

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

  The description is a single concise sentence, front-loading the primary action. It avoids redundancy and is easy to scan. It loses a point for omitting any structural hints about optional fields or examples that would aid comprehension.

  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 tool with 6 parameters and no output schema or annotations, the description is far too minimal. It does not explain the purpose of filename keyword constraints, source handling, tag limits, or how the note is persisted. An agent would need additional information to correctly invoke all parameters.

  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?

  The description adds no parameter-specific guidance. Schema coverage is 50% (only date, content, keyword have descriptions), and the tool description fails to clarify the roles of title, source, or tags, or to supplement what the schema does provide. The phrase 'Markdown note' hints at content, but not enough to compensate for the coverage gap.

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

  Purpose4/5

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

  The description clearly states a specific verb ('Save'), a resource ('external input'), and the output format ('Markdown note'). It lists example inputs (article, book, podcast) making the purpose unambiguous. However, it does not explicitly distinguish from sibling 'capture_journal', so it loses some differentiation credit.

  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 capture_journal or any conditions for selecting this over other capture/search tools. An agent would not know whether this is appropriate for a specific scenario without further inference.

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

• capture_journalB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a write operation ('create or append') and a light-editing philosophy, which is genuine behavioral context. However, it does not disclose how the tool decides append vs. create, whether it is idempotent, auth requirements, or what it returns — gaps that matter for a write 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.

  Conciseness4/5

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

  Two tight sentences with no filler. The purpose is front-loaded in the first sentence, and the second sentence carries the only substantive addition (editing guidance). Every word earns its place.

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

  Completeness3/5

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

  For a 4-parameter write tool with no annotations and no output schema, the description is thin but the schema is fully self-documenting. The main gaps are the append-vs-create decision logic and the missing differentiation from capture_input in the sibling set, neither of which the schema can compensate for.

  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 the baseline is 3 even without parameter detail in the description. The description reinforces the content parameter's meaning via 'lightly edited content,' but adds nothing about keyword-as-filename, date defaults, or title that the schema already explains. It does not exceed the baseline.

  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 and resource: 'Create or append a personal journal fragment.' This clearly separates it from the read-oriented siblings get_records_by_date_range and search_records. However, it does not distinguish itself from the near-namesake capture_input, leaving the agent to guess how journal capture differs from general input capture.

  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 instruction to 'Supply lightly edited content that preserves the user's words and uncertainty' provides useful guidance on how to phrase the content body. But there is no when-to-use guidance versus capture_input, and no conditions under which one should be preferred over the other, so an agent selecting between the two capture tools gets no help.

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

• get_records_by_date_rangeA
  3.5/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 behavioral disclosure burden. It states the operation is a read and that the date range is inclusive, but it does not mention return format, pagination, default behavior when 'types' is omitted, or error handling.

  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, focused sentence with no filler. The verb and resource appear immediately, and every word ('inclusive', 'date range') adds relevant meaning.

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

  Completeness3/5

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

  With no annotations and no output schema, the description leaves the return shape and default behavior unstated, and the relationship to search_records is unexplored. Still, for a straightforward date-range read, the schema plus description provides a minimally viable definition.

  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 documents from/to with inclusive YYYY-MM-DD formats. The description adds that records are journal/input, which aligns with the optional types enum, but does not clarify the default filtering behavior when types is omitted. With 67% schema coverage, the description partially compensates but not fully.

  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 clear verb ('Read') and resource ('journal and input records') with a date-range scope, making the tool's query purpose obvious. It distinguishes itself from the capture_* siblings by being a read operation, though it does not explicitly contrast with search_records.

  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 when to use the tool: when records need to be read within an inclusive date range. However, it provides no explicit exclusions or alternatives, leaving the choice between this tool and search_records to inference.

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