Server Quality Checklist

Tool Scores

• get_lawC
  2.8/5.0
  Behavior1/5

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

  With no annotations, the description must carry the behavioral burden. It does not disclose whether the operation is read-only, what the response shape is, whether there are errors, or what 'GREEN' means. The name suggests retrieval, but the description itself offers no behavioral detail.

  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 short and front-loads the core resource before the args. The unexplained 'GREEN.' and odd capitalization slightly hurt clarity, but there is no fluff.

  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?

  With no output schema and no annotations, the description should explain return expectations and usage context. It only says the result is a freedom-of-information act with deadline rules and gives the id source; it does not describe response fields, errors, or how this relates to siblings like check_deadlines and get_authority. For a one-parameter geter this is below minimally 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?

  The schema only states that id is an integer and required; the description adds that it is a numeric law id and, more valuably, that it comes from get_authority(...)['laws']. Since schema description coverage is 0%, this provenance meaningfully supplements the schema.

  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 phrase 'One freedom-of-information act with its deadline rules' clearly identifies the resource and the relevant content, and the example ties the id to get_authority(...)['laus']. It lacks an explicit verb like 'retrieve', and 'GREEN' is unexplained, but an agent can infer this returns a single law by id.

  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 siblings like search_authorities, get_authority, or check_deadlines. The only usage hint is that the id comes from get_authority(...)['laws'], which explains parameter provenance rather than selection context.

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

• get_messagesB
  3.1/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 does disclose useful behavior: the result covers all messages and is ordered oldest first. However, it omits pagination/limits, error behavior, permissions, and any explanation of what 'YELLOW.' means, so the behavioral profile is incomplete.

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

  Conciseness3/5

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

  The core sentence is short and front-loaded, and the Args section is appropriately compact for one parameter. The dangling 'YELLOW.' does not earn its place and creates ambiguity, which prevents a higher score.

  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 one-parameter getter without an output schema, the definition conveys the basic return subject and ordering. It lacks detail on the message shape, failure modes, and the meaning of 'YELLOW,' leaving some uncertainty for an agent that needs to consume the response or handle errors.

  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 only parameter is described as 'numeric request id,' which essentially restates the schema's integer type and 'Request Id' title. Since schema description coverage is 0%, the description needed to add operational meaning such as where to obtain the id, constraints, or an example, and it does not.

  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 identifies a concrete operation and resource: it returns all messages for a request, oldest first. This is specific enough to separate it from sibling tools like get_request or list_attachments, though it does not name alternatives and the stray 'YELLOW.' marker is unexplained.

  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 'of a request' implies the intended context: use this when you need the message thread for a specific request_id. It gives no explicit when-not-to-use guidance and does not point to alternatives such as get_request for request metadata or list_attachments for files.

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

• list_attachmentsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description is the only source of behavioral info. It only states the resource; it does not disclose whether the operation is read-only, what is returned, or any side effects. The unexplained 'YELLOW.' label adds ambiguity rather than transparency.

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

  Conciseness3/5

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

  The definition is appropriately tiny and front-loaded. However 'YELLOW.' is an unexplained fragment that does not earn its place; without known tool conventions, it confuses more than it clarifies.

  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 one-parameter list operation, the essential call data is present and the prerequisite is stated. Yet without an annotations safety profile or output schema, the description should at least note that this lists metadata and that download_attachment is the sibling for retrieving content; that distinction 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 schema only provides title/type, and description coverage is 0%. The description compensates by explaining that message_id is the numeric id from get_messages, which gives provenance and reduces ambiguity enough for the sole parameter.

  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 identifies the resource ('attachments') and scope ('belonging to one message'), and the tool name supplies the 'list' verb. However, the sentence is a noun phrase and does not explicitly differentiate from download_attachment, so it is clear but not fully explicit.

  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 parameter line tells the agent to obtain message_id from get_messages, establishing a prerequisite and a minimal usage context. But it does not say when to prefer this over download_attachment or any other sibling, nor 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.

