belong-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resources and actions, with clear descriptions for each. Some similar-sounding tools (e.g., list_flats vs list_flats_by_occupancy, get_announcements vs list_community_feeds) exist but are still separable by their parameters and purpose.
Naming Consistency3/5
All tool names use snake_case and mostly follow a verb_noun pattern, but there is a mix of verbs (get, list, search, check, request, verify) that isn't always predictable. For example, 'get_towers' returns a list while 'list_flats' is also a list, and 'search_vehicles' breaks the get/list convention.
Tool Count2/5
With 45 tools, the set is far too large and will be difficult for an agent to navigate efficiently. Even a broad domain like community management can be covered with fewer, more generalized endpoints.
Completeness2/5
The tool surface is heavily read-focused, covering retrieval of bookings, issues, vehicles, financials, etc., but lacks any create/update/delete operations (except OTP auth). There are no tools to book an amenity, raise a complaint, approve a visitor, or update a profile, leaving many common workflows incomplete.
Average 3.5/5 across 45 of 45 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 only states the basic lookup operation and does not disclose whether it is read-only, any permission requirements, what happens with invalid resident IDs, or the structure of the returned data. This is insufficient for a tool with no other 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 a single concise sentence with no redundant content. It is appropriately brief, though 'look up' is a generic verb; still, it earns a solid score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature but no output schema, and the description does not explain the return value, error behavior, or how resident IDs are matched to flats. Given the lack of supporting structured data, the description is insufficient for full understanding.
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 provides full descriptions for both parameters (comma-separated resident IDs and internal project ID), so the description adds little beyond restating the criteria. It does not introduce new parameter details or clarify relationships, so the baseline score is appropriate.
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 the verb 'Look up' with resource 'flats' and specifies the criteria 'specific resident IDs within a project', which distinguishes it from siblings like list_flats or list_flats_by_occupancy. However, it does not explicitly name alternative tools, so it falls short of a perfect score.
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 such as list_flats or get_flat_access. The description only states what it does, not when to choose it, and no exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that service types are listed; it does not disclose pagination behavior, ordering, return format, or whether any filters apply. While the operation is likely safe (a read), the description gives no such assurance.
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, efficient sentence with useful examples—no wasted words. It could be more informative, but as a concise statement it performs well.
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, optional-pagination list tool, the description provides the essential purpose but omits any mention of pagination (despite schema having it) or the return shape. Given the tool's simplicity, the description is adequate but not comprehensive; a couple of extra details would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (page, items) with descriptions and defaults, so the schema carries the semantic weight. The description adds no parameter information, but the baseline of 3 applies due to 100% schema coverage.
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's function with a specific verb ('List') and resource ('service types'), and the parenthetical examples ('maid, cook, driver') further clarify the resource. However, it does not explicitly distinguish this tool from sibling list tools, though the examples implicitly do.
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 usage guidance is provided—there is no mention of when to use this tool versus other list tools, no prerequisites, and no context such as 'use to populate service type dropdowns'. This is a minimum-viability gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 restates the tool's name and does not explain pagination behavior, what 'available for chat' means, authentication requirements, or any side effects. This is a minimal description with no added 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. No redundant words or rephrased schema content.
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 list tool with full schema coverage, the description is minimally sufficient. However, the lack of an output schema and details about the response structure or the meaning of 'available for chat' leaves some ambiguity, making it a baseline rather than a complete description.
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 schema already documents all parameters. The description adds no further meaning about how parameters should be used or combined, but the baseline of 3 applies since the schema is self-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 states a specific action ('List') and resource ('residents available for chat') with a scope ('in a project'), making the purpose clear. However, it does not distinguish this from the sibling tool 'list_chat_flat_residents', which may cover a similar or overlapping use case.
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. The context is implied (list chat-enabled residents for a project), but no exclusions or references to sibling tools are provided, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'Get the community feed posts', which implies a read operation but provides no additional behavioral information such as pagination behavior, ordering, authentication requirements, or result format limits. This is minimal disclosure.
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 short sentence that communicates the core function without any wasted words. It is front-loaded and easily parsed, making it an example of effective conciseness.
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 list operation with two optional parameters, the description is minimally viable but lacks contextual depth. It does not explain pagination behavior, what fields are returned, or any edge cases. Given the absence of an output schema and annotations, more context would help, but the tool is simple enough that this is not severely deficient.
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 input schema already provides 100% coverage with descriptions for 'page' and 'items'. The tool description does not add any extra meaning beyond what the schema states, so the baseline of 3 applies. It neither conflicts with nor enhances 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 description 'Get the community feed posts' uses a clear verb ('Get') and a specific resource ('community feed posts'), which makes its function understandable. However, it does not explicitly differentiate from sibling tools like list_service_staff_bookings or get_announcements, except by naming the unique resource. It is clear but lacks an explicit scope or contrast with other list tools.
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 on when to use this tool versus alternatives. It does not mention any prerequisites, context, or mention that other tools might be more appropriate for different feed-related queries. With many sibling list tools, this absence of usage context is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, but it only states a list operation. It does not mention pagination behavior, default sorting, authentication/authorization requirements, how the stats_type parameter alters results, or any side effects. The 'raised by the resident' scoping is the only behavioral context 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 a single, concise sentence that immediately conveys the core purpose. It is front-loaded and contains no filler. While it is minimal, it is appropriately sized for a simple listing tool and earns its place by clarifying the scope of issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations, so the description must compensate. It only provides the basic list purpose and does not address filtering semantics, result shape, or the meaning of stats_type in the context of maintenance issues. The description is insufficient for an agent to fully anticipate tool behavior.
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 each parameter is already described with types and meaning. The tool description adds no extra semantic value beyond the schema, which is acceptable per the baseline of 3. The parameters are straightforward (page, items, status, stats_type) and well-documented in the 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 uses a specific verb 'List' and resource 'maintenance issues/complaints' with a clear scope 'raised by the resident'. This distinguishes it from sibling tools like list_issue_categories and get_issue_stats, making the tool's purpose unambiguous.
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 provides no explicit guidance on when to use this tool versus alternatives. There is no mention of alternatives, prerequisites, or scenarios where another list_* tool would be more appropriate. The 'raised by the resident' scope offers a slight hint, but it does not frame selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It does not mention that the operation is read-only, indicate pagination behavior, or note any permissions or side effects. The one-line description offers minimal insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, effectively front-loading the core purpose. Every word adds value, and the example aids comprehension without unnecessary length.
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 list tool, the description gives the essential purpose but lacks any mention of the return structure or pagination details. Given the absence of an output schema and annotations, the description is only minimally complete, leaving some ambiguity about what data is returned.
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 schema already documents all parameters. The description adds the example 'delivery services' to clarify the meaning of 'visitor category', slightly enriching the context, but it does not substantially enhance the parameter semantics beyond what the schema provides.
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 ('List') and resource ('companies/brands under a visitor category') with an illustrative example ('delivery services'). This clearly conveys the tool's function, though it does not explicitly distinguish it from sibling tools like 'list_external_services'.
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 or any exclusions. The description only states what it does, not when it should be preferred over related list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'List', implying a read operation, but doesn't specify pagination behavior, data included, ordering, or any access requirements. The description adds no behavioral context beyond what the one-word verb implies.
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, front-loaded sentence with no waste. It effectively communicates the essence without unnecessary detail, scoring high on conciseness.
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 no output schema and no annotations, the description is too sparse to be fully complete. It lacks information about the response structure, default sorting, or any limitations. While the schema covers parameters, the description doesn't provide enough context for the AI to understand what will be returned or how the list behaves.
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 input schema fully describes all three parameters (flat_id, page, items) with clear descriptions, giving 100% coverage. The description repeats the flat scope but adds no additional semantic meaning about parameters or their use. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('community announcements') with scope ('for a flat'), making the tool's purpose unmistakable. It distinguishes itself from similar list tools like list_community_feeds by emphasizing announcements targeted to a flat.
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 provides no guidance on when to use this tool over alternatives. It doesn't mention any exclusions, prerequisites, or relationships to sibling tools like list_community_feeds or get_banners. The AI agent is left without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the output categories but does not explain how the optional 'range_type' parameter affects results, whether a default range is applied, or the exact return format. This is a significant gap for safe and correct invocation.
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, front-loaded sentence that names the verb and resource without waste. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple design (one optional parameter, no output schema), but the description lacks details about parameter behavior and return structure. The agent cannot fully understand what the response will look like or how range_type influences the counts, making the description incomplete for correct invocation.
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 provides a clear description and enum for the single 'range_type' parameter. The tool description adds no additional semantics about the parameter, so it receives the baseline score of 3 for high schema coverage.
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 retrieves visitor entry statistics with specific counts (approved, completed, request_approved). It distinguishes the tool by listing the specific stats, though it does not explicitly name alternative sibling tools for different use cases.
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 by the name and the word 'statistics' – one would use this tool when needing entry counts. However, there is no explicit guidance on when to choose this over sibling tools like get_visitor_approvals or get_approvals_count, nor any exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only restates the purpose and date range, without mentioning pagination behavior, result ordering, what transactions are included/excluded, or any authentication/read-only aspects.
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 that immediately conveys the tool's core function with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for an agent to fully understand the tool's behavior. It lacks details on return format, pagination behavior, and how to distinguish this from related tools, especially given the absence of an output schema and 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?
The schema fully documents all four parameters with types, defaults, and formats. The description only reiterates the date range, adding no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves financial transaction history, specifying the content (maintenance bills, payments) and the date range scope. It uses a specific verb 'Get' and resource, distinguishing it from stats or demand-note tools among siblings.
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 provides no guidance on when to use this tool versus alternative financial tools like get_invoice_stats or list_demandnote_requests. It does not mention exclusions or prerequisites, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the listing action and does not mention pagination behavior, response format, or any side effects. The schema hints at pagination via page/items, but the description adds no context.
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, front-loaded sentence with no unnecessary words. It clearly conveys the tool's purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse. It does not explain what 'available for chat' means, how pagination works, or what the response contains. For a simple list tool, more context is needed to fully equip an agent.
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. The description does not add meaning beyond the schema; it only echoes the tower context already present in the tower_id param.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (wings/sections), and the context (available for chat in a tower). It distinguishes from sibling tools that list chat-enabled residents or flats.
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 like list_chat_enabled_residents or list_chat_flat_residents. The description implies the use case but does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior alone. It states the tool returns closed and in_progress counts but fails to explain how range_type affects results, whether additional stats are returned, or any output structure. Minimal disclosure.
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 succinct sentence with no filler. Well-structured and front-loaded with the main verb and resource.
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?
The tool is simple, but the absence of an output schema means the description should clarify the response format and the effect of range_type. The parenthetical gives some hint but leaves ambiguities about whether counts are aggregated by time period.
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 provides full description for the sole parameter (range_type with 'Time range'), and the description does not add any extra semantic detail beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing issue statistics with specific counts (closed, in_progress). This distinguishes it from sibling tools that list issues or categories, making the purpose unambiguous.
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 provided about when to use this tool versus alternatives like get_booking_stats or list_maintenance_issues. The description simply restates the function without any contextual or exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the 'active' filter but does not explain pagination behavior, data scope, or any side effects. The read-only nature is implied but not explicit.
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, concise sentence that states the core function without wasted words. It is appropriately sized for a simple list operation.
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 straightforward list tool with complete schema coverage, the minimal description is borderline adequate. It lacks context on what defines 'active' and the structure of the returned list, but given no output schema, some of this is implied.
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% with clear descriptions for 'page' and 'items'. The description adds no additional parameter semantics, but the schema already fully handles them, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and the resource ('active campaigns/promotions'). This is specific and distinguishes it from sibling tools by the resource, even without explicit comparison.
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 provided on when to use this tool versus alternatives. It does not mention filtering options, prerequisites, or exclusions beyond the 'active' status. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 disclosing behavioral traits. It only states that the tool lists residents, without mentioning pagination (despite page/items parameters), response format, or whether 'chat purposes' implies filtering to chat-enabled residents. This lack of additional context leaves significant ambiguity for the agent.
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, concise sentence with no filler words. It articulates the core function efficiently without redundancy, earning a high score for conciseness and structure.
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?
The tool has 3 parameters (one required), no output schema, and no annotations. The description is minimal but adequate for a straightforward listing operation. However, it leaves gaps: pagination behavior is not mentioned, the meaning of 'for chat purposes' is ambiguous (e.g., does it filter to chat-enabled residents?), and there is no mention of what fields are returned. Given the simplicity, a score of 3 reflects a minimally viable but incomplete description.
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%, meaning all parameters (floor_id, page, items) already have descriptions in the schema. The tool description adds no extra meaning beyond the schema, but does not need to compensate given the high coverage. The mention of 'specific floor' maps to floor_id, but this is not additional semantic insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('residents') with a clear scope ('on a specific floor') and purpose ('for chat purposes'). This distinguishes it from sibling tools like list_chat_enabled_residents and list_flats, making the tool's intent immediately understandable.
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 provides no guidance on when to use this tool versus alternatives. For example, it does not clarify whether this should be used instead of list_chat_enabled_residents when targeting a specific floor, or how it relates to list_chat_wings. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 disclosing behavioral traits. It states the action ('List') but does not mention whether this is a read-only operation, any authentication requirements, or potential side effects. It also doesn't clarify pagination behavior or that results are sorted/ordered in any way.
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 concise sentence with a helpful parenthetical. It is front-loaded with the verb and resource, contains no redundant information, and every word earns its place. This is an model of brevity.
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?
The tool is a simple list operation with well-documented parameters, but there is no output schema and the description doesn't mention what the response contains (e.g., fields, pagination metadata). Given the simplicity, the lack of return-type detail is a minor gap, but the description is not fully self-contained for an agent.
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 100%, with each parameter (page, items, status) having a description. The tool description itself adds no parameter semantics, but the schema already provides sufficient meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a specific resource 'demand note requests', with a clarifying parenthetical 'payment demands from management' that distinguishes it from other list tools in the sibling set. This makes the tool's purpose unambiguous.
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 on when to use this tool versus alternatives. It doesn't mention any filtering or search alternatives, nor does it provide context about when this list is appropriate. The parenthetical gives a hint about the domain but is not explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 basic action and does not mention pagination behavior, output format, or any potentially surprising side effects. The presence of page/items parameters is not acknowledged, leaving the agent without information about how results are returned or limited.
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, concise sentence that directly communicates the tool's purpose. It avoids unnecessary words and front-loads the essential information, making it highly efficient.
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 read-only listing tool, the description is functionally adequate, but it lacks detail about the response structure and pagination behavior that the params suggest. With no output schema and no annotations, the agent relies solely on the description, which is minimal but not misleading. It could be improved by noting that results are paginated via page/items or by providing a sample response.
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 input schema already provides complete descriptions for both parameters (page and items), achieving 100% schema_description_coverage. The description adds no extra parameter detail, but the baseline of 3 is appropriate since the schema handles the semantics adequately.
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's function with a specific verb ('List') and resource ('available languages'), making it unambiguous and distinct from sibling tools that list other entities (e.g., flats, vehicles). It conveys exactly what the tool does without vagueness or tautology.
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 provides no guidance on when to use this tool versus alternatives. While it's implied that one would use it to fetch languages, there are no explicit context cues or exclusions, and the many sibling list tools are not differentiated beyond their names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the core listing behavior but does not mention pagination behavior, potential empty results, or any additional context beyond the schema fields.
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 concise sentence that states the essential purpose without any redundant or 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?
For a simple listing tool, the description is minimally sufficient, especially with a fully documented schema. However, it lacks return-value context and does not clarify how this tool fits with search_vehicles, making it less complete for an agent deciding between similar endpoints.
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 applies. The description adds 'registered to a flat' which aligns with flat_id, but does not enrich the semantics of page, items, or vehicle_type beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'vehicles registered to a flat', making the action and scope immediately obvious. This distinguishes it from sibling tools like list_vehicle_brands and search_vehicles.
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 provided on when to use this tool versus search_vehicles or other list endpoints. There are no prerequisites, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. It only states the basic function and gives no information about pagination, status filtering, ordering, permissions, or error behavior. This is insufficient for a tool with four parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that is front-loaded with the core purpose. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations, making the description the primary source of context. It is too terse, omitting guidance on pagination, status filtering, return value structure, or how this tool fits among the many list siblings. An agent would need to infer too much.
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. The description does not add any parameter-specific meaning beyond what the schema already provides; it only gives examples of amenity types. It neither clarifies the flat_id requirement nor explains the status enum 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 states a specific verb ('List'), resource ('amenity bookings'), and scope ('for a flat'), with examples of amenity types. It distinguishes itself from the sibling tool 'list_service_staff_bookings' by focusing on amenity bookings rather than staff bookings.
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 is implied from the name and description, but there is no explicit guidance on when to use this tool versus alternatives. The sibling list includes related tools like 'list_service_staff_bookings', but the description does not mention when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 merely states 'List', implying a read operation, but does not mention pagination behavior, ordering, response format, authentication needs, rate limits, or any side effects. This is a significant gap for a tool with zero annotations.
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 concise sentence of ten words. It is front-loaded with the action word 'List' and includes the key resource and scope. There is no redundancy, and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should provide more context about what the response contains, pagination limits, or any conditions. It is a bare one-liner that tells the core purpose but does not explain the shape of results or any non-obvious behavior. For a list tool with pagination parameters, this feels incomplete.
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 input schema has 100% description coverage for all three parameters, including 'page', 'items', and 'requested_project_id'. The description adds no extra meaning beyond the schema, but the schema already provides the necessary context (page/items with defaults, internal project ID). Thus baseline 3 is appropriate.
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 specific action (List), the resource (RWA committee members), and the context (for a project). This distinguishes it from sibling tools, which are mostly about other entities like flats, visitors, or vehicles. The verb and resource are 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 usage is implied: use this tool to retrieve RWA committee members for a project. However, there are no explicit when-to-use or when-not-to-use instructions, no mention of alternatives, and no prerequisites. It provides only minimal context, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It claims to 'list all available vehicle brands,' but the pagination parameters in the schema suggest results are page-based, which is not disclosed. The read-only nature and any rate limits or authentication requirements are also not mentioned.
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 concise sentence that is front-loaded with the primary action and resource. Every word is necessary, and there is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is too minimal. It does not mention pagination behavior, response structure, or any filtering options, leaving the agent uncertain about the return format and the effect of the page and items parameters.
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 coverage is 100%—both the 'page' and 'items' parameters have descriptions. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and explicitly names the resource 'available vehicle brands,' making the tool's function immediately clear. It also distinguishes itself from sibling tools like list_resident_vehicles and search_vehicles by focusing specifically on the brand catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and description: use it when you need the complete list of vehicle brands. However, there is no explicit guidance on when not to use it or how it compares to related tools like search_vehicles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get', implying a read operation, but does not disclose permissions, response format, pagination behavior, or any side effects. This is a significant gap for a tool with no other behavioral annotations.
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, efficient sentence with no wasted words, front-loading the action and resource. It is appropriately sized and structured.
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 lack of an output schema, the description does not explain what the activity/history response contains or any pagination details. For a simple getter tool with well-documented params, it is minimally sufficient but leaves gaps.
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 input schema already covers all 3 parameters with descriptions (100% coverage), so the description adds minimal value beyond reinforcing flat_id via 'for a flat'. It does not elaborate on page/items semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource as 'buggy ride activity/history' scoped to 'a flat', clearly distinguishing it from sibling tools like list_buggy_stops or other list/get tools.
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 'for a flat' implies the tool is used when activity for a specific flat is needed, but there is no explicit guidance on when to use it versus alternatives, nor any exclusions or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a read operation ('Get') but does not disclose return format, permission requirements, or potential side effects. The parenthetical hint about the setting is minimal context but lacks explicit detail.
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, front-loaded sentence with no fluff. It efficiently conveys the tool's purpose and key nuance in under 10 words, earning every character.
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?
The tool is simple (zero parameters, no output schema), but the description does not explain the return value format. The parenthetical hints at a boolean setting, but without an output schema or annotations, the agent is left guessing about the exact response structure. This is adequate for a trivial getter but has a clear gap.
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, which warrants a baseline of 4. The description adds value by clarifying that 'delivery preferences' refers to the auto-approve setting, providing semantic context beyond the empty 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 clearly states the tool gets 'delivery preferences' and clarifies the specific setting ('auto-approve deliveries setting'). This distinguishes it from sibling tools like get_visitor_approvals or get_approvals_count, which relate to different domains.
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 provided on when to use this tool versus alternatives. The description simply states what it does, leaving the agent to infer usage context without any exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It lists expected output fields but does not mention whether the operation is read-only, any authentication requirements, data scoping, error conditions, or response format. The 'get' prefix implies read-only but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and uses a colon to efficiently enumerate key result fields. Every word adds value with no redundancy or filler.
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 zero-parameter tool, the description is minimally viable: it names the operation and the key fields. However, with no output schema or annotations, it lacks details on the response shape (single object vs. list), any time or user scoping, and any prerequisites. Some context is missing but the core intent is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter meaning, and it does not attempt to add any parameter-related information. The listed fields are output semantics rather than parameter semantics.
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 tool's specific purpose with a clear verb ('Get') and resource ('invoice summary'), followed by the exact fields returned (total unpaid, payable amounts, interest, closing balance). This clearly differentiates it from other stats tools like get_entry_stats or get_issue_stats.
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 provided on when to use this tool versus alternatives such as get_financial_ledger or list_demandnote_requests. The description only states the function without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states 'List', without adding context about pagination behavior, response format, or any potential side effects. For a read-only list tool, this is minimal but does not contradict anything.
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, front-loaded sentence with no unnecessary words. It conveys the core purpose efficiently without redundancy.
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 tool's simplicity and the fully documented schema, the description is minimally adequate. However, without annotations or an output schema, it lacks guidance on when to use it or what the return structure looks like, leaving some gaps for an agent.
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 input schema has 100% coverage for parameter descriptions, so the description does not need to add parameter meaning. The schema adequately explains project_id, page, and items, and the description adds no extra semantics beyond the 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 'List towers/buildings in a project' uses a specific verb and resource, clearly identifying what the tool does and its scope. It distinguishes from sibling tools like list_flats, which focus on flats rather than towers/buildings.
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 'in a project' implies the tool is intended for retrieving towers tied to a specific project, but there is no explicit guidance on when to use this tool versus alternatives like list_flats. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the basic retrieval operation without disclosing pagination behavior, default status filtering, or the shape of the response. The word 'Get' implies read-only, but the description does not confirm non-mutating behavior or provide any additional context beyond what the schema already offers.
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, concise sentence that is front-loaded with the verb and resource. It contains no unnecessary words or vague qualifiers, and every word adds 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?
The tool has five parameters and no output schema, so the description should ideally provide some context about the return shape or pagination behavior. While the schema fully documents parameters, the description does not mention what the response list contains, typical page sizes, or whether the 'status' filter defaults to a certain value. This is adequate for a simple getter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with each parameter having a clear description. The tool description adds no new meaning beyond mapping 'flat' to flat_id and 'date' to the date parameter, which is already explicit in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 operation ('Get'), the resource ('visitor/guest approval entries'), and the scope ('for a flat on a given date'). This specificity distinguishes it from sibling tools like get_approvals_count, which searches for approval counts rather than entry lists.
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 its use for listing approvals, but it provides no explicit guidance on when to prefer this tool over alternatives, such as get_approvals_count or other listing tools. The context of siblings is not referenced, and the description does not mention exclusions or scenarios where another tool is more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'List' which implies a read operation, but does not disclose pagination behavior, whether stops are active/available under certain conditions, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no fluff. The purpose is front-loaded and all words contribute 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?
The description covers the core purpose but lacks details about response format (no output schema) or edge cases like pagination defaults, though the schema covers pagination. Given the tool's simplicity, it is minimally complete but could benefit from more context.
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 100%, so parameters are already documented. The description adds the clarifying context that 'buggy' refers to golf carts, but does not provide additional meaning beyond the schema's own descriptions.
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 specific verb 'List' with a clear resource 'buggy stops' scoped to 'a flat'. It distinguishes from the sibling tool 'list_buggy_activity' by focusing on stops rather than activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a flat's buggy stops are needed, but does not provide explicit when/when-not guidance or mention alternatives. No exclusions or contextual cues are given, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic 'list' action and gives examples, but does not mention pagination behavior, default page/items values, whether the list includes only active services, or any access/permission requirements. This lack of behavioral disclosure is a significant gap.
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, concise sentence that front-loads the action and resource, with helpful examples in parentheses. There is no redundant or unnecessary content; 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 simple list tool with two optional parameters, the description is adequate but does not mention pagination or return structure. Since there is no output schema, the agent might need more context about what the response contains, but the core purpose is clear enough for basic use.
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 input schema fully describes both parameters (page and items) with default values, so the description adds no additional meaning beyond what the schema already provides. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'external services integrated with the project' with concrete examples ('laundry, food, etc.'). This clearly distinguishes it from sibling tools like list_service_types and list_service_staffs, which focus on different aspects of services.
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 you need to list external services), but it does not explicitly state alternative tools or exclusion conditions. There is no guidance on when not to use this tool or when to prefer a sibling tool, leaving the usage context only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. The verb 'List' implies a read-only operation, but no additional behavioral context is given—such as pagination behavior, filtering options, or handling of invalid flat_id. This is adequate but minimal.
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, well-structured sentence that front-loads the core purpose without any fluff or repetition. Every word contributes to clarity.
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 list tool, the description captures the essential purpose. However, without an output schema or annotations, it omits details about the return format, ordering, or typical use cases. The tool is understandable but lacks contextual richness.
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 input schema provides full descriptions for all three parameters (flat_id, page, items), so schema coverage is 100%. The description adds no extra semantic meaning beyond what the schema already contains, warranting the baseline score of 3.
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 'List' and the specific resource 'service staff booking schedules' scoped to 'a flat', which effectively distinguishes it from sibling tools like list_service_staffs and list_booked_slots. It is concise and unambiguous.
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 provides no guidance on when to use this tool versus alternatives, nor does it include exclusions or prerequisites. Given the large number of sibling list tools, this is a missed opportunity to differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It only states the core listing/filter behavior and does not mention pagination behavior, authentication requirements, rate limits, or any other operational details. This is minimal transparency for a tool with no annotations.
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, concise sentence that is front-loaded with the verb and resource. It contains no filler or redundant information, earning full marks for conciseness and 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?
The tool is a simple list operation with a single required filter and two pagination parameters. The schema fully documents the parameters, and the description explains the core purpose. It does not overcomplicate, and while it doesn't mention pagination behavior, that is adequately covered by the schema. Given the simplicity and schema coverage, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description only reiterates the flat_occupancy_id filter that already appears in the schema, adding no extra semantic value beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('flats') with a clear filter scope ('filtered by a specific flat_occupancy_id'). It clearly distinguishes from the sibling tool 'list_flats' by indicating the occupancy-based filter.
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 is for listing flats for a given flat_occupancy_id, which suggests a use case, but it does not explicitly state when to prefer this over alternatives like 'list_flats' or provide exclusions. The filter mention gives some context, but there is no direct alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. However, it only states what the tool lists and mentions the flat scope; it does not mention read-only behavior, pagination, authentication, or response format. 'List' implies a safe read, but that is not explicitly stated, leaving a gap in transparency.
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, concise sentence that is front-loaded with the verb and target. It includes useful examples without unnecessary detail, making it highly efficient and scannable.
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 list tool with complete schema parameter descriptions and no output schema, the description is sufficient to convey the core purpose and scope. It lacks explicit mention of pagination or response contents, but given the simplicity and the flat_id scope, the description is nearly complete, with only minor gaps in return-value expectations.
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. The description adds minimal semantic value beyond the schema—it clarifies that the categories are issue/complaint types and are tied to a flat, but it does not explain page/items parameters, which are already well-described in the schema. The description does not compensate for any missing parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'available issue/complaint categories for a flat' with concrete examples (plumbing, electrical). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like list_maintenance_issues or get_issue_stats, which address different aspects of issues.
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 is used to fetch the list of categories relevant to a flat, but it does not explicitly contrast with alternatives or state when not to use it. Since siblings like list_maintenance_issues likely list actual issues rather than categories, the usage context is mildly implied but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic search operation. It lacks disclosure about pagination behavior, partial matching, or response structure, leaving the agent without important context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose without redundant words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool, the description covers the core function, and the schema documents parameters and defaults. However, with no output schema or annotations, it would benefit from mentioning typical return values or that it returns a paginated list, though given the tool's simplicity this is a minor gap.
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 covers all three parameters with descriptions (100% coverage), so the description need not add parameter details. It adds minimal context by indicating 'across the society' but does not clarify search semantics beyond the 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 clearly states the tool's function: searching vehicles by registration number across the society, using a specific verb and resource. It distinguishes from sibling list tools like list_resident_vehicles by emphasizing a search operation.
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 is for searching by registration number but provides no explicit guidance on when to prefer it over alternatives such as list_resident_vehicles or list_vehicle_brands. No exclusions or alternate suggestions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only restates the basic purpose and does not disclose pagination behavior, ordering, response format, or any side effects. The schema hints at pagination via page/items, but the description adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the essential verb and resource. No filler or redundant 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?
For a simple read tool with rich schema coverage, the description is adequate but not complete. It omits any mention of pagination behavior, output structure, or prerequisites. Since there is no output schema, more detail would be helpful, but the low complexity keeps this at a minimum viable level.
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 schema fully documents all three parameters. The description adds no extra meaning beyond what the schema provides, but per the calibration rule, the baseline for high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('promotional banners') with a scope ('for a flat'). This is specific and distinguishes it from other sibling tools, none of which relate to banners.
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 the tool: when promotional banners for a flat are needed. No exclusions or alternatives are mentioned, but given the uniqueness of the tool among siblings, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It states the purpose ('complete login') but does not mention success/failure behavior, whether the OTP is consumed/invalidated, required authentication context, or what the tool returns. This leaves significant unknowns for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the primary purpose, the second gives sequencing guidance. It is front-loaded, directly actionable, and contains zero filler or redundant 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?
While the tool is simple and parameter coverage is complete, the description lacks information about return values (there is no output schema) or side effects beyond 'complete login'. It does provide the flow context ('after request_otp'), which is helpful, but the absence of response or failure behavior leaves a moderate completeness gap.
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 input schema already provides 100% coverage for both parameters (mobile_number and otp) with clear descriptions. The tool description adds no additional parameter syntax, format, or relationship details beyond what the schema provides, so it stays at the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Verify') and resource ('OTP received on mobile to complete login'). It distinguishes itself from siblings like request_otp (which sends the OTP) and check_auth_status (which checks login state) by defining its role as the verification step in the login flow.
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 instruction 'Call after request_otp' provides explicit sequencing context for when to use this tool, directly referencing a sibling tool. However, it does not state when not to use it or compare with alternatives like check_auth_status, so it falls just short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the core behavior and return value (auth state and mobile number if available), but does not mention error conditions, security requirements, or side effects. This is adequate for a simple read-only check but lacks depth.
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, concise sentence with no unnecessary wording. It front-loads the primary action and clearly explains the result.
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 tool's simplicity (no parameters, no output schema), the description covers the essential elements: purpose and return data. Additional error semantics are not critical for a basic status check, so it is complete enough.
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 the schema coverage is 100%, so there is nothing to explain. The description adds context about the output format, and for a no-parameter tool the baseline is 4.
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 checks authentication status and returns auth state plus optional mobile number. This is a specific verb-resource pair and easily distinguishes it from sibling tools like request_otp and verify_otp.
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 provided on when to use this tool versus alternatives, such as after OTP verification or for session validation. The description only explains what it does, not 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.
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. It clearly states the tool returns a count, but does not disclose any additional behavioral traits such as whether the count includes only approved approvals or any filtering logic. This is acceptable for a simple read-only count operation, but not richly 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?
The description is a single concise sentence that efficiently states the tool's purpose without wasted words. It is front-loaded and easy to parse.
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 tool with only three parameters and no output schema, the description sufficiently explains the core functionality. It could have mentioned the return format (e.g., a single number) or clarified that month and year are required together, but the schema covers the required aspects. Overall, the description is complete enough for its complexity.
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 schema already explains the parameters. The description adds no extra parameter-specific details beyond what the schema provides, which is the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get the count') and clearly identifies the resource ('visitor approvals for a flat in a given month'). This distinguishes it from sibling tools like get_visitor_approvals, which likely returns a detailed list.
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 you need just the count of approvals), but does not explicitly state when not to use it or mention alternatives like get_visitor_approvals. Guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. 'Get' and count categories imply a read operation and define the core output, but the description does not disclose default range behavior, authentication requirements, or whether counts are scoped globally or per amenity.
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?
Description is a single, front-loaded sentence with no filler; every phrase adds meaningful information about resource and metric types.
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 one-optional-parameter read tool, the description covers the resource and returned count categories. It lacks default behavior and scope details, but the low complexity and complete parameter schema make it sufficiently complete for selection and invocation.
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?
Input schema fully describes the sole optional parameter with enum and 'Time range' description, so schema coverage is 100%; description adds no extra meaning beyond what the schema already provides, earning baseline 3.
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?
Description uses specific verb 'get' and identifies resource 'amenity booking statistics' plus metric categories (booked, completed, waitlisted counts), clearly distinguishing from sibling list_booked_slots which would provide raw booking data. It precisely conveys what the tool returns.
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?
No explicit guidance on when to use this tool over siblings like list_booked_slots or get_issue_stats. The name and phrasing imply aggregate statistics, but no when-to-use or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 merely states the purpose and does not disclose behavioral traits such as pagination, status filtering, or whether results are read-only. The schema implies pagination and status, but the description adds no behavioral context beyond the action.
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, concise sentence that states the action, resource, and scope without redundant text. It is front-loaded and efficiently communicates the essential purpose.
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 tool's simplicity and the rich parameter schema, the description is sufficiently complete. It lacks an output schema but 'List' naturally implies a list of exit passes, and the schema covers all parameters. A slightly more detailed mention of pagination or status could improve it, but it is adequate.
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 input schema has 100% description coverage for all four parameters, so the baseline is 3. The description adds no extra parameter meaning beyond what the schema already provides, only associating the flat_id concept.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'exit passes' and adds scope 'for a flat'. It also clarifies what exit passes are ('material movement out of society'), distinguishing this tool from other listing 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?
The description clearly indicates the tool is for listing exit passes related to a flat, providing context for when to use it. It doesn't explicitly name alternatives or exclusions, but the context is clear enough given the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return fields, which helps set expectations, but does not mention error behavior, authentication requirements, or side effects. For a read-only 'get' operation, this is adequate but not rich.
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, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's purpose.
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?
The tool has low complexity (one parameter, no nested objects, no output schema). The description lists expected output fields, and the schema fully documents the parameter. It lacks return structure/error details but is sufficient for a simple detail-fetching tool.
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%, and the parameter's description already explains where the ID comes from ('from profile or list_flats'). The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed occupancy info for a flat' and enumerates the specific fields returned (tower, wing, floor, project, flat number, occupancy type). This distinguishes it from list-oriented siblings like list_flats and get_flat_access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when detailed occupancy info for a specific flat is needed, but does not explicitly state when to use it versus alternatives or mention exclusions. The schema's parameter hint ('from profile or list_flats') provides indirect context, but the description itself lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety. The verb 'Get' indicates a read-only operation, but the description does not disclose authentication needs, side effects (though none are likely), or what exactly 'configuration' includes beyond the enumerated methods. It provides minimal transparency but does not contradict anything.
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, well-structured sentence that front-loads the action and resource, then immediately provides relevant examples. Every word earns its place, with no redundant filler or unnecessary detail.
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 should clarify the return value. It names the payment methods but leaves the term 'configuration' ambiguous—what fields or options are returned per method is not specified. This is adequate for a simple tool but lacks full transparency about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially covered (100%). The description adds value by enumerating the payment method types (UPI, card, netbanking, wallet), which gives context about the expected configuration scope, exceeding the baseline 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 clearly states the tool's purpose with a specific verb ('Get') and a distinct resource ('available payment methods'), listing concrete examples (UPI, card, netbanking, wallet). It is unambiguous and distinguishes itself from unrelated sibling tools that focus on bookings, users, or maintenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage whenever payment configuration is needed, but it does not provide explicit guidance on when to use it over other tools or any exclusion criteria. There are no alternatives listed among siblings, but the description lacks an explicit 'when to use' statement, leaving usage only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. The verb 'Get' indicates a read operation, and the enumeration of included data (buggy service, cometchat auth, electricity meter) provides some insight. However, it doesn't disclose authentication requirements, potential errors, or data freshness, which are relevant for a zero-parameter getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then lists key examples. No redundant words or fluff.
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 0-parameter getter, the description covers the main return components (buggy service status, cometchat auth, electricity meter, feature flags). The phrase 'and more' leaves some ambiguity about the full return set, and with no output schema, the agent cannot fully anticipate the response structure. Still, the core context is sufficient for most use cases.
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 zero parameters, so parameter explanation is unnecessary. The baseline is 4, and the description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies a distinct resource 'current flat access details' with concrete examples (buggy service status, cometchat auth, electricity meter, feature flags). This clearly separates it from siblings like get_module_access (module-level) and check_auth_status (auth status).
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 is implied: it's for flat-level access details rather than module-level or auth-only checks. However, there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It states the core behavior (returns a count, filters by unread status, scopes to a flat) but does not elaborate on authentication, error conditions, or return format. This is adequate but not rich, earning a 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 a single, front-loaded sentence that conveys the entire functionality without any extraneous words. Perfect conciseness.
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 tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential context: what is counted, for whom, and the filter. It does not explain return details, but 'count' implies the return type. For a tool of this complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter flat_id ('Internal flat ID'). The description adds minimal extra meaning beyond the schema—it simply recontextualizes the flat as the subject of the count. Per the baseline rule for high schema coverage, this scores a 3.
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's purpose: 'Get the count of unread notifications for a flat.' It uses a specific verb ('get'), a specific resource ('unread notifications'), and a clear scope ('a flat'). This distinguishes it from sibling count tools like get_approvals_count and get_booking_stats.
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 provides clear context: use this tool when you need the count of unread notifications for a flat. It does not explicitly mention alternatives or exclusions, but the usage is unambiguous and self-evident from the description. No competing tool offers this specific functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavior. It adds context by specifying the returned fields, but does not explicitly state authentication requirements, side effects, or error behavior. The word 'Get' implies a read-only operation, but this is not stated explicitly.
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, front-loaded sentence that immediately states the action and resource, followed by a concise list of the returned fields. Every word adds value with no redundancy.
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 no-input getter, the description provides a clear picture of the return content by naming the five fields. It is missing explicit details about the response shape (single object vs array) and error cases, but the absence of an output schema makes this less critical. The description is sufficiently complete for straightforward usage.
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 (empty properties object), so there is no parameter semantics to explain. According to the rubric, 0 params yields a baseline of 4. The description adds no parameter information, which is acceptable since none exist.
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's function: 'Get the logged-in resident's profile' and enumerates the specific fields included (name, mobile, email, resident_id, default_flat_occupancy_id). This distinguishes it from sibling tools like get_flat_access or get_occupancy_detail by focusing on the resident's own identity data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via the phrase 'logged-in resident', indicating this is for fetching the current user's profile. However, it provides no explicit guidance on when to choose this over alternatives or when not to use it. For example, it doesn't mention that flat-specific data should be retrieved via other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the tool lists flats and returns tower/wing/floor/project info, which implies a read-only operation. However, it does not mention pagination behavior, potential absence of results, or any other edge cases.
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, well-structured sentence that front-loads the main action and includes the most important qualifiers without any fluff or redundant wording.
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 read-only list tool with two optional pagination parameters, the description adequately covers what is listed, for whom, and what fields are returned. While it doesn't describe the response format or pagination defaults, the schema handles the parameters and the tool is not complex enough to require more.
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 100%, and both parameters (page, items) are already fully described in the schema. The description adds no param-level detail beyond the general context of listing flats, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('all flats associated with the current resident') plus the included data (tower/wing/floor/project info). This distinguishes it from sibling tools like list_flats_by_occupancy or get_flats_by_resident_ids by explicitly scoping to the current resident.
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 clearly implies the tool should be used when you need the current resident's flats, but it does not explicitly state when not to use it or name alternative tools. The context is clear, but no exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It indicates a read-only listing operation but does not mention pagination, sorting, or any limitations. The examples add scope clarity but not deep 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, immediately states purpose and examples. Extremely concise and well-structured.
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 list tool with a detailed schema, the description is adequate. It conveys the purpose and examples; the schema covers parameters. It lacks explicit return format info, but no output schema exists and the behavior is straightforward.
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 100% with descriptions for each parameter. The description does not add meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists service staff (maids, cooks, drivers, etc.) for a flat, using a specific verb and resource. It distinguishes from sibling tools like list_service_staff_bookings and list_service_types.
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: to get staff registered for a flat. It implies the use case without explicitly naming alternatives or exclusions, which is acceptable given the sibling tools are clearly different.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the primary action (sending an OTP) and its purpose (starting authentication). However, it does not disclose side effects, delivery characteristics, error possibilities, or whether any prerequisites exist. For a relatively simple send tool, the transparency is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and includes a practical usage tip. Every word earns its place; no fluff or repetition. It is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential what and when. It does not mention return values or the next step (e.g., verifying the OTP), but these are inferable from sibling tools. Given the low complexity, the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a full description of the parameter: '10-digit mobile number' (100% coverage). The description adds no additional semantic meaning beyond confirming the destination ('to a mobile number'). Given the high schema coverage, the baseline score of 3 is appropriate.
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's function: 'Send an OTP to a mobile number to start authentication.' It uses a specific verb ('send') and resource (mobile number), and the phrase 'start authentication' distinguishes it from sibling tools like verify_otp. The addition of 'Call this first' further clarifies its role.
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 provides a clear usage condition: 'Call this first if not logged in.' This gives both a precondition and sequencing. It does not explicitly name alternatives (e.g., verify_otp), but the context makes it evident that this tool precedes OTP verification. The guidance is functional though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The use of 'Get' clearly indicates a read-only operation, and specifying 'enabled' clarifies what subset of modules is returned. No side effects or prerequisites are mentioned, which is appropriate for a simple getter.
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, concise sentence that front-loads the core action and resource. There is no wasted wording.
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 zero-parameter, no-output-schema tool, the description completely conveys its functionality. The scope is explicitly tied to the 'current project', making it contextually complete for an agent to select and invoke the 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 tool has zero parameters, so according to the rubric the baseline is 4. The description adds no parameter-specific details, but none are needed; the empty schema is fully 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 tool's function: retrieving enabled modules/features for the current project. The verb 'Get' combined with the specific resource 'modules/features' makes the purpose unambiguous, and it is distinct from sibling tools which address different domains (bookings, OTP, residents, etc.).
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 needing to know which modules or features are active in the current project. However, it does not explicitly mention any alternatives or exclusions, leaving the usage context to be inferred rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![belong-mcp MCP server](https://glama.ai/mcp/servers/arjun1194/belong-mcp/badges/card.svg)](https://glama.ai/mcp/servers/arjun1194/belong-mcp)

Score Badge

Copy to your README.md:

[![belong-mcp MCP server](https://glama.ai/mcp/servers/arjun1194/belong-mcp/badges/score.svg)](https://glama.ai/mcp/servers/arjun1194/belong-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/arjun1194/belong-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server