Server Quality Checklist

Tool Scores

• academy_update_page_textB
  3.4/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. It discloses one important behavior (changes stay as concept until published), which is genuinely useful. However, it does not mention whether the update overwrites the entire body, permissions required, reversibility, or what happens to unpublished vs published pages. For a mutating tool with zero annotation coverage, more behavioral disclosure is warranted.

  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 compact, efficient two-sentence Dutch text with no filler. Each sentence earns its place: the first states the core action, the second provides workflow and parameter guidance. Slightly more could be added about behavior, but there is zero waste here.

  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 only 2 simple string parameters and no output schema, the completeness burden is moderate. The description covers the core semantics (update existing page text, stays concept until publish) and parameter sourcing, which is adequate for a low-complexity tool. However, given no annotations and no output schema, it could disclose a bit more about side effects (e.g., whether bodyHtml replaces or merges content) for full completeness.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It helpfully explains that id comes 'uit create of list' and bodyHtml is the text to set, but it adds no format details, encoding requirements, or length constraints beyond indicating bodyHtml is the text. There are only 2 params, both simple strings, so limited elaboration is needed; the description adds modest value.

  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 Dutch description clearly states the action: 'Werk de tekst van een bestaande pagina bij' (update the text of an existing page). It specifies the resource (existing page) and verb (update text). It doesn't explicitly distinguish from siblings like academy_create_concept_page, but the focus on updating existing content is reasonably clear.

  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 helpful context: changes remain a concept until you publish, and instructs users to provide id (from create or list) and bodyHtml. This implicitly guides when to use the tool (update an existing concept page's text) and hints at workflow context via 'blijft concept tot je publiceert,' but doesn't explicitly exclude alternatives or name sibling tools.

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

• academy_publish_pageA
  3.6/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 burden of behavioral disclosure. It reveals that publishing requires ownership or owner approval, which is meaningful behavioral context. However, it doesn't disclose side effects such as whether the previous live version is destroyed, whether republishing overwrites, or if there's any rollback possibility.

  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?

  One sentence, front-loaded with the core action (Publiceer een pagina). Every clause earns its place. Slightly under-specified in parts but highly economical.

  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?

  This is a single-parameter publish action with no output schema and no annotations. The description covers the action, the requirement (ownership/approval), and the parameter. However, it lacks detail on what parameters the id references, the success/failure response, and how to locate the id - gaps that are more significant given the lack of annotations.

  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 0%, so the description must compensate by explaining the single 'id' parameter. It does say 'Geef id' (give id), which tells the agent to provide the page identifier. However, it doesn't clarify whether id refers to a page id, version id, or concept page id, nor does it explain where to obtain the id (e.g., from list_pages).

  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 clear verb+resource structure: 'Publiceer een pagina' (publish a page) and specifies the effect ('maakt de laatste versie live'). It distinguishes from siblings by focusing on publishing/making-live rather than creation or listing, though it doesn't explicitly name a sibling alternative.

  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 when to use it ('doe dit als eigenaar, of na akkoord van de eigenaar'), indicating you should have owner rights or owner approval. This is clear usage context, though it doesn't explicitly explain when NOT to use it versus alternatives like update_page_text or create_concept_page.

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

• academy_create_concept_pageA
  3.9/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 full burden. It discloses that this creates a draft (not published) and describes the optional bannerUrl/ownerEmail behaviors. However, it doesn't disclose what happens on success/failure, whether it overwrites an existing name, or if permissions are required.

  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 dense sentence front-loads the core purpose (create draft page) and each parameter is explained inline with concrete examples. Slightly long, but every clause adds value.

  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 creation tool with 5 params and no output schema or annotations, the description covers the essential behavioral and parameter details well. It could benefit from noting response behavior or idempotency, but the main gaps (what the tool does, what each param means) are filled.

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

  Parameters3/5

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

  With 0% schema description coverage, the description must compensate, and it does reasonably well: it explains name as filename-without-path with example 'Mijn-onderwerp', bodyHtml as an HTML fragment with h2/p/ul, bannerUrl as full URL from SiteAssets, and ownerEmail as byline with example. However, some specifics like title semantics and validation rules are not covered.

  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 (create), resource (concept-page/draft page on HTJZ Academy), and explicitly notes it's a draft not published. This distinguishes it from siblings like academy_publish_page and academy_update_page_text.

  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 explains this creates an unpublished draft, which implicitly positions it against academy_publish_page. While it doesn't explicitly name alternatives or exclusions, the draft-vs-published clarification provides clear usage context.

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

• academy_list_menuA
  3.9/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 full burden. It discloses it returns a menu with item IDs, which is useful behavioral info. However, it doesn't mention whether this is a read-only safe operation, auth requirements, or the menu structure's mutability. With zero annotation coverage, more behavioral context would strengthen it, but the read-like nature of listing is reasonably 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?

  Single sentence, no filler, front-loaded with the core action and outcome. Every word earns its place; the parent-selection use case adds functional context without bloat.

  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?

  This is a simple parameterless listing tool with no output schema. The description explains the menu items include IDs and why you'd want them (parent selection). It's reasonably complete, but lacks mention of what subset of items is returned (full tree vs flat list) and whether the menu can be modified. For a listing tool with no schema, it's adequate but could be richer.

  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 0 parameters, and schema coverage is 100% (vacuously). No parameter description is needed, so the tool description doesn't need to compensate. A baseline of 4 is appropriate for a parameterless 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 states a specific verb+resource: 'Toon het menu (QuickLaunch) van de Academy met de id's per item' (Show the Academy menu/QuickLaunch with IDs per item). It clearly explains the purpose is to choose a parent to hang a page under, distinguishing its intent from sibling tools like academy_list_pages which lists pages.

  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 explains the use case—selecting a parent to attach a page under—which implies when you'd use this tool (before creating/adding menu items). However, it doesn't explicitly state when NOT to use it or contrast with alternatives like academy_add_menu_item. The guidance is contextual but lacks explicit exclusions.

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

• academy_add_menu_itemA
  4/5.0
  Behavior4/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 discloses that the page must already be published before use, and that pageUrl must be server-relative with a concrete example. The sequencing prerequisite is valuable. It doesn't disclose what happens on failure or whether existing menu items get overwritten, but given a simple 3-param tool this is reasonably complete.

  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?

  Three concise sentences, front-loaded with the primary action and key constraints. The concrete URL example is efficient. Slight inefficiency is that the language/dutch adds a little overhead, but each sentence 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 3-param tool with no output schema and no annotations, the description adequately explains purpose, parameters, sequencing, and relationships to sibling tools. It covers the main behavioral constraint (must publish first). Missing some detail like whether parentId is validated or what happens on invalid pageUrl, but overall adequate 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 description coverage is 0%, so the description must compensate for all three parameters. It does: title is mentioned as required, pageUrl explained with a concrete example and server-relative constraint, and parentId explained as coming from academy_list_menu to nest under a section. This fully covers all parameters despite empty schema descriptions.

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

  Purpose4/5

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

  The description clearly states the action: placing a published page into a menu ('Zet een gepubliceerde pagina in het menu'). It specifies the required parameters and the optional parentId. It distinguishes well from siblings like academy_list_menu (viewing the menu) and academy_publish_page (publishing the page). No explicit sibling named, but action is distinct enough.

  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 clear context for when to use it: after publishing ('Doe dit pas NA publiceren'), and references the sibling academy_list_menu for sourcing parentId. However, it doesn't explicitly name the alternative for creating/publishing pages or state when NOT to use it beyond the sequencing note.

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

• academy_list_pagesA
  4.4/5.0
  Behavior4/5

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

  The description states the tool is a read-only listing operation ('Lijst de pagina's op'), showing fields returned and its purpose (checking existence, fetching an id). With no annotations provided, the description carries the full burden, but for a simple parameterless read tool this is reasonably transparent. It doesn't describe pagination or sorting behavior, but that's minor for an id/name/title 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?

  One concise sentence in Dutch that efficiently communicates what the tool returns and why it's useful. No wasted words, clear structure.

  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 this is a parameterless read-only tool with a clear output of listed fields (id, name, title, webUrl), the description is complete enough. It names the exact fields returned, which serves as an implicit output schema since none is provided. The stated utility (checkening existence, retrieving id) gives sufficient context.

  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?

  There are 0 parameters with 100% schema description coverage, so the baseline is 4 for a parameterless tool. There is nothing to explain and the description correctly focuses on return values instead. The description actually captures the parameter-free nature implicitly by simple listing.

  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?

  Lists a specific verb+resource ('Lijst de pagina's op de Academy op') and names the exact output fields (id, name, title, webUrl). It clearly distinguishes from siblings like academy_list_menu (listing menu items) by explicitly being about pages. Clear, specific, and differentiated.

  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 when it's useful: 'Handig om te zien of iets al bestaat en om een id op te halen.' This gives clear usage context. It doesn't explicitly exclude alternatives or name siblings, but for a listing tool the intended use case is well conveyed. It does not say when not to use it, but its limited role is clear from the pages vs menu distinction among siblings.

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