• get_requestB
  3.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 must carry the behavioral disclosure burden. It does convey an auth-related trait: 'public requests work without a token.' However, it does not explain what happens for non-public requests, whether the operation is read-only, error behavior, or rate limits. The 'YELLOW' label is only partially explained. Some useful behavioral context is present, but notable gaps remain.

  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 compact: a one-line purpose, a brief auth note, and an argument definition. Every sentence carries useful information and the core purpose is front-loaded. There is no redundancy with the schema.

  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 single-parameter getter, the description covers the essential call: what it returns and what parameter is needed. However, with no output schema and no annotations, it leaves out details about what 'in detail' includes, how non-public requests are authenticated, and possible failure modes. It is adequate for a basic call but not fully self-sufficient.

  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?

  With schema description coverage at 0%, the description adds the crucial semantic that 'id' is a numeric request id, going beyond the schema's bare integer type. It tells the agent which identifier to pass. It is minimal but sufficient for a single parameter.

  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 identifies the tool as returning a single FOI request's details ('One FOI request in detail'). This distinguishes it from list-oriented siblings like list_my_requests, though it does not explicitly name an alternative. The verb and resource are clear enough for an agent to understand 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 Guidelines2/5

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

  The description gives no guidance about when to use this tool versus siblings such as list_my_requests or search_authorities. It implies the agent should already have a request id, but it does not state that a prior lookup is needed or mention any exclusions or alternatives. This leaves usage context entirely to inference.

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

• check_deadlinesA
  3.8/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 disclosure burden. It usefully explains that froide stores no 'deadline expired' flag and that the value is computed from due_date against the current time, matching frontend behavior. This gives an agent useful context about why the result set is time-dependent.

  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 short and front-loaded with the essential meaning. The only minor issue is the unexplained 'YELLOW' label, which adds slight ambiguity but does not bloat the 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?

  Given that the tool takes no parameters and has no output schema, the description is sufficiently complete: it states what the tool returns and explains the deadline computation. It could mention return format or pagination, but those are not essential for a zero-argument listing tool.

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

  Parameters4/5

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

  The input schema has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because the description does not need to compensate for any schema gaps.

  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 identifies the tool's result as the user's open requests whose statutory deadline has passed, which distinguishes it from list_my_requests and get_request. It lacks an explicit verb like 'lists' or 'returns', but the meaning is unambiguous and matches the tool name.

  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 usage is implied: use this when you need to see open requests with expired statutory deadlines. However, it does not explicitly compare with sibling tools such as list_my_requests 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.

• get_authorityA
  4/5.0
  Behavior5/5

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

  With no annotations, the description carries the full transparency burden and it excels: it discloses that the API does not expose default_law, that the default is recomputed using a specific ordering, that it is almost always the meta law, and that this means the API cannot be used to file under a specific act. This is valuable behavioral information 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 first sentence front-loads the core purpose, and the rest is a tight caveat plus parameter note. The technical detail about froide's order_by is dense but earns its place because it explains why the tool behaves as it does. No unnecessary 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?

  For a one-parameter retrieval tool with no output schema and no annotations, this description covers the essential bases: what the tool returns, how the default law is computed, a key limitation, and the argument semantics. It could add explicit sibling routing or expected return structure, but it is 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 description coverage is 0%, so the description must compensate. It does so by defining id as 'numeric public body id', which adds real semantic meaning beyond the schema's generic integer title 'Id'. For a single-parameter tool, this is sufficient.

  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 it returns the full record for one public body, including its laws, and identifies the resource as a public body. It distinguishes itself from search_authorities by emphasizing singular retrieval, though it does not explicitly name the 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 Guidelines3/5

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

  Usage context is implied: use this when you need a complete record for a known public body by id. However, there is no explicit guidance about when to prefer this over search_authorities or get_law, and no stated exclusions beyond the filing limitation.

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

