LIMU Portal MCP

by gochi20

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but the three budget-related get/list pairs (customs, shipping, shipment) are very similar and could cause confusion, though descriptions help differentiate.
Naming Consistency5/5
All tools follow a consistent 'limu_verb_noun' pattern in snake_case, with the minor exception of 'limu_health' which is still clear and fits the convention.
Tool Count2/5
With 39 tools, the set is well beyond the recommended 3-15 range. While the domain is broad, the server would benefit from consolidating similar tools (e.g., unifying budget endpoints).
Completeness3/5
The server covers a wide range of query and management operations, but lacks create and update for many core entities (e.g., cargo, shipments), suggesting incomplete lifecycle coverage for autonomous agents.
Average 3.3/5 across 39 of 39 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate safety and idempotency. Description adds only the word 'Report', offering no additional behavioral context (e.g., pagination, default limit, sorting, or if the response includes summaries).
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?
Single sentence, no redundancy. However, it sacrifices necessary detail for brevity, which harms overall usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters, zero schema descriptions, no output schema, and a bare-bones description, the tool is severely underdocumented. Agent cannot infer return format, pagination behavior, or valid parameter combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — no parameter descriptions. Description mentions 'status, permission, district, owner, and volume summaries', which maps to some params (status, permissionStatus, district, ownerId, includeSummary), but critical params like limit, offset, search, groupBy, leadId, etc. are unexplained. Agent would lack understanding of filtering and pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Report on client leads' which is ambiguous — it could imply generating a report rather than listing. Title clarifies 'List', but within description, the purpose is somewhat vague. Does not differentiate from sibling list tools like limu_list_client_profile_reports.
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 on when to use this tool versus alternatives like limu_get_lead_report (which seems to fetch a single report). No mentions of use cases, prerequisites, or exclusions.
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?
Annotations already declare `readOnlyHint: true`, `idempotentHint: true`, `destructiveHint: false`, so the tool's safety is clear. The description adds only that results include 'context', which is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise, but it is too vague to be efficient. It could have included key details (e.g., pagination, filtering) without increasing length significantly.
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?
No output schema, and the description omits pagination (limit/offset), filtering criteria, and result format. For a list tool with many optional filters, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 13 parameters, yet the description provides no parameter details at all. It fails to compensate by explaining what `search`, `status`, `cargoId`, etc., do.
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 it searches cargo records with contextual info (client, shipment, package), clearly indicating a list/search operation. It distinguishes from the sibling `limu_get_cargo` (single record), but the phrase 'summary context' is vague.
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 explicit guidance on when to use this tool versus alternatives like `limu_get_cargo` or other list tools. The description lacks context about filtering or search scenarios.
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?
Annotations already declare it as a read-only, idempotent, non-destructive operation. The description adds no behavioral details beyond what annotations provide, such as pagination or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but under-informative given the complexity. It earns its place but fails to provide sufficient value for such a parameter-rich tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 13 parameters, no output schema, and a brief description, the tool is incomplete. It does not cover return value expectations, default behavior, or how to construct effective queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 13 parameters. It mentions cargo activity, lead counts, and order-form totals but never how parameters like 'onlyWithCargoActivity', 'tier', or 'clientType' affect results.
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 it reports on client profiles with cargo activity, lead counts, and order-form totals. It clearly differentiates from the singular variant 'limu_get_client_profile_report' but could be more precise about the listing aspect.
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 on when to use this tool vs alternatives like 'limu_get_client_profile_report' or other list reports. Context signals show many sibling tools with different filtering, so explicit usage conditions are missing.
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?
Annotations confirm readOnly, idempotent, non-destructive, so safety is clear. The description adds that the report includes status, assignee, client, shipment, value, and volume summaries, giving some insight into output. However, it omits behavioral details like pagination, filtering, or that this is a list of reports, not a single report.
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 short sentence with no fluff. It is concise but could be slightly expanded without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no output schema, the description is severely incomplete. It fails to explain parameters, pagination, filtering, or the structure of the returned report, leaving agents with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the tool description does not explain any of the 14 parameters. It mentions report fields (status, assignee, etc.) but these are not parameters. Without parameter info, the agent cannot understand how to use filters like limit, search, groupBy, etc.
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 it provides a report on order forms with specific summaries (status, assignee, etc.), clearly indicating the resource and action. However, it does not explicitly say 'list reports' which could be inferred from the name but the wording is slightly ambiguous.
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 on when to use this tool over alternatives. The sibling tools include other list operations and a singular get report, but the description offers no context on when to choose this list report over others like get_order_form_report.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds that the tool returns 'package groups' and 'unit check progress,' which is useful but minimal. No additional behavioral traits (e.g., pagination, ordering) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading key information. It is not overly verbose. However, it could be slightly more detailed without losing 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?
Given the tool has 10 parameters, no output schema, and no parameter descriptions, the description is highly incomplete. It does not explain the return format, pagination, filtering options, or how to use the various parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool description does not mention any of the 10 parameters, their purposes, or constraints. It entirely fails to compensate for the lack of schema documentation.
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 'Search cargo package groups and their unit check progress,' which clarifies the specific scope (cargo package groups and check progress) beyond just listing packages. It distinguishes from siblings like limu_get_package (single package) and limu_list_cargo (cargo items). However, 'Search' is slightly different from 'List' in the name, causing minor ambiguity.
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 does not mention contexts where it is appropriate, prerequisites, or when not to use it. Given many sibling list tools, this is a significant gap.
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?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which already inform the agent that the tool is safe, idempotent, and non-destructive. The description adds context about the return data (summary context), but does not disclose pagination behavior, rate limits, or data scope. The description adds some value beyond annotations but not extensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it is overly terse and lacks structure. It could be front-loaded with the main action and then elaborated with list-specific filters. The current form is acceptable but not optimal.
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 absence of an output schema, the description should help understand the return structure. It mentions 'summary context' but does not specify fields. With 9 parameters and no parameter descriptions, the tool definition is incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining key parameters. However, the description only generically mentions 'context' without describing any of the 9 parameters (e.g., status, voucherId, dates). The agent has no guidance on how to use these filters effectively, which is critical for a list tool.
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 tool name and title clearly indicate listing payment vouchers. The description adds that it includes context about requisition, spend, item, and proof summary, distinguishing it from other list tools. However, it does not fully differentiate from the get tool (limu_get_payment_voucher) or explain the scope of the list.
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 guidelines are provided. The description does not specify when to use this list tool versus alternatives like limu_get_payment_voucher or other list tools. There is no mention of prerequisites, common filters, or avoidance scenarios.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety profile is clear. The description adds no additional behavioral context such as pagination behavior (limit/offset) or filtering logic. It does not contradict annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence directly states the tool's purpose with no wasted words. However, it may be too terse and could benefit from additional details without sacrificing 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?
Given the 11 parameters and no output schema, the description is incomplete. It omits pagination details, filtering parameters, return format, and how totals are calculated. The context of many sibling tools also demands more clarity about what makes this tool distinct.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with 11 undocumented parameters. The description adds no meaning to any parameter; it only mentions 'search' and totals but does not explain how parameters like mode, status, location, or date ranges work. This fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it searches shipments with calendar, cargo, and package totals, clearly indicating the tool's function. However, 'calendar totals' is somewhat ambiguous and does not differentiate from sibling list tools like limu_list_cargo or limu_list_packages, which also deal with shipments but may lack totals.
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 on when to use this tool versus the many sibling list tools. The description does not mention alternatives or context for using this specific search/list tool over others.
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?
Annotations already provide readOnlyHint and idempotentHint. The description repeats 'read-only' but adds no new behavioral context beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and concise, but its brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no parameter descriptions, the description does not provide sufficient context for correct usage, such as return format or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 5 parameters (limit, offset, search, budgetId, shipmentId), leaving the agent without understanding their meaning or usage.
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 lists shipping/shipment budgets with specific totals, but does not differentiate from sibling tool limu_list_shipment_budgets, which may have similar functionality.
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 on when to use this tool versus alternatives like get or list specific budgets, nor any prerequisites or exclusions.
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?
Annotations already declare readOnlyHint and idempotentHint, so the read-only nature is clear. The description adds 'recent' context but does not elaborate on consistency, freshness, or any other behavioral traits. With annotations covering safety, the description provides minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of 13 words, very concise. However, it sacrifices informative content for brevity. Could be restructured to add key details without becoming verbose.
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 5 parameters, no output schema, and sibling tools, the description is too brief. It does not explain the output format, what 'recent' means, or how the parameters affect the report. The annotations help but the description alone is incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no property descriptions (0% coverage). The description mentions 'cargo, lead, and order-form' which hints at the boolean parameters, but does not explicitly clarify their meanings or the purpose of the 'limit' parameter. The description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one client profile and includes recent cargo, lead, and order-form report context. It distinguishes from siblings like limu_get_client (basic client info) and list tools, but does not explicitly differentiate from limu_get_client or explain what the profile report contains versus a simple client retrieval.
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 on when to use this tool versus alternatives like limu_get_client, limu_get_lead_report, or limu_get_order_form_report. The description does not mention prerequisites, use cases, or exclusions.
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?
The description adds value beyond annotations by specifying the return content: income rows, expense rows, totals, and logs when present. Annotations already indicate safe read-only behavior, so the description's behavioral detail is complementary and informative.
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, front-loaded sentence that efficiently conveys the core function without extraneous words. It earns its place but could be slightly improved by incorporating parameter hints.
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 output schema and 0% parameter coverage, the description is incomplete. It does not explain the relationship between the two IDs (budgetId, shipmentId), the meaning of logLimit, or the default behavior of includeLogs. The tool's complexity (5 parameters) demands more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides no parameter explanations. It fails to clarify the distinction between budgetId and shipmentId, the meaning of logLimit, or the effect of includeLogs and budgetType. This is a critical gap given the parameter count of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single customs or shipping shipment budget with detailed components (income rows, expense rows, totals, logs). The verb 'Get one' and resource 'customs or shipping shipment budget' are specific. However, it does not distinguish itself from sibling tools limu_get_customs_budget and limu_get_shipping_budget, which may cause confusion about when to use this versus those.
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 like limu_get_customs_budget, limu_list_shipment_budgets, or other list functions. There is no mention of prerequisites, when to use budgetId vs shipmentId, or when logs would be present.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the response includes certain fields and optional approval logs (controlled by includeLogs parameter). This adds some value but does not disclose pagination behavior or other API quirks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. However, given the tool's complexity (16 parameters), it is too brief to be helpful. It sacrifices necessary detail for 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?
The tool has 16 parameters, no output schema, and no schema descriptions. The description omits filtering capabilities, pagination (offset/limit), and behavior of optional fields. This leaves significant gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 16 parameters with 0% description coverage. The description only mentions fields returned, not parameter meanings or usage. Critical parameters like stage, status, date range filters, and search are unexplained, making it nearly impossible for an agent to assemble correct calls.
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 'leave applications', and lists specific fields returned (employee, leave type, balance, approval stage, optional approval logs). This distinguishes it from sibling tools like limu_list_cargo or limu_list_requisitions.
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 (e.g., limu_review_leave_application), nor when not to use it. There is no mention of prerequisites or typical use cases.
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?
Annotations already declare readOnlyHint and idempotentHint, reducing the need for behavioral disclosure. The description adds context about the data source but omits details on pagination behavior, empty results, or authorization requirements.
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 communicates the core purpose efficiently. It is front-loaded with the action and resource, but could benefit from slight expansion to cover key parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 9 undocumented parameters, the description lacks sufficient detail about input options and return format. Agents cannot infer what fields are returned or how to filter effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; none of the 9 parameters are described in the schema. The description provides only a vague hint about filtering ('from monthly budget entries and split schedules') and does not explain any specific parameter's meaning or usage.
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 specifies the action ('list') and resource ('scheduled budget purchases') and distinguishes from sibling list tools by mentioning 'from monthly budget entries and split schedules', but could be more precise about what a purchase schedule includes.
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 on when to use this tool versus alternatives like other list_* tools. The description lacks context on prerequisites or cases where this tool is appropriate.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds only a modest amount of context about the report's contents (schedule, shipment, payment, employee). It does not elaborate on return format, pagination, or other behaviors.
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 efficiently conveys the core purpose without fluff. However, it could benefit from slight structuring to cover more details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 10 undocumented parameters, the description is insufficiently complete. The tool is relatively complex, and the description alone does not equip an agent to understand the full scope of data returned or how to use the parameters effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions exist in the schema. The description fails to explain any of the 10 parameters, and while 'schedule, shipment, payment, employee context' hints at some parameters, it does not directly connect to them.
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 it provides a report on warehouse work timesheets with context variables, and the title includes 'list', making the purpose clear. Although it does not use an explicit verb like 'retrieve', it is effectively a listing tool. It distinguishes from sibling 'limu_list_timesheet_reports' by specifying 'warehouse'.
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 lacks any indication of when to use this tool versus alternatives, such as the general timesheet report list. No prerequisites, exclusions, or context for selection 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'recent' for associated data but does not explain recency criteria or other behavioral traits. Minimal additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 19 words. Efficiently conveys the tool's purpose. Could be slightly improved by grouping related entities, but concise for the information provided.
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?
No output schema exists, but description does not hint at return format or structure. Does not explain 'recent' behavior or how parameters control included data. Significant gaps for a 12-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any of the 12 parameters (e.g., includeKyc, includeCargo). It merely lists associated data types without linking to include flags. No meaning added beyond parameter names and types in 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?
Description clearly states it retrieves a single client with many related entities (cargo, shipments, etc.). Title 'Get client' and verb 'Get' with resource 'one LIMU client' are specific. Distinguishes from siblings like 'limu_get_clients' for listing and 'limu_get_client_profile_report' for a report subset.
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 versus alternatives like 'limu_get_client_profile_report' or 'limu_update_client'. Usage is implied for obtaining a full client summary, but no conditions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds that it returns totals, but does not disclose pagination behavior, ordering, or any side effects beyond the annotation's safety profile.
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?
Single sentence that is mostly concise, though 'customs and shipping shipment budgets' is slightly redundant. No unnecessary words, but could be slightly more streamlined.
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?
No output schema or description of return format. For a list tool with 6 parameters, the description is too sparse to fully understand usage without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description provides no information about any of the 6 parameters (limit, offset, search, budgetId, budgetType, shipmentId), leaving the agent to infer meaning solely from names and schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists customs and shipping shipment budgets with specific totals (income, expense, spend, balance). It distinguishes from siblings like limu_list_customs_budgets and limu_list_shipping_budgets by combining both types.
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 on when to use this tool versus more specific list tools (e.g., for only customs or only shipping budgets). No context on prerequisites or use cases.
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?
Annotations already provide readOnly and idempotent hints, which the description does not contradict. The description adds the fact that it summarizes data like lateness and exceptions, but does not elaborate on behavior not covered by annotations (e.g., pagination, empty results).
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 sentence that is concise and front-loaded with the main purpose. However, it could include brief parameter guidance without losing 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?
With no output schema and many parameters, the description lacks completeness. It does not explain what the output contains exactly, how parameters affect results, or how to effectively use the tool. The tool is relatively complex with 8 parameters, but the description offers minimal context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 8 parameters (limit, offset, search, status, dates, employeeId, includeSummary). Without any parameter semantics, the agent cannot infer how to use these fields from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists timesheet reports with specific details (hours, lateness, exceptions, leave, summaries). It distinguishes from the sibling limu_list_warehouse_timesheet_reports, indicating a specific resource (employee timesheet reports).
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 on when to use this tool versus alternatives, no prerequisites, and no context on filtering or typical use cases. The description only states 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds that the tool returns schedule splits and linked usage, which is behavioral context beyond annotations. However, it does not disclose potential errors, missing fields, or other traits.
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 sentence, front-loaded with the verb 'Get' and key resources. It is concise with no wasted words, though the phrase 'or one budget entry' could be slightly clearer. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema, no param descriptions), the description is severely lacking. It does not explain how to use the tool, what the output contains beyond mentioned items, or how to interpret results. The tool has high information needs that are unmet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 11 parameters and 0% schema description coverage, the description should explain parameter meanings. It does not mention any parameter, leaving all parameters opaque. The description only states the general output, not how to specify the month, entry ID, pagination, or filtering. This is insufficient.
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 a monthly budget period summary or a single budget entry with schedule splits and linked requisition/payment voucher usage. It distinguishes from sibling 'limu_list_monthly_budgets' which lists budgets, implying this tool gets detailed information for a specific entry or period.
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 when-to-use or when-not-to-use guidance is provided. The description implies it is for getting a specific budget entry or periodic summary, but does not compare with alternatives like 'limu_list_monthly_budgets' or other detail tools. The context is present but not explicitly guided.
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?
Annotations already indicate read-only and non-destructive behavior. The description adds that results include associated summary data, but does not address pagination or performance.
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 front-loads the action, though the long list of associated data could be structured better for readability.
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 18 parameters, no output schema, and many sibling tools, the description is too minimal; it lacks details on filtering, search behavior, and return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no details on individual parameters, leaving their semantics entirely to the schema property names and constraints.
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/search') and resource ('LIMU clients'), and lists the associated data types, distinguishing it from singular 'get_client'.
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 for broad client searches with many associations, but does not explicitly state when to choose this tool over siblings like limu_get_client or limu_list_cargo.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, establishing safety. The description adds value by disclosing the content of the return (items, proofs, linked requisition details). However, it does not elaborate on additional behaviors such as pagination, error states, or permissions.
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 of 11 words, directly stating the tool's purpose. No extraneous information is included, and it is appropriately front-loaded.
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 one parameter and no output schema, the description covers the return content but omits explanation of the input parameter. Combined with existing annotations, it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation for the 'voucherId' parameter beyond its name and type. The agent must rely entirely on the parameter name and schema constraints, which lack semantic context such as what constitutes a valid voucher ID or how to obtain it.
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 explicitly states the action ('Get') and the resource ('one payment voucher'), and specifies what is included (items, proofs, linked requisition details). It clearly distinguishes from sibling list tools by indicating it retrieves a single voucher.
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 limu_list_payment_vouchers. The agent must infer from the name and parameter that this is for retrieving a specific voucher by ID, but no explicit context or exclusion criteria are given.
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?
Annotations already indicate readOnlyHint and idempotentHint, so the description adds value by specifying the return content (categories, spend, balance, schedule summaries). It does not contradict 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?
Single sentence with no redundancy. Every word adds value, making it highly 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?
Given the tool's complexity (8 parameters, no output schema, no parameter descriptions), the description is too brief. It provides minimal context about return structure or filtering capabilities, leaving agents undersupplied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to explain any of the 8 parameters (limit, offset, search, category, etc.). With low coverage and no compensation, the tool provides almost no semantic guidance for parameter usage.
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 'monthly budget entries' and specifies included data fields (categories, spend, balance, schedule summaries). It distinguishes from sibling 'limu_get_monthly_budget' which retrieves a single budget.
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 on when to use this tool versus alternatives, no mention of filtering, pagination, or prerequisites. The description only states what it does without contextual usage hints.
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?
Annotations do not indicate read-only, idempotent, or destructive behavior, leaving the full burden on the description. The description mentions 'sequencing as the portal' but does not disclose side effects, reversibility, or permission requirements. It is adequate 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, direct sentence that front-loads the core action. There is no extraneous information, and every word contributes to the purpose.
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 complexity (7 parameters, 2 enums, no output schema), the description is too sparse. It does not explain the approval workflow, the meaning of stages, the role of actorId, or the effect of confirm/dryRun. The tool modifies state, yet the description omits essential behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the seven parameters, including their meaning, required constraints, or usage. With 0% schema description coverage, the agent must rely solely on the schema, which only lists enum values without explanations.
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 action (approve or decline) and the resource (requisition approval stage), with specific reference to the three-stage sequencing (admin, finance, management) that mirrors the portal. It is distinct from sibling review tools that target different entities.
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 approving/declining requisition stages but does not explicitly state when to use it versus alternative tools or provide exclusion criteria. The context is clear from the name, but no additional guidance is given.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns totals but does not disclose pagination behavior (limit/offset) or how search/budgetId/shipmentId filters work. It is adequate but not comprehensive.
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 sentence of 12 words, very concise and front-loaded. However, given the number of parameters and sibling tools, slightly more contextual information could improve usability without sacrificing 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?
With 5 parameters, no output schema, and many sibling tools, the description is incomplete. It fails to explain filtering, pagination, or the output format, leaving significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description provides no explanation for any of the 5 parameters (limit, offset, search, budgetId, shipmentId). The description only mentions the returned totals, leaving the agent to infer parameter meanings from names and schema properties alone, which is insufficient.
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 specifies the verb 'list', the resource 'customs shipment budgets', and the specific fields included (income, expense, spend, balance). It clearly distinguishes from sibling tools like 'limu_get_customs_budget' (single item) and 'limu_list_shipment_budgets' (different budget type).
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 a read-only use case but does not explicitly state when to prefer this tool over siblings or provide any exclusions. With numerous sibling tools, more explicit guidance would be beneficial.
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?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying the return content (income rows, expense rows, totals, logs), which is beyond 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?
Single sentence that is clear, front-loaded, and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good purpose clarity, the description fails to cover parameter semantics and return structure. With 4 parameters and no output schema, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (budgetId, logLimit, shipmentId, includeLogs). No help is provided for parameter usage.
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 'Get', the resource 'one read-only shipping/shipment budget', and specifies the content (income rows, expense rows, totals, logs). It distinguishes from sibling 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'read-only' but lacks explicit guidance on when to use this tool versus alternatives like list tools. No when-not or alternative names are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds value by detailing the return content (income rows, expense rows, totals, logs when present), which is not present in annotations. No contradiction.
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, front-loaded sentence with no wasted words. However, it could be slightly more structured by breaking out key behavioral aspects.
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 4 parameters, no output schema, and low schema coverage, the description is insufficient. It does not clarify parameter purposes like logLimit or the duplicated shipmentId reference, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions logs but does not explain the four parameters (budgetId, logLimit, shipmentId, includeLogs) beyond a vague implication that includeLogs controls log inclusion. With 0% schema description coverage, the description fails to compensate.
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 'Get' and the resource 'customs shipment budget', and specifies what is included (income rows, expense rows, totals, logs). It distinguishes well from sibling tools like limu_list_customs_budgets and other 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?
While the description implies use when a single customs budget is needed, it does not explicitly contrast with list tools or provide when-not/alternatives. The guidance is minimal and inferred.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's addition of 'assigned employees and portfolio context' provides useful behavioral detail beyond what annotations offer. It does not disclose error conditions or auth requirements, but for a simple read operation this is adequate.
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 conveys the essential information without any wasted words. It is front-loaded with the 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?
For a simple get tool with one parameter and no output schema, the description provides the essential return context (employees and portfolio). However, given the number of sibling tools, it could be more explicit about the exact coverage of data to help the agent disambiguate. Lacks details on error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'leadId'. The description does not elaborate on the parameter's format, constraints, or purpose beyond what the schema (exclusiveMinimum>0) already indicates. No additional semantic value is provided.
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 clearly identifies the resource ('one lead') and the additional context returned ('assigned employees and portfolio context'). This distinguishes it from sibling tools like list tools or tools for other entities.
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 on when to use this tool versus alternatives. No mention of scenarios where this is preferred over listing leads or other get tools. No exclusions or prerequisites.
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?
Annotations already declare readOnlyHint and idempotentHint, so safety profile is clear. Description adds that it returns line items, status timeline, and purchase proofs, but no further behavioral details (e.g., performance, rate limits).
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, 10 words, efficiently conveys tool's purpose and output. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides a useful summary of returned data but lacks guidance on parameter usage, error handling, or prerequisites. With no output schema, the description partially compensates but remains incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain how to use the two optional parameters. Does not specify whether orderId or orderNumber should be used, or if both can be provided.
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 clearly states it retrieves a single order form, specifying included data (line items, status timeline, purchase proofs). Distinguishes from sibling 'list' tool which returns multiple order forms.
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 versus alternatives, though the phrase 'Get one' implies it is for a single record. Does not mention when not to use or which sibling to choose in different scenarios.
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?
Annotations indicate mutation (readOnlyHint=false) and non-idempotency. The description adds context beyond annotations by detailing side effects: posting spend to monthly/shipment budget items and refreshing requisition status. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 20 words, front-loading the main action. It is efficient but could include brief parameter explanations without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 4 parameters (including boolean flags dryRun and confirm), the description lacks essential details like return value, required actorId role, and the effect of dryRun/confirm. The agent cannot confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the purpose of any parameter (voucherId, actorId, dryRun, confirm). For a mutation tool, the role of dryRun and confirm is critical but missing, leaving ambiguity.
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 'mark', the resource 'payment voucher', and the status 'paid'. It also specifies side effects: posting to budget items and refreshing requisition status. This distinguishes it from siblings like 'limu_review_payment_voucher' (review/approve) and 'limu_get_payment_voucher' (read).
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 voucher is 'management-approved' but does not explicitly state when to use this tool vs. alternatives like 'limu_review_payment_voucher' (prerequisite) or how to handle errors. No exclusions or when-not-to guidance is 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?
Annotations indicate the tool is not read-only and not destructive, and the description adds the confirm/dryRun behavior which is critical. However, it does not disclose other behavioral traits like atomicity, side effects, or error states, leaving gaps in understanding the full behavior.
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 exceptionally concise with two sentences: the first states the purpose, and the second provides critical execution instructions. No wasted words, and the most important information is front-loaded.
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 complexity (26 parameters, no output schema), the description covers core behavior and the confirm/dryRun mechanism but omits details like prerequisites, return values, error conditions, and handling of partial updates. It is sufficient for basic use but incomplete for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It only mentions 'confirm' and 'dryRun' parameters, ignoring 24 others. While many parameter names are self-explanatory (e.g., firstName), others like 'includeAssociatedData' or 'clearEmail' lack explanation, forcing the agent to rely on names alone.
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 'Update' and the resource 'editable LIMU client profile fields in the Clients table,' which distinguishes it from sibling tools like get_client or get_clients. The specific reference to the table and profile fields makes 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear execution guidance on using 'confirm=true' for real writes and 'dryRun=true' for previews. However, it does not specify when to use this tool versus alternatives, such as when to update vs. use other tools for related operations. It lacks explicit when-not-to-use or alternative strategies.
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?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that the tool returns packages, collection details, and recent log events, which is useful behavioral context beyond 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?
Single sentence front-loaded with the tool's purpose. No extraneous 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?
Tool has 4 parameters and no output schema. Description mentions return content vaguely but does not explain how parameters affect results. Agent lacks info to correctly set optional parameters or understand output shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. Description does not explain any parameters or their effects, leaving the agent to infer how logLimit, includeLogs, packageLimit control output. Schema provides defaults and ranges, but description adds no additional meaning.
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 clearly states it retrieves one cargo record with related data. The verb 'Get' and resource 'cargo record' are specific. It distinguishes from sibling 'limu_list_cargo' which retrieves multiple records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for single cargo retrieval but does not explicitly state when to use versus alternatives or provide exclusions. Sibling tools suggest a divide between get and list, but no direct guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, making the safety profile clear. Description adds behavioral detail on returned data (approval stage, items, voucher spend totals) beyond annotations, but does not cover all nuances like pagination behavior.
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 fluff, front-loaded with verb and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite annotations providing safety context, the description omits critical details such as pagination (limit/offset), filtering options (stage, status, search, dates), and output structure. For a tool with 9 parameters and no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter meanings or usage. With 9 unannotated parameters, the description fails to compensate for the lack of parameter documentation.
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 clearly states the verb 'list' and the resource 'finance requisitions', specifying the data returned (approval stage, items, voucher spend totals). This distinguishes it from other list tools and provides a clear purpose.
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 vs alternatives like limu_get_requisition or other list tools. Implied usage from name and description, but lacks explicit context or exclusions.
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?
Annotations already indicate write behavior (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds workflow context (management-approved state, finance marks paid separately) but omits details about decline effects, dryRun behavior, or confirm requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Every word adds value, clearly conveying the tool's action and its place in the workflow.
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?
While the description covers the primary action, it lacks details on return values (no output schema) and optional parameters (dryRun, confirm, reason) that are critical for proper usage. The 6-parameter complexity is not adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does not. Parameters like dryRun, confirm, and reason are left unexplained, leaving the agent to guess their purpose and required format.
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 approves or declines a payment voucher, with a specific verb ('Approve or decline') and resource ('submitted payment voucher'). It distinguishes from the sibling tool 'limu_mark_payment_voucher_paid' by explaining the workflow separation.
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 implies when to use (for the approval step) and notes that finance handles payment separately, guiding the agent to the correct sibling. However, it does not explicitly state when not to use or mention prerequisites like voucher state.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, ensuring the agent knows it's a safe read operation. The description adds value by stating that the response includes 'units and stage checks', which is additional behavioral context beyond the annotations. There are no contradictions.
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, 14-word sentence that immediately conveys the core action and key details. It is front-loaded and contains no redundant information, achieving maximum 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?
While the tool is a simple read operation with good annotations, the description does not explain what 'stage checks' are, what units represent, or the structure of the response. Since there is no output schema, additional clarity would help the agent understand the returned data. The description covers basic usage but lacks detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in the schema), so the description must compensate. It mentions 'by id or code' (covering packageId and packageCode) and 'including units' (hinting at includeUnits and unitLimit), but does not explicitly define each parameter's purpose, default, or constraints. For 4 parameters, this is insufficient.
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 a cargo package by id or code, including units and stage checks. It uses a specific verb ('Get') and distinguishes from sibling tools like limu_get_cargo (which gets cargo) and limu_get_shipment.
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 two identifiers (id or code) but does not provide explicit guidance on when to choose one over the other, nor does it differentiate from alternatives like limu_list_packages or explain prerequisites. Usage context is only implied.
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?
Annotations already indicate destructiveHint=true. The description adds the valuable two-step dry-run/confirm process, going beyond the annotation to inform safe usage. It does not, however, detail other behaviors like irreversibility or cascading effects beyond items/proof rows.
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 that front-load the core action and then provide essential usage guidance. Every word serves a purpose, with no redundancy.
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 tool has 5 parameters and no output schema, the description fails to document required parameters (voucherId, actorId) and the optional reason field. The workflow is explained, but parameter meanings are missing, leaving the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains dryRun and confirm but omits voucherId, actorId, and reason. Users must infer or assume their purposes from context, which is insufficient.
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 deletes a submitted or declined payment voucher and its associated items/proof rows. This verb+resource+scope specification effectively distinguishes it from sibling tools that review or mark paid.
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 advises using dryRun=true first and confirm=true for actual deletion, providing a clear usage workflow. However, it does not explicitly state when not to use this tool or list alternatives among siblings.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying that the response includes items, logs, and linked payment vouchers. No contradictions observed.
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 with no unnecessary words. It is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (get one requisition by ID) and lack of output schema, the description adequately covers the return content (items, logs, linked vouchers). However, it could clarify the role of logLimit and includeLogs parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the tool description must compensate. The description does not explain parameters (requisitionId, includeLogs, logLimit) beyond what the schema provides. It mentions logs are included but not how includeLogs and logLimit control them.
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 'Get' and resource 'requisition', and specifies included sub-resources 'items, logs, and linked payment vouchers'. It distinguishes from listing tools like limu_list_requisitions and other 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 description implies use when a single requisition with details is needed, but does not explicitly state when to use vs alternatives or provide exclusion criteria. Siblings like limu_list_requisitions for listing and other get tools for different resources are not mentioned.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds value by detailing the specific data returned (cargo summary, calendar, budget, updates), providing behavioral context beyond the annotations. No contradictions noted.
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, clear sentence with no extraneous information. It is efficiently front-loaded with the core 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 that this is a simple get operation with no output schema, the description adequately summarizes what is returned. However, it could mention that logs and cargo are optional via parameters, which would improve completeness for agents configuring calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the burden of explaining parameters. However, it does not mention any parameter (e.g., what 'logLimit' or 'includeLogs' control). The parameter names are self-evident, but the description should at least clarify how they affect the returned data.
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 explicitly states the action ('Get one shipment') and specifies the included data ('cargo summary, calendar entries, budget summary, and recent updates'). It clearly distinguishes from sibling tools like 'limu_list_shipments' (which lists multiple) and other get tools focusing on subsets.
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?
While it is implied that this tool is used when detailed information about a specific shipment is needed, the description does not explicitly state when to use it over alternatives or provide exclusions. No guidance is given for context selection.
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?
Annotations already indicate destructiveHint=true, and the description adds behavioral context: it deletes requisition items/logs and only works when no linked payment vouchers, plus the confirm/dryRun workflow. This adds useful information beyond the 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?
Two sentences, no wasted words. Highly efficient and front-loaded with the key action and conditions.
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 explains the core workflow and condition, but given 5 parameters with no schema descriptions and no output schema, it lacks details on required parameters (requisitionId, actorId) and behavior on errors or edge cases. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the purpose of confirm and dryRun parameters but does not mention requisitionId, actorId, or reason. Only 2 of 5 parameters are covered, leaving significant gaps.
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 'delete' and the resource 'requisition', specifies that it also deletes items and logs, and adds a condition (no linked payment vouchers). This distinguishes it from sibling tools like limu_delete_payment_voucher.
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 explicit guidance on when to use the tool and the safe procedure: 'Requires confirm=true for real deletes; use dryRun=true first.' It does not mention alternatives or when not to use it, but the context is clear.
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?
The description explains the need for confirm=true to actually perform writes and the availability of dryRun for preview. This adds behavioral context beyond the annotations, which only indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. No contradiction with 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 two sentences, front-loading the purpose and then providing usage guidance. Every sentence adds value without 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?
The description covers the core action and key parameters (confirm/dryRun) but omits details about the optional note parameter, return values (no output schema), or any prerequisites. For a tool with 7 parameters and no output schema, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only explains confirm and dryRun parameters. The other five parameters (applicationId, stage, decision, actorId, note) are not described. Given the low coverage, the description should provide more parameter guidance.
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 (approve or decline), the resource (leave application), and the specific stages (admin or management). It effectively distinguishes from sibling tools like limu_review_payment_voucher by specifying the resource.
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 for using confirm and dryRun parameters. It explains when to use each, but does not explicitly state when not to use this tool or mention alternatives.
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?
Beyond annotations (destructiveHint=true), the description adds that writes require confirmation, implying a two-phase commit and that dryRun is safe. This is valuable behavioral context. It also summarizes the five action types, though it doesn't detail per-action effects.
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 only two sentences, both front-loaded with the purpose and the critical workflow. Every word adds value—no filler or 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?
The tool has 8 parameters, 5 actions, and no output schema. The description covers the action categories and the confirm/dryRun workflow but omits dependencies between parameters and actions. For a complex tool, more detail on valid parameter combinations per action would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It mentions 'set or clear a monthly budget purchase date' (implying scheduleDate) and 'add/update/delete split rows' (implying splitId and scheduledAmount), but does not specify which parameters are needed for which action. The enum for action is explicit in the schema, but the description lacks parameter-to-action mapping, leaving the agent to infer.
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 specific actions: setting/clearing a monthly budget purchase date and adding/updating/deleting split purchase schedule rows. It uses strong verbs like 'set', 'clear', 'add', 'update', 'delete' and identifies the resource 'monthly budget purchase date' and 'split purchase schedule rows', distinguishing it from sibling tools that are mainly get/list/review operations.
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 explicit workflow guidance: 'Requires confirm=true for real writes; use dryRun=true first.' This tells the agent to test with dryRun before committing. While it doesn't compare to alternative tools, the sibling list shows no other scheduling tool, so the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds specific context about checking connectivity and reporting tables, which adds value beyond annotations without contradiction.
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 clear sentence front-loading the tool's purpose. No wasted words.
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?
Given no parameters, no output schema, and simple health check purpose, the description is fully complete. It states exactly what the tool does and what it reports.
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?
No parameters, so schema coverage is 100%. Baseline 4 per instructions for zero parameters. Description does not need to add 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 specific verb 'check' and resource 'database connectivity and which LIMU Portal tables are visible', clearly distinguishing from sibling tools that operate on specific entities.
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 versus alternatives, though it is likely unique among siblings. Implied usage for health verification but no exclusion or context.
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:

[![limuMCP MCP server](https://glama.ai/mcp/servers/gochi20/limuMCP/badges/card.svg)](https://glama.ai/mcp/servers/gochi20/limuMCP)

Score Badge

Copy to your README.md:

[![limuMCP MCP server](https://glama.ai/mcp/servers/gochi20/limuMCP/badges/score.svg)](https://glama.ai/mcp/servers/gochi20/limuMCP)

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/gochi20/limuMCP'

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