Server Quality Checklist

Tool Scores

• find_nearest_mosquesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description adds the behavioral trait of injecting map routing strings. However, it does not disclose permissions, rate limits, or whether it is read-only, leaving gaps for a search tool.

  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 concise sentences front-load the purpose and key feature. No extraneous text, though it could benefit from a structured parameter list.

  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?

  Despite an output schema, the description lacks detail on return format beyond routing strings. With no parameter descriptions and no annotations, important context like how to specify location is 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%, yet the description only indirectly references the distance_km parameter via 'target search radius'. No explanation of location_name, latitude, longitude, or default values.

  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 it finds verified mosques/masjids/suraus within a radius and injects map routing strings. It is distinct from sibling tools (prayer times and events) with a specific verb and resource.

  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 (find mosques near a location) but no explicit when-to-use, when-not-to-use, or alternatives are given. The sibling tools are different, but no guidance on choosing between them.

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

• get_yearly_islamic_eventsB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden. It discloses the default-year behavior but fails to mention that location parameters (location_name, latitude, longitude) could affect the events returned. No disclosure on permissions or response structure.

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

  Conciseness5/5

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

  Two sentences with no fluff. Every word serves a purpose. The default-behavior detail is well placed.

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

  Completeness3/5

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

  Given 0 required parameters and existing output schema, the description is minimally adequate. But it omits explanation of location parameters and the nature of 'milestones,' which would be helpful for a complete understanding.

  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%, but the description only adds default value info for target_year. It does not explain the purpose or effect of location_name, latitude, or longitude, leaving their meaning ambiguous.

  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 tool retrieves 'significant Islamic calendar milestones for a target year' and mentions defaulting to current year. This specific verb+resource structure distinguishes it from sibling tools like find_nearest_mosques and get_monthly_prayer_times.

  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 notes defaulting to current year, providing some usage context, but does not explicitly state when to use this tool over alternatives or when not to use it. Since siblings are clearly different, the implication is sufficient but not explicit.

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

• get_monthly_prayer_timesA
  3.9/5.0
  Behavior3/5

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

  Without annotations, the description must reveal behavioral traits. It mentions computing Dhuha intervals and normalizing Hijri months, but does not disclose rate limits, data freshness, or whether it is read-only. No contradictions with annotations since none provided.

  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 concise with two sentences plus a usage instruction. It front-loads the main action and every sentence adds value. Minor improvement could be better structuring parameter relationships.

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

  Completeness3/5

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

  Given the output schema exists (not shown), the description covers purpose and usage scenarios adequately but lacks detail on parameter semantics and edge cases (e.g., conflicting inputs). Overall sufficient but not thorough.

  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%. The description mentions GPS coordinates or location name, partially covering location_name, latitude, longitude, but does not explain month and year parameters or their optionality/format. Parameter semantics are inadequately conveyed beyond a high level.

  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 tool fetches comprehensive monthly prayer times based on GPS coordinates or location name. It specifies computing Dhuha intervals and normalizing Hijri months, distinguishing it from siblings like find_nearest_mosques and get_yearly_islamic_events.

  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 instructs to use this tool whenever the user asks for today's prayer times, this week's schedule, or a specific month's schedule. This provides clear context for when to invoke it.

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

• get_current_timeA
  4.3/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 only states the basic function. It does not disclose any behavioral traits such as rate limits, authentication requirements, or whether the tool is read-only. For a simple time-fetch, this is adequate but minimal, hence a score of 3.

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

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the core purpose. Every sentence earns its place: first defines what it does, second gives usage context, third distinguishes from siblings. No extraneous information.

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

  Completeness3/5

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

  Given no output schema, the description does not explain the return format or content. It would be more complete if it mentioned the time format (e.g., ISO 8601) or any additional details. However, the context signals indicate a simple tool with no parameters, and the description provides adequate context for when to use it relative to siblings.

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

  Parameters4/5

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

  The tool has zero parameters, and schema description coverage is 100%. The description adds no parameter information because there are none. For zero-parameter tools, the baseline is 4. The description does not need to add anything beyond what the schema 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?

  Clearly states 'Returns the current server UTC time'. The verb 'returns' and resource 'current server UTC time' are specific. Distinguishes from sibling tools by specifying that for Hijri date, other tools should be used.

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

  Usage Guidelines5/5

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

  Explicitly states when to use: 'when the user asks about current prayer status, time remaining to next prayer, or any query that requires comparing current time against prayer times'. Also specifies when not to use and provides alternative tools (get_monthly_prayer_times, get_yearly_islamic_events) for Hijri dates. This provides clear guidance and differentiation from siblings.

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