• list_my_requestsA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description discloses that the operation is read-only, requires a token with scope read:request, and is limited to the caller's own requests. That is meaningful behavioral context. It does not mention response format or pagination beyond the limit parameter, but for a simple list operation the core behavior is clear.

  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-loads the resource and safety profile, followed by two parameter lines. No filler or repetition of schema defaults.

  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 low-complexity list tool with no output schema, it covers purpose, auth, read-only behavior, and all parameters. It could additionaly state the shape of the returned request objects, but that is not essential for basic invocation.

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

  Parameters5/5

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

  Schema description cover age is 0%, yet the description compensates by explaining both parameters: status is an optional filter with concrete example values, and limit is the maximum number of results. This adds meaning the schema's titles and defaults alone do not provide.

  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 identifies the resource as the user's own FOI requests, which distinguishes it from siblings like get_request or search_authorities. It lacks an explicit verb, though the tool name 'list' carries the action. Overall clear and specific.

  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?

  It states the scope ('your own') and an authorization prerequisite, which gives context for when to call it. It does not explicitly name alternatives or say when not to use it, so routing to siblings is left to inference.

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

• validate_draftA
  4.1/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 transparency burden, and it does: offline rules R01-R16 always run, live rules L01-L04 require network and only run with dry_run=False, and dry_run=True does not touch the file. The main unknown is what happens if dry_run=False, but the key side-effect and network dependencies are disclosed.

  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 front-loaded with purpose, then behavior, then arguments, with no fluff. There is slight redundancy between the live-rules paragraph and the dry_run argument explanation, but it does not hurt readability.

  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?

  Invocation is well specified, but there is no output schema and the description never says what validate_draft returns or how the agent should interpret the result. Because no annotations or output schema exist, this is a meaningful gap.

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

  Parameters5/5

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

  Schema coverage is 0%, and the description fully compensates: path is explained as a YAML file path, and dry_run is described as controlling offline-only vs live execution, including the default and side-effect. This adds real meaning beyond the schema's bare names and types.

  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 opens with a specific action and object: 'Run the rule set against a draft,' which makes the tool's validation role clear and distinguishes it from sibling build/create/submit tools. It does not explicitly name or contrast a sibling tool, so it stops short of 5.

  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 concrete conditions for when offline-only vs live validation runs, directly explaining how dry_run changes execution. It omits an explicit 'use before submitting' statement and does not name alternatives, but the context is clear enough.

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

• search_authoritiesA
  4.3/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 and explicitly discloses 'no auth, no side effects,' which is critical behavioral information. It also reveals the API-only-id caveat for jurisdiction. It could go further by describing the response shape, but the safety and side-effect profile is 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?

  Every sentence is purposeful: the opening states the action, the GREEN tag summarizes safety in one token, and each parameter gets a compact line with no redundancy. The most important operational detail is front-loaded.

  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 three-parameter read-only search, the description covers the service, auth, side effects, and each parameter, including the jurisdiction id conversion caveat. It does not explicitly state the return shape, which would be more important here because no output schema exists, but the gap is 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.

  Parameters5/5

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

  The input schema provides only names, types, and defaults, so the description must add meaning. It fully compensates: query gets a free-text explanation with examples, jurisdiction gets accepted formats and the API-only-id constraint, and limit gets its maximum-result meaning plus the server page-size hint. This gives an agent everything needed to construct arguments 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 opens with a specific verb and resource: 'Search public bodies on fragdenstaat.de.' This clearly identifies it as a discovery/list-search tool and distinguishes it from siblings like get_authority, which implies direct retrieval. The scope 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 Guidelines3/5

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

  The description implies the tool should be used when an agent needs to find public bodies by free-text, but it does not explicitly state when not to use it or name alternatives such as get_authority for known IDs. The GREEN safety note adds operational context but not routing guidance.

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

• build_submit_urlA
  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 behavioral disclosure burden and does a good job: it discloses the 4096-byte GET URL limit, the two-step sidecar fallback, and dry_run side-effect. It does not fully specify the return contract, but the core behavioral traits are clearly revealed.

  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 front-loaded with the summary and then gives the critical constraints and parameter docs. Every sentence carries information, including the measured URL-length limit that explains the side-car behavior.

  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 two-paramter tool with no annotations and no output schema, the description covers purpose, key constraints, side effects, and parameter semantics. It leaves the exact return format implicit, but the core workflow is sufficiently 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 description coverage is 0%, so the description must document parameters, and it does: path is explained as a draft YAML file path, and dry_run's default and side-effect are described. This adds real meaning beyond the bare schema fields.

  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 the specific verb+resource: "Build the prefilled web form URL," and positions it as the recommended route. It also distinguishes it from the REST API by noting it is the only route where legal basis can be chosen, so an agent can tell it apart from related tools.

  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?

  Gives explicit guidance: it is the recommended way out, the only route that supports law_type, and sending stays with the human. It implicitly warns against using the REST API for this purpose, though it does not name a specific sibling alternative for automatic submission.

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

• check_jurisdictionA
  4.6/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, and it delivers: it explains the resolution algorithm, the stopping rule ('first level that yields any authority'), why that rule matters, and what happens at wider levels ('reported by id only'). It also discloses the default behavior of include_wider and its rationale, giving substantial behavioral context.

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

  Conciseness4/5

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

  The description is compact and front-loaded, moving from purpose to algorithm to example to parameters. Every section earns its place, though the initial 'GREEN —' fragment is cryptic and slightly distracting without explanation. Overall it is efficiently structured with little 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?

  Given the absence of an output schema and annotations, the description explains the input semantics, the algorithm, the stopping condition, and the nature of the returned evidence trail. It does not specify the exact response structure or edge cases such as unknown places or levels with no authorities, so it is strong but not fully exhaustive.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description fully compensates: place_name is defined as 'name of the municipality, district or state', and include_wider is explained semantically ('also list the authorities of the wider levels') plus its default and why it defaults to false. This adds real meaning beyond the raw schema titles.

  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 the precise question 'Which authority covers a given place?' and then explains the resolution mechanism by walking the georegion and publicbody hierarchy. This clearly identifies a specific verb+resource behavior and distinguishes it from sibling tools like search_authorities or get_authority by focusing on place-to-jurisdiction resolution rather than keyword search or direct lookup.

  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 case: determining the responsible authority for a municipality, district, or state, with a concrete Rhineland-Palatinate example. It also explains when include_wider is inappropriate ('at country level that is thousands of bodies'), but it does not explicitly name alternatives or state when not to use this tool versus search_authorities.

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

• download_attachmentA
  4.6/5.0
  Behavior5/5

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

  With no annotations at all, the description carries the full burden and handles it well. It labels the operation as read-only, warns that it writes a file locally, explicitly says it will not create directories, and explains the security rationale along with the FDS_MCP_DOWNLOAD_DIR confinement option. This is substantive behavioral context beyond the schema or annotations.

  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 one-sentence purpose is front-loaded and the Args list is terse. The second paragraph is longer, but it earns its length by explaining a real path-injection risk and the recommended confinement mechanism, so it is not padding.

  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 two-parameter download tool, the description covers purpose, input source, directory preconditions, and safety configuration. It omits details like return values or overwrite behavior, but those are minor for a download operation and no output schema exists to supply them.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description fully compensates: attachment_id is explained as the numeric id from list_attachments, and target_dir is explained as an existing local directory with a usage constraint. Both required parameters receive meaning beyond their bare types.

  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 the verb, resource, and destination clearly: 'download one attachment into a local directory.' It also identifies the attachment_id source as list_attachments, so an agent can distinguish this tool from sibling listing and request tools 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?

  It gives explicit preconditions: target_dir must already exist, and the tool will not create a path. It also points to attachment_id as coming from list_attachments, which tells the agent where to get its input. It does not name alternatives, but no sibling tool performs the same download function, so the preconditions are sufficient guidance.

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

• create_request_draftA
  4.8/5.0
  Behavior5/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 does so thoroughly. It discloses that no network traffic occurs, that the file begins with status 'draft' and a placeholder confirmation token, that a human must approve/replace the token, and that dry_run returns the draft without writing the file.

  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 front-loaded with the most critical facts (local draft, no network, human approval required), followed by a compact Args list. Every sentence adds value; the length is justified by the 14 parameters it documents.

  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?

  Despite having no annotations or output schema, the description gives the agent everything needed to call the tool correctly: the purpose, the safety profile, the approval workflow, parameter constraints, and dry_run behavior. Nothing essential is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the Args list describes all 14 parameters with useful semantics: constraints (subject 8-230 chars, body max 5000), meanings ('public' means CC0), options (submit_via choices), and cross-tool references (law_api_default_id -> get_authority()). This fully compensates for the bare 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 opens with a specific verb and resource: 'Write a local YAML draft', which clearly distinguishes this from submission, validation, or retrieval tools. It further clarifies scope with 'performs NO network traffic at all' and explains this is a preparatory step before a human approves and submits.

  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 clear context for usage: this is a local, network-free drafting step that requires human approval before submission. It does not explicitly name alternatives or exclusion conditions, but the workflow context ('before anything can be submitted') makes the intended position in the process clear.

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

• submit_requestA
  4.8/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 full responsibility for behavioral disclosure. It clearly states that the action is IRREVERSIBLE, sends immediately, has no draft/preview/undo, and enumerates the exact gate conditions that control whether the request is actually submitted. This is unusually complete.

  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 long but every sentence carries necessary safety-critical information. The irreversibility warning is front-loaded, the gates are listed in a clear numbered order, and the parameter explanations are tightly integrated rather than repeated from the schema.

  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 high-risk, irreversible submission tool with no annotations and no output schema, the description covers the essential context: preconditions, gate order, parameter constraints, safety default behavior, and the fact that no undo is possible. Nothing needed to decide whether and how to invoke it is missing.

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

  Parameters5/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 explain the parameters itself. It does: path is the approved draft YAML file, confirmation_token must match the value inside that draft, and dry_run defaults to true and prevents any sending. Every parameter is given meaningful semantics beyond its bare schema 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 names a specific action ('POST the request'), a target resource ('fragdenstaat.de'), and a clear scope ('sends the e-mail to the authority immediately'). It also distinguishes itself from sibling draft/build/validate tools by emphasizing this is the actual irreversible submission step, not a draft or preview.

  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 strong contextual guidance: the five gates must agree before submission, and dry_run is presented as a safe way to test every gate without sending. It does not explicitly name sibling alternatives such as validate_draft or build_submit_url, so the when-not-to-use guidance is implied rather than fully explicit.

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

• build_reply_draftA
  4.9/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, and it does so thoroughly. It discloses that the tool only reads and never sends, that no argument changes this, that the API contract was verified, and that follow-up validation differs from request validation. This is exceptionally transparent about side effects and constraints.

  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 front-loaded with the key purpose and safety statement, followed by behavioral context and a structured Args section. It is long but information-dense; some of the API-test evidence could be shortened, but it does earn its place by substantiating the 'sends nothing' claim.

  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 tool with no annotations and no output schema, the description is remarkably complete. It explains what the tool does, what it returns conceptually, validation rules, parameter semantics, the file-writing side effect, and the hard limit that sending is impossible through the API. No critical decision-relevant information appears to be missing.

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

  Parameters5/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 fully compensate for every parameter. It does: request_id is explained as the numeric id of an existing request, text must include salutation and closing formula, subject has a documented default, and path is described with its exact purpose and file behavior. This adds substantial meaning beyond the bare 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 starts with a specific verb and resource: 'Prepare a follow-up message to an authority.' It immediately clarifies the key behavioral distinction from sibling tools: 'reads the API, sends nothing.' It also names itself as the counterpart of build_submit_url, which clearly differentiates it from related tools.

  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?

  The description explicitly frames this tool as being for an existing request, in contrast to build_submit_url. It also gives a clear exclusion: replying is not possible through the API at all, so no tool argument can turn this into a send. The path parameter is explicitly tied to the condition of later using send_reply_via_browser, which gives clear when-to-use guidance.

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